* Re: UDP connections and Conntrack... [not found] <Pine.LNX.4.33.0401071011330.18324-100000@blackhole.kfki.hu> @ 2004-01-07 13:33 ` Eddahbi Karim 0 siblings, 0 replies; 7+ messages in thread From: Eddahbi Karim @ 2004-01-07 13:33 UTC (permalink / raw) To: netfilter Le mer 07/01/2004 à 10:13, Jozsef Kadlecsik a écrit : > On Tue, 6 Jan 2004, Eddahbi Karim wrote: > > > Ok, so the state of the connection change in the nat table of the OUTPUT > > Chain ? > > Why should the state of the connection change in the nat table? > ^^^^^^^^^^ ^^^ > State changes happen in connection tracking itself. > Conntrack and nat are bound. The connection state change at the nat table of the PREROUTING chain and at the nat table of the OUTPUT chain. Btw Iptables for IPv6 doesn't have any conntrack for the moment ;-). -- -- Eddahbi Karim Phone : (33) (0)6 61 30 57 77 France ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <Pine.LNX.4.33.0401071254170.18324-100000@blackhole.kfki.hu>]
* Re: UDP connections and Conntrack... [not found] <Pine.LNX.4.33.0401071254170.18324-100000@blackhole.kfki.hu> @ 2004-01-07 16:23 ` Eddahbi Karim 2004-01-08 7:22 ` Jozsef Kadlecsik 0 siblings, 1 reply; 7+ messages in thread From: Eddahbi Karim @ 2004-01-07 16:23 UTC (permalink / raw) To: netfilter Le mer 07/01/2004 à 12:57, Jozsef Kadlecsik a écrit : > On Wed, 7 Jan 2004, Eddahbi Karim wrote: > > > The connection state change at the nat table of the PREROUTING chain and > > at the nat table of the OUTPUT chain. > > False. Check the source code. After checking the source code, I can see that the two principals hooks are on these chain. /* Connection tracking may drop packets, but never alters them, so make it the first hook. */ static struct nf_hook_ops ip_conntrack_in_ops = { .hook = ip_conntrack_in, .owner = THIS_MODULE, .pf = PF_INET, .hooknum = NF_IP_PRE_ROUTING, .priority = NF_IP_PRI_CONNTRACK, }; static struct nf_hook_ops ip_conntrack_local_out_ops = { .hook = ip_conntrack_local, .owner = THIS_MODULE, .pf = PF_INET, .hooknum = NF_IP_LOCAL_OUT, .priority = NF_IP_PRI_CONNTRACK, }; Now, I can't really bet these hooks are on the nat table but conntrack and nat are very related. I get the information here : http://iptables-tutorial.frozentux.net/chunkyhtml/statemachine.html There's another explanation here : http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html If I'm wrong, I want to have a proof... > > > Btw Iptables for IPv6 doesn't have any conntrack for the moment ;-). > > There is an experimental code which you can find in the mailing list > archives. It's not in p-o-m yet. > Ok thanks :), -- -- Eddahbi Karim Phone : (33) (0)6 61 30 57 77 France ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: UDP connections and Conntrack... 2004-01-07 16:23 ` Eddahbi Karim @ 2004-01-08 7:22 ` Jozsef Kadlecsik 2004-01-09 7:09 ` Eddahbi Karim 0 siblings, 1 reply; 7+ messages in thread From: Jozsef Kadlecsik @ 2004-01-08 7:22 UTC (permalink / raw) To: Eddahbi Karim; +Cc: netfilter On Wed, 7 Jan 2004, Eddahbi Karim wrote: > After checking the source code, I can see that the two principals hooks > are on these chain. No, it's reversed: the OUTPUT/PREROUTING chains of the nat table are on the (same) hooks. But as the comment says as well: conntrack has got higher priority than nat, so conntrack sees the packet first. > /* Connection tracking may drop packets, but never alters them, so > make it the first hook. */ > static struct nf_hook_ops ip_conntrack_in_ops = { > .hook = ip_conntrack_in, > .owner = THIS_MODULE, > .pf = PF_INET, > .hooknum = NF_IP_PRE_ROUTING, > .priority = NF_IP_PRI_CONNTRACK, > }; > > static struct nf_hook_ops ip_conntrack_local_out_ops = { > .hook = ip_conntrack_local, > .owner = THIS_MODULE, > .pf = PF_INET, > .hooknum = NF_IP_LOCAL_OUT, > .priority = NF_IP_PRI_CONNTRACK, > }; > > Now, I can't really bet these hooks are on the nat table but conntrack > and nat are very related. Yes, nat depends on conntrack. conntrack can be standalone. > I get the information here : > http://iptables-tutorial.frozentux.net/chunkyhtml/statemachine.html > There's another explanation here : > http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html I had sent some corrections to Oskar for the iptables tutorial. I'll look at the second URL as well. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: UDP connections and Conntrack... 2004-01-08 7:22 ` Jozsef Kadlecsik @ 2004-01-09 7:09 ` Eddahbi Karim 0 siblings, 0 replies; 7+ messages in thread From: Eddahbi Karim @ 2004-01-09 7:09 UTC (permalink / raw) To: Jozsef Kadlecsik; +Cc: netfilter Le jeu 08/01/2004 à 08:22, Jozsef Kadlecsik a écrit : > On Wed, 7 Jan 2004, Eddahbi Karim wrote: > [snip] Thanks for these explanations, It's more clear now :). -- -- Eddahbi Karim Phone : (33) (0)6 61 30 57 77 France ^ permalink raw reply [flat|nested] 7+ messages in thread
* UDP connections and Conntrack... @ 2004-01-03 5:04 Eddahbi Karim 2004-01-05 12:33 ` Jozsef Kadlecsik 0 siblings, 1 reply; 7+ messages in thread From: Eddahbi Karim @ 2004-01-03 5:04 UTC (permalink / raw) To: netfilter Hiya, When a client sends an UDP datagram to an UDP server, the connection is ESTABLISHED when the server sends back an UDP datagram and the client sends another UDP datagram or does the connection is ESTABLISHED when the server answer to the first UDP datagram ? For example, is it like that : Client -> DATA -> Server Client <- DATA <- Server Connection ESTABLISHED for the server ! Or Client -> DATA -> Server Client <- DATA <- Server Client -> DATA -> Server Connection ESTABLISHED for the server ! Thanks, -- -- Eddahbi Karim Phone : (33) (0)6 61 30 57 77 France ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: UDP connections and Conntrack... 2004-01-03 5:04 Eddahbi Karim @ 2004-01-05 12:33 ` Jozsef Kadlecsik 2004-01-06 12:35 ` Eddahbi Karim 0 siblings, 1 reply; 7+ messages in thread From: Jozsef Kadlecsik @ 2004-01-05 12:33 UTC (permalink / raw) To: Eddahbi Karim; +Cc: netfilter On Sat, 3 Jan 2004, Eddahbi Karim wrote: > When a client sends an UDP datagram to an UDP server, the connection is > ESTABLISHED when the server sends back an UDP datagram and the client > sends another UDP datagram or does the connection is ESTABLISHED when > the server answer to the first UDP datagram ? > > For example, is it like that : > > Client -> DATA -> Server > Client <- DATA <- Server > > Connection ESTABLISHED for the server ! This one happens in conntrack for UDP. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: UDP connections and Conntrack... 2004-01-05 12:33 ` Jozsef Kadlecsik @ 2004-01-06 12:35 ` Eddahbi Karim 0 siblings, 0 replies; 7+ messages in thread From: Eddahbi Karim @ 2004-01-06 12:35 UTC (permalink / raw) To: netfilter Le lun 05/01/2004 à 13:33, Jozsef Kadlecsik a écrit : > > This one happens in conntrack for UDP. > Ok, so the state of the connection change in the nat table of the OUTPUT Chain ? Thanks for the previous answer :), -- -- Eddahbi Karim Phone : (33) (0)6 61 30 57 77 France ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-01-09 7:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.33.0401071011330.18324-100000@blackhole.kfki.hu>
2004-01-07 13:33 ` UDP connections and Conntrack Eddahbi Karim
[not found] <Pine.LNX.4.33.0401071254170.18324-100000@blackhole.kfki.hu>
2004-01-07 16:23 ` Eddahbi Karim
2004-01-08 7:22 ` Jozsef Kadlecsik
2004-01-09 7:09 ` Eddahbi Karim
2004-01-03 5:04 Eddahbi Karim
2004-01-05 12:33 ` Jozsef Kadlecsik
2004-01-06 12:35 ` Eddahbi Karim
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox