How to Configure a WatchGuard Firewall for VoIP

Configuring a WatchGuard firewall for VoIP is more straightforward than most guides make it look, but only if you start from the right mental model. WatchGuard's Firebox handles SIP traffic differently than FortiGate, SonicWall, or Sophos -- and the most important thing to understand before you touch a single setting is that the SIP-ALG on a Firebox is not on by default. It is an opt-in proxy policy. If you have not created one, it is not running.

That single fact changes the entire configuration approach. For cloud VoIP deployments where phones register outbound to a hosted provider's Session Border Controller, the right path is a clean packet filter policy, not an ALG. This guide walks through the full WatchGuard Firebox VoIP setup from pre-configuration baseline through troubleshooting, written for MSPs and IT admins managing hosted voice across multiple client sites.

Quick Answer

Step 1: Verify Your Baseline Before You Touch Anything

Firewall configuration changes made on a network that cannot support real-time voice are wasted effort. Before you create a single policy, run a VoIP network qualifier from inside the client network to get a pre-configuration baseline. You need actual numbers, not a speed test screenshot.

Standard voice quality thresholds to hit before any firewall work:

• One-way latency: under 150ms
• Jitter: under 30ms
• Packet loss: under 1%
• MOS score: 4.0 or above at baseline

If the WAN is already failing those thresholds under light load, firewall tuning improves call quality at the margins but will not fix a congested or unstable circuit. Document your pre-change baseline so you have a comparison point after configuration is complete.

Also collect these details from your VoIP provider before you start building policies -- guessing at this data produces configs that look right but fail in the field:

• SIP signaling protocol (UDP 5060, TCP 5060, TLS 5061)
• Provider SBC IP addresses or IP ranges
• RTP media port range (commonly UDP 10000-20000, but confirm with your provider)
• Whether the provider requires symmetric RTP
• Whether the provider uses encrypted media (SRTP)

Step 2: Understand the SIP-ALG Decision (and Why Most MSPs Get This Wrong)

The most common misdirection in WatchGuard VoIP support calls goes like this: the VoIP provider's support team says "disable SIP ALG," the MSP searches the Firebox interface for a toggle, finds nothing, and assumes the issue must be somewhere else. On WatchGuard, that search is the right response -- if you do not find a SIP-ALG proxy policy in your configuration, SIP-ALG is not running.

WatchGuard's SIP-ALG is a proxy policy type that must be explicitly added to the Firebox config. There is no default SIP-ALG policy. This is the opposite of routers that enable SIP inspection by default (many consumer-grade and some enterprise devices do this). Check under Firewall > Firewall Policies in Fireware Web UI -- if you see no SIP-ALG proxy policy listed, it is off. You can safely tell your provider that SIP-ALG is not enabled and move on to other troubleshooting.

When to use each approach:

Scroll to see full table on mobile

For the rest of this guide, the configuration follows the packet filter path -- the right choice for the vast majority of hosted cloud VoIP deployments. For deeper background on SIP ALG behavior across platforms, the SIP ALG reference guide covers how different firewalls implement it and what symptoms to watch for.

Step 3: Set Up a Dedicated Voice VLAN and Alias

Mixing voice and data traffic on the same VLAN creates two problems: QoS enforcement becomes harder to apply cleanly, and voice traffic competes directly with bulk data during congestion windows. A dedicated voice VLAN solves both and is the foundation every subsequent configuration step depends on.

In Fireware Web UI, configure the voice VLAN as a tagged VLAN on an internal interface:

1. Navigate to Network > Interfaces
2. Select the internal interface that connects to your managed switch
3. Click Edit, then select VLAN/Bridge
4. Add a new VLAN -- assign an ID (example: VLAN 20 for voice), a subnet (example: 192.168.20.0/24), and a descriptive name (VoIP-Voice)
5. Set the interface type to Trusted
6. Configure DHCP Server for the voice VLAN if phones will pull addresses automatically
7. Click Save

On your managed switch, configure the port connecting to IP phones as untagged on the voice VLAN and configure the uplink port to the Firebox as tagged for both the voice VLAN and any data VLANs. If your phones support CDP or LLDP-MED auto-provisioning, enable it on the switch to push the voice VLAN automatically to phones.

Next, create a WatchGuard alias for the VoIP subnet so you can reference it cleanly in policies:

1. Navigate to Firewall > Aliases
2. Click Add Alias
3. Name it VoIP-Devices (or similar)
4. Add the voice VLAN subnet as a member (example: 192.168.20.0/24)
5. Save

Step 4: Build Your VoIP Firewall Policies (Packet Filter Approach)

With the voice VLAN alias in place, you can build a dedicated outbound VoIP policy. The goal is to allow SIP signaling and RTP media from your voice devices to your provider's infrastructure, with QoS applied, while keeping the policy tight enough to be meaningful as a security control.

In Fireware Web UI:

1. Navigate to Firewall > Firewall Policies
2. Click Add Policy
3. Select Packet Filter as the policy type
4. Name the policy (example: VoIP-Outbound)
5. Click Add Policy

On the Settings tab:

• Connections are: Allowed
• From: Remove Any-Trusted, add your VoIP-Devices alias
• To: Any-External (or restrict to provider SBC IP ranges if your provider gives you a specific list)

Under Protocols, add the following port/protocol combinations:

• UDP 5060 -- SIP signaling (cleartext)
• TCP 5060 -- SIP signaling (TCP fallback)
• TCP 5061 -- SIP-TLS (encrypted signaling -- use if your provider supports it)
• UDP 10000-20000 -- RTP media (confirm exact range with your provider; some use different ranges)

Policy order matters on WatchGuard. The VoIP policy should process before your general outbound (Outgoing) policy. In Fireware Web UI, use the policy list to drag or reorder so VoIP-Outbound appears above the Outgoing policy. If you are in Automatic Policy Order mode on a cloud-managed Firebox, add the VoIP policy as a First Run policy so it evaluates before Core policies.

Enable logging on this policy. Accurate logs are essential for diagnosing call quality issues -- if you cannot see what the Firebox is doing with SIP and RTP traffic, troubleshooting becomes significantly harder.

Step 5: Configure 1-to-1 NAT for the VoIP Subnet

This is the step most WatchGuard VoIP guides skip, and it is the most common reason incoming calls have one-way audio while outbound calls work fine.

The issue: when a phone behind the Firebox places or receives a call, the SIP packet's SDP body contains the phone's private IP address. The remote party uses that address to send RTP audio back. If the Firebox has not rewritten that private IP to the public IP in the SDP, the remote party sends audio to an address that is unreachable from the internet -- and only one direction of audio works.

1-to-1 NAT solves this by mapping your VoIP subnet to a public IP address, which causes the Firebox to automatically rewrite the private IP in SDP packets to the corresponding public IP. This achieves proper SDP rewriting without enabling SIP-ALG at all.

To configure 1-to-1 NAT in Fireware Web UI:

1. Navigate to Firewall > 1-to-1 NAT
2. Click Add
3. For Type, select Dynamic NAT (if mapping a subnet) or Static NAT (if mapping individual IPs)
4. Set the Internal IP/range to your VoIP subnet (example: 192.168.20.0/24)
5. Set the External IP to your public IP address (the WAN IP assigned by your ISP)
6. Leave the Enable NAT Loopback option enabled if phones need to reach each other through the public IP
7. Save and deploy the configuration

After configuring 1-to-1 NAT, retest with an incoming call. If one-way audio was your problem, this resolves it in the majority of cases without any ALG configuration. For a broader troubleshooting walkthrough covering one-way audio and other VoIP issues across firewall platforms, see the SIP ALG troubleshooting guide.

Step 6: Enable QoS and Traffic Shaping for Voice

QoS configuration on WatchGuard differs depending on whether your Firebox is locally-managed (configured in Fireware Web UI or Policy Manager) or cloud-managed (configured in WatchGuard Cloud). Both paths deliver the same outcome -- guaranteed bandwidth and DSCP marking for voice -- but the steps are different. This section covers both.

Locally-Managed Fireboxes (Fireware Web UI / Policy Manager)

First, enable the global QoS setting:

1. Navigate to System > Global Settings
2. Select the Networking tab
3. Under Traffic Management and QoS, check Enable all Traffic Management and QoS features
4. Click Save

Next, apply QoS marking to the VoIP-Outbound policy:

1. Open the VoIP-Outbound policy you created in Step 4
2. Select the Advanced tab
3. Check Override per-interface settings
4. For Marking Type, select DSCP
5. For Marking Method, select Assign
6. For Value, select EF (Expedited Forwarding -- DSCP value 46)
7. For Prioritize Traffic Based On, select Custom Value
8. For Value, select 5 (WatchGuard recommends priority level 5 for VoIP streaming traffic; reserve levels 6 and 7 for network administration policies)
9. Click Save and deploy

Cloud-Managed Fireboxes (WatchGuard Cloud)

For Fireboxes managed in WatchGuard Cloud, traffic shaping is configured as a separate rule attached to the VoIP firewall policy:

Add the VoIP firewall policy first (as a First Run policy):

1. In WatchGuard Cloud, click Device Configuration
2. Click the Firewall Policies tile
3. Click Add Firewall Policy
4. Select First Run in the Exception Policies section, then click Next
5. Configure From (VoIP-Devices alias), To (Any-External), and add your SIP and RTP ports
6. Save

Then add the Traffic Shaping rule:

1. In WatchGuard Cloud, click the Traffic Shaping tile
2. Select Firewall Policies > Add Traffic Shaping Rule
3. Select First Run in the Exception Policies section
4. Click Next
5. Name the rule (example: VoIP-Guarantee)
6. For Behavior, select Guarantee Bandwidth
7. For Method, select Per User
8. Set Maximum Users to your maximum concurrent VoIP device count
9. Set Upload to 200 Kbps (per device -- accounts for G.711 audio plus SIP signaling overhead)
10. Set Download to 200 Kbps
11. In the Policies list, select your VoIP First Run policy
12. Click Save

For VLAN-based QoS (if phones are on a tagged VLAN and you are running Fireware v12.7 or higher), you can also enable DSCP marking at the VLAN interface level. Interface-level marking is less granular than policy-level marking but requires less configuration work on sites with simpler traffic mixes.

Step 7: Tune Application Control and IPS for VoIP Traffic

WatchGuard's security subscriptions -- Application Control and Intrusion Prevention Service (IPS) -- add significant value for most traffic types. For VoIP traffic, they need to be handled carefully.

Application Control can be used to increase bandwidth allocation to VoIP applications (Zoom, Teams, and similar) when paired with a Traffic Management action. Attach the Application Control action to your VoIP policy and apply a Traffic Management action that guarantees bandwidth. This is a supported and useful configuration for unified communications traffic.

IPS requires more caution. IPS signature sets targeting SIP traffic can flag legitimate call setup messages as potential attacks -- particularly on high-volume sites where many simultaneous registrations look statistically similar to a SIP flood. Symptoms of IPS false positives on VoIP include:

• Phones that register intermittently and drop after a predictable interval
• Registration failures that appear random but correlate with traffic spikes
• Traffic Monitor showing IPS blocks on SIP source addresses you recognize as your provider's SBCs

If IPS is triggering false positives on SIP traffic, the fix is not to disable IPS globally. Add an exception for your VoIP policy or create an IPS allowlist entry for your provider's SBC IP ranges. This preserves IPS protection for all other traffic while removing interference from the voice path.

Advanced: On-Premises PBX Inbound Call Handling

The configuration above covers outbound registration to a cloud provider. If your deployment includes an on-premises PBX that must receive inbound SIP calls directly from a SIP trunk provider (no cloud SBC in front of it), the firewall configuration changes in a few important ways.

For inbound call termination to an on-premises PBX:

• You need a static NAT (SNAT) or 1-to-1 NAT entry that maps the public SIP port to the PBX's private IP
• Create an inbound policy allowing SIP from your trunk provider's IP ranges to the PBX's private IP (not Any-External -- restrict the source to your provider's published SBC ranges)
• Create a corresponding inbound RTP policy from Any-External to the PBX (RTP source can be more variable depending on provider infrastructure)
• Test inbound call audio separately from outbound -- one-way audio on inbound vs. outbound points to different root causes

For most MSPs deploying hosted VoIP today, the cloud SBC handles inbound call routing and the on-premises PBX configuration is avoided entirely. If you are supporting legacy on-prem PBX environments, the configuration complexity is notably higher and the SIP-ALG path may be worth evaluating more carefully alongside the packet filter approach.

Troubleshooting WatchGuard VoIP Issues by Symptom

When calls fail on a WatchGuard deployment, classifying the failure type first saves significant time. The right starting point depends on what exactly is broken.

Phones Register but Calls Fail to Establish

This points to SIP signaling reaching the provider but failing at call setup. Check:

• Traffic Monitor for denied traffic on TCP/UDP 5060 or 5061 during call attempts
• Policy order -- confirm the VoIP packet filter policy processes before the general Outgoing policy
• DNS resolution -- if the provider's SBC address is a hostname, confirm DNS resolves from inside the voice VLAN
• Whether your IPS subscription is blocking SIP INVITE packets from the provider's SBC

Calls Connect but Incoming Audio Is Missing (One-Way Audio)

This is almost always a NAT/RTP problem. The remote party cannot reach your phone's private IP. Check:

• 1-to-1 NAT configuration -- confirm the VoIP subnet is mapped to your public IP
• RTP port range in the policy -- confirm it matches your provider's actual media port range
• Preserve Source Port in Dynamic NAT settings if 1-to-1 NAT is not configured
• Whether a SIP-ALG proxy policy accidentally exists -- if so, remove it and test with packet filter only

Calls Drop After a Predictable Time (30, 60, or 90 Seconds)

Short, consistent call drop intervals on WatchGuard usually point to SIP session timer conflicts, not firewall timeouts. The Firebox closes idle UDP sessions after a configurable timeout period, but a 30-second drop is shorter than the default idle timeout and suggests the PBX or endpoint is not refreshing the SIP session correctly. Check:

• SIP session timer configuration on the PBX or softphone (the Re-INVITE interval)
• Whether IPS is resetting connections based on a rate or pattern threshold
• The SIP-ALG registration expiry setting (default 180 seconds) if a SIP-ALG proxy policy accidentally exists

Choppy or Robotic Audio During Active Calls

Audio quality problems during established calls point to congestion and QoS gaps, not signaling issues. Check:

• DSCP marking in Traffic Monitor -- confirm voice packets are tagged with EF/46
• WAN utilization during the problem period -- run a speed test during a call and compare to baseline
• Whether Traffic Management bandwidth guarantees are configured and active
• Jitter and packet loss using the VoIP network qualifier during an active session

For a symptom-by-symptom breakdown of SIP ALG interference specifically, the SIP ALG troubleshooting guide covers detection and resolution steps across WatchGuard and other platforms.

WatchGuard vs. Other Firewall Platforms for VoIP

If you manage multi-vendor environments, the configuration differences between WatchGuard and other platforms are worth knowing. The key distinctions:

Scroll to see full table on mobile

Configure WatchGuard Firewall for VoIP and Build a Repeatable Deployment Standard

A properly configured WatchGuard Firebox is a capable platform for cloud VoIP -- the Firebox's approach of keeping SIP-ALG off by default actually puts it in a better starting position than firewalls that enable ALG inspection automatically. The configuration is less about fighting default behavior and more about building the right structure: VLAN isolation, a clean packet filter policy, 1-to-1 NAT for SDP rewriting, and DSCP marking that follows voice packets through the entire path to your provider.

For MSPs managing hosted VoIP across multiple client sites, the value of this work is not just the individual deployment. It is the repeatable template. Document the alias names, VLAN IDs, policy structure, and NAT configuration so your next WatchGuard VoIP deployment takes 30 minutes instead of three hours of troubleshooting. Every site that deploys clean the first time is a support ticket that never gets opened.

If you are deploying Viirtue's white-label VoIP platform across your client base, the Viirtue support team can provide SBC IP ranges and port requirements specific to your cluster assignment -- which makes the firewall policy and 1-to-1 NAT configuration significantly more precise than building from generic port lists. Viirtue's partner program is built for MSPs and IT providers who want infrastructure-grade VoIP with full margin control, not a referral arrangement with a provider that owns the customer relationship.