T/TCP connections not NATed

T/TCP connections not NATed

[Frederik Deweerdt]

Hi,

We're trying to use a home brewed T/TCP stack in addition to Linux plain
SNAT. Everything works as expected, except for the first packet, which
is not NATed. Communication is as follows:

	C		S
1.	SYN*
2.	DATA
3.			SYN/ACK*
4.	ACK*
5.	REST_OF_COM*

[*] The packet is NATed


Our hypothesis du jour, is that packet #2 is not NATed because it is
not currently part of a connection from netfilter point of view. Hence
my questions:
- Does our hypothesis seem you reasonable?
	- If yes, is it possible to tell NAT to ignore the connection
	tracking informations, and NAT all the packets getting out of
	a given interface
	- If not, what do you reckon could be the cause for having the
	#2 packet not NATed?

Thanks,
Frederik

Re: T/TCP connections not NATed

[Pascal Hambourg]

Hello,

Frederik Deweerdt a écrit :
> 
> We're trying to use a home brewed T/TCP stack in addition to Linux plain
> SNAT. Everything works as expected, except for the first packet, which
> is not NATed.

I guess you mean the _second_ packet ?

> Communication is as follows:
> 
> 	C		S
> 1.	SYN*
> 2.	DATA
> 3.			SYN/ACK*
> 4.	ACK*
> 5.	REST_OF_COM*
> 
> [*] The packet is NATed
> 
> 
> Our hypothesis du jour, is that packet #2 is not NATed because it is
> not currently part of a connection from netfilter point of view. Hence
> my questions:
> - Does our hypothesis seem you reasonable?

Yes. A TCP data segment before the end of the 3-way handshake is not 
supposed to happen in standard TCP, so the TCP connection tracking in 
kernel >= 2.6.9 considers such packet as INVALID, and the NAT skips 
INVALID packets. You can check this by logging packets in the INVALID 
state with LOG rules.

> 	- If yes, is it possible to tell NAT to ignore the connection
> 	tracking informations, and NAT all the packets getting out of
> 	a given interface

You cannot tell stateful NAT (iptables NAT) to ignore the connection 
tracking informations because it needs them to work properly. But you 
can try to tell the connection tracking to be less strict with TCP 
connections by setting the kernel parameter 
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal to 1. I suppose 
packet #2 should be seen in the NEW state with this setting, so don't 
drop or reject non-SYN TCP packets which are in the NEW state.