Solutions for SIP and NAT

Using SIP Devices behind NAT

SIP Devices behind NAT: What solutions are available?

When an IP phone is installed behind NAT, problems can be created by the NAT device itself, by the phone's inability to correctly understand its own networking environment or from a combination of the two. Because it is such a common problem, most IP Phones have built-in facilities designed to help them analyse their own networking environment and to help overcome the problems of NAT traversal. Probably the most useful and effective of these is the so-called STUN mechanism. STUN is explained in more detail below. Another facility that some IP phones can use is ICE. ICE usually operates in conjunction with STUN, allowing the phone to offer several possible contact addresses to a remote SIP server. When the remote SIP device wants to connect to your phone it can try each contact address one at a time until it finds one that works. STUN and ICE alone may not be enough. As mentioned above, the problem is not just that your IP phone needs to know it is behind NAT. It may also need some help getting through the NAT device or even maintaining a connection that has already been made through the NAT device. In particular, the NAT device may be blocking all inbound IP connections to your phone and thereby preventing a two-way audio path being established. To overcome this, you may have to use port forwarding on the NAT/firewall device. Port forwarding is a little tricky to implement, especially if you have several IP phones behind the same NAT/firewall device. However, it can sometimes be the key that unlocks the problem so give it serious consideration and remember it influences the outcomes of the STUN tests described below. Resolving your NAT traversal problems may therefore require configuration changes to the NAT device and to the IP phone.

 

STUN - Simple Traversal of UDP through NAT

STUN - Simple Traversal of UDP through NAT STUN is an industry standard approach for traversal of NAT and the technical details are published as RFC 3489. It requires that your IP phone has access to a STUN server somewhere on the Internet. Your VoIP service provider should be able to give you the address details of their STUN server, but don't despair if they cannot. See the section below that explains how to make your phone use STUN. A simple explanation of how STUN works Before you can use STUN, your IP phone has to be told the address (or URL) of a STUN server somewhere on the Internet. Now, when your phone is switched on and before making any attempt to register, it sends a number of queries to the specified STUN server. The STUN server carries out a few simple tests to determine things like: Is the IP phone behind a NAT device? What is the external IP address of the NAT device? How tightly does the NAT device enforce rules for blocking inbound UDP connections? Does it make a difference to inbound connections if an outbound connection has already been established to that remote address? It then reports the results back to the IP phone. The IP phone is now able to use this information to modify the SIP messages it sends when it registers and, if you are lucky, everything will now work perfectly. So how do I make my IP phone use STUN? Let's assume your IP phone is STUN capable. Most IP phones have a configurable parameter for the URL (or IP address) of the STUN server. Often, all you need to do is fill in a valid address in this box, perhaps tick a check box, reboot the phone and that's it. You are perhaps wondering what address to use in this box. The answer is you should use the STUN server recommended by your VoIP Service Provider. However, here is a tip: STUN does not include an authentication dialogue so generally any phone can use any STUN server. Here are some addresses that might work with your phone: stun.xten.com, stun.sipgate.net, stunserver.org. The address of the service provider's STUN server can sometimes be found from a special DNS lookup. Usually, IP phones have a configurable address for the STUN server, but if you cannot see one in your phone's configuration menus it may still be able to use STUN by automatically getting the address from a public DNS server. You would have to consult the phones manuals and specifications to check if it supports STUN in this way.

 

Port Forwarding

Port Forwarding Port forwarding is where you configure your NAT/firewall device to deliberately allow some inbound connections through to specific designated servers or host devices on the LAN (or in the DMZ). You would usually do this by adding a rule that specifies the port number, or service type, on the external WAN interface and the IP address of the target server on the LAN. In some cases the rule may also specify the port number to be used when the connection is passed through to the host on the LAN - this allows Port Address Translation or PAT. Most NAT/firewall devices allow port forwarding. However, the feature may not necessarily be called "port forwarding". Sometimes, it is just a firewall rule; sometimes it requires a firewall rule and a NAT rule. Some firewalls allow the inbound port on the external interface to be mapped to a different port on the target host device on the LAN - so-called PAT. Others will only allow the same port number to be used for both. You therefore need to be reasonably proficient with your firewall's configuration options before attempting to set up port forwarding. When working with SIP devices behind NAT, the ports that you may need to set forwarding for are: 1. The main SIP connection port - usually this is port 5060. The protocol is nearly always UDP 2. The RTP media port or ports - often a range of higher port numbers. UDP protocol. You will need to find out which ports your IP phone uses for RTP media. The actual port number(s) are usually configurable. You should set the range of port numbers to as few as necessary. For a single line IP phone you may only need one or two. You should enable port forwarding for all the RTP ports plus one more in addition because RTP connections normally use the port one numerically above for information feedback. If possible, try not to use any port address translation. Unfortunately, if you have more than one IP phone behind the same NAT device then you may find that port address translation is almost unavoidable. One alternative would be if you have several static IP addresses configured on the external WAN port of the NAT device, in which case you could use one-to-one NAT for each phone. Another possibility is to reset the default SIP port 5060 on each phone to a different number - i.e. no two IP phones should use the same SIP port. Furthermore, you must ensure that no two IP phones use the same RTP ports. You may then be able to configure your firewall/NAT device to do port forwarding for each phone while retaining the same port numbers on the external WAN port of the firewall as those on each phone. I've never tried this so cannot guarantee it will work.   One-to-one NAT: One-to-one NAT can be a very useful solution for VoIP NAT traversal. The reason it helps is because it does not require any port address translation. If your IP phone specifies in the SIP INVITE that it will be listening for RTP on Port 10005 then it is easy to set up the NAT device to forward Port 10005 to the IP phone. Typically, most User Agents (IP phones) can be configured to use a preset range of port numbers for the RTP Media session. The same applies to SIP servers behind NAT - e.g. Asterisk - where you can specify the range of port numbers to be used for media sessions. Once you have defined that range of port numbers, you simply have to set the firewall/NAT device to forward that range of ports to the IP phone or server. This should work provided the external IP address is also substituted either by the UA that is behind the NAT device or by the host server operating a far-end NAT traversal strategy.

 

What other mechanisms allow IP Phones to work behind NAT?

Keep-alive packets: Many SIP phones make use of "keep-alive" packets to maintain the connection that is first established during registration of the phone. Registration involves an outbound connection through the NAT device and so it generally works without any problems (because NAT firewalls generally allow outbound connections and only block inbound ones). Look on your IP phone's configuration menus to see if there is a "keep alive" option. If there is, try setting it to an interval of about 1 minute. This is usually enough to fool the NAT device into keeping the connection open and this allows the host server to send SIP requests directly to the registered phone. However, it does not solve the problem of media sessions being unable to come in through NAT so you may find your IP phone rings, but there is no audio or there is 1-way audio when you answer the call. Tip: Do not confuse the "keep-alive" interval with the "Re-registration" interval. The latter is the time the phone will wait before it sends another registration request to the Registrar server. You should set this to a much longer time interval - for example 30 or even 60 minutes - to avoid flooding the service provider's servers with unnecessary registration attempts. The host server will ignore surplus registration requests but it puts an unnecessary burden on their equipment. Far-end NAT Traversal: It is possible for a well designed SIP Proxy and Registrar server to recognise that a remote IP phone trying to connect or make calls is actually behind NAT and to compensate for it automatically. This is called "far end NAT traversal" and it is generally supported by most, but not all, of the big VoIP Service Providers. It involves manipulation of the SIP headers when they arrive at the server and also requires something called a Media Proxy. If your provider operates far-end NAT traversal on its servers then it is possible that you will have to disable STUN on your phone to allow the host server to work properly. If the host server is really well designed then it will cope with most phones behind NAT irrespective of whether they are using STUN or not. Setting up your own VoIP service Proxy and Registrar servers with far-end NAT traversal Smartvox Limited has a wealth of experience setting up the open source SIP telephony server SER (or OpenSER). SER stands for SIP Express Router and it runs on Linux. It must be connected directly to the Internet on a static IP address (it must not be behind a NAT device itself) so that it can be configured to provide far-end NAT traversal. Yet more solutions to NAT Manual setting of external IP address: Some VoIP devices - User Agents and SIP Servers including Asterisk -have configurable parameters that include an option to specify the IP address of the external interface on your NAT device. So, for example, if your Asterisk PBX is behind NAT and you are having trouble making SIP calls to external peers, it is likely that you can help to solve the problem by specifying the external IP address in your SIP.CONF file - the parameter is called externip. Port forwarding may also be necessary. VPN: Some users find it convenient to use a VPN connection to overcome the problems of NAT traversal. This makes sense for a home worker who needs the VPN connection for other reasons and wants to use an IP phone that registers with the office PBX. However, operating SIP across VPN can also create problems because the VPN mechanism encrypts all the packets at one end and decrypts them at the other end. This process is quite demanding of your computer's resources or perhaps of the CPU resources in the firewall that is terminating the VPN at the office. When your IP phone streams audio media (speech) back and forth between home and office it is having to encrypt and decrypt a lot of data. This can cause delays and CPU bottlenecks which in turn cause a degradation of the speech quality so some care is needed. Of course, it does bring the benefit of greater security for your voice calls. SIP aware firewalls: Some firewalls are designed to be SIP aware. This means they can be configured to inspect packets as they pass through and actually substitute the IP addresses or port numbers embedded in the SIP messages to match the IP address and port number it is opening on the external WAN interface of the firewall. A great idea, if it works! Regrettably, my experience of such devices has not been good and I usually disable the feature and manually open the required ports. UPnP: If the firewall and the SIP device behind the firewall are both able to use UPnP then it may be the right solution - they can talk to each other and hopefully agree which ports need to be opened to allow SIP through. Again, this is a great idea if it works, but don't assume that UPnP is the solution to all NAT traversal problems. Worth a try if available on the equipment you are using.