[asterisk-users] Understanding NAT Traversal

[hugolivude]

Quick question re. NAT traversal.

I understand how sitting behind a NAT could cause problems for a SIP UA.
The SIP UA would create SIP mesages using IP addresses from inside the
network (i.e. 192.#.#.# or 10.#.#.#) and these IP addresses are of course
unnavigable for the recipient.

What I don't get is why don't web browsers suffer the same problem?

A web brower behind a NAT sends an HTTP request much the same way as a SIP
UA might send an INVITE. However it seems to me that in the case of the Web
Browser, the HTTP request includes the IP address of the NAT and the NAT
takes care of routing the server's response back to the web browser.

So what am I missing here? Why doesn't it work the same way for SIP? Where
does the HTTP / SIP analogy breakdown? Perhaps NATs just take care of HTTP
better than SIP because it's an older protocol (i.e. perhaps NATs replace
the unnavigable IP address with a navigable one for HTTP requests)? Curious
anyway.

Similarly, why do we need a timeout on a SIP registration? Does this work
the same way as a "heartbeat" enabling disconnected UA to be unregistered?

Thanks,
H

[Mojo with Horan & Company, LLC]

I'll take a stab at the first one, but I am probably gonna get nailed
for my own rudimentary understanding of it...

Post by hugolivude
I understand how sitting behind a NAT could cause problems for a SIP
UA. The SIP UA would create SIP mesages using IP addresses from inside
the network (i.e. 192.#.#.# or 10.#.#.#) and these IP addresses are of
course unnavigable for the recipient.
What I don't get is why don't web browsers suffer the same problem?

When the initial http request goes out the packet has a return address
with a source port on the (for example) 192.x.x.x machine. the NAT
router does the same thing, sending it out into the world, with a return
address containing a source port on the NAT router. when it receives a
response, it knows which internal box to route it to, things are OK.
The HTTP server simply sends its reply to that return address, and it's
routed back the way it came.

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. 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 :)

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?

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.

Moj

[Samy Kamkar]

Hi guys,

In addition to the required RTP ports needing to be opened on a NAT
router, the primary difference between HTTP and SIP is that SIP opens up
an additional session (the RTP session) on a completely different port
(and possibly IP) as stated below, and even more specifically, the SIP
packet defines where to connect to.

When you send an HTTP request, the only place your IP address is located
is in the IP header itself, not the HTTP header of the packet. A typical
(see: symmetric) NAT changes your internal IP address in the IP header
of the HTTP you've sent to the IP address of the gateway, sends it along
its merry way, and waits for it to come back (with the same source and
destination ports/IPs, but swapped). Once it comes back, it contains all
the data you asked for. At no time does the remote HTTP server ever have
any idea that you're on an internal IP.

SIP, on the other hand, typically only handles the call setup/etc, but
not the audio (RTP) stream. When you send a SIP INVITE, included is an
SDP header which contains _your_ IP address in addition to the IP header
of the packet. While your router modifies your internal IP address to
the gateway address in the IP header, it does not alter the internal IP
address in the SDP header (unless it's a SIP-enabled router/fw). The
destination then attempts to connect to the RTP IP+port you provided,
which is an internal IP address and probably not accessible from
wherever you're sending your INVITE to. Asterisk's sip.conf's `externip`
and `localnet` lines are used to resolve this when making calls through
Asterisk.

The way SIP works is much more like active FTP connection rather than
HTTP, where there are actually multiple connections and the important
data you're trying to transmit (audio, data, pron) is sent on a
different port. One of the benefits is that you don't need to transmit
the data yourself if you're simply handling the session data between two
remote parties. Being a SIP proxy in this scenario is very similar to
FTP's "FXP".

Hope that helps

-samy

Post by Mojo with Horan & Company, LLC
I'll take a stab at the first one, but I am probably gonna get nailed
for my own rudimentary understanding of it...

Post by hugolivude
I understand how sitting behind a NAT could cause problems for a SIP
UA. The SIP UA would create SIP mesages using IP addresses from
inside the network (i.e. 192.#.#.# or 10.#.#.#) and these IP
addresses are of course unnavigable for the recipient.
What I don't get is why don't web browsers suffer the same problem?

When the initial http request goes out the packet has a return address
with a source port on the (for example) 192.x.x.x machine. the NAT
router does the same thing, sending it out into the world, with a
return address containing a source port on the NAT router. when it
receives a response, it knows which internal box to route it to,
things are OK. The HTTP server simply sends its reply to that return
address, and it's routed back the way it came.
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. 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 :)
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?
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.
Moj
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
http://lists.digium.com/mailman/listinfo/asterisk-users

[hugolivude]

Thanks Moj! The RTP packet problem makes sense. Still unclear on

Post by Mojo with Horan & Company, LLC
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?

Post by Mojo with Horan & Company, LLC
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.

Post by Mojo with Horan & Company, LLC
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...

Post by Mojo with Horan & Company, LLC
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

[Martin Joseph]

Post by hugolivude
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?

Remember that the browser INITIATES all activity on the port 80
transfers. There is no data "coming in out of the blue" to you browser.

This makes it MUCH simpler for you NAT to send the right data to the
right machine.

[Tim Panton]

Post by Martin Joseph

Post by hugolivude
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?

Remember that the browser INITIATES all activity on the port 80
transfers. There is no data "coming in out of the blue" to you browser.
This makes it MUCH simpler for you NAT to send the right data to
the right machine.

Which is exactly why IAX is so much better than SIP at this stuff.




Tim Panton

www.mexuar.com

[Mojo with Horan & Company, LLC]

H,

Post by hugolivude

Post by Mojo with Horan & Company, LLC
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...

While I could probably never bring myself to enjoy (Microsoft's?)
Universal Plug-n-Play features, they would be helpful for the rtp
streams, although not the signalling.

Conceivably, if only one SIP UA were in use behind a NAT router, then
when it constructed a call and needed to receive RTP streams, it would
configure port mappings in the router via the UPnP protocol, so external
port 10xxx is forwarded to the internal IP of the SIP UA. It could
remove this port mapping when the call was deconstructed.

The problem of course happens when two SIP UAs need to work behind a NAT
router, because, as Cullin mentioned, "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. "

Thanks Cullin!

Moj

[Brian Candler]

Post by Mojo with Horan & Company, LLC
Conceivably, if only one SIP UA were in use behind a NAT router, then
when it constructed a call and needed to receive RTP streams, it would
configure port mappings in the router via the UPnP protocol, so external
port 10xxx is forwarded to the internal IP of the SIP UA. It could
remove this port mapping when the call was deconstructed.

I don't know much about UPnP, but has anyone considered using a SOCKS 5
proxy? This is a clean way in which the UA can remotely open sockets on the
firewall itself. I've not seen any SIP terminals yet which support it.

Post by Mojo with Horan & Company, LLC
The problem of course happens when two SIP UAs need to work behind a NAT
router, because, as Cullin mentioned, "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. "

Yep, but IIUC the 'rport' extension (RFC 3581) means in practice you don't
actually have to use 5060 as your source port.

Regards,

Brian.

[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-***@lists.digium.com
[mailto:asterisk-users-***@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

Post by Mojo with Horan & Company, LLC
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.

Post by Mojo with Horan & Company, LLC
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?

Post by Mojo with Horan & Company, LLC
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.

Post by Mojo with Horan & Company, LLC
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...

Post by Mojo with Horan & Company, LLC
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

[Brian Candler]

Post by hugolivude
I understand how sitting behind a NAT could cause problems for a SIP
UA. The SIP UA would create SIP mesages using IP addresses from
inside the network (i.e. 192.#.#.# or 10.#.#.#) and these IP addresses
are of course unnavigable for the recipient.
What I don't get is why don't web browsers suffer the same problem?
A web brower behind a NAT sends an HTTP request much the same way as a
SIP UA might send an INVITE.

Kind of, except:

(1) HTTP runs over TCP, SIP runs over UDP. This is not in itself a major
issue, because the NAT firewall will keep state open in both cases (so
that inbound response packets are de-masqueraded back to the original
host). But:

(2) All the web content (whether it be HTML, embedded images etc) is pulled
back down the same TCP session as requested it in the first place.
With a SIP phone, one UDP exchange performs the INVITE signalling, but
a separate (unrelated at the IP layer) UDP exchange is used for the actual
audio traffic.

(3) A web browser is not expected to receive inbound requests from a
central server. A SIP client has to receive unsolicited INVITEs for
inbound calls.

(4) The HTTP request does not include any IP addresses within the request or
response. SIP headers and SDP bodies do: e.g.

Contact: <sip:***@192.168.0.1>

This information is invalid on the other side of a NAT, since these
addresses are not reachable by the other party.

So SIP and NAT do not mix well. There are a host of half-baked solutions
which sometimes work and sometimes don't, because even the concept of NAT
itself is not well-defined, and NAT implementations differ widely (see RFC
3489 for the gorey details)

Probably the most nearly-baked solution is to use a SIP and RTP proxy, such
as siproxd, and give it a real public IP address. Roll on the day when all
NAT routers have this built in.

For more info see:

* http://www.voip-info.org/wiki-NAT+and+VOIP
* http://www.sipcenter.com/sip.nsf/html/WEBB5YN5GE/$FILE/SIPNATtraversal.pdf
* http://siprouter.onsip.org/doc/gettingstarted/ch04s05.html

HTH,

Brian.

[Brian Candler]

Post by hugolivude
Similarly, why do we need a timeout on a SIP registration? Does this
work the same way as a "heartbeat" enabling disconnected UA to be
unregistered?

Yes, that's the purpose: so that if you unplug a SIP phone without giving it
a chance to unregister itself, it will eventually be unregistered due to the
timeout.

(Additionally, some half-baked SIP NAT solutions require you to set a
ludicrously short registration timeout, e.g. 20 seconds, just to keep UDP
state open on the firewall)

Regards,

Brian.