I hope this post finds you well. I'm reaching out to the community for some expert advice on a persistent issue we've been facing for the past year. Despite multiple tickets with Fortinet support, we haven't been able to identify the root cause or find a lasting solution.
The Problem: Our Canon printers are experiencing frequent disconnections from Uniflow (Print Server). This issue seems to be particularly prevalent after power failures in our remote offices. Interestingly, the printers reconnect after a couple of days or when we change the printer's IP address.
Here's a bit about our network setup:
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Have you found in traffic logs any blocked traffic from printer to print server or vice versa? Make sure the related policies have all traffic log enabled, and implicit deny policy as well.
On the other hand ha e you checked if one of the two devices was listed in quarantine monitor during the issue?
Hi!
Did you find a solution to this?
I have a customer with the somwhat the same issue.
We also noticed that the UDP Traffic from the serve on port 53214 to the printer, is sendt out the server. but when doing a diag sniffer packet, we dont see it at all in the fortigte.
Even after the problem where resolved, and we see 2 waytraffic on the server(Wireshark), but we dont se the UDP traffic from in the diag sniffer packet output.
We do however se other traffic on port 8443 and 8000 between server and printer.
Why do you send UDP to printer?
As per my knowledge printers use TCP for printing.
I dont send UDP to the printer, the server do ;)
Its Uniflow managment traffic, if the server dont get a response, it thinks the printer is offline, and dont reply to userauth messages. Hens, print stops working.
If FG doesn't see UDP traffic from server to printer that means it is stopped somewhere before the FG, e.g.: could be at Windows' firewall level.
If this only occurs after a tunnel failure (due to power outage), it might be that tunneled traffic is sent out of the WAN interface instead of the tunnel IF. Put in a blackhole route for the private address range you use. It will not harm during normal operation but will prevent a session out of the WAN interface which would prevent the correct VPN tunnel session.
We did that, but that alone did not solve it completly.
After Creating the Blackhole routes, AND Disableing Auto-Asic-Offload and NP-Accelleratin on the relevant firewall rules, it seems to have been solved. (At least no issues have been reported the last few weeks)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1468 | |
1006 | |
748 | |
443 | |
206 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.