Live Chat Software by Kayako |
Knowledgebase: Router & Network Help > Generic Router Help
|
Understanding How NAT and Firewalls Affect UCaaS Services
Posted by , Last modified by Daniel Diaz on 21 June 2023 11:36 AM
|
|
|
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. Should I configure specific SIP or NAT traversal technologies on my firewall? In most cases, no. In-fact, unless you have a very specific reason for enabling a particular SIP or NAT feature on a known router/firewall with a known and tested configuration, doing so will likely introduce more issues than solve problems. Unfortunately, some of today's commercial routers enable some of these features by defualt and we recommend that you disable them when possible. This includes features including, but not limited to a SIP ALG, SIP Stateful Packet Inspection (SPI), SIP Transformations and others. To learn about SIP ALG's and the havoc they cause, you can check this article on our blog: https://www.ringlogix.com/blog/how-to-detect-and-disable-a-sip-alg. Why do you recommend I turn these features off? As mentioned above, in most cases these features cause more issues than solve problems. Further, the RingLogix Hosted PBX service 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. 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. However, these circumstances requires advanced networking experiencing by a local sys-admin and the only configuration that we can officially 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. Firewall Settings You should not have to "open up" any ports or IP address ranges for RingLogix. The phone, the device behind the firewall makes the connection from inside the network out to RingLogix. 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 Please note that RingLogix does not officially support use if its VoIP services behind a firewall, as such there is limited assistance available for these deployments. In general, VoIP services behind a firewall do not work well and introduce many calling issues that are out of our control, including but not limited to; dropped, one way or no audio, failed inbound calls and more. If the customer has a firewall the VoIP Device should be outside of its control. In the event this is not possible below are some best practices and helpful information. 1. RingLogix's network elements including our Session Border Controller and RTP Proxy are designed handle multiple IP phones behind the same NAT eliminating the need for a local proxy or port forward. 2. 'Port Forwarding' and 'ALG' features should be disabled as they almost always cause audio issues. 3. 'SIP Keep Alive' options on the VoIP Device should be enabled and set to 30 seconds. This is done automatically for auto-provisioned devices. 4. If the VoIP Device is on a Public IP you will need to manually engage the RTP Proxy in the Reseller Portal. If the RTP proxy is not engaged, the carrier involved might use a Media IP or Port which cannot be pre-determined. 5. If the VoIP device IS behind NAT or you have manually engaged the RTP Proxy the following IP's and Ports will be used. | |
|
|