Persistent Canon Printer Disconnection Issue with UniFlow and Fortinet Firewall

[faisalvt]

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:

• Branch Fortinet firewall is connected to the HQ Fortinet firewall via an IPsec VPN.
• The print server is located in the HQ.
• The Printers are in our remote offices
• Branch firewall we are using Fortigate101F,81E,61F(Firmware 7.2.4)
• HQ firewall  Fortigate601E(Firmware 7.2.4)
• Branch and HQ firewall are connected over IPsec VPN

[AEK]

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?

[sveinol]

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.

[AEK]

Why do you send UDP to printer?

As per my knowledge printers use TCP for printing.

[sveinol]

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.

[AEK]

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.

[ede_pfau]

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.

[sveinol]

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)

[Nerds]

I believe the issue is primarily on the Uniflow Server end and is related to the MEAP portion of the copiers only.  We have this issue as well, but can still print to the copier, people just cannot login locally/etc.  Can still ping the copier as well. 

We have Fortigate 200f/60f hub/spoke combos v 7.4.xx ADVPN so site to site basically.  Uniflow server is at main site.  When the tunnel goes down people cannot login to the copier locally to scan/copy.  They can still print using uniflow though.  

It seems Uniflow cache's files with the copiers info like IP address/mac address/etc and something is changing when the network goes down that prevents the server from replying to it.  The network itself is fine, but the server rejects the incoming requests. 

What you can do, if that sounds like your exact issue, is to clear the cache on the uniflow server in question:

The workaround solution I have found is that you must remove stale files on the uniflow server.  It seems to 

Cleanup Temporary Files and Junk

1) Login to the uniFLOW server
2) Navigate to the “Admin Services” http://localhost:49580/status.htm
3) Optional: click “Configure Admin Service” and set “Automatically Restart Failed
Services” to “No”
4) Stop each of the services from top to bottom waiting for a Red X before stopping the next
one. If your “MOMSVC” takes a long time to close please open a command prompt with
administrator privileges and enter the following commands (They do kill different tasks):
taskkill -IM DsPcSrv.exe -F
taskkill -IM DsPcSrv.exe /F
5) Navigate to “C:\Program Files (x86)\Common Files\NT-ware Shared\Data” in File
explorer
6) Select the 3 “InactiveJobs.db” Files (-SHM and -WAL) and delete them (These will
rebuild.
7) In the “Temp” Folder, delete anything older than a day but make sure not to delete the
“Requests.dat” file.
8) Clean out the other sub-folders under “Data” (“Scan”, “SDM”, “Spool”,
“Spoolfilestorage”, “SPS”, and “VDP”) as needed
9) Return to the Admin services from Step 2 and starting from the bottom start the services
in order, waiting for the Green “OK” before starting the next service. If you did step 3,
follow the same steps and set it to “Yes”

If that fixes it, then call NT-Ware and complain with us!!!! lol...

[wdbict]

Have you received any response from NT-Ware? We are experiencing exactly the same problem.