[SOLVED] NAT Puzzle: What's going on here?

Question

I recently ran into some very unexpected behavior involving package dependencies, iptables, and NAT.  Just in case this is an issue, here is my network topology:
   {Internet} --- Netgear WNDR3700  ------ (eno1)
                            router w/ NAT                      |
                                                               |  Arch Server |
                                                                       |
                                                                 (enp2s0) ----------- Netgear GS105 ------------------ [Test machine]
                                                                                                     Switch
and here are the profiles for the ethernet ports on the Arch server:
Description='A basic static ethernet connection'
Interface=eno1
Connection=ethernet
IP=static
Address=('192.168.1.5/24')
#Routes=('192.168.0.0/24 via 192.168.1.2')
Gateway='192.168.1.1'
DNS=('192.168.1.1')
Description='A basic static ethernet connection'
Interface=enp2s0
Connection=ethernet
IP=static
Address=('172.18.90.1/24')
I activated both interfaces, intending to start testing nftables, and set up the Test machine with a static address of 172.18.90.2/24 and gateway 172.18.90.1.  I was only expecting to be able to ping 172.18.90.1 from the Test machine with this setup, but was  extremely surprised to learn that I could not only ping any host, but further was able to run a web browser on the test machine with no problems connecting to anywhere.  Somehow the Arch server was doing forwarding and address translation even though I hadn't installed iptables or nftables (yet).
So, it turns out that iptables is a dependency of netctl?
ibis:~iptables$ pactree -r iptables
iptables
..iproute2
..netctl
ibis:~iptables$ pacman -Q iptables
iptables 1.4.21-1
The first question is
Why does  netctl need iptables?
I was quite shocked to see NAT happening without my having done anything to set it up.
But beyond this, the default firewall rules installed with the package  look like this:
ibis:~iptables$ cat /etc/iptables/simple_firewall.rules
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p icmp -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
There's no mention of the NAT table, so presumably there is some kind of default NAT behavior that is being invoked?  This is my second question:
When you install iptables, NAT works by default somehow?
The final mystery is I never started the iptables service; in particular didn't even know that iptables had been installed as a dependency until NAT was magically working.  When I check
systemctl | grep iptables
Nothing comes up.  Third question:
Who/what/why is the iptables service being automatically activated, if indeed this is what is happening?
Edit: I'm an idiot.  See my last comment on this thread for an explanation of why I thought ip forwarding was being enabled without my explicit permission.
Last edited by pgoetz (2014-06-12 10:07:43)

Answer 1

*filter
All the following commands are to be applied to the 'filter' table.
:INPUT DROP [0:0]
The default policy for the INPUT chain is DROP
:FORWARD DROP [0:0]
The default policy for the FORWARD chain is DROP
:OUTPUT ACCEPT [0:0]
The default policy for the OUTPUT chain is DROP
-A INPUT -p icmp -j ACCEPT
ACCEPT all incoming packets of protocol ICMP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ACCEPT all incoming packets that belong to a RELATED or ESTABLISHED connection in the state tracking table.
-A INPUT -i lo -j ACCEPT
ACCEPT any packets that come "in" the loopback interface (lo).
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
REJECT any incoming TCP packets by sending a TCP RST packet.
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
REJECT any incoming UDP packets by sending an ICMP port-unreachable packet.
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
REJECT any other packets by sending an ICMP protocol-unreachable packet.
COMMIT
COMMIT all these rules (above) into the kernel (atomically unloading any existing rules first).
Remember that rules process in order, so TCP packets will get REJECT'ed by the third-last rule, and never get to the second last and last rules.
You've checked ip_forward now, but is the host still forwarding packets? The kernel will NEVER forward packets without ip_forward being != 0.