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.
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. OnSIP Hosted PBX service utilizes a remote "server side" solution to this technical issue.
Should I set NAT traversal technologies such as STUN and ICE on my phones?
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.
Should I configure SIP or NAT traversal technologies on my firewall?
If you are using a Cisco ASA Router which is known to have a quality SIP ALG implementation that works well generally then enabling the SIP ALG will generally work and not cause any issues.
Unfortunately many of today's lower end commercial routers implement SIP ALG (Application Layer Gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers' ALG implementations are wrong and break SIP.
An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol stateful packet inspection (SPI) of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signaling and audio traffic between the client behind NAT and the SIP endpoint possible.
So unless you know the SIP ALG on your router/firewall works (the SIP ALG on a Cisco router for example), we recommend that you disable it and all NAT traversal technologies including, but not limited to, SIP ALG (ALG), and SIP Stateful Packet Inspection (SPI), and SIP Transformations.
Why do you recommend I turn these features off?
OnSIP 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 - 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 SIP packet has been modified on the client side in some manner.
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.
That said, there are completely valid and workable circumstances where a network administrator may require local NAT traversal technologies to be deployed on their router/firewall. For example, the SIP ALG on Cisco routers is known to work well with our service and we recommend it (our server side system will not be engaged at all in this scenario). However, the only configuration that we currently support is our server side solution.
How will multiple internal NATs affect my service?
Using multiple internal NATs may be alright in some circumstances but not others depending on your LAN's configuration. If you are using phones on multiple internal LANs you will experience problems calling across LANs unless your network administrator has previously configured internal network traffic to route appropriately. For instance a phone on the 192.168.1/24 network will not be able to reach a host in the 192.168.2/24 network unless steps have been taken to ensure this kind of routing behavior.
In other words, the best way to ensure a simple seamless experience is to put all of your IP phones that are located behind a single public IP address on the same LAN.
You should not have to "open up" any ports or IP address ranges for OnSIP. The phone, the device behind the firewall makes the connection from inside the network out to OnSIP. We simply respond to those packets. As long as nothing is specifically being blocked, this conversation should happen just like any normal network traffic and should not be an issue.
If you are forced to specifically open ports, it will be a difficult task. SIP uses one port for call setup - easy to open - but for the call media, the phone uses any of a range of ports, and it's a different range for each phone manufacturer.
"General" Firewall Rules
Not all firewalls will support these settings, but as a general rule, if you are having firewall issues, these settings should clear those issues:
UDP Port Timeout:
Increase UDP timeout to 120 seconds
SIP uses UDP (as opposed to TCP) and our keep alive messages arrive every 25 seconds. A very short UDP port timeout will cause phones to be unable to receive inbound calls because the port we are sending the call to will have timed out. Setting the UDP port timeout to anything between 45 and 120 seconds will alleviate that issue.
VOIP => Settings:
- Turn on Consistent NAT.
- Disable SIP ALG
Consistent NAT helps the device to have the same external port opened every time it connects. In this way, if the UDP port does timeout, the next time the phone makes an outbound call, that original port is re-opened thereby allowing the next inbound call to successfully arrive.
IP Address Range:
Add an 'Access Rule' for any traffic from WAN Network 188.8.131.52 Netmask 255.255.255.0 to the LAN.
Add an 'Access Rule' for any traffic from WAN Network 184.108.40.206 Netmask 255.255.255.0 to the LAN.
Add an 'Access Rule' for any traffic from WAN Network 220.127.116.11 Netmask 255.255.255.0 to the LAN.
Add an 'Access Rule' for any traffic from WAN Network 18.104.22.168 Netmask 255.255.255.0 to the LAN.
Updated November 2017