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