On Wednesday 2019-04-17 13:54, Xiaozhou Liu wrote: >On Wed, Apr 17, 2019 at 10:58:37AM +0200, Jan Engelhardt wrote: > >> 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). > >Allowing ct-less packets out does not help in this situation either. If for >some reason the NAT's ct gets emptied, and some abnormal packets (orphaned >SYN-ACK/FIN) pass through SNAT without NATed, they'd still carry their inner >source IP (e.g. 192.168.X.X) in the header
Well argued. I also failed to notice that the return NF_ACCEPT; statement was in nf_nat_core.c (as opposed to somewhere in general connection tracking). >, which will not be respected outside >of our private network. Hence, although the bad packets are not dropped by NAT, >they can go to the internet but eventually gets dropped somewhere else. Only if SNAT, but SNAT is not the only type of NAT that is possible. Though I cannot think of a sensible use case involving DNAT where forwarding to the original destination is meaningful either. >On the other hand, we see that normal established-state packets can setup ct >info on-the-fly even if NAT's ct gets emptied, This mechanism is part of CT (not NAT), and I am not sure that will work if the packet goes from public to private network (as there is no NAT entry, there is no knowing where it could possibly go).
