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" <[EMAIL PROTECTED]>
To: "'Asterisk Users Mailing List - Non-Commercial Discussion'" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
