ADVANCED HOSTED SERVICES

 VoIP & QoS Configuration for SonicWALL Firewalls

 

  

 

 

 

 

 

February 3, 2020

SonicWALL firewalls are VoIP aware and work great with Advanced Hosted Services If properly configured.  Some IT pros (and some VoIP pros don’t have the experience with the SonicWALL Enhanced OS to configure it properly.  You may inherit SonicWALL’s from clients you pick up for VoIP and the person who installed it doesn’t know how to make it work properly.  On the surface it may seem like any standard “firewall router” that you can simply plug in and have work, but the operating system is very robust and can get complex very quickly.  This has led to a lot of speculation that SonicWALL’s don’t work with VoIP.  Many AHS partners can attest to the fact that they do indeed work, and they work well.  For many, it’s the only firewall they use in hosted VoIP deployments. This document is intended for anyone who needs to setup a SonicWALL for AHS hosted VoIP and includes dual WAN setup and special routing for phones to use any WAN interface when needed.

Topics covered: 

  1. Selecting the right SonicWALL model
  2. Configuring SonicWALL enhanced OS for QoS
  3. Configuring SonicWALL for Failover (Dual WAN)
  4. Configuring SonicWALL to force phones to use secondary WAN (X2)

Selecting the right SonicWALL for your needs: 


 All models are not created equally.   It’s optimal to have a SonicWALL that is fast enough to handle all traffic on the network.  This includes computers, phones, wireless access points, etc., anything that uses it as the gateway.  The differences in the models are not only related to how many ports or VPN tunnels they offer, but also the amount of RAM, CPU speed, and throughput.   If your SonicWALL is too slow to handle the entire network load, your VoIP quality will suffer.   Models change from time to time, so this guide isn’t meant to tell you exactly which model to purchase, but rather to suggest that you consult your SonicWALL vendor when selecting the proper model for your environment.  Keep in mind that if a SonicWALL is configured properly, it will be doing stateful packet inspection, anti-virus, anti-spyware, VPNs, etc, etc.  It has a lot of work to do, so a faster box is going to produce better results overall.  If the budget supports it, an NSA model is always a great choice, but the CURRENThigher end TZ models should work well for most. The older, white plastic TZ models generally should not be used for hosted VoIP on any network with more than 25 devices.

 

 

Configuring SonicWALL Enhanced OS for QoS
 
This is a step by step guide of how to configure a SonicWALL for hosted VoIP. You should be using firmware SonicOS Enhanced 6.5 or higher. *NOTE* For the SonicWALL to work properly in providing QoS for VoIP traffic, ALL network devices must go through the SonicWALL for Internet access.  If you plug in something like a wireless access point into an open port on your Internet provider’s gateway box, that traffic will not be managed and can throttle your bandwidth and cause the VoIP traffic to not have priority over it!

 

  1. Check the box to “Enable consistent NAT”.
     Never check any of the boxes under SIP Settings unless specifically told to by your provider.  Most VoIP providers perform the SIP Transformations on their end.  This will cause one way audio issues and internal calls to go to incorrect extensions, etc, etc.

     Consistent NAT

 

Located under VoIP/Settings.   This should always be checked.  Consistent NAT enhances standard NAT policy to provide greater compatibility with peer-to-peer applications that require a consistent IP address to connect to, such as VoIP. Consistent NAT uses an MD5 hashing method to consistently assign the same mapped public IP address and UDP Port pair to each internal private IP address and port pair.  Basically, this allows the SIP server to always locate your phones behind the firewall.

 

 

 

 

 

 

 

 

 

  1. UDP Default to 90

Nothing else on this page needs to be changed from the default settings.

 

 

Located under Manage/Firewall Settings/Flood Protection.  This is the number of seconds of idle time you want to allow before UDP connections time out.  This value is overridden by the UDP Connection timeout you set for individual rules.  If this value is too short, the SIP server will lose your phone’s registrations and won’t be able to find your phones.  However, if this setting is too high, it makes your network vulnerable to hackers since UDP ports will be left open too long.  You can opt to set it on the rule we are going to create, but it is easy to do it here for all newly created rules. If you are concerned about utmost security, I recommend leaving the default at 30, and just setting your VoIP firewall rule to 90.

 

 

 

 

 

 

 

 

 

 

 

Configuring SonicWALL enhanced OS for QoS

In this section, you’re going to create a custom service for the ports that AHS uses for the streaming audio portion of phone calls, then create a Group with that newly created service, along with the built in SIP services (5060 & 5061).

 

 

 

  1. Create Custom Service for RTP (2000-65000) 

 

 

 

Located under Manage/Objects/Service Objects.  Here you will create a custom service for the RTP ports the phones use to stream audio over the Internet.  Click on View Custom on the Service Objects tab, then click +ADD.

Give the service any name you like, choose UDP as the protocol, and set the port range as shown.       Ok to Save.

 

 

 

 

 

  1. Create Custom Group for RTP and SIP

 

Here, you will create a group with the new RTP service you just created along with the built in SIP service that the SonicWALL already has (ports 5060 & 5061).  

Located under Manage/Service Objects/Service Groups Tab. Click on Service Groups Tab, set View to Custom, and then click +Add

 

Give the group a name, then add the custom service you just created for RTP along with the SIP service that already exists.  Press OK to save.

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. Create LAN > WAN rule for new Service

 


 You will now create a single rule that is going to control QoS for all VoIP phones on the network.


Located under Manage/Rules/Access Rules.  Choose From LAN to WAN. You will be creating a rule from LAN to WAN.  You will be configuring 3 tabs for this rule. Press +ADD

For Service, choose the custom group service you just created in the previous step.  Source and Destination can be Any.  Set a comment so you know what this rule is for.

 

 

The only setting that needs to be modified on the Advanced tab is the UDP Connection Inactivity Timeout.  90 seconds should be sufficient, but some phones might require more.  Adjust accordingly.  If you didn’t modify the default setting, make sure you adjust this setting to 90. This will only apply to your phones, not every device on the network.   This is more secure for your network.

 

 

On the QoS tab/DSCP Marking Settings:

Choose Explicit from the drop down for DSCP Marking Action.

Choose 46 – Expedited Forwarding from the Explicit DSCP Value drop down.

This is the setting that tells the SonicWALL to forward VoIP packets first from the LAN to the WAN.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Configuring SonicWALL Enhanced OS for Failover (Dual WAN)

 

With one of VoIP’s failure points being the WAN connection, it’s always a good idea to recommend having a backup WAN (Internet connection) from a different provider in case the main WAN goes down for some reason.  SonicWALL’s enhanced OS handles this easily if configured properly.  This ensures connectivity not only for VoIP phones, but for all devices on the network needing Internet connectivity.

 

 

Located under Manage/Network/Failover & Load Balancing.  Click on the small down arrow under Groups to expand the windows.  All WAN interfaces you have configured will appear there.  Also, you must check the boxes “Enable Load Balancing” and “Respond to Probes”.  Do that first and press Accept.  Now click the configure button for the Default Group.

On the General Tab, you shouldn’t have to change anything if you want to use Basic Failover.       That is selected under Type.       The check box tells the SonicWALL to fall back to your primary WAN interface when it’s up. The interface ordering should be fine if you setup your primary on X1 and your secondary on X2 or other interface (it will automatically be shown here) The probing tab is where the magic happens.  First box you are telling the SonicWALL to check the WAN interfaces every X seconds.  Next, you are asking it to deactivate if it misses x intervals.  In this example, after 2 minutes of your primary WAN being down, the SonicWALL will automatically start routing traffic on the secondary WAN port (X2).

  

The Probing tab settings need to be carefully thought out.  If you have a WAN connection that tends to bounce offline a lot for some reason, setting the “Check Interface” setting to a number too low will cause the SonicWALL to switch between WAN ports too often.  While not a problem for web traffic, VoIP phones don’t register with their SIP server that often.  Most register every 300 seconds or more.  This means if you’re SonicWALL switches to the secondary WAN, the phones will be “offline” until their registration period occurs again, plus the amount of time set in the “Deactivate Interface” box.  It’s recommend to use these settings to only have the SonicWALL failover if the WAN connection is really down and will be for a period of time longer than several minutes.  In the example, the config is to check the WAN interfaces every 60 seconds, but only “failover” after 1 minutes of being down.  Come back up after it is solid and back online for 1 minute.

 

Now the probes themselves need to be configured.  Click configure for each WAN interface.

 

Select the radio button “Logical/Probe Monitoring enabled”.  From the drop down, select “Probe succeeds when either Main Target or Alt Target responds.  This setting is critical! The SonicWALL will be pinging two different targets to see if your WAN connection is up.  This is the setting that instructs it to “Failover” to the secondary WAN if the probe (ping) fails.  It’s strongly recommended to use Ping, and that you use host addresses from two different public DNS servers.  This almost ensures that your probe will never be wrong about your WAN connection.  For example, if you were to use the two public, Google DNS servers (8.8.8.8 and 8.8.4.4) and Google’s DNS goes down (it has), the SonicWALL would think the primary WAN is down because the ping failed.  It would then be in failover mode and using the secondary WAN.  Not a huge issue, but remember, the phones will be offline for 1 minute, plus the registration timeout period.  So by using two different public DNS servers for your probe, the SonicWALL will only ever failover when the WAN interface is truly down.   Choose Ping for both Target settings and enter your host IP addresses that will be pinged.

 

 

 

 

 

 

 

Configuring SonicWALL to force phones to use secondary WAN (X2)


 Here‘s the scenario.  You have two WAN connections to two different ISP’s.   You have Failover on the SonicWALL in case the primary goes down.  You have your QoS rule setup for VoIP phones on the network and everything is working smoothly.  Suddenly, and without warning, you are told that voice calls are “choppy” and the customer is experiencing jitter.  Obviously, this isn’t a SonicWALL issue as you know it’s worked perfectly for months.   You have rebooted all phones, the LAN switch, and perhaps even the SonicWALL.  Nothing locally appears to have changed and you can’t find anything wrong that would suddenly be causing this.  Web browsing is fine, and everything else that uses the Internet is working normally. Your first call should be to the primary WAN provider.  In most cases, they will come out and test the node in your area and find an issue with overloading, or some other infrastructure issue causing major packet loss.  HTTP and other protocols really don’t care as the packets eventually show up, but obviously VoIP traffic can’t handle this. The bad news is that it may take days or even weeks to identify and resolve the issue!  You can’t have VoIP phones using a connection like that for even a day.   Fortunately, you have a secondary WAN connection!  SonicWALL can be easily configured to route any Address object over any Gateway that you choose.  This example will force all VoIP phones on the network to only use the secondary WAN connection (X2), which hopefully is operating properly. This will require some level of IP knowledge that I won’t go into detail here, but it’s very straightforward.

 

 

 

 

  1. Create a Route Policy: Located under Manage/Network/Routing.

 

 

Click Add.

Source is Any.
Destination is Any.
Service will be the Address object you just created VOIP (Phones in this example).
Interface: X3
Gateway: This is your secondary WAN (X3 Default Gateway) in this example

Metric is 1.
Comment to describe what this used for.
 Check the box to “Disable route when the interface is disconnected”.   Think of this as backward failover.  If this WAN (X3) fails, the phones will go back to using the primary WAN (X1).

 

You might even consider just using this WAN connection 100% of the time only for the VoIP phones as it essentially is QoS by default as it would have no other traffic to compete with (unless the primary WAN fails, then everything else on the network will use it while the primary is down), but your QoS rule would still apply and give the phones priority over everything else.