[asterisk-users] Understanding NAT Traversal

[Cullin J. Wible]

1) The difference between a web browser using port 80 and SIP on port 5060
is as follows:

- HTTP uses TCP, which maintains state and therfore can be tracked in a NAT
table. SIP uses UDP, which is a stateless protocol, which is more difficult
to track. (This by itself isn't a big deal, since UDP+NAT work well
together).

- The source port for a web browser is random, the destination port is 80.
So you have an random->80 request and 80->random response. In SIP you have a
5060->5060 request and a 5060->5060 response. It is very difficult to track
a a many-to-one NAT (technically port address translation (PAT)) when you
can't change the source or destination ports. For those who have ever had
problems NAT'ing GRE/IPSec VPN's this is the same issue.

2) Responses to new port numbers to a NAT'ed host don't work without special
code on the NAT'ing box. Linux has code to support this for Real Audio,
Quake, FTP, and others. Perhaps someone needs to write the
iptables_sip_helper module.

3) The Upnp network device would be the smame as #2, except that UPNP
doesn't do this type of thing so it's totally irrevelant here.

4) STUN Can help with discovering the external address, but this, combined
with a fixed port PAT is what really causes the underlying issues with SIP
NAT traversal. Additionally, due to the X-OR checksums that are done with
STUN it will only work through 1-level of NAT. >1 Levels of NAT will cause
STUN to determine that its IP address has immediately changed and to
re-fresh and re-register as soon as possible (which could easily bring down
your server, as we have seen).

Conclusions:

If you can eliminate 1/2 of the NAT issue (run asterisk or a SIP proxy on a
public address) you will be able to solve all of your issues. This combined
whith a few settings such as responding to the report port (instaed of
5060), etc (asterisk standard NAT settigns) will do all that you need.

After spending lots of time with all of this: If you're running STUN you're
trying too hard.

Cullin J. Wible


-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of hugolivude
Sent: Tuesday, October 10, 2006 9:12 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Understanding NAT Traversal

Thanks Moj!  The RTP packet problem makes sense.  Still unclear on some of
the other points:

> I think the biggest problem with SIP is the RTP ports.  The initial 
> SIP request goes out (for example) to port 5060, and FROM port 5060 as
well.
>   The response needs to get back to the SIP UA on that port (which 
> would limit the nat router to only be able to deal with ONE internal 
> ua at a time, if they were both using the standard port 5060), which 
> could conceivably happen easily enough.

An Internet browser uses port 80.  I might have two or more behind a NAT
both using port 80.  Isn't that the same thing?

> But in the SIP "handshake" more ports
> are chosen, typically in the 10,000 to 20,000 range.  The NAT router 
> would then need to be configured to direct that anticipated RTP stream 
> to the proper internal client.  That just doesn't happen :)

Hmmm, that makes sense.

> For various reasons, I'm not too partial to UPnP, but maybe there 
> needs to be a SIP UA that uses UPnP to configure a NAT router for it, 
> when an RTP stream is begun?

Not following this part...

> Now the clincher to all of this is that I'm merely talking about the 
> ip packets transferred and their return addresses.  While I'm not 
> qualified or experienced enough to comment on problems that might 
> arise with the contents of the SIP headers themselves, I suspect 
> that's where the REAL trouble lies with SIP NAT traversal.  The SIP UA 
> needs to put the proper return address in the SIP headers before the 
> lower layers of the OSI model take over.  It can't know its 
> externally-visible ip address unless
> A) the user manually enters it or B) it can ask some outside server 
> what it's perceived address is.

Isn't this what a STUN server does?  Sends an HTTP message to SIP UA so that
the SIP UA can strip out the external IP address of the NAT?

Thanks again,
H
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users