TFTP cross vlan and TFTP proxy

patient0

@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.

rodrigoantunes

@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.

stephenw10

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....

stephenw10

What pfSense version are you using?

rodrigoantunes

@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)

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.

stephenw10

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.

stephenw10

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

rodrigoantunes

@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?

stephenw10

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