TCP/IP Printing mangled across subnets
-
Why is traffic ingressing and egressing on the same interface? Do you have mutliple subnets in the same broadcast domain?
-
I'm not sure what you mean by "broadcast domain." Each subnet by nature of layer 3 is its own broadcast domain. The downstream router ahead of the pfSense is in the same broadcast domain as the print server, and the pfSense functions as the head router for the subnets.
-
@shawniverson said in TCP/IP Printing mangled across subnets:
an asymmetric one.
Asymmetrical is always going to be BORKED!!! having multiple vlans on the same interface is not going to be asymmetrical. Having some downstream router sitting on a non transit network for sure is going to be asymmetrical and borked. If you have downstream routers then connect pfsense to them via a transit network.. It could be a vlan sitting on same physical interface as other vlans - but use of transit network will remove asymmetrical problems.
-
Moving the downstream router to its own vlan to create symmetry resolves the issue. I still contend that pfSense should not cause routed traffic to become mangled, even in an asymmetric case.
-
Who said it's mangled? Many services/devices will not function with asymmetrical. And through a firewall you have a problem where states time out, and then traffic gets blocked.
You can not expect anything to work correctly if the traffic is asymmetrical - especially if through a firewall and or local where I send traffic to mac address abc (your gateway) and then get traffic back from a different mac.
Depending on the direction of the traffic its possible the firewall just blocks the answers because it never saw the syn to open the state, etc. The solution is do not do asymmetrical traffic flow.
-
It is mangled because the payload is getting altered in transit. This is apparent with a packet capture. Asymmetric routing does not cause issues on other platforms including my cisco routers. Furthermore, if I disable packet filtering in the original scenario, everything functions as expected, so why is the packet filter still interfering when it and the bypass is enabled, and why does it suddenly stop mangling the packets when the packet filter is disabled? Why is the packet filter even a factor here?
-
Cisco routers are not stateful firewalls. pfSense is, until you disable pf.
http://www.cymru.com/gillsr/documents/icmp-redirects-are-bad.pdf
-
Then what is the point of this setting, and why does it not completely disable packet filtering for this interface and leave the packets unaltered that route via the same interface?
Static Route Filtering
Bypass firewall rules for traffic on the same interface
This option only applies if one or more static routes have been defined. If it is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be desirable in some situations where multiple subnets are connected to the same interface.I agree that a network shouldn't be asymmetric, but the presence of this setting and the unexpected behavior should be cause for some concern.
-
Your design is flawed so your network performance is sub-optimal.
Different clients and network devices treat ICMP redirects differently. Your best bet is to design your network so such hackiness is unnecessary.
-
Boy, you are dense and must not have read my earlier post or you would have realized that I have already redesigned my network.
"Moving the downstream router to its own vlan to create symmetry resolves the issue."
And you are dodging the issue. Static Route Filtering shouldn't be an option in pfSense if it is an unsupported configuration.
-
It is not an unsupported configuration. It can "solve" (or paper over) a great many asymmetric routing cases.
That it does not work for you in your specific case with your specific types of traffic does not mean the feature is broken.
-
So it is supported. Well, then be advised that you cannot TCP/IP print across a Static Route Filtered interface, which results in packet level alterations that interfere with printing as long as the packet filter is enabled.
You did not explain why that is happening or attempt to shed light on it, but with the push-back, I'll leave this here and rest my case.
-
@derelict said in TCP/IP Printing mangled across subnets:
Different clients and network devices treat ICMP redirects differently.
Actually, I did: "Different clients and network devices treat ICMP redirects differently."
Packet capture analysis would be necessary to determine exactly what is breaking the flow.
Good luck.
-
@shawniverson said in TCP/IP Printing mangled across subnets:
where multiple subnets are connected to the same interface.
That is just BORKED design out of the gate as well.. There is one valid reason when you would be running multiple layer 3 on the same layer 2... That is during the migration from 1 address scheme to another address scheme..
Something like running some link-local address space on that layer 3, at the same time as a global address.. But I wouldn't really count this as running 2 L3 on the same wire, since 1 of the address scheme's is only designed to be used on the same layer 2, etc.
-
@shawniverson said in TCP/IP Printing mangled across subnets:
avoid asymmetric configurations....
Told you that 2 months ago.. ;)
-
A packet capture and deep analysis revealed that ICMP redirects were the root cause of the failed print jobs. The printer appeared to not understand these packets. Lesson learned. Hopefully this will serve as a reminder to others to avoid asymmetric configurations....
-
@shawniverson said in TCP/IP Printing mangled across subnets:
The printer appeared to not understand these packets.
As soon as you stray
from the tried and true
You never know
what's going to screw you
burma shave
