TFTP won't cross pfSense: no rule to handel ephemeral ports?

tlum

I'm trying to do PXE boot across pfSense and it's not working. The TFTP request makes it to the server okay, but pfSense rejects the return traffic. The thing is, the TFTP server is just replying to the original source port (2070), but the complaint is an active ICMP Destination Unreachable, Port Unreachable.

What may be important is the TFTP server is not replying from the original destination port (69). The xinetd service listens on port 69 (TFTP), however, I believe that when it accepts the inbound request, it starts the in.TFTP service, which binds to a random port. So the conversation is like this:

69 <- 2070
46539 -> 2070

As long as both machines are on the same segment everyone is happy and the transfer succeeds - clients reply to the last source port they saw, not 69 - but across pfSense acknowledgements don't come back… and I presume that's because it's checking the source port. I'm using CentOS so that TFTP server is```
tftp-hpa 0.49, with remap, with tcpwrappers


So, I'm not using NAT here; all these segments are routable, so I can't see why I'd need TFTP-Proxy. Nor, do I see how I can disable it since once a line has been selected in the combo box it's impossible to deselect the last one. And, while it's not selected on any of the adapters in question, I see evidence of it rewriting traffic in the network traces.

So, I see what is happening, but I don't really know how any of this is really supposed to work.

tlum

So, I've narrowed some tings down:

TFTP definiently uses ephemeral ports. That's not some configuration anomaly, it's expected behavior.
If this were Iptables on CentOS the answer would be ip_conntrack_tftp module, which apparently knows how to properly track the ports in the traffic and dynamically adjust the firewall accordingly, at least in theory.

So, how can TFTP work through pfSense under these conditions?… and is the TFTP-Proxy supposed to help with that?

With the TFTP-Proxy disabled on these interfaces the exchange looks like this:

192.168.4.14:69 <- 192.168.2.177:2072  [Initial request]
102.168.4.14:33526 -> 192.168.2.177:2072  [Acknowledge]

Generates an ICMP Destination Unreachable, Port Unreachable

and this one log entry:

Syslog message: LOCAL0.INFO: Jan 20 17:45:47 filterlog: 170,16777216,,1425503669,lagg0_vlan2,match,block,in,4,0x0,,64,61970,0,none,17,udp,42,192.168.4.14,192.168.2.177,33526,2072,22

With the TFTP-Proxy enabled it rewrites the source address and generates slightly different logging:


[code]192.168.4.14:69 <- 192.168.4.250:50136  [Initial request]
102.168.4.14:59199 -> 192.168.4.250:50136  [Acknowledge]

Generates an ICMP Destination Unreachable, Port Unreachable

and these two log entries:

Syslog message: LOCAL0.INFO: Jan 20 18:19:04 filterlog: 217,2,90185.1,0,lagg0_vlan2,match,pass,out,4,0x0,,64,44778,0,none,17,udp,55,192.168.4.250,192.168.4.14,50136,69,35

Syslog message: LOCAL0.INFO: Jan 20 18:19:04 filterlog: 170,16777216,,1425503669,lagg0_vlan2,match,block,in,4,0x0,,64,43330,0,none,17,udp,42,192.168.4.14,192.168.2.177,59199,2071,22[/code]

tlum

You know it's getting really bad when you spend sleepless nights desperately trying to solve a tough firewall issue, only to eventually find the most useful information in all of the internet ends up being a solution to your exact problem which you yourself wrote four years ago.

https://forum.pfsense.org/index.php?topic=48891.0

The PXE boot still is not working, but the proxy appears to be passing traffic now. I will write this up as a bug/feature this time since I never got any feedback the last time, and then I forgot about it.