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.

  1. 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.

  1. 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?

  • The important keyword is conntrack. And iptables doesn't "add any implicit rules", it's just that established connections get special treatment. I have no idea about official references (kernel source code?), but the effect is easy to test. – dirkt Nov 15 '17 at 22:56
  • @dirkt From the perspective of the filter table it seems like there are implicit rules here, no? Established connections aren't automatically allowed through there, right? Or am I really missing something? – igal Nov 15 '17 at 23:37
  • Well, something additional happens, but I'm not even sure if you can express this something correctly with ipfilter rules, so I'm not sure why you insist on thinking of this something as "additional implicit rules". Think "established connections are tracked, and when the kernel code detects packets belonging to such a connection, they get additional treatment based on the existing rules. This may include evaluating existing rules for the 'reverse' case". – dirkt Nov 16 '17 at 7:17
  • @dirkt I'm not insisting on anything. I'm using the language which was used in the articles I referenced (where they talk about "automatically added inverse rules"). This is in part what motivated my question. I've updated my question to clarify why I find this somewhat confusing. Does my question make more sense now? – igal Nov 16 '17 at 7:34
  • 1
    Note, you can see the currently tracked connections with sudo conntrack -L (package conntrack-tools). – meuh Nov 16 '17 at 14:08

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.

  • It sounds to me like you're just repeating a statement that's already in the body of the question. What I was asking for was a reference to where this is explained in the official documentation. Am I missing something here? – igal Mar 6 '18 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.