Re: Not NATed packets

[Pascal Hambourg <pascal.mail@plouf.fr.eu.org>]

Petr Pisar a écrit :
> 
> and after doing this excercise I can't see any change on counters in 
> POSTROUTING chain. Naturaly I can't see anything in the kernel log (as 
> you can see, I log everything before MASQ and after that).
> 
> I seems, these magic packets are completly bypassing POSTROUTING chain.
> 
> I found out too that TCP traffic goes inside this chain only with first 
> SYN packet. After that there the packets are I don't see them anymore. 
> Is it normal?
> 
> So, I have one workaround. These magic packets are INVALID from point of 
> state module's view.

Connection tracking state is the key to explain all that you observed.
Only NEW packets can create an entry in the connection tracking table 
(which contents can been seen through /proc/net/ip_conntrack) and can go 
through the 'nat' chains. That's why :
- INVALID packets bypass the nat chains, thus aren't NATed nor counted
- only the first NEW packet of a connection, which is usually a SYN in 
TCP connections, goes through the nat chains. Duplicate SYN, although 
NEW too, or subsequent packets belonging (ESTABLISHED) or related 
(RELATED) to the same connection in either direction don't. However all 
get automatically NATed according to the conntrack entry in a way 
determined by how the first packet was NATed.

> 
> I'm not sure if any INVALID packet can also be considered as a health 
> packet. Can you see any false positivities?

Unlike malformed packets which the experimental "unclean" match tries to 
detect, INVALID packets are not "unhealthy" in nature, they're just 
unexpected. And yes, false positive can occur. With kernels older than 
2.4.29, some locally-generated ICMP replies are wrongly considered 
INVALID instead of RELATED.