Scenarios in which NAT may adversely affect Asterisk SIP connections
The Asterisk Server is behind NAT
The Asterisk server could be on the LAN (or in a DMZ) with a NAT firewall between it and the Internet. When it communicates with external peers or devices, the network connections have to pass through the local NAT device.
The remote device that is connecting to Asterisk is behind NAT
Suppose that your Asterisk server is connected directly to the Internet. Provided your system is made reasonably secure (e.g. through firewall rules) there can be significant benefits in having it directly connected to the Internet. However, you are unlikely to be able to control the networking environment of the devices that connect to it. If remote users have IP phones that register with your Asterisk server, it is very likely that those phones will be behind a NAT device at the far end.
Asterisk is behind one NAT and the remote device is behind another
This is an unattractive situation for Asterisk to handle and should generally be avoided if possible. However, it can be made to work provided suitable NAT traversal solutions are applied at both ends.
When the Asterisk server is behind a local NAT router
Settings within the sip.conf file when you have a static IP address
This article is relevant to the original chan_sip driver only. Please be aware that it will be of limited help if you are using chan_pjsip.
The externip parameter in sip.conf tells Asterisk what the external IP address is for the NAT/firewall/router. This is the address that external devices on the Internet must use to reach the Asterisk server. If you are unsure what this address is, ask your system administrator or open a web browser on the Asterisk server and point it at
The externhost parameter in sip.conf may be used to tell Asterisk the external address of your NAT/firewall/router in the form of a FQDN. It is an alternative to externip. You must either use externip or externhost, not both. This parameter is the key to solving the NAT problem if your ISP has not allocated you with a static IP address.
The externrefresh parameter in sip.conf works in conjunction with externhost. It tells asterisk how often to query the host name using DNS. I recommend you set it to a higher value than the default – perhaps 600.
The localnet parameter in sip.conf is used to tell Asterisk which addresses are local. This is important because Asterisk will substitute the value given in externip for its own local address whenever it thinks it is communicating with a remote peer or device. The only way it knows that a device is local, is through the IP address of that device being within the range specified by localnet.
Note how you can specify several different subnets using the localnet parameter – simply put each one on a new line.
Settings within the sip.conf file when you have a dynamic IP address
Internet Service Providers normally charge extra to provide one or more static IP addresses – the option may not even be available if you have a domestic rather than a business broadband package. If your public IP address is dynamic (allocated by your provider’s DHCP service) then you will still be able to use Asterisk behind your firewall provided it supports automatic registration with a Dynamic DNS service such as DynDNS.com. The basic service is free so it is worth a try. First, you must register with DynDNS.com (or one of the alternative dynamic DNS service providers), then instruct your firewall to use the service and finally you must use the externhost parameter to specify your host name.
Don’t use externip, but do specify externrefresh and localnet as described above.
I’m using Trixbox/FreePBX. Where do I set these parameters?
Just edit the file /etc/asterisk/sip_general_custom.conf and put the parameters in there, then restart the asterisk service or reboot the machine.
Settings on the local NAT/firewall/router
If you are unable to make configuration changes (or have changes made on your behalf) on the local NAT/firewall/router device, then you are unlikely to be able to make Asterisk work for SIP connections to remote peers and devices. The suggestions given here assume that you do have access to the configuration rules on this device. If not, consider using the IAX protocol instead.
The NAT/firewall/router should be configured to allow inbound UDP connections to your Asterisk server on the primary SIP port (usually 5060), but remember that in so doing you greatly increase the risk of hacking and toll fraud (see related articles on Asterisk security). The firewall must also be configured to allow inbound UDP connections to the same ports on the Asterisk server as are defined in the rtp.conf file. The default port range in rtp.conf is 10000 to 20000. However, it is recommended that the range of port numbers assigned for RTP is reduced by editing rtp.conf, changing the parameter settings and then restarting Asterisk. It will usually be sufficient to have a range that is approximately four times the maximum number of simultaneous calls, plus a few on top for good measure.
When configuring your NAT/firewall/router device, you will probably need to find the settings for “port forwarding” or “one-to-one” NAT. Make sure your NAT device does not use port address translation. i.e. if your Asterisk server expects to receive SIP messages on port 5060, make sure you also use port 5060 on the WAN port of your NAT device to forward these messages. Similarly, make sure the same range of port numbers are forwarded on the WAN port for RTP as will receive the RTP on the Asterisk server.
When the remote devices are behind a NAT router
Settings within the sip.conf file
The nat parameter in sip.conf tells Asterisk that the remote device is behind a NAT router. There are a number of options for this parameter, but the most likely to work with NAT’d remote devices is nat=yes. You should set this parameter for each peer or device in sip.conf – i.e. don’t simply use a default setting for all peers and devices unless you fully understand the implications of doing so.
The qualify parameter in sip.conf tells Asterisk to send a kind of ping message to the remote device about every 30 seconds. This can be very helpful when connected to a remote device behind NAT because it forces the NAT router to keep the connection open. Normally, NAT routers will automatically close existing connections if there is no activity on them for more than a preset time. The time that must elapse before a connection is dropped will vary from one manufacturer to another, but it will almost always be more than 30 seconds. It also has a another benefit because it allows Asterisk to know if the connection is still working.
Checking your remote devices
From the Asterisk CLI (Command Line Interface) type the command “sip show peers”. This will report back a list of all peers/devices configured in sip.conf and will show if they have registered successfully. It will also show if they are still reachable provided you specified qualify=yes.
Settings on the remote NAT/firewall/router
Very similar rules apply to the configuration of the remote NAT/firewall/router as those described above for the local firewall. However, the settings on the remote firewall need to be matched to the ports used by the remote device. If the remote device is an IP phone you will ideally want to check the phone’s configuration and find out what port numbers it uses for SIP messaging (usually UDP port 5060) and for RTP. Then set port forwarding on the remote firewall for those ports.
Fortunately, the solutions available for remote devices, especially IP phones, are more wide ranging than those available for the Asterisk server. Firstly, most modern IP phones will be able to use a STUN server. This is an incredibly useful option and you should certainly try to switch on STUN on all the remote devices if available. STUN can take advantage of symmetrical RTP sessions on the server (i.e. sessions where the server can receive RTP audio on the same port as it uses to send the RTP audio). This option is enabled on your Asterisk server by setting “nat=yes” as described above. Also, many IP phones will recognise and use other NAT traversal techniques including sending “keep-alive” packets after registration (similar to “qualify=yes”).
If you want to read more about the techniques used to overcome NAT problems in SIP, then click here.