Re: Problem with seq adjustment for NAT over loopback device

[Pablo Neira Ayuso <pablo@netfilter.org>]

On 29/05/11 20:36, Julian Anastasov wrote:
> 
> 	Hello,
> 
> 	I see a problem that nf_nat_seq_adjust is called twice
> for same packet. I saw it while playing with IPVS NAT forwarding
> over loopback device, it happens for iptables -j DNAT too. For example:
> 
> - I'm adding two addresses: 192.168.1.200 (long) and 192.168.1.2 (short)
> 
> - Adding DNAT rule to redirect local clients to different local server:
> 
> iptables -t nat -A OUTPUT -p TCP -d 192.168.1.200 --dport 21 \
> 	-j DNAT --to-destination 192.168.1.2
> 
> 	Trying passive FTP causes address info in PASV response
> to be mangled in reply direction from 192.168.1.2 to 192.168.1.200
> increasing the payload with 2 bytes. Later, in original direction the
> acks are decreased with 2 but the problem is that it happens
> once in POSTROUTING and second time in LOCAL_IN, i.e. the two places
> where seq adjustment happens in ipv4_confirm. The funny effect is
> that the client receives next response with the "\r\n" (remember,
> 2 bytes) from the PASV response copied before the next 150 response:
> 
> RX: 227 Entering Passive Mode (...)\r\n		<<<- \r\n duplicated
> TX: LIST\r\n
> RX: \r\n150 Directory listing	<<<- extra "\r\n" at beginning
> 
> 	I assume the problem happens because same conntrack is
> used in original direction for the outgoing phase (OUTPUT->POSTROUTING)
> and for the incoming phase (PREROUTING->LOCAL_IN). Looking at
> nf_nat_rule_find() I see that checking with nf_nat_initialized()
> allows only one src and/or one dst manipulation. For traffic
> over loopback I assume these NAT manipulations will be scheduled
> in OUTPUT and POSTROUTING (the outgoing phase) and no NAT
> rules will be considered from the incoming phase (PREROUTING and
> LOCAL_IN). In such case NAT does not occur in the incoming
> phase and we do not need any seq adjustments and NAT manips
> in LOCAL_IN for loopback traffic.
> 
> 	I guess that a skb flag is needed that can be set after
> POSTROUTING, so that we should avoid any SEQ and NAT manipulations
> for the incoming phase if this flag is set. All NAT hooks
> can ignore such packets to save some CPU cycles (NF_ACCEPT in
> nf_nat_fn). By this way, even if a single manipulation is possible
> for two hooks, eg. src manip for POSTROUTING and LOCAL_IN,
> and dst manip for PREROUTING and OUTPUT we should do it only
> once for a packet.
> 
> 	Any ideas how to solve this problem? If such solution
> sounds good I can prepare and test some patch...

I haven't missed this report :-), however, I didn't come with a clean
solution for this yet, let give it some spins.