Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 1 Posters 2.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tlum
      last edited by

      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.
      1 Reply Last reply Reply Quote 0
      • T
        tlum
        last edited by

        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]
        
        1 Reply Last reply Reply Quote 0
        • T
          tlum
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.