NAT and Firewall Traversal Recommendation

Router Make/Model Configuration

Q: 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.

Q: What is "Firewall and NAT traversal"?

One of the technical challenges to implementing a SIP based VoIP solution is making everything work when a firewall and/or NAT is deployed between devices exchanging data. Junction Network's OnSIP Hosted PBX service utilizes a remote "server side" solution to this technical issue.

Q: Should I set NAT traversal technologies such as STUN and ICE on my phones?

No.

While there are some perfectly valid circumstances where configuring NAT traversal technologies on your local device is desired, unless you have a concrete reason to do so and clearly understand what you are doing, we strongly recommend that you disable all NAT traversal technologies including, but not limited to, STUN, ICE, and hard coding external addresses.

Q: Should I configure SIP or NAT traversal technologies on my firewall?

No.

While there are some perfectly valid circumstances to deploy NAT traversal technologies on your firewall (or router), unless you have a concrete reason to do so and clearly understand what you are doing, we strongly recommend that you disable all NAT traversal technologies including, but not limited to, SIP Application Level Gateway (ALG), SIP Transformations, and SIP Packet Inspection.

Q: Why do you recommend I turn these features off?

Junction Network's OnSIP Hosted PBX service utilizes a complete "server side" solution to NAT traversal. This solution operates under the assumption that the end user is not employing any "client side" NAT traversal technologies on their devices or firewalls. In some cases, our server side solution can be confused by changes made by client side technologies and visa versa - the net effect being that NAT traversal fails.

Problems typically arise when client side NAT traversal technologies are either a) successful enough that they convince our server side solution that the end user device is not behind a NAT, but otherwise fail to work correctly or completely, or b) fail to work to the extent that our server side solution still recognizes that the end user device is behind a NAT but does not function correctly because the original data has been corrupted in some fashion (garbage in, garbage out).

Furthermore, our server side solution optimizes call routing by making use of the IP packet header in conjunction with the internal IP address information inside the SIP packet body. For example, if we determine that both the caller and callee are behind the same NAT, the media will be routed directly between phones such that it never leaves the internal LAN (for example, extension to extension calls within the same office). Client side NAT traversal technologies which modify SIP packets can interfere with this process and in some cases can cause calls that could stay on the internal LAN to routed across the Internet.

While there are completely valid circumstances where a network administrator may require local client side NAT traversal technologies to be deployed, the only configuration that we currently support is our server side solution.