NAT table bypass for local traffic

NAT table bypass for local traffic

[Bill Prochazka]

So, I have an interesting observation.  I am doing some wonky fun
stuff with iptables and have noticed that traffic generated by a host
on an existing connection, is bypassing the NAT table for processing.
I ran netcat listenening on a host and log all traffic on the OUTPUT
and POSTROUTING chains.  When I connect from another host, the traffic
is not processed by those chains.  However, if I initiate a connection
from that host, the chains are processed appropriately.  Is this by
design or is this a bug?  The traffic does pass through the mangle
table, just not the NAT table.  Anyone ever encounter something like
this?  I have verified this on both CentOS 5.4 (2.6.18) and busybox
(2.6.27).

Bill

Re: NAT table bypass for local traffic

[Steve Fink]

I probably shouldn't be responding, knowing as little as I do about
such things, but I believe this is by design. The nat table only gets
a crack at packets that initiate a connection -- as in, do not yet
exist in the connection tracking tables. This is true even of UDP
packets, because connection tracking heuristically assigns those to
connections based on observed IP,port pairs and the traffic pattern.

If you want to see those packets in the nat table, you have a number
of options: (1) figure out how to do what you want on a connection
basis and make sure you have everything set up before any connections
are established; (2) install conntrack-tools and do a conntrack -F to
flush out tracked connections, so you'll get one packet from each
connection through the nat table; or (3) add a rule to the raw table
that bypasses connection tracking via the NOTRACK target.

From the iptables manpage, in the description of the nat table: "This
table is consulted when a packet that creates a new connection is
encountered."

I don't know what mechanism makes related packets in an established
connection follow the translation actions set up by the initial
packets. There's a magic sheep bit in there somewhere.

On Wed, Apr 28, 2010 at 10:19 AM, Bill Prochazka <billprozac@gmail.com> wrote:
> So, I have an interesting observation.  I am doing some wonky fun
> stuff with iptables and have noticed that traffic generated by a host
> on an existing connection, is bypassing the NAT table for processing.
> I ran netcat listenening on a host and log all traffic on the OUTPUT
> and POSTROUTING chains.  When I connect from another host, the traffic
> is not processed by those chains.  However, if I initiate a connection
> from that host, the chains are processed appropriately.  Is this by
> design or is this a bug?  The traffic does pass through the mangle
> table, just not the NAT table.  Anyone ever encounter something like
> this?  I have verified this on both CentOS 5.4 (2.6.18) and busybox
> (2.6.27).
>
> Bill
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: NAT table bypass for local traffic

[Jan Engelhardt]

On Wednesday 2010-04-28 19:59, Steve Fink wrote:
>
From the iptables manpage, in the description of the nat table: "This
>table is consulted when a packet that creates a new connection is
>encountered."
>
>I don't know what mechanism makes related packets in an established
>connection follow the translation actions set up by the initial
>packets. There's a magic sheep bit in there somewhere.

A ct entry with mappings already exists when a related packet shows up, 
so there is no need to do a relookup in the table.

Re: NAT table bypass for local traffic

[Bill Prochazka]

Steve,
Thanks for the info.  I have been playing around with it and that
helped...a little.  I played around with the raw table and found that
that fixed the issue of traversing the nat table for related
connections, but it does not fix the initial problem when acks are not
properly dealt with.  A more simple example is that ICMP echo requests
go out the nat table's output chain, but ICMP echo replies do not.

Bill

On Wed, Apr 28, 2010 at 3:46 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Wednesday 2010-04-28 19:59, Steve Fink wrote:
>>
> >From the iptables manpage, in the description of the nat table: "This
>>table is consulted when a packet that creates a new connection is
>>encountered."
>>
>>I don't know what mechanism makes related packets in an established
>>connection follow the translation actions set up by the initial
>>packets. There's a magic sheep bit in there somewhere.
>
> A ct entry with mappings already exists when a related packet shows up,
> so there is no need to do a relookup in the table.
>

Re: NAT table bypass for local traffic

[Sven-Haegar Koch]

On Wed, 28 Apr 2010, Bill Prochazka wrote:

> A more simple example is that ICMP echo requests
> go out the nat table's output chain, but ICMP echo replies do not.

The incoming ICMP echo-request (should be visible in PREROUTING) sets up 
a conntrack entry, the outgoing echo-reply matches to it and thus does 
not show up in nat OUTPUT/POSTROUTING.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

Re: NAT table bypass for local traffic

[ratheesh k]

 >>the outgoing echo-reply matches to it and thus does
> not show up in nat OUTPUT/POSTROUTING.

Does echo reply will show up in nat PREROUTING chain ?

Thanks,
Ratheesh

On Thu, Apr 29, 2010 at 2:25 AM, Sven-Haegar Koch <haegar@sdinet.de> wrote:
> On Wed, 28 Apr 2010, Bill Prochazka wrote:
>
>> A more simple example is that ICMP echo requests
>> go out the nat table's output chain, but ICMP echo replies do not.
>
> The incoming ICMP echo-request (should be visible in PREROUTING) sets up
> a conntrack entry, the outgoing echo-reply matches to it and thus does
> not show up in nat OUTPUT/POSTROUTING.
>
> c'ya
> sven-haegar
>
> --
> Three may keep a secret, if two of them are dead.
> - Ben F.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Re: NAT table bypass for local traffic

[ratheesh k]

>On Thu, Apr 29, 2010 at 6:07 PM,  <billprozac@gmail.com> wrote:
> The echo-reply does not.

Is icmp different from other protocol packets ?

My understanding is  : - { In a router }  whenever a packet hits
PREROUTING  chain , a tuple is created  and state is made NEW by
conntrack module . When the packet goes out of POSTROUTING chain,
install  original and reply direction tuples in hash table . When
reply packet comes back and hits PREROTUING chain , state is made
ESTABLISHED .

So , in icmp , whenever request goes out itself  , state will be made
ESTABLISHED ???

Thanks,
Ratheesh

On Thu, Apr 29, 2010 at 6:07 PM,  <billprozac@gmail.com> wrote:
> The echo-reply does not.
>
> On Apr 29, 2010 2:25am, ratheesh k <ratheesh.ksz@gmail.com> wrote:
>>  >>the outgoing echo-reply matches to it and thus does
>>
>> > not show up in nat OUTPUT/POSTROUTING.
>>
>>
>>
>> Does echo reply will show up in nat PREROUTING chain ?
>>
>>
>>
>> Thanks,
>>
>> Ratheesh
>>
>>
>>
>> On Thu, Apr 29, 2010 at 2:25 AM, Sven-Haegar Koch haegar@sdinet.de> wrote:
>>
>> > On Wed, 28 Apr 2010, Bill Prochazka wrote:
>>
>> >
>>
>> >> A more simple example is that ICMP echo requests
>>
>> >> go out the nat table's output chain, but ICMP echo replies do not.
>>
>> >
>>
>> > The incoming ICMP echo-request (should be visible in PREROUTING) sets up
>>
>> > a conntrack entry, the outgoing echo-reply matches to it and thus does
>>
>> > not show up in nat OUTPUT/POSTROUTING.
>>
>> >
>>
>> > c'ya
>>
>> > sven-haegar
>>
>> >
>>
>> > --
>>
>> > Three may keep a secret, if two of them are dead.
>>
>> > - Ben F.
>>
>> > --
>>
>> > To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>
>> > the body of a message to majordomo@vger.kernel.org
>>
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> >
>>

Re: NAT table bypass for local traffic

[ratheesh k]

On Thu, Apr 29, 2010 at 6:07 PM,  <billprozac@gmail.com> wrote:
> The echo-reply does not.
>
> On Apr 29, 2010 2:25am, ratheesh k <ratheesh.ksz@gmail.com> wrote:
>>  >>the outgoing echo-reply matches to it and thus does
>>
>> > not show up in nat OUTPUT/POSTROUTING.
>>
>>
>>
>> Does echo reply will show up in nat PREROUTING chain ?
>>
>>
>>
>> Thanks,
>>
>> Ratheesh
>>
>>

Is icmp different from other protocol packets ?

My understanding is  : - { In a router }  whenever a packet hits
PREROUTING  chain , a tuple is created  and state is made NEW by
conntrack module . When the packet goes out of POSTROUTING chain,
install  original and reply direction tuples in hash table . When
reply packet comes back and hits PREROTUING chain , state is made
ESTABLISHED .

So , in icmp , whenever request goes out itself  , state will be made
ESTABLISHED ???

Thanks,
Ratheesh



>>
>> On Thu, Apr 29, 2010 at 2:25 AM, Sven-Haegar Koch haegar@sdinet.de> wrote:
>>
>> > On Wed, 28 Apr 2010, Bill Prochazka wrote:
>>
>> >
>>
>> >> A more simple example is that ICMP echo requests
>>
>> >> go out the nat table's output chain, but ICMP echo replies do not.
>>
>> >
>>
>> > The incoming ICMP echo-request (should be visible in PREROUTING) sets up
>>
>> > a conntrack entry, the outgoing echo-reply matches to it and thus does
>>
>> > not show up in nat OUTPUT/POSTROUTING.
>>
>> >
>>
>> > c'ya
>>
>> > sven-haegar
>>
>> >
>>
>> > --
>>
>> > Three may keep a secret, if two of them are dead.
>>
>> > - Ben F.
>>
>> > --
>>
>> > To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>
>> > the body of a message to majordomo@vger.kernel.org
>>
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> >
>>

Re: NAT table bypass for local traffic

[ratheesh k]

>On Thu, Apr 29, 2010 at 6:07 PM,  <billprozac@gmail.com> wrote:
> The echo-reply does not.
>
> On Apr 29, 2010 2:25am, ratheesh k <ratheesh.ksz@gmail.com> wrote:
>>  >>the outgoing echo-reply matches to it and thus does
>>
>> > not show up in nat OUTPUT/POSTROUTING.
>>
>>
>>
>> Does echo reply will show up in nat PREROUTING chain ?
>>
>>
>>
>> Thanks,
>>
>> Ratheesh

Is icmp different from other protocol packets ?

My understanding is  : - { In a router }  whenever a packet hits
PREROUTING  chain , a tuple is created  and state is made NEW by
conntrack module . When the packet goes out of POSTROUTING chain,
install  original and reply direction tuples in hash table . When
reply packet comes back and hits PREROTUING chain , state is made
ESTABLISHED .

So , in icmp , whenever request goes out itself  , state will be made
ESTABLISHED ???

Thanks,
Ratheesh

Re: NAT table bypass for local traffic

[Pascal Hambourg]

Hello,

ratheesh k a écrit :
> 
> Does echo reply will show up in nat PREROUTING chain ?

No.
If conntrack saw the echo request and the related "connection" exists,
then the echo reply is in the ESTABLISHED state and by-passes the nat
chains.
If conntrack did not see the echo request or the related "connection"
was further deleted or expired, then the echo reply is in the INVALID
state and by-passes the nat chains too.