What is NAT?

NAT (Network Address Translation) is a technology most commonly used by firewalls and routers to allow multiple devices on a LAN with 'private' IP addresses to share a single public IP address. A private IP address is an address, which can only be addressed from within the LAN, but not from the Internet outside the LAN. In order to let a device with a private IP address communicate with other devices on the Internet, there needs to be a translation between private and public IP addresses at the point where the LAN connects to the Internet, that is within the firewall/router connecting the LAN to the Internet. Such a translation is commonly referred to as NAT (for Network Address Translation) and a router doing such translation is often called a NAT router or NAT firewall/router. Sometimes NAT is also called IP Masquerading. The passing of traffic through NAT is called NAT Traversal.

The way NAT works is in principle rather simple. When a device on the LAN initiates a connection with a device on the Internet, the device will send all traffic to the NAT router first. The NAT router then replaces the source address, which is the device's private address, with its own public address before passing the traffic to its destination on the Internet. When a response is received, the NAT router searches its translation tables to find the original source address of the packet from which the device on the LAN originally started the connection and thus passes the response to that device.

Unfortunately, when a connection is originated by a device on the Internet outside the LAN it is not clear which device on the LAN the connection is meant to be established with. In this case there needs to be some rule that tells the NAT router what to do with the incoming traffic, otherwise it will simply discard the traffic and no connection will be established. If the NAT router supports what is commonly referred to as a 'software DMZ' it can handle simple rules, such as "pass all incoming connection requests to the device with address 192.168.0.2". Another technique, called port forwarding allows the NAT router to pass incoming connection requests to different devices on the LAN depending on the type of connection (ie web or mail connection). However, if there are multiple devices on the LAN to which a certain type of connection from outside may need to be established, then neither a software DMZ nor port forwarding will be sufficient.

Sometimes people (those without network experience) have difficult to understand if their host is or not behind NAT, there is a website that can help you to get a clear answer (you need to have Java): (amibehindnat.com).

The Trouble with NAT and VOIP

In addition, the way in which conventional VoIP protocols are designed is also posing a problem to VoIP traffic passing through NAT. Conventional VoIP protocols only deal with the signalling of a telephone connection. The audio traffic is handled by another protocol and to make matters worse, the port on which the audio traffic is sent is random. The NAT router may be able to handle the signalling traffic, but it has no way of knowing that the audio traffic is related to the signalling and should hence be passed to the same device the signalling traffic is passed to. As a result, the audio traffic is not translated properly between the address spaces.

At first, for both the calling and the called party everything will appear just fine. The called party will see the calling party's Caller ID and the telephone will ring while the calling party will hear a ringing feedback tone at the other end. When the called party picks up the telephone, both the ringing and the associated ringing feedback tone at the other end will stop as one would expect. However, the calling party will not hear the called party (one way audio) and the called party may not hear the calling party either (no audio).

The issue of NAT Traversal is a major problem for the widespread deployment of VOIP. Yet, the issue is non-trivial and there are no simple solutions. In general terms there are two ways to deal with this problem:

• avoid the problem altogether
• working around the problem

Avoidance

By far the best way to deal with the issue of VoIP NAT Traversal is to avoid the cause of the problem in the first place:

• Do not use NAT and obtain public IP addresses for all VoIP devices
• If you cannot avoid NAT, use IP Tunneling between VoIP devices on different LANs
• Use a public service. Eg sign up both sides to FWD and call from one to the other. Look at user authentication page for ways to control who has access to your internal lines
• Use servers that implement http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-06.txt. One of those is Yate

Workarounds

If you cannot avoid the problem, there are still several techniques available to work around the problem, none of them without their downsides. A white paper (NAT Traversal in SIP) explains some of the issues (at least as they relate to SIP signling) and discusses STUN- & ICE-based workarounds in more detail.
fridu has published a set of clarifications and a step by step solution to interconnect an Asterisk server and remote SIP phones over a dual NAT configuration. You will find it on fridu.org web site.

However, there are some simple workarounds available:

• (Re) Configure your NAT device to provide (limited) VoIP support. The specific configuratios required depend on what is required by the signaling method used (e.g. SIP, H.323, etc.) and the number and type of devices inside your NAT, and are set using the specific user interface supplied by your NAT vendor.
  • For instance, to set up a single SIP phone inside a residential NAT:
    • Set the SIP phone up with a static IP address;
    • Set up two forwarding entries the "Port Forwarding" (or similar) configuration form on the NAT configuration interface, each of which cause the NAT device to forward all traffic destined for the designated range of port numbers to the fixed IP address of the SIP phone:
      • SIP signaling: Ports 5060 to 5070
      • RTP audio: Ports 8766 to 35000
  • For enterprise firewalls, many directly support SIP and H.323 forwarding to both Proxy/PBX devices as well as to/from VoIP phone endpoints
• Use a VoIP Protocol that overloads HTTP in order to traverse NATs on normally-open IP ports, such as the open IAX protocol. (Caution: IP network protocol experts will point out that techniques such as this which use HTTP for purposes for which it was not intended frequently carry negative unintended side-effects.) A utility is available that enables Asterisk (win32) to work on the same box as ISA Server: SIPPF script.
• IXC found an approach to enable NAT customers to be callable via h323. It's possible to test this 'know how' after registration. News release of new version is also available.
• Linux kernel: Netfilter seems to have got a conntrack patch for sip/rtp nat/firewall traversal: Iptables sip conntrack

'different approaches for making sip devices work behind a dd-wrt router'

• 'dd-wrt v23sp1voip' - upgrade your dd-wrt compatible router to dd-wrt v23sp1 (didn't test sp2 yet) VOIP version

This software release includes a special version of the ser (sip express router) software, which is able to act as an outbound proxy for sip devices (almost like a http proxy does for webbrowsers). ser and the second component rtpproxy take care of registering clients on the private network and forward all trafic between the sip service provider and the internal client (sip messages and rtp media streams).

This solution works fine for any device that has "outbound proxy" support as many ata (e.g. linksys-sipura spa 2001, grandstream budgetone etc.) do.

Just enter the ip adress and sip port (see dd-wrt administration interface for ip/port) of your dd-wrt router as outbound proxy in your phone's configuration screen. Restart the phone, and voila, you can talk. This works for an unlimited number of phones, as long as each phone uses a different sip username. Using the same sip username e.g. on a two analoge port sipura ata for both analog ports causes the second port to get registered to not work for incoming calls (not 100 % verified - please let me know if you tested it).

• 'transparent proxy on dd-wrt/openwrt'

Me myself having trouble using sip devices without "outbound proxy" support behind my dd-wrt routers, I was searching for a more simple solution. My motivation was to have booth my asterisk box behind the router as well as my nokia e61 sip smartphone being able to register to out companies public sip server. This was not possible as both asterisk as well as the current nokia sip client don't support outbound proxy nor stun.

Having used transparent proxies for hhtp for a while, the question was, why not do the same for sip messages and the rtp media streams? Well, it's possible. I didn't actually figure it out using dd-wrt voip's built in ser/rtpproxy package (maybe it's possible too with them), but relied on the instructions i found for the software "sipproxd" which is luckily available for the mips based broadcom plattform (openwrt package).

What you basically need is:

- dd-wrt/openwrt (non voip firmeware version - tested with v23sp1) with jffs enabled (and enough spare memory - this solution does not work for 8mb and maybe also not for 16 mb broadcom based router models). I myself us a 32mb Linksys WRT54GS v1.1. You need JFFS as a filesystem to download, install and configure additional software packages useing ipkg.
- ssh/telnet access to your router
- the information available on http://siproxd.sourceforge.net/siproxd_guide/siproxd_guide_c6s4.html

First enable jffs and initialize ipkg (see other dd-wrt/openwrt faqs/howtos on how to do this in detail). Once you've done this log onto your router using telnet or better ssh (root/<yourwebadminpw>).

Then download the siproxd package using the command "ipkg install siproxd". Then follow the instructions on this manual page http://siproxd.sourceforge.net/siproxd_guide/siproxd_guide_c6s4.html

You've to create the config file using the editor "vi" on while being looged onto your router. Copying the Text from the webrowser to the console vi using putty can be quite a hassle as for some reason characters seem to move to other places whil in reality they are still on their old place in the textfile. To be sure, save the file often, then open it again to get a clean view and then copy the next part of the file.

Then start siproxd by calling it from the command line cd ... then ./siproxd -c <location of the config file you created e.g. /jffs/etc/siproxd.conf>.

Finally copy the iptables commands one after each other to the console. Then fire up your sip client with it being configures as if it had a public ip address (e.g. xxxxxx@sipgate.at etc.) and voila you can talk and you be reachable if someone is calling you.

Currently the solution is not 100 % stable, as my nokia e61 is registering with my public asterisk server sucessfully the first time, but not the second time once I lost wlan connectivity. I did not determine yet if it is a problem on the router/siproxd or if it was the due to nokia e61 software problems (I then had the www.one.at branded april/2006 software version in the phone. I have not tried it with the generic nokia 07/2006 version yet as I found an even better solution for my nokia which I'll describe below.

• 'Mobile IPv4/Birdstep SmartRoaming'

The sipproxd solution works fine for clients within a fixed wlan/lan network. But what about poor me using my nokia outside my home/office network. It's nearly impossible to have all routers's equipped with siproxd transparent proxy solution.

After searching for a long time and having spent hours with Nokias incomplete SIP/Network Group Roaming implementation, I found a software supporting the Mobile IPv4 RFC on symbian operating systems. Great, what it basically does is having a client installed on your mobile phone, which makes a new connection available to all applications. It works like a vpn/tunnel. Thus once any network connection is available, the software signs up and creates a tunnel to Birdstel/Smartroaming and your phone gets a public IP from them.

Now it also takes care of you allways using the best connection, thus it's scanning for the wlan networks you've defined, and once you enter the office, it automatically sends all traffic via the wlan, or grps/umts vice versa when you leave the office. The applications are ALLWAYS ONLLINE and don't notice the connection change which is taking place in the background.

The best thing, there's no NAT, all applications are using the phones public ip via the tunnel. Thus your SIP client works flawlessly being able to register with my asterisk, sipgate and probably many other sip providers without any problem. Works like a charm.

The only drawback: after 1 month free trial, you've to pay a yearly fee of ~30 eur if you're using their Mobile IPv4 service. The say you can use the software (once you buy a licence) with other providers too. Too bad all open source software in regard to Mobile IPv4 is completely outdated and so to my knowledge no alternative option of being your own Mobile IPv4 Provider exists (apart from commercial software from hp/cisco etc.).

Some vendors offer information on the problem, and on how you can use their products to address the problem:

• SNOM white paper: Operating phones behind NAT
• Cisco.com whitepaper: VOIP traversal of NAT and firewall
• White Paper: The SIP Protocol and Firewall Traversal
• Newport Networks White Paper NAT Traversal for Multimedia over IP
• White Paper: NAT Traversal for VoIP and Internet Communications using STUN, TURN and ICE
• Use a SIP- and RTP-Proxy combination on your NAT/Firewall/Router - as done by the SIPatH Project

Free SIP NAT Solutions

• Xtunnels Free NAT solution from Counterpath. Works with all Xlite and Eybeam softphones.

Other NAT Solutions

Some vendors offering NAT traversal 'solutions' for VOIP:

• Acme Packet
• AG Projects
• BorderWare Technologies Inc.
• Brekeke
• CommuniGate Systems
• Creacode
• Cylogistics Trueline Session Border Controller
• Eyeball Networks AnyFirewall Server and SDK
• Data Connection
• FreeSwitch opensource server that avoids most NAT issues by design
• Ingate
• Intertex
• iSoftel
• IXC
• Jasomi Networks
• Kagoor Networks
• MediaRing
• Mera
• miniSipServer for windows.
• NeoTIP
• Netrake
• Newport Networks
• NexTone
• OpenSBC Open source Session Border Controller
• Ranch Networks
• Ridgeway
• Sansay
• MailVision's NAT Traversal Solutions
• Voice SIstem
• Loongtek: p2p nat tunnel library

See also:

• Freshmeat Article on SIP and NAT
• How to solve the NAT traversal issue in SIP?
• Asterisk: How to connect to FWD: Examples on Asterisk and NAT (to/from FWD )
• Asterisk SIP NAT solutions
• Avoid SIP NAT Traversal using the NAT friendly IAX protocol
• ICE: Interactive Connectivity Establishment (a proposal for NAT and SIP)
• NAT survey: Types of NAT in various equipment
• NAT Traversal for VoIP and Internet Communications using STUN, TURN and ICE - white paper
• SER NAT support: How SIP Express Router supports NAT (Interesting solution - check nathelper!)
• STUN: Simple Traversal of UDP through NAT
• VOIP Routers
• quintum http://www.binnacleita.com/ VoIP gateways NAT Traversal ready
• Important thing to look at if you get one way audio problem with Asterisk 1.4.10 and FreePBX 2.3.0
• A basic explanation of STUN protocol
• STUN protocol and VOIP A technical explanation of the purpose of STUN protocol in VOIP scenarios.