* NAT table bypass for local traffic @ 2010-04-28 17:19 Bill Prochazka 2010-04-28 17:59 ` Steve Fink 0 siblings, 1 reply; 10+ messages in thread From: Bill Prochazka @ 2010-04-28 17:19 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-28 17:19 NAT table bypass for local traffic Bill Prochazka @ 2010-04-28 17:59 ` Steve Fink 2010-04-28 19:46 ` Jan Engelhardt 0 siblings, 1 reply; 10+ messages in thread From: Steve Fink @ 2010-04-28 17:59 UTC (permalink / raw) To: Bill Prochazka; +Cc: netfilter 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-28 17:59 ` Steve Fink @ 2010-04-28 19:46 ` Jan Engelhardt 2010-04-28 20:50 ` Bill Prochazka 0 siblings, 1 reply; 10+ messages in thread From: Jan Engelhardt @ 2010-04-28 19:46 UTC (permalink / raw) To: Steve Fink; +Cc: Bill Prochazka, netfilter 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-28 19:46 ` Jan Engelhardt @ 2010-04-28 20:50 ` Bill Prochazka 2010-04-28 20:55 ` Sven-Haegar Koch 0 siblings, 1 reply; 10+ messages in thread From: Bill Prochazka @ 2010-04-28 20:50 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Steve Fink, netfilter 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. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-28 20:50 ` Bill Prochazka @ 2010-04-28 20:55 ` Sven-Haegar Koch 2010-04-29 6:25 ` ratheesh k 0 siblings, 1 reply; 10+ messages in thread From: Sven-Haegar Koch @ 2010-04-28 20:55 UTC (permalink / raw) To: Bill Prochazka; +Cc: Jan Engelhardt, Steve Fink, netfilter 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-28 20:55 ` Sven-Haegar Koch @ 2010-04-29 6:25 ` ratheesh k [not found] ` <001636c5c15232dea504855f65c2@google.com> 2010-05-01 14:29 ` Pascal Hambourg 0 siblings, 2 replies; 10+ messages in thread From: ratheesh k @ 2010-04-29 6:25 UTC (permalink / raw) To: Sven-Haegar Koch; +Cc: Bill Prochazka, Jan Engelhardt, Steve Fink, netfilter >>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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <001636c5c15232dea504855f65c2@google.com>]
* Re: Re: NAT table bypass for local traffic [not found] ` <001636c5c15232dea504855f65c2@google.com> @ 2010-04-30 6:25 ` ratheesh k 2010-04-30 7:22 ` ratheesh k 2010-05-01 4:23 ` ratheesh k 2 siblings, 0 replies; 10+ messages in thread From: ratheesh k @ 2010-04-30 6:25 UTC (permalink / raw) To: billprozac; +Cc: netfilter >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 >> >> > >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic [not found] ` <001636c5c15232dea504855f65c2@google.com> 2010-04-30 6:25 ` ratheesh k @ 2010-04-30 7:22 ` ratheesh k 2010-05-01 4:23 ` ratheesh k 2 siblings, 0 replies; 10+ messages in thread From: ratheesh k @ 2010-04-30 7:22 UTC (permalink / raw) To: billprozac; +Cc: netfilter, Jan Engelhardt 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 >> >> > >> ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic [not found] ` <001636c5c15232dea504855f65c2@google.com> 2010-04-30 6:25 ` ratheesh k 2010-04-30 7:22 ` ratheesh k @ 2010-05-01 4:23 ` ratheesh k 2 siblings, 0 replies; 10+ messages in thread From: ratheesh k @ 2010-05-01 4:23 UTC (permalink / raw) To: billprozac; +Cc: Jan Engelhardt, netfilter >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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: NAT table bypass for local traffic 2010-04-29 6:25 ` ratheesh k [not found] ` <001636c5c15232dea504855f65c2@google.com> @ 2010-05-01 14:29 ` Pascal Hambourg 1 sibling, 0 replies; 10+ messages in thread From: Pascal Hambourg @ 2010-05-01 14:29 UTC (permalink / raw) To: ratheesh k; +Cc: netfilter 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-05-01 14:29 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-28 17:19 NAT table bypass for local traffic Bill Prochazka
2010-04-28 17:59 ` Steve Fink
2010-04-28 19:46 ` Jan Engelhardt
2010-04-28 20:50 ` Bill Prochazka
2010-04-28 20:55 ` Sven-Haegar Koch
2010-04-29 6:25 ` ratheesh k
[not found] ` <001636c5c15232dea504855f65c2@google.com>
2010-04-30 6:25 ` ratheesh k
2010-04-30 7:22 ` ratheesh k
2010-05-01 4:23 ` ratheesh k
2010-05-01 14:29 ` Pascal Hambourg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).