NAT: The Cause of the 2nd Most Frequent VoIP Problem – How to Understand and Detect it
NAT (Network Address Translation) is the process of translating private IP addresses to a public IP address that can be used for routing to and from entities outside this private local area network. During traversal of voice/video from the private network to the public network, do you have double NAT, should you disable SIP ALG to prevent audio problems, how well do you need to understand the Microsoft Teams direct routing call flow, the ICE protocol and TURN and STUN.
No matter how charming they are, there comes a time when there are too many chefs in the kitchen, pots will start clanging and too many cooks will spoil the broth. It’s the same when you have too many NAT devices. One of them will try to be better than the other and step-up to be chief-ALG.
This article gives you a quick overview of the mechanisms used to manage NAT Traversal and ensure packets can be safely and reliably routed inside and outside your home or organization. This info will allow you to make clear and concise decisions, to eliminate the possibility of problems happening and limiting the scope of investigation if the problem hits.
Problems Caused by NAT and Double NAT or ALG
Below is a list of the most frequent problems affecting VoIP networks and services. Often these problems have a common root cause.
- One way voice or audio
- Call established but no media flow
- Registrations expiring
- Failed incoming and outgoing calls
- Not able to answer calls even though phone rings
- Features controlled by Subscribe/Notify not working properly
This article will explain the problem in terms of SIP & other protocols and network interactions so that you can troubleshoot the exact cause in your situation. You’ll be able to use Wireshark or more sophisticated tools such as Oracle OCOM/EOM, which can automatically show which IAD/NAT equipment is the common factor and what steps to take to fix it forever.
VoIP Security
Dealing with NAT traversal (The process of getting packets in and out of your NAT device) has significant impacts on VoIP security so you need to know what the issues are and how to protect your network.
The most effective way to ameliorate the security problems with NAT traversal and STUN is to encrypt the connection from you to your network or from the VoIP client to the server. For example, this is done by Microsoft Teams when implementing Direct Routing. However, under the covers, even though it’s TLS encrypted and more secure, the functionality problem persists.
What Is NAT, What Is Double NAT and Why Does It Cause Problems
NAT is used to allow a large number of IP addresses or workstations per location or private network (i.e. , LAN) to route in and out of an enterprise and to provide some measure of protection for these devices. Routing outside this LAN requires the internal private IP addresses to be translated to a public IP address outside the organization for transport across the wide area network (WAN) or Internet.
Often an ITSP or MSP may wish to provide a demarcation point for their service on their customer premises in order to control quality e.g. implement quality of service (QoS) correctly, according to their policy.
However, in addition to this, the enterprise may have an access router or IAD device or a firewall device in order to protect their enterprise from the outside. So, we have two devices attempting to perform gateway network functions and the most basic of these functions is Network Address Translation (NAT).
The above diagram shows a double NAT scenario. A return packet may make it through the ITSP device, but not through the home router or enterprise firewall router. There are two phases of translation and twice the opportunity for things to go wrong.
Many techniques have been thrown at the problem of NAT traversal. These include SIP Hosted NAT Traversal (HNT), TURN, STUN and ICE. And still problems remain in real networks.
See here for the abbreviations in our glossary
SIP ALG is a common response to this problem but because of the complexity of parsing and processing SIP and the diversity of SIP implementations, problems often occur interoperating between the branch office or WFH environment and the HQ’s network.
- NAT traversal is the process of maintaining a connection across a NAT device.
How to Keep a Safe Pinhole Open on the Customer Prem Firewall
A Quick Review of SIP Hosted NAT Traversal
HNT is a technique the Oracle® Acme SBC pioneered to provide persistent reachability for SIP UAs located in private LANs behind NAT/firewall devices. It uses frequent, persistent SIP messages such as SIP RE-REGISTRATIONS or SIP OPTIONS to ensure that the binding or pinhole on the firewall/NAT device remains open even when there’s no activity. HNT does not require special support for the NAT in the SIP endpoint but does assume that the pinhole remains open for a specified period of time. The RE-REGISTRATION time should be set to less than this. In addition, there is a grace timer supported by the Oracle SBC which keeps the registration valid even if the registration expires. However, the pinhole in the firewall may still close.
More details can be obtained from RFC 7362 Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication
Security Concerns
When IP information is thrown around the Internet containing SIP details and private IP addresses, these can identify voice assets and both the UA/endpoint, the SBC at the network end and the STUN server itself become vulnerable to denial-of-service attacks or a rogue intermediate server may insert itself into a session.
Quick Tip : How Does STUN Work?
STUN is a service that allows a SIP endpoint inside a private network/LAN to discover what its public IP would look like, in order to go ahead and populate a SIP INVITE with the correct parameters to ensure that media packets are returned to itself from the WAN through a NAT Traversal. It’s a bit like “What Is My IP” service but for SIP. The default port for STUN requests is 3478, for both TCP and UDP.
And so What About TURN?
A TURN server is a STUN server that is in the path and routes the audio, video and data streaming to its destination if peer to peer connections are not possible. The TURN server is used to relay the media only. The SIP signaling goes directly from peer to peer!
A STUN or TURN server is not used if the HQ or ITSP/MSP uses an SBC because the SBC typically implements HNT as described above. The TURN protocol was introduced in RFC 3489 and updated in RFC 5389.
The Protocol Known as Interactive Connectivity Establishment (ICE)
These might include:
- A transport address on a directly attached network interface
- A translated transport address on the public side of a NAT (call a “server-reflexive” address)
- A transport address allocated from a TURN server (a “relayed address”)
ICE describes a mechanism for the endpoints to agree on which the method they should use for the session to route the media packets. This method is then used for two-way conversation. If there’s a problem due to interoperability issues between multiple SIP vendors then one way communication or zero way communication may result.
