5 Ways to Solve NAT Traversal for VoIP Protocols

By Ran Arad

Categories: Standardization

August 13th, 2008

In my previous post, I discussed the problems firewalls and NATs have with VoIP communications, and I touched briefly on the ways to get around them. I will go into more details in this post. I will treat NATs and firewalls as mostly the same thing, and use one term or another as convenient. Although there are problems associated specifically with one or the other, the general solutions are similar. The proposed solutions are very different from each other both in the method of solution (network solution or per-device solution) and in their applicability (home user, small office, corporate), but it is difficult to clearly divide the solutions. For instance, some require both the network to allow a behavior and the device to operate it.

1. Reconfiguring the firewall

“On the RTA220 select “Configuration” then “Security” and hit the “Create a New Filtering Rule” button. You will then see a screen similar to the one shown in the screenshot below…”

Do you remember when guides like this where around (notice that it’s from 2004)? Now try to say this with a straight face: “Look, mom, it’s very simple, just follow the instruction on this page. No, your firewall is a little bit different; you have to adjust the instructions a bit.” So this solution is first meant for the tech savvy, and can probably only be done for small offices and home environment (the latter - only if the ISP provides a public address and the firewall is local). If you have the need to get your fingers dirty, you can still do it - assuming you know the exact ports used by the product you’re using. You’ll have a hard time finding a good guide as well, as these are disappearing. Once you go down this path, you need to do it for each application you have. Taken to the long haul - all your PCs on the network, your mobile devices, etc.

2. Session Border Controller

The Session Border Controller (SBC) represents your VoIP equipment to the outside world. It sits in the DMZ, has a public address, and it will relay calls to and from the endpoints inside the firewall. Problem is, you don’t always have access to this area of the network, and even if you do - you would need to place a proxy machine there which can be compromised by hackers more easily, making it a headache.

3. Protocol workarounds

Many protocols now have additional procedures to get around firewalls. These include using connections opened from inside the private network, using connections for multiple purposes and using external servers to get public addresses. There’s a nice whitepaper on the way H.323 handles NAT traversal in such a way. These techniques work some of the time, with some network configurations, but usually do not work when both call parties are behind a firewall. This also requires that both VoIP endpoints support the procedures.

4. Third party relay

Sometimes, the only way to connect two points is through a third one. Skype is notable for using this system to allow incoming calls from inside a private network: a Skype node behind a firewall or NAT connects to another node in the public network (called a supernode), and uses this node to receive incoming calls. If both call parties are behind a firewall, this node tries to help them punch holes in the firewall, and failing that, acts as a relay for the call. This solution costs nothing (to the node inside the private network, it costs bandwidth to the super nodes) and requires no configuration, but it slows down the call, and may raise privacy concerns.

5. Asking nicely

Many applications are now using UPnP as a method of crossing firewalls. This also includes file sharing software and online games. While this solution does not require any configuration, it requires a firewall supporting the UPnP protocol. It also poses a security risk: surfing to a malicious website could trigger UPnP commands that will allow free access to any computer on the network.

Overall, there is no one magic solution to allow both complete firewall protection and easy VoIP communication. Users must balance out security, reliability, quality, cost and ease. From my experience, cost and ease are the foremost considerations, followed by reliability and quality as a close second, while security seems to lag behind. I think the race will go to options 4 or 5, with my money on 5.

For further reading, see Considerations for Selection of Techniques for NAT Traversal.