* NAT problem with related connections @ 2003-10-30 10:31 Nikolai Dahlem 2003-11-03 7:48 ` Harald Welte 2003-11-03 11:12 ` Harald Welte 0 siblings, 2 replies; 7+ messages in thread From: Nikolai Dahlem @ 2003-10-30 10:31 UTC (permalink / raw) To: netfilter-devel Hi, this is (still ;-))my setup: Host1(172.30.8.100) --> Masq(172.30.8.1/10.20.10.213) --> Server(10.20.0.14) <-- Host2(10.20.10.198) A Master connection is established between Host1 and Server. Host1 and Host2 negotiate connection parameters via the Server. Then related data connections are established between Host1 and Host2 directly. The control-connection is established and an expectation is created. The related connections work in some cases, the problem is that NAT changes the source port. example: 1. master connection with one data connection udp 17 3598 src=172.30.8.100 dst=10.20.0.14 sport=5060 dport=5060 src=10.20.0 .14 dst=10.20.10.213 sport=5060 dport=5060 [ASSURED] use=2 udp 17 177 src=10.20.10.198 dst=10.20.10.213 sport=5004 dport=5024 src=172.30 .8.100 dst=10.20.10.198 sport=5024 dport=5004 [ASSURED] use=1 2. master connection with two data connections udp 17 3596 src=172.30.8.100 dst=10.20.0.14 sport=5060 dport=5060 src=10.20.0 .14 dst=10.20.10.213 sport=5060 dport=5060 [ASSURED] use=3 udp 17 138 src=10.20.10.198 dst=10.20.10.213 sport=5004 dport=5024 src=172.30 .8.100 dst=10.20.10.198 sport=5024 dport=5004 [ASSURED] use=1 udp 17 176 src=10.20.10.198 dst=10.20.10.213 sport=5006 dport=5026 src=172.30 .8.100 dst=10.20.10.198 sport=5026 dport=5006 [ASSURED] use=1 3. master connections with two data connections and one with a changed port udp 17 3597 src=172.30.8.100 dst=10.20.0.14 sport=5060 dport=5060 src=10.20.0 .14 dst=10.20.10.213 sport=5060 dport=5060 [ASSURED] use=3 udp 17 103 src=10.20.10.198 dst=10.20.10.213 sport=5004 dport=5024 src=172.30 .8.100 dst=10.20.10.198 sport=5024 dport=5004 [ASSURED] use=1 udp 17 141 src=10.20.10.198 dst=10.20.10.213 sport=5006 dport=5026 src=172.30 .8.100 dst=10.20.10.198 sport=5026 dport=5006 [ASSURED] use=1 udp 17 27 src=172.30.8.100 dst=10.20.10.198 sport=5028 dport=5008 [UNREPLIED] src=10.20.10.198 dst=10.20.10.213 sport=5008 dport=1024 use=1 udp 17 26 src=10.20.10.198 dst=10.20.10.213 sport=5008 dport=5028 [UNREPLIED] src=10.20.10.213 dst=10.20.10.198 sport=5028 dport=5008 use=1 EXPECTING: 4987 use=1 proto=17 src=10.20.10.198 dst=10.20.10.213 sport=5008 dport= 5028 As one can see the expected reply for the 3. data connection has dport=1024, thus the reply send by server (using the negotiated parameters) doesn't establish a connection (thus the expectation isn't met). Is there a way to know/reserve ports that nat uses for a certain connection ? or is there a way to tell nat which port to use ? kind regards Nikolai Dahlem ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT problem with related connections 2003-10-30 10:31 NAT problem with related connections Nikolai Dahlem @ 2003-11-03 7:48 ` Harald Welte [not found] ` <DAELKAPIKOFAFFKELNHOCEAICAAA.Nikolai.Dahlem@epygi.de> 2003-11-03 11:12 ` Harald Welte 1 sibling, 1 reply; 7+ messages in thread From: Harald Welte @ 2003-11-03 7:48 UTC (permalink / raw) To: Nikolai Dahlem; +Cc: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 985 bytes --] On Thu, Oct 30, 2003 at 11:31:19AM +0100, Nikolai Dahlem wrote: > A Master connection is established between Host1 and Server. > Host1 and Host2 negotiate connection parameters via the Server. > Then related data connections are established between Host1 and Host2 > directly. > The control-connection is established and an expectation is created. > The related connections work in some cases, the problem is that NAT changes > the source port. this seems like a bug in your conntrack helper, but without having access to the source I cannot possibly imagine what you are doing. > Nikolai Dahlem -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <DAELKAPIKOFAFFKELNHOCEAICAAA.Nikolai.Dahlem@epygi.de>]
* Re: NAT problem with related connections [not found] ` <DAELKAPIKOFAFFKELNHOCEAICAAA.Nikolai.Dahlem@epygi.de> @ 2003-11-03 11:08 ` Harald Welte [not found] ` <DAELKAPIKOFAFFKELNHOGEAICAAA.Nikolai.Dahlem@epygi.de> 0 siblings, 1 reply; 7+ messages in thread From: Harald Welte @ 2003-11-03 11:08 UTC (permalink / raw) To: Nikolai Dahlem; +Cc: Netfilter Development Mailinglist [-- Attachment #1: Type: text/plain, Size: 1470 bytes --] [Cc'ing netfilter-devel again, without your attachment] On Mon, Nov 03, 2003 at 11:15:40AM +0100, Nikolai Dahlem wrote: > Hi, > > we talked about the implementation of a conntrack-module for SIP @ linuxtag, > maybe you remember ... yes, I do remember the company/domain name 'epygi', but I didn't remember your name. > I attached my code, which I just started working on, so its still very beta, > but at least I managed to make some SIP-calls with it ;-) Main parts are not > implemented: handling of hostnames instead of ips, safely getting > consecutive ports, SIP-state machine, support for 2 SIP-calls with the > sample tuple (2 or more phone on one machine using the same server). > Please tell me what you think of my efforts so far. I have to be honest that I didn't read the code thoroughly. But according to a quick guess, what you are lacking is a call to ip_conntrack_change_expect() from the nat helper. The NAT helper has to alter the expectation raised by conntrack... See the ftp/irc helpers as an example. > kind regards > > Nikolai Dahlem -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <DAELKAPIKOFAFFKELNHOGEAICAAA.Nikolai.Dahlem@epygi.de>]
* Re: NAT problem with related connections [not found] ` <DAELKAPIKOFAFFKELNHOGEAICAAA.Nikolai.Dahlem@epygi.de> @ 2003-11-03 15:39 ` Harald Welte 2003-11-04 13:41 ` Nikolai Dahlem 0 siblings, 1 reply; 7+ messages in thread From: Harald Welte @ 2003-11-03 15:39 UTC (permalink / raw) To: Nikolai Dahlem; +Cc: Netfilter Development Mailinglist [-- Attachment #1: Type: text/plain, Size: 2225 bytes --] On Mon, Nov 03, 2003 at 01:28:29PM +0100, Nikolai Dahlem wrote: > -----Original Message----- > From: Harald Welte [mailto:laforge@netfilter.org] > Sent: Montag, 3. November 2003 12:08 > To: Nikolai Dahlem > Cc: Netfilter Development Mailinglist > Subject: Re: NAT problem with related connections > > On Mon, Nov 03, 2003 at 11:15:40AM +0100, Nikolai Dahlem wrote: > >> we talked about the implementation of a conntrack-module for SIP @ > linuxtag, > >> maybe you remember ... > > >yes, I do remember the company/domain name 'epygi', but I didn't > >remember your name. > I'm the inconspicuous student ;-) > > >I have to be honest that I didn't read the code thoroughly. But > >according to a quick guess, what you are lacking is a call to > >ip_conntrack_change_expect() from the nat helper. The NAT helper has to > >alter the expectation raised by conntrack... > >See the ftp/irc helpers as an example. > > do I have to change the expectation, if I inserted a complete tuple in > conntrack ? a conntrack helper should just insert the tuple provided by the protocol payload (SIP/sdp). The nat helper then changes the protocol payload (i.e. the IP address / port number) inside the master connection, and has to alter the expectation accordingly. > SIP provides all the information, so I thought why not fill the complete > tuple or is this completely wrong ? take the example of FTP (more common, and I already forgot most SIP relevant stuff): client: 1.2.3.4, firewall: 10.20.30.40, ftp-server: 9.9.9.9 packet received: client -> server PORT 1,2,3,4,5,6 - conntrack helper raises expectation 9.9.9.9:any->1.2.3.4:(5<<16 & 6) - nat helper alters packet payload to PORT 10,20,30,40,5,6 - nat helper alters expectation to 9.9.9.9:any->10.20.30.40:(5<<16 & 6) > kind regards > Nikolai Dahlem -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: NAT problem with related connections 2003-11-03 15:39 ` Harald Welte @ 2003-11-04 13:41 ` Nikolai Dahlem 2003-11-04 15:44 ` Harald Welte 0 siblings, 1 reply; 7+ messages in thread From: Nikolai Dahlem @ 2003-11-04 13:41 UTC (permalink / raw) To: Harald Welte; +Cc: netfilter-devel On Mon, Nov 03, 2003 at 01:28:29PM +0100, Nikolai Dahlem wrote: >> -----Original Message----- >> From: Harald Welte [mailto:laforge@netfilter.org] >> Sent: Montag, 3. November 2003 12:08 >> To: Nikolai Dahlem >> Cc: Netfilter Development Mailinglist >> Subject: Re: NAT problem with related connections >> >> On Mon, Nov 03, 2003 at 11:15:40AM +0100, Nikolai Dahlem wrote: >take the example of FTP (more common, and I already forgot most SIP >relevant stuff): >client: 1.2.3.4, firewall: 10.20.30.40, ftp-server: 9.9.9.9 >packet received: client -> server PORT 1,2,3,4,5,6 > - conntrack helper raises expectation 9.9.9.9:any->1.2.3.4:(5<<16 & 6) > - nat helper alters packet payload to PORT 10,20,30,40,5,6 > - nat helper alters expectation to 9.9.9.9:any->10.20.30.40:(5<<16 & 6) Ok, this is understood. Sorry, if I didn't describe my problem properly. What I got is : client 1.2.3.4, firewall: 10.20.30.40, ext. client: 9.9.9.9 (simplified, no SIP-server) client:INIVTE message 1.2.3.4:5000 -> ext.client ext.client: OK message 9.9.9.9:6000 -> client conntrack raises the correct expectations and all client 1.2.3.4:5000 via firewall (changes sport to 1024) -> ext.client 9999:6000 ext.client 9.9.9.9:6000 via firewall -> client 1.2.3.4:5000 connection tracking doesn't see a connection, because the firewall changed the sport to 1024, but ext.client is answering to 6000. So what do you think of raising the expectation after the INVITE packet, instead of after the OK packet. This way I'd be able to rewrite to the correct port, but at this moment there is no info about the ext.client, so what should I enter in the expect-tuple ? kind regards Nikolai Dahlem ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT problem with related connections 2003-11-04 13:41 ` Nikolai Dahlem @ 2003-11-04 15:44 ` Harald Welte 0 siblings, 0 replies; 7+ messages in thread From: Harald Welte @ 2003-11-04 15:44 UTC (permalink / raw) To: Nikolai Dahlem; +Cc: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 2351 bytes --] On Tue, Nov 04, 2003 at 02:41:59PM +0100, Nikolai Dahlem wrote: > So what do you think of raising the expectation after the INVITE packet, > instead of after the OK packet. you don't nee to raise the expectation at that way, but you definitely already need to determine the new 'client' port number and replace it in the packet payload. This is what the ip_nat_pptp.c helper does with the CallID in the OUT_CALL_REQUEST case. However, there is no way to reserve the tuple at that moment. So you can just blindly set it to a random port number, and hope that the full tuple (which you only know after the OK packet arrived) has not been taken at that time. There is no way to recover if the tuple is taken at that point :( With PPTP it's easier, since we don't deal with port numbers, but with GRE key id values (and almost nobody uses GRE, so the probability of a taken tuple is low). > This way I'd be able to rewrite to the correct port, but at this moment > there is no info about the ext.client, > so what should I enter in the expect-tuple ? that is not the problem. You can easily raise an expectation at that point (fill in zweroes and a mask of 0xFF of the part you don't know yet, so it won't match)... you'd then later change the expectation after you've received the OK message from the ext.client. However, the problem I've described above still persists. We'd need some kind of reservation for that. And that is really hard in the SIP case, since all of conntrack works by unique _tuples_. It doesn't have a concept of a unique (srcip,srcport) independent of the destination. We have full symmetric NAT, and thus can use the same (srcip,scrport) to may different destinations at the same time. The only way I see is to restrict the port range of your MASQUERADE or SNAT rule to a certain range, and have some ports guaranteed to be free and usable for SIP NAT bindings. > kind regards > Nikolai Dahlem -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: NAT problem with related connections 2003-10-30 10:31 NAT problem with related connections Nikolai Dahlem 2003-11-03 7:48 ` Harald Welte @ 2003-11-03 11:12 ` Harald Welte 1 sibling, 0 replies; 7+ messages in thread From: Harald Welte @ 2003-11-03 11:12 UTC (permalink / raw) To: Nikolai Dahlem; +Cc: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 891 bytes --] On Thu, Oct 30, 2003 at 11:31:19AM +0100, Nikolai Dahlem wrote: > Is there a way to know/reserve ports that nat uses for a certain > connection ? or is there a way to tell nat which port to use ? yes, by calling ip_conntrack_change_expect() to change the port number of the to-be-expected connection. in the nat helpers expectfn(), you then call ip_nat_setup_info() with a per-proto (l4) range of exactly one port number. the ftp helper shows this for the DNAT case. > kind regards > Nikolai Dahlem -- - Harald Welte <laforge@netfilter.org> http://www.netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-11-04 15:44 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-10-30 10:31 NAT problem with related connections Nikolai Dahlem 2003-11-03 7:48 ` Harald Welte [not found] ` <DAELKAPIKOFAFFKELNHOCEAICAAA.Nikolai.Dahlem@epygi.de> 2003-11-03 11:08 ` Harald Welte [not found] ` <DAELKAPIKOFAFFKELNHOGEAICAAA.Nikolai.Dahlem@epygi.de> 2003-11-03 15:39 ` Harald Welte 2003-11-04 13:41 ` Nikolai Dahlem 2003-11-04 15:44 ` Harald Welte 2003-11-03 11:12 ` Harald Welte
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.