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!
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 thePREROUTING
orPOSTROUTING
, so use it in theFORWARD filter
orFORWARD mangle
tables.Additional note:
state
match module is obsolete and removed from the kernel. Actual match is implemented with theconntrack
module. In my opinion, it is better to use it explicitely, so better always use-m conntrack --ctstate ...
rather that-m state
.