2

I am using Arch Linux (the 32 bit version) on a Raspberry Pi 3.

When I attempt to add any -j SNAT or -j DNAT rules to iptables, it doesn't work - I receive an error

iptables: No change/target/match by that name

I don't normally have a problem with iptables. For example, the standard INPUT, OUTPUT and FORWARD have plenty of rules. Also, POSTROUTING contains a MASQUERADE rule which is working fine to allow the internal LAN to talk to the internet.

I encountered the SNAT problem while trying to allow internet to send traffic to the public IP to get to a machine on the internal network. When this did not work, I then tried simpler rules and they did not work either. Then I tried to add DNAT rules and had the same problem.

I can add my more complex rules to the PREROUTING and POSTROUTING without specifying the -j DNAT or -j SNAT and then they will add, and the counters will increment.

Below are some examples of the simplest attempts at adding -j SNAT and -j DNAT rules and the errors. No matter what SNAT or DNAT rule I try to add, the error is always the same as that shown below.

[root@hostname ~]# iptables -F PREROUTING -t nat
[root@hostname ~]# iptables -A PREROUTING -t nat -d $public_IP -j DNAT --to-destination $internal_IP
iptables: No chain/target/match by that name.

[root@hostname ~]# iptables -F POSTROUTING -t nat
[root@hostname ~]# iptables -A POSTROUTING -t nat -o teql+ -j SNAT --to-source $public_IP
iptables: No chain/target/match by that name.

Linux details and current -t nat configuration:

[root@hostname ~]# uname -a
Linux hostname.local 4.4.37-1-ARCH #1 SMP Fri Dec 9 19:03:41 MST 2016 armv7l GNU/Linux

[root@hostname ~]# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 18 packets, 1184 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
600 37155 MASQUERADE  all  --  *      teql+   0.0.0.0/0            0.0.0.0/0
[root@hostname ~]#

Here is a list of loaded Kernel modules that maybe relevant in case it helps:

[root@hostname ~]# lsmod | grep ip
ipt_REJECT              1543  142
nf_reject_ipv4          3223  1 ipt_REJECT
ipt_MASQUERADE          1223  1
nf_nat_masquerade_ipv4  2893  1 ipt_MASQUERADE
iptable_nat             1812  1
nf_nat_ipv4             5573  1 iptable_nat
nf_nat                 15506  2 nf_nat_ipv4,nf_nat_masquerade_ipv4
nf_conntrack_ipv4      13768  7
nf_defrag_ipv4          1684  1 nf_conntrack_ipv4
nf_conntrack          101220  5 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_ipv4
iptable_filter          1665  1
ip_tables              12280  2 iptable_filter,iptable_nat
x_tables               17670  5 ip_tables,ipt_MASQUERADE,xt_conntrack,iptable_filter,ipt_REJECT
ipv6                  370087  20
bao7uo
  • 1,704
  • 12
  • 24

2 Answers2

1

In Arch xt_nat is not loaded by default.

This is fixed with:

modprobe xt_nat
echo "xt_nat >> /etc/modules-load.d/iptables.conf"
Stuart Cardall
  • 610
  • 5
  • 8
0

So I figured this out eventually.... it turns out that the xt_nat Linux kernel module needs to be loaded. Running the following command to load that module fixed the problem immediately.

insmod /lib/modules/`uname -r`/kernel/net/netfilter/xt_nat.ko.gz

To try to figure out what was going on I then decided to reboot the Pi. The xt_nat module loaded at boot and iptables was still working properly - allowing the rules to be added.

So although I'm not sure how the module got unloaded (seeing as it was already supposed to be loading at boot time), at least it is working now. In theory, the problem shouldn't recur now because the module can't be unloaded while a -j DNAT or -j SNAT rule exists.

bao7uo
  • 1,704
  • 12
  • 24