Implicit Inverses for iptables NAT Rules

Question

Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?

Typically, assuming a DROP policy, for each INPUT rule in the filter table there is a corresponding OUTPUT rule which accepts related or established traffic (and vice versa). For example, to enable inbound SSH to pass through an iptables firewall there would be an INPUT rule to allow incoming connections to be established:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

But there would also be a corresponding OUTPUT rule allowing return traffic:

iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

While this kind of explicit reverse-traffic rule is necessary in the filter table, it seems that this is not the case for the NAT table.

Consider the following excerpts from various unofficial references:

1. Digital Ocean: A Deep Dive into Iptables and Netfilter Architecture

Certain events will cause a table's chain to be skipped during processing. For instance, only the first packet in a connection will be evaluated against the NAT rules. Any nat decisions made for the first packet will be applied to all subsequent packets in the connection without additional evaluation. Responses to NAT'ed connections will automatically have the reverse NAT rules applied to route correctly.

2. SuperUser: Internal working of rules in forward chain for NAT

But netfilter (i.e., the packet filtering/mangling framework that's the 'engine' of iptables) is smart enough. Whenever an incoming [NAT] packet is received, it's matched with netfilter's conntrack table. If the packet is a reply to an existing outgoing connection (ACK flag set, matching IP:port, matching TCP sequence number, etc), netfilter automatically performs DNAT. No need for additional rules.

3. Karl Rupp: NAT Tutorial

Fortunately the netfilter framework automatically adds to each rule its inverse rule, therefore we only have to set one explicit rule. Usually the decision for one of these two rules is made by taking the one with the lower level of undetermination. For example, the rule 'Replace the sender's address for all packets from the local subnet' is much easier than 'if a client has sent something to a server, then replace the receipient in the server's response by something'. As a rule of thumb can be used that the rule that is executed first is the one that is set explicitly in the kernel.

I've perused the official netfilter documentation but I haven't managed to find this behavior mentioned anywhere. Is there an official reference that corroborates the preceding claims?

Answer 1

Does iptables implicitly and automatically add the reverse/inverse rules for every NAT rule that is added explicitly?

Not exactly

Your first two quotes are correct, the third is confused ramblings of someone who doesn't understand how the system works.

iptables nat (unlike iptables filtering) works on connections. The first packet of the connection passes through the nat tables and is translated according to it. Later packets belonging to the same connection do not pass through the nat tables they are simply translated accoridng to the rules established when the first packet was translated.

The iptables man page https://linux.die.net/man/8/iptables documents that the nat table is consulted for "the first packet of a connection" and the man page section for the DNAT and SNAT target say "(and all future packets in this connection will also be mangled)".

Unfortunately I haven't seen any official documentation which goes into more depth than that. My go-to reference for iptables is the frozentux iptables tutorial but I don't think it's official.

Answer 2

The question was already answered but you did ask for a ref to the "official" documentation, this is what I found (was looking for the answer myself).

From the official documentation (2.1. What is Network Address Translation?)

If one of these links were to do NAT, then they would alter the source or destinations of the packet as it passes through. As you can imagine, this is not how the system was designed to work, and hence NAT is always something of a crock. Usually the link doing NAT will remember how it mangled a packet, and when a reply packet passes through the other way, it will do the reverse mangling on that reply packet, so everything works.