Recommended Sonicwall Firewall Settings
Gain an understanding of how to set up your Sonicwall Firewall for VoIP services.
Written by Thomas Gipson
Updated at May 1st, 2026
Table of Contents
Internet networks that experience latency due to high network congestion can cause VoIP phones to experience poor call quality. Like most hosted VoIP phone systems, our services work best in networks that maintain consistently low ping times. This can be achieved by preparing your router(s) and firewall(s) for use in VoIP. This can entail creating VoIP VLANs or Zones, implementing bandwidth management policies, and protecting voice traffic that traverses your network to our services.
DISCLAIMER: SpectrumVoIP does not manage or install SonicWalls.
For further assistance with your firewall, please reach out to your IT team or MSP (Managed Service Provider). Those teams would have a better understanding of your network, its topology, and the requirements of devices connected to your internet network.
For more general information about SonicWall firewalls, you can visit the Documentation website for SonicWall
This document provides guidance for configuring a SonicWALL for SpectrumVoIP services. Included are instructions for traffic prioritization. This uses features within the SonicWALL firewall to appropriately prioritize VoIP-related traffic to help ensure a positive calling experience for your team and callers.
Recommended Adjustments
Before learning how you can optimize your Sonicwall's settings for use with VoIP reliant devices, it is recommended to read the sections below to review the different adjustments suggested by our team, such as ports and subnets to allow traffic to use, bandwidth requirements, and more.
Create Service Objects for Subnets and Ports
To make sure traffic to our specific services is not blocked, Service Objects should be created for each of the different port ranges used by the SpectrumVoIP services your company uses. If you are using multiple services with different port ranges, then multiple service objects will need to be created for each port range. These Service Objects can be grouped together into a single Service Group.
Note: If you are not sure which services you are using and which ports and subnets should be opened, contact your Installer or our Technical Support team for more information.
These Service Objects can be created on the OBJECTS page by navigating to Match Objects → Services.
More Info: To review how service objects can be created for your SonicWall, read one of the guides below:
For SonicOS 7.X:
SonicWall Configuration for VoIP on SonicOS 7.X
For SonicOS 6.5:
SonicWall Configuration for VoIP on SonicOS 6.5
SpectrumVoIP Public Subnets
- 199.71.209.0/24
- 24.227.249.0/25
- 72.249.136.32/28
- 206.123.122.32/27
- 212.69.157.32/27
- 40.143.31.64/27
- 45.41.5.0/24
- 12.150.91.0/24
Ports - Stratus Platform
IMPORTANT: These ports only need to be opened if you are utilizing our Stratus platform. If you are using our Enswitch (ES) platforms, these ports do not need to be opened.
If your company does not use the StratusHUB desktop app, the SpectrumVoIP Stratus mobile app, StratusMEETING, or StratusWEB PHONE, the ports/subnets for those services do not need to be allowed or opened.
If you are not sure which services you are utilizing, contact your Installer or our Technical Support team for more information.
Main Utilized Ports
- 5060-5062 UDP - SIP
- 20,000-40,000 UDP - RTP
- 80, 443 TCP - HTTP/HTTPS
Portal Dynamic Updates
- 8001 - TCP
Text-to-Speech Services - TCP and UDP
- 35.175.185.150:3001
- 35.175.185.150:8000
- 44.212.88.215:8000
- 54.149.243.27:3001
- 54.149.243.27:8000
- 54.70.235.134:3001
- 54.70.235.134:8000
StratusFAX 2.0 - TCP
- 5066 TCP - HTTPS and HTTP
REMINDER: If your company does not pay for and use StratusFAX 2.0, the port for this service does not need to be opened.
StratusHUB Desktop App - TCP
REMINDER: If your company does not use the StratusHUB desktop app, the IP address for this service does not need to be whitelisted.
- 199.71.209.150:8082 - TCP
StratusMEETING - TCP and UDP
REMINDER: If your company does not use StratusMEETING, the subnets for this service do not need to be allowed.
- 54.188.133.147:3443
- 3.130.158.184:3443
- 35.183.150.146:3443
StratusWEB PHONE
REMINDER: If your company does not use StratusWEB PHONE, the port for this service does not need to be opened.
- 9002 - TCP - websockets
Ports - Enswitch 1 and 2 Platforms
IMPORTANT: These ports only need to be opened if you are utilizing one of our Enswitch (ES1 or ES2) platforms. If you are using our Stratus platform, these ports do not need to be opened.
If you are not sure which service you are utilizing, contact your Installer or our Technical Support team for more information.
- 5060-5062 UDP - SIP
- 10,000-20,000 UDP - RTP
- 80, 443 TCP - HTTP/HTTPS
Push Notifications Ports
IMPORTANT: If your users are using our softphone mobile apps on cellular devices or tablets connected to the office's Wi-Fi network, it is recommended to open these ports on the firewall equipment so that push notifications for the apps are not blocked.
Android and Google Devices - Google's Firebase Cloud Messaging, aka FCM
- 443, 5228, 5229, 5230 - TCP
More Info: Ports 5228, 5229, and 5230 are the primary ports used by Google's Firebase Cloud Messaging (FCM) service for mobile devices to receive push notifications.
Apple Devices - Apple Push Notification Service, aka APNs
- 5223, 443, 2197 - TCP
More Info: Port 5223 is the primary port for communication used by Apple's Push Notification Service (APNs).
Ports 443 and 2197 are used for sending notifications from Mobile Device Management (MDM) software to APNs and as a fallback on Wi-Fi if port 5223 cannot be utilized.
Bandwidth Requirements
Voice-only applications utilize G.711 U-Law as the primary codec and require 87.2 kbps of bandwidth per active call.
It is recommended to round the requirement up to 100 kbps to account for signaling and overhead.
For Example… A 10Mbps/1Mbps ISP connection solely dedicated to the phones would support 10 concurrent phone calls.
Connect Devices to an Interface Set as a VoIP Zone
It is best practice to create separate zones for your different groups of IP devices, such as your desk phones. Doing so can simplify managing your network and troubleshooting future issues with those devices.
Setting VoIP devices in a separate zone will keep VoIP traffic separate from Data traffic. Creating a VoIP Zone will allow you to more easily create Access Rules and NAT Rules for VoIP traffic,
More Info: To review how you can create a VoIP Zone and assign it to a physical interface or a virtual interface, read one of the guides below:
For SonicOS 7.X:
SonicWall Configuration for VoIP on SonicOS 7.X
For SonicOS 6.5:
SonicWall Configuration for VoIP on SonicOS 6.5
Manual/Static Interface Configuration
For this method, an interface tied to a port of the SonicWall is set to use a VoIP Zone you create. This interface can be one of the physical interfaces that exists within the SonicWall, or a Virtual Sub-Interface (VLAN) that you can create and assign to a physical interface (the Parent Interface).
For Devices Connected to a Specific Port
In many networks, VoIP devices may be connected to ports of a specific network switch that connects to a port (i.e., a physical interface) of the SonicWall. That physical interface will need to be assigned a VoIP Zone you create to ensure devices that are physically connected to it follow Access Rules, NAT Rules, and security settings you set to use the VoIP Zone.
For Devices Connected to a VLAN
If you create a virtual sub-interface to act as a VLAN, you can assign it a VLAN Tag (i.e., 20) the SonicWall will look out for. 
This VLAN tag would then be added to the VoIP devices that would need to be connected to this VLAN. This is done by assigning the Static IP Addresses to the VoIP devices.
When the SonicWall sees a device connecting that has the VLAN tag within its IP Address (e.g., desk phone uses IP address 192.168.20.5), the SonicWall will follow any Access Rules and NAT Rules that have been created to handle traffic that has the VLAN as a source/destination. The settings that were configured for the VoIP Zone during its creation will also be followed since the VoIP Zone is set as the Zone for the VLAN.
Note: If you do create a VoIP VLAN for the phones, inform your SpectrumVoIP Installer or our Technical Support team of the VLAN Tag you selected and your IP address range, so that any VoIP devices we manage are assigned static IP addresses that match.
Automatic Discovery via LLDP/CDP
If your network switches support Link Layer Discovery Protocol (LLDP), LLDP Media Endpoint Discovery (LLDP-MED), and/or Cisco Discovery Protocol (CDP), Grandstream, Yealink, and Polycom desk phones are compatible with these protocols and can utilize them to be discovered by neighbor devices and switches.
If your network switch does offer LLDP, LLDP-MED, or CDP, it is recommended to ensure these protocols are enabled and configured to point to your desired VLAN. Doing so will allow the switches to discover compatible IP phones and set the devices in a VLAN dynamically depending on the device's configuration information.
What is LLDP-MED?
LLDP-MED is an extension of LLDP that operates between IP phones and network devices, such as switches for voice over IP (VoIP) applications. It does this by sending TLVs.
TLVs (Type-Length-Value) are attributes that describe type, length, and value. Devices that support LLDP can use TLVs to receive and send information with neighboring devices. The information shared using this protocol can be configuration information, device capabilities, and device identity.
Switches that have LLDP-MED enabled can use specialized TLVs that describe discovery capabilities, supported network policies, Power over Ethernet (PoE) capability, and inventory management. This can make connecting and managing IP devices, such as our desk phones, more streamlined.
Option 132 for Yealink Phones
Option 132 in DHCP is a feature that enables automatic VLAN assignment. When a device connects to the network, it sends a DHCP request containing its MAC address. The DHCP server that has Option 132 configured identifies the device and assigns a suitable VLAN.
NOTE: This only works for Yealink brand phones and needs to be made as a custom option on a DHCP Server.
To create a DHCP VLAN option on your DHCP server to allow Yealink phones to automatically connect and provision when plugged in, the following can be configured:
- Option 132: Set Voice VLAN ID
- Type: String (ASCII)
- Value : 'VLANTAG' for example '20' for VLAN 20
This DHCP option should be applied to your native DHCP server so that the phones receive the configuration when first plugged in. This may also be applied to the voice VLAN if needed.
Configure Your Sonicwall's VoIP Settings
SonicWalls offer a VOIP Settings page where you can find two settings that need to be updated for networks utilizing VoIP services: Consistent NAT and SIP Transformations.
For most networks utilizing SpectrumVoIP's PBX, Consistent NAT should be enabled, and SIP Transformations should be disabled.
REMINDER: SpectrumVoIP does not manage or install SonicWalls.
For further assistance with your firewall, please reach out to your IT team or MSP (Managed Service Provider). Those teams would have a better understanding of your network, its topology, and the requirements of devices connected to your internet network.
For more general information about SonicWall firewalls, you can visit the Documentation website for SonicWall
For SonicOS 7.X:
For SonicOS 6.5:
For SonicOS 6.2 and below:
Why Enable Consistent NAT?
Consistent NAT almost always needs to be enabled for your SonicWall's VoIP settings.
IMPORTANT: To see if enabling Consistent NAT is okay for your network, please reach out to your IT team or MSP (Managed Service Provider). Those teams would have a better understanding of your network, its topology, and the requirements of devices and applications connected to your internet network.
This setting improves compatibility between peer-to-peer applications that require a consistent IP address to route traffic to, such as VoIP reliant devices and softphones.
This feature is important for VoIP applications since endpoints within a call need to be able signal to each other and send media back and forth without any interruptions. Consistent NAT prevents sudden call disruptions by mapping internal IP addresses and ports to the same external IP addresses and ports as the SonicWall filters traffic using its NAT rules.
Why Disable SIP Transformations?
For VoIP systems, SIP Transformations almost always need to be disabled.
IMPORTANT: To see if disabling SIP Transformations is okay for your SonicWall, please reach out to your IT team or MSP (Managed Service Provider). Those teams would have a better understanding of your network, its topology, and the requirements of devices and applications connected to your internet network.
The SIP Transformations function (also referred to as SIP ALG) allows your SonicWall to rewrite the destination addresses of the SIP packets sent during VoIP calls. Since the destination IP addresses of the packets being sent during a call are overwritten by the Application Layer Gateway (ALG), this causes the call's packets to not reach their destination. This can result in one-way audio during calls where only one side of the call is able to hear the other caller.
In the Sonicwall's SIP Settings, the Enable SIP Transformations setting is enabled by default. Having this setting enabled can commonly cause quality of service issues with VoIP calls. It is recommended to disable SIP Transformations to avoid one-way audio and issues with parking and transferring.
Prioritize SpectrumVoIP Traffic
One of the greatest challenges for VoIP is ensuring high speech quality over an IP network. VoIP and other types of media streaming are very sensitive to delay and packet loss. Managing access and prioritizing traffic are important requirements for ensuring high-quality, real-time VoIP communications.
This can be done by creating Access Rules and NAT Rules for your SonicWall that will
More Info: To review how you can create Access Rules and NAT Rules for your SonicWall, read one of the guides below:
For SonicOS 7.X:
SonicWall Configuration for VoIP on SonicOS 7.X
For SonicOS 6.5:
SonicWall Configuration for VoIP on SonicOS 6.5
Use Option 66: Phone Provisioning via DHCP
If your Sonicwall will act as a DHCP server, you can set it to utilize Option 66 to make it simpler to install and provision your desk phones.
Note: If you are interested in setting up Option 66 for the DHCP server of your Sonicwall, contact your Installer or our Technical Support team for further assistance.
When Option 66 is configured, phones that boot up and connect to the Sonicwall will be provided a Provisioning URL. When the phones use the Provisioning URL to connect to our TFTP server, they can request and apply a config file to make setting up and updating themselves more streamlined.
To configure Option 66 for your Sonicwall, this can be done by creating an Option Object in its DHCP Advanced Settings.
- Login to the SonicWall Management GUI
- Navigate to Network → System → DHCP Server.
- Click the Advanced button next to the Enable DHCPv4 Server option.
- On the Option Objects tab of the DHCP Advanced Settings window, click the + Add button.
- Enter the following information:
- Option Name: Enter a name for this object, such as “Option 66”.
- Option Number: Select 66 (TFTP Server Name)
-
Option Value: Enter the URL for our provisioning server provided by a SpectrumVoIP Installer or Technician.
Note: If you do not have this URL, contact your SpectrumVoIP Installer or our Technical Support team for further assistance.
- Click the Save button.
✔ Once you have created an Option 66 Option Object, you can assign it to existing DHCP Server Lease Scopes that are assigned to subnets your desk phones will be connected to.
Quality of Service
QoS encompasses a number of methods intended to provide predictable network behavior and performance. Network predictability is vital to VoIP services. QoS, when configured and implemented correctly, can properly manage traffic and guarantee the desired levels of network service.
✔ SonicOS includes QoS features that add the ability to recognize, map, modify and generate the industry-standard 802.1p and Differentiated Services Code Points (DSCP) Class of Service (CoS) designators.
Manage Bandwidth on a WAN Interface
WARNING: Voice-only applications utilize G.711 U-Law as the primary codec, which requires 87.2 kbps of bandwidth per active call. It is recommended to round the requirement up to 100 kbps to account for signaling and overhead.
The bandwidth specified should reflect the actual bandwidth available for the link. Oversubscribing the link (declaring a value greater than the available bandwidth) is not recommended.
Enable VoIP Logging
You can enable the logging of VoIP events on the Log → Settings page. Log entries are displayed on the Log → Monitor page. To enable logging of VoIP, see Log → Settings.