SonicOS 5.9 Admin Guide



Configuring VoIP Support

VoIP Overview


What is VoIP?

Voice over IP (VoIP) is an umbrella term for a set of technologies that allow voice traffic to be carried over Internet Protocol (IP) networks. VoIP transfers the voice streams of audio calls into data packets as opposed to traditional, analog circuit-switched voice communications used by the public switched telephone network (PSTN).

VoIP is the major driving force behind the convergence of networking and telecommunications by combining voice telephony and data into a single integrated IP network system. VoIP is all about saving cost for companies through eliminating costly redundant infrastructures and telecommunication usage charges while also delivering enhanced management features and calling services features.

VoIP Security

Companies implementing VoIP technologies in an effort to cut communication costs and extend corporate voice services to a distributed workforce face security risks associated with the convergence of voice and data networks. VoIP security and network integrity are an essential part of any VoIP deployment.

The same security threats that plague data networks today are inherited by VoIP but the addition of VoIP as an application on the network makes those threats even more dangerous. By adding VoIP components to your network, you’re also adding new security requirements.

VoIP encompasses a number of complex standards that leave the door open for bugs and vulnerabilities within the software implementation. The same types of bugs and vulnerabilities that hamper every operating system and application available today also apply to VoIP equipment. Many of today's VoIP call servers and gateway devices are built on vulnerable Windows and Linux operating systems.

Firewall Requirements for VoIP

VoIP is more complicated than standard TCP/UDP-based applications. Because of the complexities of VoIP signaling and protocols, as well as inconsistencies that are introduced when a firewall modifies source address and source port information with Network Address Translation (NAT), it is difficult for VoIP to effectively traverse a standard firewall. Here are a few of the reasons why.

VoIP operates using two separate protocols - A signaling protocol (between the client and VoIP Server) and a media protocol (between the clients). Port/IP address pairs used by the media protocols (RTP/RTCP) for each session are negotiated dynamically by the signaling protocols. Firewalls need to dynamically track and maintain this information, securely opening selected ports for the sessions and closing them at the appropriate time.
Multiple media ports are dynamically negotiated through the signaling session - negotiations of the media ports are contained in the payload of the signaling protocols (IP address and port information). Firewalls need to perform deep packet inspection on each packet to acquire the information and dynamically maintain the sessions, thus demanding extra firewall processing.
Source and destination IP addresses are embedded within the VoIP signaling packets - A firewall supporting NAT translates IP addresses and ports at the IP header level for packets. Fully symmetric NAT firewalls adjust their NAT bindings frequently, and may arbitrarily close the pinholes that allow inbound packets to pass into the network they protect, eliminating the service provider's ability to send inbound calls to the customer. To effectively support VoIP it is necessary for a NAT firewall to perform deep packet inspection and transformation of embedded IP addresses and port information as the packets traverse the firewall.
Firewalls need to process the signaling protocol suites consisting of different message formats used by different VoIP systems - Just because two vendors use the same protocol suite does not necessarily mean they will interoperate.

To overcome many of the hurdles introduced by the complexities of VoIP and NAT, vendors are offering Session Border Controllers (SBCs). An SBC sits on the Internet side of a firewall and attempts to control the border of a VoIP network by terminating and re-originating all VoIP media and signalling traffic. In essence, SBCs act as a proxy for VoIP traffic for non-VoIP enabled firewalls. SonicWall security appliances are VoIP enabled firewalls that eliminate the need for an SBC on your network.

VoIP Protocols

VoIP technologies are built on two primary protocols:


H.323 is a standard developed by the International Telecommunications Union (ITU). It is a comprehensive suite of protocols for voice, video, and data communications between computers, terminals, network devices, and network services. H.323 is designed to enable users to make point-to-point multimedia phone calls over connectionless packet-switching networks such as private IP networks and the Internet. H.323 is widely supported by manufacturers of video conferencing equipment, VoIP equipment and Internet telephony software and devices.

H.323 uses a combination of TCP and UDP for signaling and ASN.1 for message encoding. H.323v1 was released in 1996 and H.323v5 was released in 2003. As the older standard, H.323 was embraced by many early VoIP players.

An H.323 network consists of four different types of entities:

Terminals - Client end points for multimedia communications. An example would be an H.323 enabled Internet phone or PC.
Gatekeepers - Performs services for call setup and tear down, and registering H.323 terminals for communications. Includes:
Address translation.
Registration, admission control, and status (RAS).
Internet Locator Service (ILS) also falls into this category (although it is not part of H.323). ILS uses LDAP (Lightweight Directory Access Protocol) rather than H.323 messages.
Multipoint control units (MCUs) - Conference control and data distribution for multipoint communications between terminals.
Gateways - Interoperation between H.323 networks and other communications services, such as the circuit-switched Packet Switched Telephone Network (PSTN).


The Session Initiation Protocol (SIP) standard was developed by the Internet Engineering Task Force (IETF). RFC 2543 was released in March 1999. RFC 3261 was released in June 2002. SIP is a signaling protocol for initiating, managing and terminating sessions. SIP supports ‘presence’ and mobility and can run over User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).

Using SIP, a VoIP client can initiate and terminate call sessions, invite members into a conferencing session, and perform other telephony tasks. SIP also enables Private Branch Exchanges (PBXs), VoIP gateways, and other communications devices to communicate in standardized collaboration. SIP was also designed to avoid the heavy overhead of H.323.

A SIP network is composed of the following logical entities:

User Agent (UA) - Initiates, receives and terminates calls.
Proxy Server - Acts on behalf of UA in forwarding or responding to requests. A Proxy Server can fork requests to multiple servers. A back-to-back user agent (B2BUA) is a type of Proxy Server that treats each leg of a call passing through it as two distinct SIP call sessions: one between it and the calling phone and the other between it and the called phone. Other Proxy Servers treat all legs of the same call as a single SIP call session.
Redirect Server - Responds to request but does not forward requests.

Registration Server - Handles UA authentication and registration.

SonicWall’s VoIP Capabilities

The following sections describe SonicWall’s integrated VoIP service:

VoIP Security

Traffic legitimacy - Stateful inspection of every VoIP signaling and media packet traversing the firewall ensures all traffic is legitimate. Packets that exploit implementation flaws, causing effects such as buffer overflows in the target device, are the weapons of choice for many attackers. SonicWall security appliances detect and discard malformed and invalid packets before they reach their intended target.
Application-layer protection for VoIP protocols - Full protection from application-level VoIP exploits through SonicWall Intrusion Prevention Service (IPS). IPS integrates a configurable, high performance scanning engine with a dynamically updated and provisioned database of attack and vulnerability signatures to protect networks against sophisticated Trojans and polymorphic threats. SonicWall extends its IPS signature database with a family of VoIP-specific signatures designed to prevent malicious traffic from reaching protected VoIP phones and servers.
DoS and DDoS attack protection - Prevention of DoS and DDoS attacks, such as the SYN Flood, Ping of Death, and LAND (IP) attack, which are designed to disable a network or service.
Validating packet sequence for VoIP signaling packets using TCP to disallow out of sequence and retransmitted packets beyond window.
Using randomized TCP sequence numbers (generated by a cryptographic random number generator during connection setup) and validating the flow of data within each TCP session to prevent replay and data insertion attacks.
Ensures that attackers cannot overwhelm a server by attempting to open many TCP/IP connections (which are never fully established-usually due to a spoofed source address) by using SYN Flood protection.
Stateful monitoring - Stateful monitoring ensures that packets, even though appearing valid in themselves, are appropriate for the current state of their associated VoIP connection.
Encrypted VoIP Device Support - SonicWall supports VoIP devices capable of using encryption to protect the media exchange within a VoIP conversation or secure VoIP devices that do not support encrypted media using IPsec VPNs to protect VoIP calls.
Application-Layer Protection - SonicWall delivers full protection from application-level VoIP exploits through SonicWall Intrusion Prevention Service (IPS). SonicWall IPS is built on a configurable, high performance Deep Packet Inspection engine that provides extended protection of key network services including VoIP, Windows services, and DNS. The extensible signature language used in SonicWall’s Deep Packet Inspection engine also provides proactive defense against newly discovered application and protocol vulnerabilities. Signature granularity allows SonicWall IPS to detect and prevent attacks based on a global, attack group, or per-signature basis to provide maximum flexibility and control false positives.

VoIP Network

VoIP over Wireless LAN (WLAN) - SonicWall extends complete VoIP security to attached wireless networks with its Distributed Wireless Solution. All of the security features provided to VoIP devices attached to a wired network behind a SonicWall are also provided to VoIP devices using a wireless network.
NOTE: SonicWall’s Secure Wireless Solution includes the network enablers to extend secure VoIP communications over wireless networks. Refer to the SonicWall Secure Wireless Network Integrated Solutions Guide available on the SonicWall Web site http://www.SonicWall.com for complete information.
Bandwidth Management (BWM) and Quality-of-Service (QoS) - Bandwidth management (both ingress and egress) can be used to ensure that bandwidth remains available for time-sensitive VoIP traffic. BWM is integrated into SonicWall Quality of Service (QoS) features to provide predictability that is vital for certain types of applications.
WAN redundancy and load balancing - WAN redundancy and load balancing allows for an interface to act as a secondary or backup WAN port. This secondary WAN port can be used in a simple active/passive setup, where traffic is only routed through it if the primary WAN port is down or unavailable. Load balancing can be performed by splitting the routing of traffic based on destination.
High availability - High availability is provided by<short product name>SonicWall <product name> high availability, which ensures reliable, continuous connectivity in the event of a system failure.

VoIP Network Interoperability

Plug-and-protect support for VoIP devices - With SonicWall <product name>, VoIP device adds, changes, and removals are handled automatically, ensuring that no VoIP device is left unprotected. Using advanced monitoring and tracking technology, a VoIP device is automatically protected as soon as it is plugged into the network behind a SonicWall security appliance.
Full syntax validation of all VoIP signaling packets - Received signaling packets are fully parsed within SonicWall <product name> to ensure they comply with the syntax defined within their associated standard. By performing syntax validation, the firewall can ensure that malformed packets are not permitted to pass through and adversely affect their intended target.
Support for dynamic setup and tracking of media streams - SonicWall <product name> tracks each VoIP call from the first signaling packet requesting a call setup, to the point where the call ends. Only based on the successful call progress are additional ports opened (for additional signaling and media exchange) between the calling and called party.

Media ports that are negotiated as part of the call setup are dynamically assigned by the firewall. Subsequent calls, even between the same parties, will use different ports, thwarting an attacker who may be monitoring specific ports. Required media ports are only opened when the call is fully connected, and are shut down upon call termination. Traffic that tries to use the ports outside of the call is dropped, providing added protection to the VoIP devices behind the firewall.

Validation of headers for all media packets - SonicWall <product name> examines and monitors the headers within media packets to allow detection and discarding of out-of-sequence and retransmitted packets (beyond window). Also, by ensuring that a valid header exists, invalid media packets are detected and discarded. By tracking the media streams as well as the signaling, SonicWall provides protection for the entire VoIP session.
Configurable inactivity timeouts for signaling and media - To ensure that dropped VoIP connections do not stay open indefinitely, SonicWall <product name> monitors the usage of signaling and media streams associated with a VoIP session. Streams that are idle for more than the configured timeout are shut down to prevent potential security holes.
SonicWall <product name> allows the administrator to control incoming calls - By requiring that all incoming calls are authorized and authenticated by the H.323 Gatekeeper or SIP Proxy, SonicWall <product name> can block unauthorized and spam calls. This allows you to be sure that the VoIP network is being used only for those calls authorized by the company.
Comprehensive monitoring and reporting - For all supported VoIP protocols, SonicWall <product name> offers extensive monitoring and troubleshooting tools:
Dynamic live reporting of active VoIP calls, indicating the caller and called parties, and bandwidth used.
Audit logs of all VoIP calls, indicating caller and called parties, call duration, and total bandwidth used. Logging of abnormal packets seen (such as a bad response) with details of the parties involved and condition seen.
Detailed syslog reports and ViewPoint reports for VoIP signaling and media streams. SonicWall ViewPoint is a Web-based graphical reporting tool that provides detailed and comprehensive reports of your security and network activities based on syslog data streams received from the firewall. Reports can be generated about virtually any aspect of firewall activity, including individual user or group usage patterns and events on specific firewalls or groups of firewalls, types and times of attacks, resource consumption and constraints, etc.

Supported VoIP Protocols

SonicWall security appliances support transformations for the following protocols.


SonicWall <product name> provides the following support for H.323:

VoIP devices running all versions of H.323 (currently 1 through to 5) are supported
Microsoft's LDAP-based Internet Locator Service (ILS)
Discovery of the Gatekeeper by LAN H.323 terminals using multicast
Stateful monitoring and processing of Gatekeeper registration, admission, and status (RAS) messages
Support for H.323 terminals that use encryption for the media streams
DHCP Option 150. The SonicWall DHCP Server can be configured to return the address of a VoIP specific TFTP server to DHCP clients
In addition to H.323 support, SonicWall <product name> supports VoIP devices using the following additional ITU standards:
T.120 for application sharing, electronic white-boarding, file exchange, and chat
H.239 to allow multiple channels for delivering audio, video and data
H.281 for Far End Camera Control (FECC)

SonicWall <product name> provides the following support for SIP:

Base SIP standard (both RFC 2543 and RFC 3261)
SIP INFO method (RFC 2976)
Reliability of provisional responses in SIP (RFC 3262)
SIP specific event notification (RFC 3265)
SIP UPDATE method (RFC 3311)
DHCP option for SIP servers (RFC 3361)
SIP extension for instant messaging (RFC 3428)
SIP REFER method (RFC 3515)
Extension to SIP for symmetric response routing (RFC 3581)
SonicWall VoIP Vendor Interoperability

The following is a partial list of devices from leading manufacturers with which SonicWall VoIP interoperates.


Partial List of Devices with which SonicWall VoIP Interoperates





Microsoft NetMeeting



SJLabs SJ Phone









OpenH323 Gatekeeper




Apple iChat


Microsoft MSN Messenger

Nortel Multimedia PC Client

PingTel Instant Xpressa


Siemens SCS Client SJLabs


XTen X-Lite

Ubiquity SIP User Agent




Grandstream BudgetOne


Packet8 ATA

PingTel Xpressa PolyCom


Pulver Innovations WiSIP


SIP Proxies/Services:

Cisco SIP Proxy Server

Brekeke Software OnDo SIP Proxy


Siemens SCS SIP Proxy



SonicWall <product name> supports media streams from any CODEC - Media streams carry audio and video signals that have been processed by a hardware/software CODEC (COder/DECoder) within the VoIP device. CODECs use coding and compression techniques to reduce the amount of data required to represent audio/video signals. Some examples of CODECs are:

H.264, H.263, and H.261 for video
MPEG4, G.711, G.722, G.723, G.728, G.729 for audio
VoIP Protocols that SonicWall <product name> Does Not Perform Deep Packet Inspection on

SonicWallSonicWall security appliances do not currently support deep packet inspection for the following protocols; therefore, these protocols should only be used in non-NAT environments.

Proprietary extensions to H.323 or SIP
Cisco Skinny Client Control Protocol (SCCP)
Proprietary protocols (Mitel’s MiNET, 3Com NBX, etc.)

How SonicOS Handles VoIP Calls

SonicWall <product name> provides an efficient and secure solution for all VoIP call scenarios. The following are examples of how SonicWall <product name> handles VoIP call flows:

Incoming Calls

The following figure shows the sequence of events that occurs during an incoming call.

How SonicOS Handles Incoming VoIP Calls

The following describes the sequence of events shown in the figure above:

Phone B registers with VoIP server - The SonicWall security appliance builds a database of the accessible IP phones behind it by monitoring the outgoing VoIP registration requests. SonicWall <product name> translates between phone B’s private IP address and the firewall’s public IP address used in registration messages. The VoIP server is unaware that phone B is behind a firewall and has a private IP address—it associates phone B with the firewall’s public IP address.
Phone A initiates a call to phone B - Phone A initiates a call to phone B using a phone number or alias. When sending this information to the VoIP server, it also provides details about the media types and formats it can support as well as the corresponding IP addresses and ports.
VoIP Server validates the call request and sends the request to phone B - The VoIP server sends the call request to the firewall’s public IP address. When it reaches the firewall, SonicWall <product name> validates the source and content of the request. The firewall then determines phone B’s private IP address.
Phone B rings and is answered - When phone B is answered, it returns information to the VoIP server for the media types and formats it supports as well as the corresponding IP addresses and ports. SonicWall <product name> translates this private IP information to use the firewall’s public IP address for messages to the VoIP server.
VoIP server returns phone B media IP information to phone A - Phone A now has enough information to begin exchanging media with Phone B. Phone A does not know that Phone B is behind a firewall, as it was given the public address of the firewall by the VoIP Server.
Phone A and phone B exchange audio/video/data through the VoIP server - Using the internal database, SonicWall <product name> ensures that media comes from only Phone A and is only using the specific media streams permitted by Phone B.
Local Calls

The following figure shows the sequence of events that occurs during a local VoIP call.

How SonicWall Handles Local VoIP Calls

The following describes the sequence of events shown in the figure above:

Phones A and B register with VoIP server - The SonicWall security appliance builds a database of the accessible IP phones behind it by monitoring the outgoing VoIP registration requests. SonicWall <product name> translates between the phones’ private IP addresses and the firewall’s public IP address. The VoIP server is unaware that the phones are behind a firewall. It associates the same IP address for both phones, but different port numbers.
Phone A initiates a call to phone B by sending a request to the VoIP server - Even though they are behind the same firewall, phone A does not know Phone B’s IP address. Phone A initiates a call to phone B using a phone number or alias.
VoIP Server validates the call request and sends the request to phone B - The VoIP server sends the call request to the firewall’s public IP address.The firewall then determines phone B’s private IP address.
Phone B rings and is answered - When phone B is answered, the firewall translate its private IP information to use the firewall’s public IP address for messages to the VoIP server.
VoIP Server returns phone B media IP information to phone A - Both the called and calling party information within the messages are translated by SonicWall <product name> back to the private addresses and ports for phone A and phone B.

Phone A and phone B directly exchange audio/video/data - The SonicWall security appliance routes traffic directly between the two phones over the LAN. Directly connecting the two phones reduces the bandwidth requirements for transmitting data to the VoIP server and eliminates the need for the SonicWall security appliance to perform address translation.

VoIP > Settings


For general information on VoIP, see VoIP Overview.

Configuring VoIP Features

Configuring the SonicWall security appliance for VoIP deployments builds on your basic network configuration in the SonicWall <product name> management interface. This chapter assumes the SonicWall security appliance is configured for your network environment.


Supported Interfaces

VoIP devices are supported on the following SonicWall <product name> zones:

Trusted zones (LAN, VPN)
Untrusted zones (WAN)
Public zones (DMZ)
Wireless zones (WLAN)

Configuration Tasks

General VoIP Configuration

SonicWall <product name> includes the VoIP configuration settings on the VoIP > Settings page. This page is divided into three configuration settings sections: General Settings, SIP Settings, and H.323 Settings.

Configuring Consistent Network Address Translation (NAT)

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.

For example, NAT could translate the private (LAN) IP address and port pairs, and into public (WAN) IP/port pairs as follows:


Sample NAT Translations

Private IP/Port

Translated Public IP/Port

With Consistent NAT enabled, all subsequent requests from either host or using the same ports illustrated in the previous result in using the same translated address and port pairs. Without Consistent NAT, the port and possibly the IP address change with every request.

To enable Consistent NAT, select the Enable Consistent NAT setting and click Accept. This check box is disabled by default.

NOTE: Enabling Consistent NAT causes a slight decrease in overall security, because of the increased predictability of the address and port pairs. Most UDP-based applications are compatible with traditional NAT. Therefore, do not enable Consistent NAT unless your network uses applications that require it.
Configuring SIP Settings

By default, SIP clients use their private IP address in the SIP Session Definition Protocol (SDP) messages that are sent to the SIP proxy. If your SIP proxy is located on the public (WAN) side of the SonicWall security appliance and SIP clients are on the private (LAN) side behind the firewall, the SDP messages are not translated and the SIP proxy cannot reach the SIP clients.

Selecting Enable SIP Transformations transforms SIP messages between LAN (trusted) and WAN/DMZ (untrusted). You need to check this setting when you want the SonicWall security appliance to do the SIP transformation. If your SIP proxy is located on the public (WAN) side of the SonicWall and SIP clients are on the LAN side, the SIP clients by default embed/use their private IP address in the SIP/Session Definition Protocol (SDP) messages that are sent to the SIP proxy, hence these messages are not changed and the SIP proxy does not know how to get back to the client behind the SonicWall. Selecting Enable SIP Transformations enables the SonicWall to go through each SIP message and change the private IP address and assigned port. Enable SIP Transformations also controls and opens up the RTP/RTCP ports that need to be opened for the SIP session calls to happen. NAT translates Layer 3 addresses but not the Layer 7 SIP/SDP addresses, which is why you need to select Enable SIP Transformations to transform the SIP messages.

TIP: In general, you should check the Enable SIP Transformations check box unless there is another NAT traversal solution that requires this feature to be turned off. SIP Transformations works in bi-directional mode, meaning messages are transformed going from LAN to WAN and vice versa.

Selecting Permit non-SIP packets on signaling port enables applications such as Apple iChat and MSN Messenger, which use the SIP signaling port for additional proprietary messages. Enabling this check box may open your network to malicious attacks caused by malformed or invalid SIP traffic. This check box is disabled by default.

The Enable SIP Back-to-Back User Agent (B2BUA) support setting should be enabled when the SonicWall security appliance can see both legs of a voice call (for example, when a phone on the LAN calls another phone on the LAN). This setting should only be enabled when the SIP Proxy Server is being used as a B2BUA.

TIP: If there is not the possibility of the SonicWall security appliance seeing both legs of voice calls (for example, when calls will only be made to and received from phones on the WAN), the Enable SIP Back-to-Back User Agent (B2BUA) support setting should be disabled to avoid unnecessary CPU usage.

SIP Signaling inactivity time out (seconds) and SIP Media inactivity time out (seconds) define the amount of time a call can be idle (no traffic exchanged) before the SonicWall security appliance denying further traffic. A call goes idle when placed on hold. The default time value for SIP Signaling inactivity time out is 1800 seconds (30 minutes). The default time value for SIP Media inactivity time out is 120 seconds (2 minutes).

The Additional SIP signaling port (UDP) for transformations setting allows you to specify a non-standard UDP port used to carry SIP signaling traffic. Normally, SIP signaling traffic is carried on UDP port 5060. However, a number of commercial VOIP services use different ports, such as 1560. Using this setting, the security appliance performs SIP transformation on these non-standard ports.

TIP: Vonage’s VoIP service uses UDP port 5061.
Configuring H.323 Transformations

Select Enable H.323 Transformation in the H.323 Settings section and click Accept to allow stateful H.323 protocol-aware packet content inspection and modification by the SonicWall security appliance. The SonicWall security appliance performs any dynamic IP address and transport port mapping within the H.323 packets, which is necessary for communication between H.323 parties in trusted and untrusted networks/zones. Disable the Enable H.323 Transformation to bypass the H.323 specific processing performed by the SonicWall security appliance.

The H.323 Signaling/Media inactivity time out (seconds) field specifies the amount of time a call can be idle before the SonicWall security appliance denying further traffic. A call goes idle when placed on hold. The default time value for H.323 Signaling/Media inactivity time out is 300 seconds (5 minutes).

The Default WAN/DMZ Gatekeeper IP Address field has a default value of Enter the default H.323 Gatekeeper IP address in this field to allow LAN-based H.323 devices to discover the Gatekeeper using the multicast address If you do not enter an IP address, multicast discovery messages from LAN-based H.323 devices will go through the configured multicast handling.

Configuring BWM and QoS

One of the greatest challenges for VoIP is ensuring high speech quality over an IP network. IP was designed primarily for asynchronous data traffic, which can tolerate delay. VoIP, however, is very sensitive to delay and packet loss. Managing access and prioritizing traffic are important requirements for ensuring high-quality, real-time VoIP communications.

SonicWall’s integrated Bandwidth Management (BWM) and Quality of Service (QoS) features provide the tools for managing the reliability and quality of your VoIP communications.

Bandwidth Management

For information on Bandwidth Management (BWM), see Bandwidth Management Overview.

Quality of Service

QoS encompasses a number of methods intended to provide predictable network behavior and performance. Network predictability is vital to VoIP and other mission critical applications. No amount of bandwidth can provide this sort of predictability, because any amount of bandwidth will ultimately be used to its capacity at some point in a network. Only QoS, when configured and implemented correctly, can properly manage traffic, and guarantee the desired levels of network service.

SonicWall <product name> includes QoS features that adds the ability to recognize, map, modify and generate the industry-standard 802.1p and Differentiated Services Code Points (DSCP) Class of Service (CoS) designators.

Configuring VoIP Access Rules

By default, stateful packet inspection on the SonicWall security appliance allows all communication from the LAN to the Internet and blocks all traffic to the LAN from the Internet. Additional network access rules can be defined to extend or override the default access rules.

If you are defining VoIP access for client to use a VoIP service provider from the WAN, you configure network access rules between source and destination interface or zones to enable clients behind the firewall to send and receive VoIP calls.

If your SIP Proxy or H.323 Gateway is located behind the firewall, you can use the SonicWall Public Server Wizard to automatically configure access rules.

TIP: Although custom rules can be created that allow inbound IP traffic, the SonicWall security appliance does not disable protection from Denial of Service attacks, such as the SYN Flood and Ping of Death attacks.
NOTE: You must select Bandwidth Management on the Network > Interfaces page for the WAN interface before you can configure bandwidth management for network access rules.
To add access rules for VoIP traffic on the SonicWall security appliance: Go to the Firewall > Access Rules page, and under View Style click All Rules.
Click Add at the bottom of the Access Rules table. The Add Rule dialog displays.

In the General tab, select Allow from the Action list to permit traffic.
Select the from and to zones from the From Zone and To Zone menus.
Select the service or group of services affected by the access rule from the Service list.
For H.323, select one of the following or select Create New Group and add the following services to the group:
H.323 Call Signaling
H.323 Gatekeeper Discovery
H.323 Gatekeeper RAS
For SIP, select SIP
Select the source of the traffic affected by the access rule from the Source list. Selecting Create New Network displays the Add Address Object window.
If you want to define the source IP addresses that are affected by the access rule, such as restricting certain users from accessing the Internet, select Range in the Type: drop-down menu. The enter the lowest and highest IP addresses in the range in the Starting IP Address: and Ending IP Address fields.
Select the destination of the traffic affected by the access rule from the Destination list. Selecting Create New Network displays the Add Address Object window.
From the Users Allowed menu, add the user or user group affected by the access rule.
Select a schedule from the Schedule menu if you want to allow VoIP access only during specified times. The default schedule is Always on. You can specify schedule objects on the system > Schedules page.
Enter any comments to help identify the access rule in the Comments field.
Click the Bandwidth tab.
Select Bandwidth Management, and enter the Guaranteed Bandwidth in Kbps.
Enter the maximum amount of bandwidth available to the Rule at any time in the Maximum Bandwidth field.
Assign a priority from 0 (highest) to 7 (lowest) in the Bandwidth Priority list. For higher VoIP call quality, ensure VoIP traffic receives HIGH priority.
TIP: Rules using Bandwidth Management take priority over rules without bandwidth management.
Using the Public Server Wizard

The SonicWall Public Server Wizard provides an easy method for configuring firewall access rules for a SIP Proxy or H.323 Gatekeeper running on your network behind the firewall. Using this wizard performs all the configuration settings you need for VoIP clients to access your VoIP servers.

Click Wizards on the SonicOS navigation bar.
Select Public Server Wizard and click Next. The Public Server Type dialog displays.

Select Other from the Server Type list.
Select SIP from the Services menu if you are configuring network access for a SIP proxy server from the WAN.
Select H323 Gatekeeper RAS if you are configuring network access for a H.323 Gatekeeper from the WAN.
Select H.323 Call Signaling for enabling Point-to-Point VoIP calls from the WAN to the LAN.
Click Next.
NOTE: SonicWallSonicWall recommends NOT selecting VoIP from the Services menu. Selecting this option opens up more TCP/UDP ports than is required, potentially opening up unnecessary security vulnerabilities.

Enter the name of the server in the Server Name field.
Enter the private IP address of the server. Specify an IP address in the range of addresses assigned to the zone where the server is located. The Public Server Wizard will automatically assign the server to the zone in which its IP address belongs. You can enter optional descriptive text in the Server Comment field.
Click Next.
Enter the public IP address of the server. The default is the WAN public IP address. If you enter a different IP, the Public Server Wizard will create an address object for that IP address and bind the address object to the WAN zone.
Click Next.

The Public Server Configuration Summary page displays a summary of all the configuration you have performed in the wizard. It should show:
Server Address Objects - The wizard creates the address object for the new server. Because the IP address of the server added in the example is in the IP address range assigned to the LAN zone, the wizard binds the address object to the LAN zone.
Server Service Group Object - The wizard creates a service group object for the services used by the new server.
Server NAT Policies - The wizard creates a NAT policy to translate the destination addresses of all incoming packets with one of the services in the new service group and addressed to the WAN address to the address of the new server. The wizard also creates a Loopback NAT policy
Server Access Rules - The wizard creates an access policy allowing all traffic to the WAN Primary IP for the new service.
Click Apply in the Public Server Configuration Summary page to complete the wizard and apply the configuration to your SonicWall.

The new IP address used to access the new server, both internally and externally, is displayed in the URL field of the Congratulations window:

Click Close to close the wizard.

Configuring VoIP Logging

You can enable the logging of VoIP events in the SonicWall security appliance log in the Log > Categories page. Log entries are displayed on the Log > Log Monitor page.

To enable logging:
Select Log > Categories.
Select Expanded Categories from the View Style menu in the Log Categories section.
Locate the VoIP (VOIP H.323/RAS, H.323/H.225, H.323/H.245 activity) entry in the table.
Select Log to enable the display of VoIP log events in on the Log > Log Monitor page.
Select Alerts to enable the sending of alerts for the category.
Select Syslog to enable the capture of the log events into the SonicWall security appliance Syslog.
Click Accept.

VoIP Deployment Scenarios

SonicWall security appliances can be deployed VoIP devices can be deployed in a variety of network configurations. This section describes the following deployment scenarios:

Generic Deployment Scenario

All three of the following deployment scenarios begin with the following basic configuration procedure:

Enable bandwidth management on the WAN interface on Network > Interfaces.
Configure SIP or H.323 transformations and inactivity settings on VoIP > Settings.
Configure the DHCP Server on the Network > DHCP Server page with static private IP address assignments to VoIP clients.
Enable SonicWall Intrusion Prevention Service to provided application-layer protection for VoIP communications on the Security Services > Intrusion Prevention page.
Connect VoIP Clients to network.

Deployment Scenario 1: Point-to-Point VoIP Service

The point-to-point VoiP service deployment is common for remote locations or small office environments that use a VoIP end point device connected to the network behind the firewall to receive calls directly from the WAN. The VoIP end point device on the Internet connects to VoIP client device on LAN behind the firewall using the SonicWall security appliance’s Public IP address. The following figure shows a point-to-point VoIP service topology.

Point-to-Point VoIP service topology

This deployment does not require a VoIP server. The Public IP address of the SonicWall security appliance is used as the main VoIP number for hosts on the network. This requires a static Public IP address or the use of a Dynamic DNS service to make the public address available to callers from the WAN. Incoming call requests are routed through the SonicWall security appliance using NAT, DHCP Server, and network access rules.

To make multiple devices behind the SonicWall security appliance accessible from the public side, configure One-to-One NAT. If Many-to-One NAT is configured, only one SIP and one NAT device will be accessible from the public side.

See the “Using the Public Server Wizard” section for information on configuring this deployment.

Deployment Scenario 2: Public VoIP Service

The Public VoIP Service deployment uses a VoIP service provider, which maintains the VoIP server (either a SIP Proxy Server or H.323 Gatekeeper). The SonicWall security appliance public IP address provides the connection from the SIP Proxy Server or H.323 Gatekeeper operated by the VoIP service provider. The following figure shows a public VoIP service topology.

Public VoIP Service Topology

For VoIP clients that register with a server from the WAN, the SonicWall security appliance automatically manages NAT policies and access rules. The SonicWall security appliance performs stateful monitoring of registration and permits incoming calls for clients while they remain registered. No configuration of clients is required. See the “Using the Public Server Wizard” section for information on configuring this deployment.

Deployment Scenario 3: Trusted VoIP Service

The organization deploys its own VoIP server on a DMZ or LAN to provide in-house VoIP services that are accessible to VoIP clients on the Internet or from local network users behind the security gateway. The following figure shows a trusted VoIP service topology.

Trusted VoIP Service Topology

For VoIP clients that register with a server on the DMZ or LAN, the SonicWall security appliance automatically manages NAT policies and access rules. The SonicWall security appliance performs stateful monitoring of registration and permits incoming calls for clients while they remain registered. No configuration on the VoIP clients is required.

To make a server on the LAN accessible to clients on the WAN:
Define a Host address object with the zone and IP address of the server.
Define a NAT policy, mapping traffic coming to the SonicWall security appliance’s public (WAN) IP address and VoIP service (SIP or H.323 Gatekeeper) to the server.
Define access rules allowing VoIP service to pass through the firewall.
See the “Using the Public Server Wizard” section for information on configuring this deployment.

VoIP > Call Status

The VoIP > Call Status page provides a listing of currently active VoIP calls. The VoIP Call Status table displays the following information about the active VoIP connection:

Caller IP
Called IP
Time Started

Click Flush All to remove all VoIP call entries.