iptables rules to forward tftp via NAT

Question

I have an embedded Linux device tethered to my PC via Ethernet. The PC is able to access a tftp server via VPN, and I am trying to set up iptables rules to allow the embedded device to access the tftp server.

First of all, I used Network Manager to bring up a connection on the eno1 device, and configured the embedded device on the same (private) network. I can successfully access the web configuration page on the device.

Secondly, I added iptables rules on the PC to forward and NAT traffic to and from the VPN, where 192.168.11.0/24 is the private subnet on the local Ethernet, and the remote tftp server is on the 172.16.0.0/16 subnet via tun0:

-A FORWARD -i eno1 -j ACCEPT
-A FORWARD -o eno1 -j ACCEPT
-A POSTROUTING -s 192.168.11.0/24 -d 172.16.0.0/16 -o tun0 -j MASQUERADE

The device can now access http on the remote server via the VPN, but I have failed to find rules to forward and NAT tftp traffic to the same server. I have manually loaded the following kernel modules (I don't know whether this is necessary):

nf_nat_tftp            16384  0
nf_conntrack_tftp      16384  1 nf_nat_tftp

I have tried every combination of -A FORWARD ... RELATED,ESTABLISHED -j ACCEPT that I could think of (and that the internet suggested), but no joy. My limited understanding is that I need some sort of stateful forwarding rule, but what can I use, please?

Answer 1

Since Linux 4.7 in 2016, the conntrack automatic helper assignment was disabled by default (after having years of warning about this in kernel messages):

Four years ago we introduced a new sysctl knob to disable automatic helper assignment in 72110dfaa907 ("netfilter: nf_ct_helper: disable automatic helper assignment"). This knob kept this behaviour enabled by default to remain conservative.

This measure was introduced to provide a secure way to configure iptables and connection tracking helpers through explicit rules.

While it's easy to revert to the non-secure version, I'd rather provide an answer using the new method using iptables (nftables can do this too, with slight differences in the chain priorities) . The way to do this is documented in this blog: Secure use of iptables and connection tracking helpers.

So following the informations there, this should be done on the router doing NAT:

• big warning:

  The helper module must exist and be able to be auto-loaded before the rule referencing it in the raw table, or the rule addition will fail. This could even prevent an iptables-restore to work correctly and leave a firewall without any rule at boot.

  Anyway the NAT part of the module (here nf_nat_tftp) will not be auto-loaded. So better load this module explicitly at system boot anyway as OP did.

• assuming this is now the default or has been done:

  # sysctl -w net.netfilter.nf_conntrack_helper=0
  

• explicit declaration of helper location, where selectors here mimic those used in OP's POSTROUTING (using the precise and unique IP address of the TFTP server would be better):

  iptables -A PREROUTING -t raw -p udp --dport 69 -s 192.168.11.0/24 -d 172.16.0.0/16 -j CT --helper tftp
  

  This rule alone should now have the helper be activated when adequate, thus triggering the mangling of TFTP data and ports, since TFTP is a complex protocol where server replies can come back from unrelated source ports to the dynamic/ephemeral client source port, as seen in this Wikipedia entry for TFTP.

• explicitly accept generic established traffic, related traffic to tftp, and initial TFTP queries:

  Since you already ACCEPT anything coming from and going to eno1 these rules aren't useful for your current configuration. Should you choose to tighten your firewall rules, here they are. You can choose to make them more or less tight (add interfaces etc.):

  iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
  iptables -A FORWARD -m conntrack --ctstate RELATED -m helper --helper tftp -s 172.16.0.0/16 -d 192.168.11.0/24 -j ACCEPT
  iptables -A FORWARD -s 192.168.11.0/24 -d 172.16.0.0/16 -p udp --dport 69 -j ACCEPT
  

  The 2nd rule authorizes those TFTP-specific reverse connections from the server to the client (hence reversed directions) before replies get them ESTABLISHED. The FORWARD chain sees non-NATed traffic, so it doesn't have to know what happened during MASQUERADE (the tftp helper did intervene there though).