Tftp-proxy between two subnets - reply blocked
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: 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?
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
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: 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...
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.