How to Configure FortiGate for VoIP (vs SonicWall and Ubiquiti)

Learning to Configure a Fortinet FortiGate for VoIP is not complicated once you know what to fix. The problem is that most guides only address half the issue. They tell you to disable SIP ALG and move on. On FortiGate, that is a two-part process, and skipping either part produces the same broken result: phones that drop mid-call, registrations that fail after a few minutes, or one-way audio that no amount of port-opening will fix.

This guide covers the full FortiGate VoIP configuration for MSPs and IT admins running cloud VoIP deployments. It targets FortiOS 7.x as the primary reference, with notes where 6.x behavior differs. It also includes a direct comparison against SonicWall and Ubiquiti, because those three platforms show up in the same MSP environments constantly, and the operational differences matter when you are building repeatable deployment standards.

Why FortiGate Needs Special Attention for VoIP

FortiGate is a capable firewall, and plenty of cloud VoIP deployments run on it without issues - after proper configuration. The challenge is that FortiOS has more than one mechanism that touches SIP traffic, and they operate independently.

On most firewalls, SIP ALG is a single toggle. On FortiGate, you are dealing with two distinct layers:

• The SIP session helper - a kernel-level helper that intercepts SIP on UDP port 5060 and rewrites headers and SDP body content
• VoIP inspection profiles - application-layer profiles that can be attached to firewall policies for deeper SIP inspection

Either one, left active and misconfigured for your deployment, can corrupt SIP signaling. Modern cloud VoIP providers use Session Border Controllers that handle NAT traversal on their side. When FortiGate's SIP helper rewrites headers that the SBC is already managing, you get conflicts: mismatched contact addresses, duplicate NAT translations, or RTP streams sent to the wrong endpoint.

The symptoms are familiar to any MSP who has debugged VoIP under a firewall:

• Phones register, then drop registration after 30 to 90 seconds
• Calls connect but one side hears nothing
• Calls drop at a consistent interval, often 30 or 60 seconds
• Inbound calls fail while outbound calls work fine

All of those symptoms trace back to SIP ALG interference, UDP session timeouts, or missing QoS. This guide addresses all three.

Step 1: Disable SIP ALG on FortiGate (The Right Way)

This is where most guides stop short. They show the sip-helper disable command and call it done. That command does not fully disable SIP ALG on FortiOS 7.x. Here is the complete process.

Part A: Set the VoIP ALG Mode

Before removing the session helper, set the VoIP ALG mode. This controls how FortiGate processes VoIP traffic at the kernel level. In the CLI console:

config system settings
    set default-voip-alg-mode kernel-helper-based
end

Reboot the FortiGate after this change. The setting does not take effect until the device restarts.

Part B: Remove the SIP Session Helper

After the reboot, open the CLI console again and identify the SIP session helper entry number. It is usually entry 13, but verify first:

config system session-helper
    show
end

Look for the entry with name "sip". Note the entry number. Then delete it:

config system session-helper
    delete 13
end

Replace 13 with whatever entry number your output showed if it differs.

Part C: Check the VoIP Inspection Profile

The session helper removal handles kernel-level SIP processing. You also need to check whether a VoIP inspection profile with SIP inspection enabled is attached to your LAN-to-WAN firewall policy.

In the GUI: go to Policy and Objects, open your LAN-to-WAN policy, and look for a VoIP Profile in the security profile section. If one is attached, either remove it from the policy or edit the profile and disable SIP inspection within it.

Via CLI:

config voip profile
    edit "default"
        config sip
            set status disable
        end
    next
end

If your policy references a custom VoIP profile name, use that name instead of "default."

For a broader look at SIP ALG behavior across firewall platforms, the SIP ALG guide for MSPs and SMBs covers how different devices handle this and what symptoms to watch for.

Step 2: Create a Dedicated Voice VLAN

VoIP traffic mixed onto a general data VLAN creates two problems: QoS is harder to enforce cleanly, and voice traffic competes directly with bulk data during congestion windows. A dedicated voice VLAN solves both.

In FortiGate, create a VLAN interface on your internal switch interface. In the GUI:

• Go to Network, then Interfaces
• Create a new interface with Type set to VLAN
• Assign a VLAN ID - common choices are 100 for data and 200 for voice, but match your environment
• Set the interface to the physical port connected to your managed switch
• Assign an IP and subnet for the voice VLAN (for example, 10.10.200.1/24)
• Enable DHCP server on this interface for phone provisioning

On your managed switch - FortiSwitch if in-stack, or your own Cisco, HP, or Ubiquiti switch - configure the voice VLAN as tagged on uplink ports and untagged on phone ports. If your IP phones support LLDP-MED, the switch can push the voice VLAN assignment automatically without manual configuration per port.

Step 3: Configure QoS and Traffic Shaping for VoIP

FortiGate's traffic shaping engine gives you real control over voice prioritization. The goal is to guarantee bandwidth for RTP media streams, mark voice packets with DSCP EF (Expedited Forwarding, value 46) so upstream routers and ISP equipment can honor the priority, and prevent bulk traffic from starving voice during peak periods.

Enable Traffic Shaping in Feature Visibility to Configure FortiGate for VoIP

In the GUI, go to System, then Feature Visibility (or Feature Select on some FortiOS builds). Enable Traffic Shaping and click Apply.

Create the Traffic Shaper to Configure FortiGate for VoIP

config firewall shaper traffic-shaper
    edit "VoIP-Priority"
        set guaranteed-bandwidth 2048
        set maximum-bandwidth 10240
        set priority high
        set dscp-marking-method fixed
        set dscp EF
    next
end

Set guaranteed-bandwidth based on your expected concurrent call count. A G.711 call uses approximately 87 kbps per direction including overhead. For 20 concurrent calls, guarantee at least 2 Mbps in each direction. Adjust maximum-bandwidth to the upper limit you want voice to consume under burst conditions.

Create the Traffic Shaping Policy to Configure FortiGate for VoIP

config firewall shaping-policy
    edit 1
        set name "VoIP-Shape"
        set service "SIP" "RTP"
        set srcaddr "Voice-VLAN-Subnet"
        set dstaddr "all"
        set dstintf "wan1"
        set traffic-shaper "VoIP-Priority"
        set traffic-shaper-reverse "VoIP-Priority"
    next
end

Replace Voice-VLAN-Subnet with the address object representing your voice VLAN range, and wan1 with your actual WAN interface name. The traffic-shaper-reverse applies the shaper to returning RTP streams, which is equally important for inbound audio quality.

Step 4: Tune UDP Session Timeouts

FortiGate's default UDP session timeout is 180 seconds. That is often too short for VoIP calls with SIP session timers, call holds, or any period of low RTP traffic. When the NAT mapping expires mid-call, the audio stream loses its return path and the call drops.

Increase the UDP timeout on your VoIP firewall policy. Per-policy is preferred because it limits the change to voice traffic only:

config firewall policy
    edit <your-voip-policy-id>
        set udp-idle-timer 300
    next
end

300 seconds is a reasonable starting point. Environments with very long hold times or extended conference calls may benefit from 600 seconds. To find your VoIP policy ID, run:

show firewall policy

Then match by policy name or source interface.

Step 5: Build the VoIP Firewall Policy

Your VoIP firewall policy controls what voice traffic is allowed through and applies the correct security profile behavior. For cloud VoIP, you are typically allowing outbound from your voice VLAN to your provider's SBC IP ranges.

In the GUI, go to Policy and Objects, then Firewall Policy. Create a new policy with these settings:

• Incoming Interface: Your voice VLAN interface
• Outgoing Interface: Your WAN interface
• Source: Address object for your voice VLAN subnet
• Destination: Address objects for your VoIP provider's SBC IPs - do not leave this as "all" in production
• Service: SIP on UDP 5060 or TCP 5060/5061, plus RTP on UDP 10000-20000 or your provider's RTP range
• Action: Accept
• NAT: Enabled, using outgoing interface address
• VoIP Profile: None, or a custom profile with SIP inspection disabled
• Log Allowed Traffic: Session Start and End for troubleshooting

Step 6: Verify the Configuration and Test

Before declaring the deployment complete, run through this verification sequence.

Confirm the SIP Session Helper is Removed

config system session-helper
    show
end

The output should not include any entry with name "sip". If it does, delete it.

Run a SIP ALG Test

Testing tools from 3CX and similar providers can confirm whether your FortiGate is still rewriting SIP headers. The SIP ALG testing and remediation guide walks through how to use them. If the test shows header modification after completing all three steps above, check whether a second FortiGate in HA, or an ISP router upstream, still has a SIP helper active.

Place a Test Call and Exercise Hold Behavior

Register a phone, make an outbound call, and hold it for three to five minutes. If the call survives the hold without dropping, your UDP timeout is working correctly. Test inbound calls separately - they exercise a different NAT path and occasionally fail for different reasons than outbound.

Verify DSCP Marking via Packet Capture

In the GUI, go to Network, then Packet Capture. Select your WAN interface and filter on your provider's SBC IP. Capture a short RTP stream and open it in Wireshark. Confirm the DSCP value in the IP header shows EF (46). If it shows 0 or another value, the traffic shaping policy is not matching correctly.

FortiGate vs SonicWall vs Ubiquiti for VoIP: What Actually Differs

MSPs managing multiple client environments often run all three of these platforms across their book of business. Knowing the VoIP behavior differences before you deploy saves troubleshooting time and prevents the situation where a config that works on one platform gets incorrectly applied to another.

SonicWall VoIP: Simpler to Configure, Less Granular

SonicWall's approach to SIP is more MSP-friendly from a speed standpoint. "SIP Transformations" lives in the Network, VoIP section of the GUI and is a single checkbox. Turn it off, save, and the main SIP ALG behavior is disabled. No reboot, no CLI session-helper deletion required.

The tradeoff is that SonicWall's traffic shaping is less granular than FortiGate's. For most SMB VoIP deployments, SonicWall's app-based QoS is sufficient. For environments with high call concurrency, bandwidth constraints, or SD-WAN voice steering requirements, FortiGate gives you more control without additional licensing. One FortiGate advantage worth noting for MSPs running larger environments: its ASIC-accelerated packet processing means deep inspection and traffic shaping do not degrade throughput the way they can on SonicWall TZ hardware at the lower end of the product line.

Ubiquiti VoIP: Network-First, Not Telecom-First

Ubiquiti gear handles VoIP reasonably well when configured correctly, and many MSPs run it successfully at SMB sites. The SIP ALG situation on Ubiquiti is platform-dependent: newer UniFi OS builds (9.0.114 and later) have SIP disabled by default in Connection Tracking, while EdgeRouter requires a CLI command to disable the conntrack SIP module.

Ubiquiti's Smart Queues feature handles bufferbloat well, which matters for voice quality on consumer broadband where jitter is the primary problem. For a full breakdown of Ubiquiti VoIP configuration, the Ubiquiti UniFi and EdgeRouter VoIP configuration guide covers the exact steps.

Where Ubiquiti falls short for larger MSP deployments is centralized management at scale and SD-WAN maturity for voice steering. For sites already fully on the UniFi ecosystem with UniFi switching and APs, it is a cohesive option. For mixed environments or enterprise-scale deployments, FortiGate or SonicWall provides more reliability and operational visibility.

MSP Deployment Runbook Notes for FortiGate VoIP

If you manage multiple FortiGate deployments for cloud VoIP clients, standardizing this into a runbook saves time on every new install and makes handoffs between techs clean. The core checklist for every FortiGate VoIP deployment:

• Set default-voip-alg-mode kernel-helper-based and reboot
• Delete SIP session helper entry - verify entry number first, do not assume 13
• Check VoIP inspection profile on LAN-to-WAN policy, disable or remove SIP inspection
• Create dedicated voice VLAN with DHCP server
• Configure DHCP Option 66 if your provider supports zero-touch provisioning
• Create high-priority traffic shaper with DSCP EF marking
• Apply shaping policy to voice VLAN outbound and inbound (use reverse shaper)
• Set UDP idle timer to 300 seconds on VoIP policy
• Lock destination addresses to provider SBC IPs
• Run SIP ALG test, inbound call test, hold test
• Verify DSCP EF via packet capture on WAN interface
• Back up config and document the VoIP policy ID and session helper removal

If you manage clients across multiple firewall platforms - some on FortiGate, some on Sophos, some on Meraki - the configuration approach changes per platform but the underlying goals do not. The Sophos Firewall VoIP configuration guide and Cisco Meraki VoIP configuration guide cover those environments with the same depth.

For MSPs also deploying AI voice agents alongside standard VoIP, the firewall configuration matters just as much. AI voice agents using real DID numbers and PSTN connectivity generate RTP traffic and SIP signaling the same way a desk phone does. The same FortiGate configuration baseline applies to both.

Choosing the Right Firewall Configuration for Your VoIP Stack

FortiGate is a capable platform for cloud VoIP deployments when the configuration is done correctly. The extra steps compared to SonicWall's single toggle or Ubiquiti's connection tracking switch are worth it for MSPs managing complex environments, high call concurrency, or clients who need SD-WAN voice steering. The granular traffic shaping and ASIC performance hold up under load in ways that matter when you are supporting twenty-seat offices across multiple sites.

The mistakes that cause FortiGate VoIP problems are almost always the same: incomplete SIP ALG removal, missing QoS, or UDP timeouts that expire before long calls do. Fix those three things correctly and FortiGate becomes one of the most stable firewall platforms for white-label VoIP resellers to deploy at client sites.

If you are building out a VoIP practice on top of a white-label platform and want the billing, tax automation, and quoting infrastructure to support it at scale, that is exactly what Viirtue is built for. MSPs who partner with Viirtue get the UCaaS and VoIP stack, the ViiBE quote-to-cash engine, and a support team that understands the network layer as well as the platform layer. Learn more about the Viirtue partner program and see how other MSPs are building repeatable, high-margin VoIP practices under their own brand.