TFTP cross vlan and TFTP proxy
-
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.240With 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,23with 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.
-
@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.
-
@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.
-
-
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....
-
What pfSense version are you using?
-
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) -
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.
-
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.
-
Yes this is a regression, probably after a change in pf. Bug to track: https://redmine.pfsense.org/issues/16485
-
@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?
-
Yes I reproduced here and asked our devs about it who confirmed the likely cause. Work is in progress.