NAT traversal is one of the most common sources of VoIP connectivity problems — understanding and correctly configuring STUN/TURN is essential for reliable SIP connectivity through NAT. This guide covers this configuration.
Why NAT Causes Genuine Problems for SIP
SIP embeds IP addresses and ports within its own message payload (not just relying on the outer network packet headers) — when a client is behind NAT, these embedded addresses reflect its private (NAT-internal) address, which is unreachable from the outside, causing exactly the connectivity confusion covered in How to Troubleshoot Common VoIP Quality Issues.
Understanding STUN
STUN (Session Traversal Utilities for NAT) helps a client discover its own public-facing IP/port as seen from outside its NAT — the client can then use this discovered public address in its SIP signaling, rather than its unreachable private address.
Configuring STUN in Asterisk
[general]
externip=YOUR_SERVER_PUBLIC_IP
localnet=192.168.1.0/255.255.255.0For your Asterisk server itself, configure the known public IP directly (since it's typically not behind NAT) — localnet tells Asterisk which addresses are internal, so it correctly substitutes the public IP for external-facing signaling.
Configuring STUN for Client-Side NAT Traversal
Individual SIP clients/softphones behind NAT typically have their own STUN server configuration setting — point them at a reliable STUN server so they can discover and use their genuine public-facing address in SIP signaling.
Understanding TURN (When STUN Isn't Enough)
STUN works for many NAT types but fails for genuinely restrictive/symmetric NAT (see Understanding NAT Types and Their Impact on Connectivity for the underlying NAT classification) — TURN provides a relay server as a fallback, actually relaying media traffic when direct connection isn't achievable.
Setting Up a TURN Server
sudo apt install coturn -y# /etc/turnserver.conf
listening-port=3478
external-ip=YOUR_SERVER_PUBLIC_IP
realm=yourdomain.com
user=turnuser:CHANGE_MECoturn is a widely-used open-source TURN server implementation — provides a fallback relay for clients whose NAT configuration prevents successful direct STUN-based connectivity.
Configuring rtp Settings in Asterisk for NAT
[general]
nat=force_rport,comediaforce_rport and comedia settings help Asterisk correctly handle media (RTP) traffic through NAT, using the actual observed source address/port rather than blindly trusting what the client's SIP signaling claims (which may be incorrect due to NAT).
Testing NAT Traversal
Test actual calls from clients on genuinely different network types (behind various NAT configurations, not just your own local network) — NAT traversal issues often only manifest for certain NAT types, meaning testing from one network alone isn't fully representative.
Combining with Firewall Configuration
See VPS Requirements for VoIP and Communication Servers for the general port requirements — ensure your firewall allows the necessary SIP signaling and RTP media port ranges alongside your NAT traversal configuration; NAT traversal alone doesn't help if the firewall separately blocks the actual required traffic.
Common Errors
Calls connect but produce one-way or no audio — a classic NAT-related symptom (see How to Troubleshoot One-Way Audio Issues in Asterisk); verify your nat= settings and confirm STUN/TURN configuration is genuinely functioning for the affected client's specific network situation.
Continue Reading
- Understanding NAT Types and Their Impact on Connectivity
- How to Troubleshoot One-Way Audio Issues in Asterisk
- How to Troubleshoot Common VoIP Quality Issues (Jitter, Latency, Packet Loss)
Browse more articles in VoIP & Communication Servers.
