0

I often see that there are some stateful matching rules in a iptables' chain such as INPUT.

I known what they are doing, and I'm interested in that

Should I do the same for the chains of the table NAT?

For example, in my home router, I want it accepts ssh, and also acts as a NAT router.

If we have:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

should I do follows for better performance?

-t nat -A POSTROUTING -m state --state RELATED,ESTABLISHED -j MASQUERADE

-t nat -A POSTROUTING -s 192.168.1.0/24 -o wan0 -m state --state NEW -j MASQUERADE

I guess that I should NOT do the same for the POSTROUTING chain, but should for the FORWARD.

Thanks!

Leon
  • 159
  • 7

1 Answers1

1

No, you don't need that.

Dynamic NAT rules always use conntrack tables. So this is useless (and wrong). The nat table is traversed only by first packet of the connection, so it'll only see --ctstate NEW packets. It never sees --ctstate ESTABLISHED packets, because these don't traverse rules. If the packet is found in the connection tracker nat table, it has the recorded translation applied and proceed with next table.

Connection state consideration appears to be useful in the FORWARD chain, not in the PREROUTING or POSTROUTING, so use it in the FORWARD filter or FORWARD mangle tables.

Additional note: state match module is obsolete and removed from the kernel. Actual match is implemented with the conntrack module. In my opinion, it is better to use it explicitely, so better always use -m conntrack --ctstate ... rather that -m state.

Nikita Kipriyanov
  • 8,033
  • 1
  • 21
  • 39