Tftp-proxy between two subnets - reply blocked

tlum

I have tftp servers on one subnet and tftp clients on another subnet. There is no NAT between subnets. I have enabled the tftp proxy, first on the client interface, then the server interface, then on both interfaces. When the tftp proxy is enabled on the client interface you can see the port 69 control channel proxied to the server subnet. However, no matter what I do the data channel on random ports are blocked.

I was under the impression that the tftp proxy was supposed to see the UDP data packets and proxy them, but they are hitting the server side filter and getting dropped.

Apr 28 13:54:06 fw1srvp01 tftp-proxy[6270]: 192.168.6.1:1042 -> 127.0.0.1:6969/192.168.20.250:64345 -> 192.168.20.2:69 "RRQ aastra.tuz"
Apr 28 13:54:06 fw1srvp01 pf: 00:00:01.009915 rule 116.6270.1.2/0(match): pass out on bge0_vlan20: (tos 0x0, ttl 64, id 6804, offset 0, flags [none], proto UDP (17), length 47)
Apr 28 13:54:06 fw1srvp01 pf:     192.168.20.250.64345 > 192.168.20.2.69:  19 RRQ "aastra.tuz" octet
Apr 28 13:54:06 fw1srvp01 pf: 00:00:00.001090 rule 102/0(match): block in on bge0_vlan20: (tos 0x0, ttl 64, id 8655, offset 0, flags [none], proto UDP (17), length 47)
Apr 28 13:54:06 fw1srvp01 pf:     192.168.20.2.36911 > 192.168.6.1.1042: UDP, length 19

is there a way around this?

tlum

Actually, that's a little deceiving. Those firewall messages were taken from the log. They show the client hitting the proxy, the proxy hitting the tftp server, and then strangely, the tftp server replying directly to the client… not to the proxy.

This is not what an actual network trace shows. That shows the proxy hitting the tftp server, the tftp server replying to the proxy, and then the proxy replying with with basically a port filtered ICMP message. This leads me to believe the proxy failed to poke a hole for port 1024 on the 192.168.6.0/24subnet. Maybe I don't understand how the proxy is supposed to work?

14:59:13.550897 IP 192.168.20.250.63864 > 192.168.20.2.69:  19 RRQ "aastra.cfg" octet
14:59:13.552083 IP 192.168.20.2.55788 > 192.168.20.250.63864: UDP, length 516
14:59:13.552141 IP 192.168.20.250 > 192.168.20.2: ICMP 192.168.20.250 udp port 1024 unreachable, length 36

tlum

Still scratching my head. This is the network trace:

BTW, if its not apparent:

tftp client = 192.168.6.1
tftp server = 192.168.20.2
pfSense = 192.168.6.250, 192.168.20.250

17:54:45.032367 IP 192.168.6.1.1024 > 192.168.20.2.69:  19 RRQ "aastra.cfg" octet

17:54:45.037600 IP 192.168.20.250.55680 > 192.168.20.2.69:  19 RRQ "aastra.cfg" octet

17:54:45.041587 IP 192.168.20.2.59077 > 192.168.20.250.55680: UDP, length 516

17:54:45.041627 IP 192.168.20.250 > 192.168.20.2: ICMP 192.168.20.250 udp port 1024 unreachable, length 36

These are the resulting state entries:

PR       DIR SRC                     DEST                    GW                               STATE                AGE       EXP     PKTS    BYTES      AVG RULE
udp      In  192.168.6.1:1024        127.0.0.1:6969          192.168.20.2:69          NO_TRAFFIC:SINGLE       00:00:13  00:00:47        1       47        3    *
udp      Out 192.168.20.250:55680    192.168.20.2:69                                      SINGLE:NO_TRAFFIC   00:00:13  00:00:47        1       47        3    *

This is the pfSense log:

Apr 28 17:54:45 fw1srvp01 tftp-proxy[61869]: 192.168.6.1:1024 -> 127.0.0.1:6969/192.168.20.250:55680 -> 192.168.20.2:69 "RRQ aastra.cfg"
Apr 28 17:54:45 fw1srvp01 pf: 00:00:03.365386 rule 116.61869.1.2/0(match): pass out on bge0_vlan20: (tos 0x0, ttl 64, id 25917, offset 0, flags [none], proto UDP (17), length 47)    192.168.20.250.55680 > 192.168.20.2.69:  19 RRQ "aastra.cfg" octet
Apr 28 17:54:45 fw1srvp01 pf: 00:00:00.004049 rule 102/0(match): block in on bge0_vlan20: (tos 0x0, ttl 64, id 47402, offset 0, flags [none], proto UDP (17), length 544)    192.168.20.2.59077 > 192.168.6.1.1024: UDP, length 516

And this is the tftp-proxy dynamic ruleset in the tftp-proxy anchor:

pass in log quick inet proto udp from 192.168.20.2 to 192.168.6.1 port = 1024 keep state (max 1) rtable 0
pass out log quick inet proto udp from 192.168.20.2 to 192.168.6.1 port = 1024 keep state (max 1) rtable 0
pass out log quick inet proto udp from 192.168.20.250 to 192.168.20.2 port = tftp keep state (max 1) rtable 0

The rule in the tftp-proxy anchor is source -> destination:port , however, the network traffic is source -> tftp-proxy. Granted I don't yet understand how tftp-proxy interacts with the firewall but at first glance it would appear the response traffic to the proxy would be blocked since the rule is written for a response directly to the client… but I don't know if the tftp-proxy hides this detail from the firewall and makes it presence transparent.

ANY help would be greatly appreciated. Thanks...

tlum

Each interface filter set ends with an explicit Block & Log rule, in my case. Apparently the tftp-proxy anchor is inserted after the user rules in the interface filter set. Thus, the block & log rule is hit prior to the pass rule for the tftp-proxy traffic. Eliminating the block and & log rule allows the traffic to pass the tftp-proxy rules but at the expense of not being able to log the blocked traffic on the interface.

I'm not real comfortable with this and will look for some clarification from the developers to understand if this is by design or if its appropriate to issue a bug report.