Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: T/TCP connections not NATed
Date: Mon, 04 Dec 2006 15:45:22 +0100	[thread overview]
Message-ID: <45743482.90109@plouf.fr.eu.org> (raw)
In-Reply-To: <20061204082355.GF3136@slug>

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.


      reply	other threads:[~2006-12-04 14:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-04  8:23 T/TCP connections not NATed Frederik Deweerdt
2006-12-04 14:45 ` Pascal Hambourg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45743482.90109@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox