[Asterisk-Users] Suggestion re: SIP/NAT/*

[Karl Brose]

RE: SIP and NAT

Of course it is not "nonsense" running Asterisk and/or SIP behind a NAT.
In fact it can and does work well if set up properly by the various methods
available, many are technically sound and reliable and potentially secure.
I am running one Asterisk server behind a commercial, mass-market
consumer NAT router using STUN support in Asterisk and processing over
2000 calls per week (not a heavy load at all, though)
NAT does not introduce any instability issues in most cases. Understanding
the NAT and characterizing it properly is important of course. Anything can
be made insecure without care.
The methods obviously need to be evaluated and selected on a case by 
case basis.
"Double NAT", id est,  device behind NAT and server behind another NAT,
can work as well with proper care and insight.

The notion that SIP and NAT together are somehow improper or unprofessional
is total nonsense. NAT is a fact of networking today and has a proper place,
despite the misuse of it and the unfortunate proliferation despite better
practices (i.e. IPv6).  IAX is no adequate replacement option for SIP 
either.

One difficulty with Asterisk NAT traversal is that none of the existing 
methods in * are
properly or at all documented and not many people actually know what they do
or how they work internally,  Even the Wiki recently (perhaps still?) 
states that this
is not well understood.

The existing NAT traversal methods are:
a)  SIP symmetric UDP transmission (send SIP packets to the address and 
port
    from which we receive a packet) which is triggered with the nat=yes/no
    parameter
b) partial implementation of RFC 3581, the "rport" header feature for 
receiving
    back the port number from which we sent our request. However, this 
information
    is then not used, therefore the feature is useless when Asterisk is 
behind NAT.
    Asterisk does now provide rport info to clients behind NAT
    This function is also controlled by the recent additions to nat=, 
however this is
    improper and rather confusing and should be controlled independently 
with
    a separate parameter (use_rport=yes, send_rport=yes)
c) Symmetric RTP, like connection-oriented mode (similar to TCP),
    sending RTP back to a port from which we received the audio,
    This works ok in some respects, but is not indicated in the SDP headers
    as described in the mmusic-commedia draft, so proper 
interoperability with
    other devices is not likely.  Also controlled by nat=  in another 
confused way.
d) the qualify=yes/no/#  option, probably not intended as a NAT helper 
originally,
    rather as a client/network monitoring tool, but can help to keep NAT 
port bindings
    for SIP protocol active. This sends SIP OPTION packets.
e)  a decision logic based on the peer IP address and the local routing 
table and
    localnet= settings, to decide whether to turn on symmetric 
transmissions.
    This is useful when multiple interfaces exist on the server and SIP 
is bound to
    0.0.0.0, ie. all interfaces.  This mechanism has been found to not 
work correctly
    when using IP aliases in some situation, rather than discrete 
hardware interfaces.

Coming methods:
f)  STUN. Has been running here in test mode and clients' networks  Will 
be released
    in the near future.  It provides for totally automatic configuration 
of  bindaddress,
    externip, localnet, etc settings, and properly opens RTP ports with 
the assistance
    of a STUN server and corrects the settings in SDP headers.
g) outbound proxy,  has been implemented, but release is questionable, 
there are
    many different interpretations of what an outbound proxy is or does, 
perhaps
    use in a similar fashion as the Freeworlddialup o/b proxy. SIP 
devices behind
    symmetric NATs typically require a provider-supplied remote outbound 
proxy,
    unless port forwarding can used.

Port forwarding of course is also a proper technique used in 
environments with firewalls
and NATs to the open Internet, but often many ports need to be opened 
for servers with
higher call volume as each call requires independent UDP ports for RTP.
IAX, which doesn't use RTP, doesn't have this requirement as all traffic 
uses a
well-known port.  This makes IAX easier to use through firewalls and NAT

If it is a concern to people that many ports need to be opened for SIP 
to operate,
than perhaps you might want to reconsider using Asterisk SIP at all.  It 
opens
RTP ports (at least 2, but 4 when video support is turned on) on every SIP
request, whether or not audio actually will get transmitted,  so even for a
simple REGISTER or OPTION it will allocate RTP sockets and bind to ports.
These are expensive system calls and if used indiscriminately, can cause
substantial system load.  Some SIP providers out there that have used 
Asterisk
SIP as their SIP server probably have found the limits from this quickly.
SIP call control is a fairly lightweight affair actually, if done properly.
For example, IPTel.org states that SER (SIP Express Router) can serve the
size of a metropolitan area easily with a regular PC or so.

BTW, to fix Asterisk SIP and RTP requires quite a bit of surgery, but will
be included in a STUN package (among other goodies often 
requested/complained
about on the list)

One of the best papers on this subject, SIP traversal across NATs can be 
found
at the SIEMENS site:
http://mysip.ch/sub_furtherinformation/sub_nat/doc/sip_architecture_with_nat_v1.0.pdf


Steve Totaro wrote:

> I would agree that it is not good to suggest or impliment a solution 
> that is not a "Best Practice" unless it is a last resort.
>
>
> ----- Original Message ----- From: "Bill Seddon" 
> <bill.seddon at lyquidity.com>
> To: "'Asterisk Users Mailing List - Non-Commercial Discussion'" 
> <asterisk-users at lists.digium.com>
> Sent: Friday, October 29, 2004 1:01 PM
> Subject: RE: [Asterisk-Users] Suggestion re: SIP/NAT/*
>
>
>> Karl
>>
>> Are you saying it is nonsense that there difficulties using Asterisk 
>> and SIP
>> behind a NAT server.  Or are you saying it is nonsense that SIP and 
>> NAT are
>> dangerous together?
>>
>> Bill Seddon
>>
>> -----Original Message-----
>> From: asterisk-users-bounces at lists.digium.com
>> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Karl Brose
>> Sent: October 29, 2004 5:49 PM
>> To: Benjamin on Asterisk Mailing Lists; Asterisk Users Mailing List -
>> Non-Commercial Discussion
>> Subject: Re: [Asterisk-Users] Suggestion re: SIP/NAT/*
>>
>> NONSENSE
>>
>> Benjamin on Asterisk Mailing Lists wrote:
>>
>>> On Thu, 28 Oct 2004 14:45:46 -0600, Ryan Courtnage 
>>> <ryan-lists at voxbox.ca>
>>
>> wrote:
>>
>>>
>>>
>>>> Yep, you can do this, just requires some port forwarding and special
>>>> considerations in sip.conf.
>>>>
>>>>
>>>
>>> You are missing the point. There is no *solution* to SIP NAT
>>> traversal. All there is are *workarounds*, otherwise known as bad and
>>> rather dangerous hacks. Whether it works or not is highly dependent on
>>> external factors that you don't usually control. It also depends on
>>> the type of NAT/PAT your router is using, ie the router's particular
>>> NAT/PAT implementation.
>>>
>>> The fact remains that SIP NAT traversal setups are highly insecure and
>>> unreliable. Consider this to be the equivalent of locking your
>>> apartment with duct tape. It may work for you, but you wouldn't
>>> recommend it to anyone else UNLESS you wish them harm.
>>>
>>> Now, this is valid for single NAT situations and it is even more valid
>>> for double NAT situations.
>>>
>>> If you want to do this properly without duct tape, then you will have
>>> the three choices I mentioned:
>>>
>>> - If you must use SIP, don't use NAT
>>> - If you must use NAT, use IAX
>>> - If you must use both SIP and NAT, build a tunnel
>>>
>>> Anything else is improper and unprofessional.
>>>
>>> rgds
>>> benjk
>>>
>>>
>>
>