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

    TFTP cross vlan and TFTP proxy

    Scheduled Pinned Locked Moved Firewalling
    13 Posts 3 Posters 104 Views 3 Watching
    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.
    • patient0P Offline
      patient0 @rodrigoantunes
      last edited by patient0

      @rodrigoantunes please don't cross post (same post in two different categories).

      I haven't used tftp for some time but I don't see why you would need a proxy for accessing tftp from one VLAN to another. It's UDP/69.

      What firewall rule did you set up to allow the client on vlan1 to access the TFTP server on vlan2? How did you configure the TFTP proxy?

      Edit: it really is a long time and I'm not correct. You do need the tftp proxy.

      R 1 Reply Last reply Reply Quote 0
      • R Offline
        rodrigoantunes @patient0
        last edited by

        @patient0

        this is the rule (it is working, I can see the pass in logs):
        pass in log quick on igVLAN1 inet proto udp from any to 172.17.247.240 port = tftp keep state (if-bound)

        to configure tftp proxy:
        I went to system->advanced->firewall & NAT and then in TFTP Proxy I have chosen the interface for VLAN1.

        Here are some logs:

        client = 192.168.0.1
        tftp server = 172.17.247.240

        With tftproxy disabled:

        <134>1 2025-10-13T13:30:00.671006-03:00 myfw filterlog 78760 - - 393,,,1760104766,bce4.105,match,pass,in,4,0x0,,127,2,0,none,17,udp,59,192.168.0.1,172.17.247.240,2070,69,39
        <134>1 2025-10-13T13:30:00.671086-03:00 myfw filterlog 78760 - - 623,,,1687876028,bce2,match,block,in,4,0x0,,64,32054,0,none,17,udp,43,172.17.247.240,192.168.0.1,38223,2070,23
        <134>1 2025-10-13T13:30:02.701673-03:00 myfw filterlog 78760 - - 393,,,1760104766,bce4.105,match,pass,in,4,0x0,,127,3,0,none,17,udp,59,192.168.0.1,172.17.247.240,2071,69,39
        <134>1 2025-10-13T13:30:02.701714-03:00 myfw filterlog 78760 - - 623,,,1687876028,bce2,match,block,in,4,0x0,,64,1882,0,none,17,udp,43,172.17.247.240,192.168.0.1,48368,2071,23

        with tftp-proxy enabled:

        <134>1 2025-10-13T13:40:15.988324-03:00 myfw filterlog 78760 - - 623,,,1687876028,bce2,match,block,in,4,0x0,,64,26938,0,none,17,udp,43,172.17.247.240,192.168.0.1,33766,2070,23
        <134>1 2025-10-13T13:40:22.054521-03:00 myfw filterlog 78760 - - 623,,,1687876028,bce2,match,block,in,4,0x0,,64,41753,0,none,17,udp,43,172.17.247.240,192.168.0.1,44905,2072,23
        <134>1 2025-10-13T13:40:28.142355-03:00 myfw filterlog 78760 - - 623,,,1687876028,bce2,match,block,in,4,0x0,,64,62212,0,none,17,udp,43,172.17.247.240,192.168.0.1,49716,2073,23

        <30>1 2025-10-13T13:40:15.196990-03:00 myfw tftp-proxy 23982 - - 192.168.0.1:2070 -> 127.0.0.1:6969/172.17.255.254:56621 -> 172.17.247.240:69 "RRQ undionly.kkpxe"
        <30>1 2025-10-13T13:40:21.236232-03:00 myfw tftp-proxy 25012 - - 192.168.0.1:2072 -> 127.0.0.1:6969/172.17.255.254:56663 -> 172.17.247.240:69 "RRQ undionly.kkpxe"
        <30>1 2025-10-13T13:40:27.223318-03:00 myfw tftp-proxy 26290 - - 192.168.0.1:2073 -> 127.0.0.1:6969/172.17.255.254:49329 -> 172.17.247.240:69 "RRQ undionly.kkpxe"

        As you can see the firewall is blocking the ephemeral ports, even with the tftp proxy enabled, if I allow the ports then it works.

        patient0P 1 Reply Last reply Reply Quote 0
        • patient0P Offline
          patient0 @rodrigoantunes
          last edited by

          @rodrigoantunes said in TFTP cross vlan and TFTP proxy:

          It does indeed looks configured correctly, odd.

          As you can see the firewall is blocking the ephemeral ports, even with the tftp proxy enabled

          Are there tftp-proxy anchor rules created by tftp-proxy? Someone with more experience with it has to chime in.

          R 1 Reply Last reply Reply Quote 0
          • R Offline
            rodrigoantunes @patient0
            last edited by

            @patient0 said in TFTP cross vlan and TFTP proxy:

            Are there tftp-proxy anchor rules created by tftp-proxy? Someone with more experience with it has to chime in.

            I don't know how to check this. But when the proxy is enabled you can see the redirects for the port 69 in system.log. And in the filter.log you can see there are no more passes for this port (because it being redirected) but the answers of the server still get blocked.

            1 Reply Last reply Reply Quote 0
            • R rodrigoantunes referenced this topic
            • stephenw10S Offline
              stephenw10 Netgate Administrator
              last edited by

              Check in /tmp/rules.debug
              You should see entries for the TFTP proxy like:

              # TFTP proxy
              rdr-anchor "tftp-proxy/*"
              rdr pass on ix2 proto udp from any to any port tftp -> 127.0.0.1 port 6969
              
              anchor "tftp-proxy/*"
              

              Testing locally though I think I se an issue. Hold on....

              1 Reply Last reply Reply Quote 0
              • stephenw10S Offline
                stephenw10 Netgate Administrator
                last edited by

                What pfSense version are you using?

                R 2 Replies Last reply Reply Quote 0
                • R Offline
                  rodrigoantunes @stephenw10
                  last edited by

                  @stephenw10

                  I can see the anchor:

                  rdr-anchor "tftp-proxy/"
                  rdr pass on bce4.105 proto udp from any to any port tftp -> 127.0.0.1 port 6969
                  anchor "tftp-proxy/
                  "

                  Version:
                  2.8.0-RELEASE (amd64)

                  1 Reply Last reply Reply Quote 0
                  • R Offline
                    rodrigoantunes @stephenw10
                    last edited by rodrigoantunes

                    @stephenw10

                    I can see that according to this site "https://man.freebsd.org/cgi/man.cgi?query=tftp-proxy", after the initial redirect and port negotiation the tftp-proxy should create another rdr rule in the oposite diretion with the new port:

                    "Assuming the TFTP command request is from $client to $server, the proxy
                    connected to the server using the $proxy source address, and $port is
                    negotiated, tftp-proxy adds the following rule to the anchor:

                    rdr proto udp from $server to $proxy port $port -> $client "

                    This second rdr rule is never created in my environment.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S Offline
                      stephenw10 Netgate Administrator
                      last edited by

                      Yup, there seems to be a problem here. We are digging....

                      You should see the rdr and pass rules dynamically added in the anchor like:

                      [2.7.2-RELEASE][admin@cedev-3.stevew.lan]/root: pfSsh.php playback pfanchordrill
                      
                      ipsec rules/nat contents:
                      
                      natearly rules/nat contents:
                      
                      natrules rules/nat contents:
                      
                      openvpn rules/nat contents:
                      
                      tftp-proxy rules/nat contents:
                      
                      tftp-proxy/66783.1 rules/nat contents:
                      rdr inet proto udp from 192.168.59.3 to 172.21.16.148 port = 59844 rtable 0 -> 192.168.85.10 port 23875
                      pass in log quick inet proto udp from 192.168.59.3 to 192.168.85.10 port = 23875 keep state (max 1) rtable 0
                      pass out log quick inet proto udp from 192.168.59.3 to 192.168.85.10 port = 23875 keep state (max 1) rtable 0
                      pass out log quick inet proto udp from 172.21.16.148 to 192.168.59.3 port = tftp keep state (max 1) rtable 0
                      
                      userrules rules/nat contents:
                      

                      But that's not happening in current versions. Works in 2.7.2 as above.

                      R 1 Reply Last reply Reply Quote 0
                      • stephenw10S Offline
                        stephenw10 Netgate Administrator
                        last edited by

                        Yes this is a regression, probably after a change in pf. Bug to track: https://redmine.pfsense.org/issues/16485

                        1 Reply Last reply Reply Quote 0
                        • R Offline
                          rodrigoantunes @stephenw10
                          last edited by

                          @stephenw10 said in TFTP cross vlan and TFTP proxy:

                          You should see the rdr and pass rules dynamically added in the anchor like:

                          I've checked with pfSsh.php playback pfanchordrill, no rules in tftp anchor indeed:

                          cpzoneid_2_auth rules/nat contents:
                          
                          cpzoneid_2_passthrumac rules/nat contents:
                          
                          ipsec rules/nat contents:
                          
                          natearly rules/nat contents:
                          
                          natrules rules/nat contents:
                          
                          openvpn rules/nat contents:
                          
                          tftp-proxy rules/nat contents:
                          
                          userrules rules/nat contents:
                          

                          Did you reproduced the behaviour in your environment?

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S Offline
                            stephenw10 Netgate Administrator
                            last edited by

                            Yes I reproduced here and asked our devs about it who confirmed the likely cause. Work is in progress.

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