Here is some generic info on NAT that may help your situation …
Network Address Translation (NAT) is a common practice used in networks, and it doesn’t play well with VoIP. Solving this problem requires an understanding of NAT, VoIP and your VoIP setup. The following focuses on the SIP protocol for VoIP using Asterisk, but problems and solutions are applicable to most other situations.
NAT can cause problems in several places. If one of the PBXes is behind a NAT gateway, the other PBX will not be able to contact it without some additional network setup. If one or more of the phones are behind a NAT gateway, the other phone will be trying to send audio to a non-routable address. This results in failed calls or missing audio.
The alternative to a re-invite is to have the PBX relay the voice packets between the two endpoints.
SIP client is behind a NAT gateway connecting to a server on the Internet
The client creates the translation entry for the SIP traffic when it first registers. As long as there is frequent communication between the two hosts, such as one packet per minute, the channel will stay open. The only configuration needed is to have the client use its external address in all SDP packets. On clients that support it, enable STUN (Simple Traversal of UDP through NAT), so the client can determine the external address dynamically, or enter it manually. Asterisk doesn’t support STUN at this time, so all NAT configuration must be done manually. The following commands in /etc/asterisk/sip.conf set up the NAT properly:
[general]
localnet=192.168.0.0/255.255.0.0 // or your subnet
externip=x.x.x.x // use your address
[YOURREMOTEPEER] // your peer’s name
nat=yes
qualify=yes // force keepalives
With this configuration, Asterisk uses the address defined by externip for all calls to the peers configured with nat=yes. The addition of qualify=yes causes Asterisk to test the connection frequently so that the NAT translations are not removed from the firewall. With these two commands, there always will be a communications channel between Asterisk and the peer, and Asterisk will use the outside address when sending SDP messages.
Multiple SIP phones and an Asterisk server behind a NAT gateway
Calls between the phones will work fine because NAT is not needed. For calls between you and other systems on the Internet there will be problems. Unless you register to the remote side as a client (as done in the previous example), you will not be able to receive SIP messages, so you will not be able to accept calls. Second, the address information in the call setup will point to the internal address of the phone, and the one-way audio problems mentioned previously will crop up.
The easiest solution to this is to avoid NAT entirely. If you have a public IP address available for your call server, use it. If your Asterisk server is connected to both the Internet and the internal network, the SIP port is reachable from both the inside and the outside, and the only problem is ensuring RTP flows properly. The PBX server does not need to be configured to route between the interfaces or provide masquerading; it simply needs to bridge the inbound and outbound voice calls.
As I mentioned earlier, the PBX either can stay in the voice path or get out of the way. In the latter case, the PBX tells both endpoints about each other after which the endpoints talk directly. However, Asterisk could have a call setup with both endpoints and relay the RTP packets on behalf of each endpoint. The inside host would be talking to the inside address, and the outside host would be talking to the outside address. The only configuration required to achieve this in sip.conf is to disable re-invites:
[general]
canreinvite=no // force relaying
This configuration works well because the Asterisk server can speak freely to the Internet to send and receive calls. It also can talk to the internal phones, and by some simple bridging, completely ignore NAT.
As it turns out, this relaying behavior also is required when the Asterisk server has only a private address. The RTP ports will have to be forwarded on the firewall too. RTP chooses random port numbers based on configured limits. Before the ports can be configured, they should be limited in range. Configuring the firewall rules is much easier if the range of ports is known beforehand.
The range of ports to be used for RTP is defined in rtp.conf. The following configuration will limit Asterisk’s choice of RTP ports from 10000 to 20000:
[general]
rtpstart=10000 // first port to use
rtpend=20000 // last port to use, rounded up if odd
Asterisk will need several RTP ports to operate properly. Only even ports are actually used, and disabling of re-invites causes two connections to be built per call. These ports and the SIP port must then be forwarded in by the firewall. The iptables syntax is:
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 10000:10100 -j DNAT \
–to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 5060 -j DNAT \
–to-destination 192.168.1.10
Replace eth0 with the outside interface of your firewall and 192.168.1.10 with the address of your Asterisk server. These rules tell the Linux kernel to translate the destination address of any UDP packets in the given range that are entering the outside interface. This must happen at the PREROUTING stage as opposed to the POSTROUTING stage, because the destination address is being translated. At this point, any SIP or RTP packet from the Internet will be forwarded to the internal Asterisk server for processing.
When a remote station makes a call to Asterisk, the SIP packet will be forwarded in because of the iptables rules. Asterisk will stay in the media stream because of the canreinvite=no command and it will use the external address of the firewall in any SDP packets because of the NAT commands. Finally, the media stream will be forwarded to the Asterisk server because of the combination of iptables RTP forwarding and port ranges defined in rtp.conf.
Up to this point, the configuration has focused on getting Asterisk working behind a NAT gateway, with some extra details to make the phones relay through Asterisk. There are, of course, more general solutions.
If you can avoid NAT in the first place, it is in your best interests to do so because it avoids all the problems encountered so far.
The Asterisk gateway can have a very restrictive firewall policy applied to it – you just need to allow UDP 5060 for SIP and whatever port range is defined in rtp.conf. In this configuration, Asterisk can contact both the internal phones and the rest of the Internet.
If SIP is not a requirement, and you are using Asterisk, consider using the IAX protocol. IAX tunnels both the control traffic and the voice traffic over a single UDP conversation that can be port-forwarded, filtered or translated easily. This method is limited to a static set of tunnels, which is sufficient if you are connecting some PBXes over the Internet or connecting to a long-distance provider.
Sometimes the above solutions are not available to you. In that case, it might be advisable to move to a full-featured SIP proxy and use Asterisk only for voice applications, such as voice mail. SIP Express Router (SER) is a powerful SIP server that handles NAT well and is used by several high-volume services, including Free World Dialup. SER’s job is only in setting up calls between endpoints, so it must rely on other applications, such as specialized media proxies, to handle RTP streams if needed.
The step beyond a SIP proxy is a Session Border Controller (SBC), which is like a VoIP firewall. The SBC can intercede in either the signaling or RTP paths to add extra features, such as signaling protocol or codec translation, all while enforcing security policies. These are almost exclusively commercial products.