NAT problem with related connections

NAT problem with related connections

[Nikolai Dahlem]

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

Re: NAT problem with related connections

[Harald Welte]

[-- 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 --]

Re: NAT problem with related connections

[Harald Welte]

[-- 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 --]

Re: NAT problem with related connections

[Harald Welte]

[-- 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 --]

Re: NAT problem with related connections

[Harald Welte]

[-- 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 --]

RE: NAT problem with related connections

[Nikolai Dahlem]

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

Re: NAT problem with related connections

[Harald Welte]

[-- 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 --]