Sonicwall Firewall Recommended Practices

The Sonicwall Firewall is a semi-complicated beast with many abilities. It does have some limitations with regard to QoS and trunking. With the right configurations, Sonicwall does work well for VoIP Applications while retaining security and performance. Here are some of the recommended practices I’ve gathered to advise the best security and service with these firewalls.

 

First, these firewalls use deep packet inspection (DPI) to tear apart traffic and inspect each packet that passes through it, please ensure that your firewall is sized properly for the amount of bandwidth you are subscribed to in order to ensure good performance.

 

The main issue that we run into with VoIP and Sonicwall Firewalls is the default UDP timeout of 30 seconds. This may be fine for DNS queries and other standard Internet services that use UDP, however for SIP it will cause phones to drop off the network, become unreachable, etc.

 

The other issue we need to account for is QoS and Bandwidth Management. This will ensure that call quality is good even if our link becomes congested. The unfortunate truth is that once the voice packets leave our firewall, they are out of our control. We can at least control the bandwidth within our LAN to prevent people on our network from causing WAN congestion related audio issues.

 

This tutorial will assume that you already have an existing Sonicwall configured for your Internet traffic, and that this is a new VoIP deployment. This tutorial also assumes that your PBX is outside of your LAN hosted elsewhere. We are also going to assume that a Voice VLAN will be used to separate traffic and broadcast from your native VLAN where the computers are. Configuring the VLAN on your switches is outside of the scope of this tutorial, and I’m going to assume that this is already done.

 

To get started we need to log into the Sonicwall and Navigate to Network -> Zones and create a new Zone for Voice. Click Add Zone and name it something like VoIP. Configure the Security Type to Trusted, and select “Allow Interface Trust.” The Trusted Security type configures the Sonicwall to apply minimal scrutiny to the traffic leaving that zone. Allow Interface Trust automates the creation of Firewall Rules to allow packets to route between other trusted interfaces. We want this in case we need to log into the web interface of an IP phone from a computer on the LAN or for any other reason we would want to route from one zone to another.

 

Next we need to create either a tagged sub-interface for our uplink or a real interface that would uplink into an untagged Voice-VLAN switch port. To do this Click on Network -> Interfaces. If we are uplinking into a Tagged switch port, click Add Interface. Select Zone VoIP and enter the VLAN ID of your Voice VLAN. For Parent Interface, Select X0 or LAN or whatever the correct port that connects the SonicWall to your switch. We want to configure a Static IP for that interface, so enter a static IP that is on a different private subnet than your main LAN. For example, if your LAN is on the 192.168.1.0/24 subnet, we could create a new subnet 192.168.2.0/24, and this interface would be the gateway for that subnet. For this example you could enter 192.168.2.1 with Subnet Mask 255.255.255.0. If you need to enable management of the Firewall from that VLAN, you could enable HTTP or HTTPS, I would at the very minimum enable p-i-n-g in case you need to try to p-i-n-g the gateway for troubleshooting purposes. If you want to use 802.1p QoS tags, click Advanced and check the box for 802.1p and select 6 – Voice.

Now that we have an interface, we can enable the DHCP service for that network and allow the SonicWall to provide DHCP to the IP phones. If DHCP was already enabled on the device, a scope will be created automatically. If not navigate to Network -> DHCP Server and enable it, then click Add Dynamic and select Interface Pre-Populate, then select your VLAN Tagged interface e.g. X0:2 to let it fill out the scope for you. Go ahead and tweak the settings to suit your environment and click OK.

 

Next step is Bandwidth Management, Click on Firewall Settings -> BWM. Select Bandwidth Management Type: Global and click Apply. We will come back here shortly. You will need to run several speed tests from sites like speedtest.net and speakeasy.net/speedtest to get your bandwidth numbers. If you are on a Fiber or T1 based connection you likely don’t need to run these as those types of connections have an SLA and bandwidth is typically guaranteed. For our purposes we’re going to assume a synchronous 10Mbps x 10Mbps connection.

Navigate back to Network->Interfaces and click the pencil icon next to your X1(WAN) interface. Click the Advanced Tab and Tick the boxes next to Enabled Ingress and Egress Bandwidth Management. Enter your Egress (Upload) Bandwidth in Kbps here. For our 10Mbps connection we enter 10240 Kbps. (Multiply your Mbps upload speed by 1024 to get your connection speed in Kbps) Since our connection is synchronous we will enter the same 10240 Kbps for the Ingress (Download) Bandwidth, then click OK.

Now that available Bandwidth is defined, we can go back to Firewall Settings -> BWM. You will notice 8 priorities (0-7) with percentages assigned to them. For our purposes we are going to disable all priorities and enable only Medium, High and Highest. It’s important to note that these priority names have no meaning, they are only labels assigned to percentages and the percentages are what is actually doing the work of managing bandwidth. In Global Mode, (The Mode we are currently using) all Traffic falls into the 4 – Medium category. So now we need to calculate out how much bandwidth is needed to reserve for our Endpoints (Phones.) To do this we can use The Asterisk Guru site: http://www.asteriskguru.com/tools/bandwidth_calculator.php.

For our purposes to keep the math simple, we’re going to be using 13 phones. If you use the calculator, select your codec, i.e. G.711, Select SIP and number of simultaneous calls (number of phones) for both inbound and outbound.

When we run this calculator we see that the required bandwidth is about 1Mbps, or 10% of our 10Mbps connection. You will notice that with this calculator there is no overhead for SIP traffic so we will just estimate that.

Since we know we have 10Mbps and if all phones are on a call we will be using 1Mbps for our RTP traffic, enter 10% for Guaranteed Bandwidth in the Highest Category and allow it to take up to 100%. For SIP traffic we’re going to set aside 512Kbps so enter 5% Guaranteed in the High Category and 100% Max.

Now since all other traffic by default is marked Medium, and we don’t want to allow it to consume our bandwidth we set aside for VoIP, lets set Guaranteed to 0% and Maximum to 85%. (We are subtracting what we guarantee from VoIP from the Max allowed for everything else, 100 – 15 = 85) We’re all done here so we can click Accept to apply our changes.

 

The next step here is to enable Consistent NAT. Click on VoIP -> Settings. Check the box next to Enable consistent NAT. What this does is ensures that the outbound port that the phones use to communicate with the PBX do not change. By default each outbound connection through the firewall will use a different random outbound port. This will cause Asterisk to be unable to talk directly to the phone back through the firewall and cause the phones to become unreachable! So by enabling consistent NAT we can know that the outbound ports will not change. Leave everything else in the VoIP section disabled; the Sonicwall SIP transformations are for old outdated PBX systems that are not NAT capable.

 

The final step here is to tie everything together with Firewall Rules. The first step here is to click on Firewall -> Address Objects. We need to create an address object for your PBX’s public IP. Click Custom Address Objects to filter out the built in ones, then click Add to create a new object. Under Name you can give it a friendly name like “PBX.” Assign the zone to WAN, since the PBX is outside of your firewall. Since we’re only entering a single IP leave type as “Host.” Enter the Public IP address of the PBX in the text box, and then click Add.

Next we need to create the RTP service. The SonicWall already is SIP aware and has the protocol already built-in. Click on Firewall -> Service Objects. Click Custom Services to filter out the built-in objects, then click Add. For name we can enter “RTP.” The protocol is “UDP(17).” Enter the default Port Range for Asterisk: 10000-20000 then click Add.

Finally we will build the rules. Click on Firewall -> Access Rules. Click on Matrix view then select “From VoIP to WAN.” Click Add to add a new rule. We will start with our SIP rule. Make sure Allow is selected, then under service, select SIP from the drop-down. Our Source will be the Subnet of the VLAN interface we created earlier, e.g. “X0:2 Subnet.” The Destination will be the “PBX” Address object we created. Click the Advanced Tab, and then change the default UDP Connection Inactivity Timeout to 3600 Seconds (1 Hour.) Click the Ethernet BWM Tab and check to enable both inbound and outbound management. Select 2-High for both inbound and outbound to use our 5% guaranteed setting we created earlier, and then click Add. The last step is to create our RTP rule. Create a new rule as described above with the same source and destination, except we want to select the RTP service. Under the Advanced Tab on the RTP rule, set the UDP Connection Inactivity Timeout to 300 Seconds (5 Minutes.) On the Ethernet BWM Tab also enable Inbound and Outbound management, and select 1-Highest as the priority to guarantee 10% of our bandwidth to the audio stream.

 

At this point, we should have a working set of rules to guarantee reliable connectivity to and from Asterisk, as well as a way to prevent our users from causing call quality issues from excessive bandwidth use. I will also note that we need to make sure that Qualify=yes is set under each defined extension in Asterisk to have Asterisk continue to “poke” the extensions and ensure that the SonicWall keeps the connections active, even though we extended the UDP timeout values.

 

You can adapt this guide for use with a provider as well if your PBX is internal. Use the number of phones as a number of calls with the Provider, i.e. 13 concurrent external calls or whatever you are paying for. And substitute the PBX IP address for your Providers IP address, or IP-Range.

 

Please let me know if you have any questions, or comments, as this guide is based on my experience and many hours of testing and tweaking.