Problem with seq adjustment for NAT over loopback device

Problem with seq adjustment for NAT over loopback device

[Julian Anastasov]

	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...

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: Problem with seq adjustment for NAT over loopback device

[Pablo Neira Ayuso]

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.