0

I'm having some issues with DNAT/SNAT after an upgrade to a newer kernel version. I'm using Fedora 24 as a network firewall and I have a FTP server inside my LAN. The firewall has public and private IP addresses. On the Fedora server, with the kernel 4.6.5-300.fc24.x86_64 the following iptables ruleset works as expected:

    #!/bin/bash

    modprobe iptable_nat
    modprobe nf_conntrack
    modprobe nf_conntrack_ftp
    modprobe nf_nat_ftp

    iptables -P INPUT DROP
    iptables -P FORWARD DROP
    iptables -P OUTPUT ACCEPT

    iptables -F
    iptables -F -t nat
    iptables -X
    iptables -Z

    echo 1 > /proc/sys/net/ipv4/ip_forward
    echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
    echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -t nat -A PREROUTING -d $public_ip -p tcp --dport 21 -j DNAT --to-destination 192.168.0.10:2121

...

    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A FORWARD -d 192.168.0.10 -p tcp --dport 2121 -j ACCEPT

    iptables -t nat -A POSTROUTING -s 192.168.0.10 -p tcp --sport 2121 -j SNAT --to-source $public_ip

    iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.10 -p tcp --dport 2121 -j SNAT --to-source 192.168.0.1

...

The issue only happens when I boot the system with the kernel version 4.10.10-100.fc24.x86_64 (I don't know if other versions between these are affected also).

The problem: users outside my LAN can access and use the FTP service normally with the rules above. The problem affects only users from the LAN who start the FTP connection using a DNS name, which resolves to the public address, so the connection goes back to the LAN and reaches the FTP server. The last line is there so the FTP server doesn't deliver the connection directly to the client.

This only seems to affect FTP connections and additional ports specified in /etc/modprobe.d while loading the nf_conntrack_ftp module (an added rule with port 80, for example, works as excpected). I don't think rp_filter has anything to do with it, because I've disabled it and nothing changed. Also, with iptables LOG I can see the packets travel all the way to the POSTROUTING chain. And while running Wireshark on the FTP server, I checked and confirmed that not one single packet reaches it.

So, my question is: am I doing anything wrong? Is there some new way to do what I need in this kernel version? Or could this be a bug?

Thanks for the help!

Daichi42
  • 55
  • 1
  • 2
  • 6

3 Answers3

0

Recent kernels no longer automatically attach connection tracking helpers based on compiled in port numbers. Instead you have to add specific rules to the raw table to attach those helpers. So for your example I think you need to add something like this:

iptables -t raw -A PREROUTING -d $public_ip -p tcp --dport 21 -j CT --helper ftp

That should also take care of making sure the helper modules are loaded without the explicit modprobe commands.

TomH
  • 1,290
  • 7
  • 10
  • Ok, had the chance to test that, but it seems nothing changed regarding the problem. But in fact, removing the modprobe lines the correct modules were loaded. – Daichi42 May 10 '17 at 20:33
0

Try this,

echo 1 > /proc/sys/net/netfilter/nf_conntrack_helper

This is related with the kernel log,
nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Georgios Syngouroglou
  • 117
  • 5
  • Yes, before trying to load the helper as suggested by TomH I had already tried to use that temporary workaround, but it seems both ways do the same thing, so unfortunately the result was the same. I've even reported it as a bug to netfilter bugzilla with more details. – Daichi42 Oct 06 '17 at 20:40
0

Giving some feedback about this issue, it seems it got fixed in kernel 4.13. Strangely, no feature regarding any netfilter component was reported in the changelog (https://kernelnewbies.org/Linux_4.13). My ruleset which worked on 4.6, stopped up to 4.12 and now it's working again on 4.13 wasn't changed a single line (apart from updating the correct use of helpers, but that was tested and worked on 4.6 too). So, booting on 4.13.9-200.fc26.x86_64 it works, and on 4.12.5-300.fc26.x86_64 it stops.

Daichi42
  • 55
  • 1
  • 2
  • 6