Printer (and possibly other things) being blocked by firewall with allow any rule
-
I have a weird problem! I'm in the process of migrating a site from Untangle to pfSense but for some reason the pfsense firewall is interfering with a very specific HP printer on a different subnet that is accessed via a static route to another router which is an issue I never had with Untangle. When I send a print job to this printer through Windows which has the printer mapped with a TCP/IP port the printer receives the job but it just sits there in an error status and has to be manually cancelled out, I have found however that if I completely disable the firewall using "pfctl -d" and kill any active states the print jobs go through like normal. This seems like a fairly straightforward configuration and like I said it was never an issue with Untangle, there's something about the inspection process in the pfSense firewall that is causing an issue.
I've dug through the firewall logs and can not find any evidence of the traffic being blocked and have temporarily added an allow any rule to the top of the rule list for this particular interface with no luck. I have also enabled the "Bypass firewall rules for traffic on the same interface" option under advanced settings > Firewall&NAT with no luck. It should be noted that I can access printers and other devices in the printer network (mainly Kyocera printers) just fine, its this lone HP machine that is having the issue. Please forgive my crappy diagram its from the only software I have access to at this moment....
-
Bump! Sorry I know that was a lengthy post but any help is greatly appreciated!
-
You are asymmetrical with such a design.. If you have a downstream router than you need to connect that downstream router with a transit network... Or you run into this problem..
-
That make sense....so the layout should look more like this updated diagram then, there should be a separate network either via a physical interface or vlan for the printer network traffic right?
-
I guess for testing purposes to eliminate the asymmetric routing I could manually create a route on a windows client machine that looks something like this right?
route add 192.168.60.0 mask 255.255.255.0 192.168.50.254
-
That would take the firewall out of the picture yes, and remove your asymmetrical mess you have... Which should just be corrected vs messing with host routes.
You posted up the same picture - there is no transit network there.
edit: my bad you just left the same routes there pointing to the wrong addresses but looks like you created 192.168.51/30 transit.. Yes that would fix the problem. -
Ah you're right I forgot to correct the routes, my bad. I definitely wouldn't use the host routes as a permanent solution that would just be a way to confirm asymmetrical routing is the cause of the problem. I think it is interesting that Untangle didn't have this issue because the network has been configured this way long before I started working on it, at any rate thanks for your help!
-
untangle does a lot of shit like arp poisoning as a way to work as well ;) Asymmetrical is broken be it your firewall or clients don't complain or not ;)
A smart client might complain even if your stateful firewall did not.. Client might say hey I sent this packet for IP 1.2.3.4 to xyz.. my gateway... Why am I getting answer from mac abc?
So while you could work for a bit in such a setup - once the state expired, and clients now wants to send to printer again.. And firewall no longer has state.. its going to drop the packets.. Printer will never see them until client sends syn again so new state could get created.
Its borked in such a configuration out of the gate.. Connect your downstream routers via transit networks and your don't run into asymmetrical flow or state issues on your stateful firewalls.
-
I wanted to post an update for anyone else that may have a similar issue and stumble across this. My plan for the windows static routes did not work at all, it looked like it did at first but within a couple hours print jobs were hanging again. I ended up having an opportunity over the long Christmas weekend to get into the 3rd party Cisco devices and configure a transport network which (knock on wood) seems to have eliminated the issue. The firewall is up and I've been checking the print logs several times a day and have yet to see any errors or hung jobs so I does indeed look like asymmetric routing was the issue. Thanks @johnpoz for the help!
