On Wednesday 2019-04-17 10:02, Xiaozhou Liu wrote: > > ct = nf_ct_get(skb, &ctinfo); > /* Can't track? It's not due to stress, or conntrack would > * have dropped it. Hence it's the user's responsibilty to > * packet filter it out, or implement conntrack/NAT for that > * protocol. 8) --RR > */ > if (!ct) > return NF_ACCEPT; > >But as normal users, we really want a NAT server which can work out of box as >expected from users' point of view. That depends on the user. NAT already breaks with expectations by messing with the end-to-end principle for instance. >That said, if any packet that is bad (in our case, orphaned SYN-ACK and FIN >packets going out without getting a chance to setup conntrack), it's better to >drop them in kernel by default. I disagree. The ct state may be absent because the firewall has an empty state (e.g. reboot / `conntrack -F`) — that alone does not make the TCP connection invalid. Blocking ct-less packets breaks the user expectation to get a timely response (the more so on connection shutdown). NF_ACCEPT is the proper action, because it mirrors the default policy when the firewall is unconfigured. Pretty much all common acts of dropping, directly or indirectly, are opt-in. >Is there any possibility to change this default behavior? iptables -I FORWARD -m conntrack --ctstate UNTRACKED -j DROP Or better yet, model your ruleset such that --ctstate NEW/ESTABLISHED/$OtherwiseGood -j ACCEPT -P DROP
