If you have a Sophos XG or Sophos Firewall in front of a hosted VoIP platform like Viirtue, the most common “mystery issues” are not actually provider problems. They’re usually one of these:
SIP helper behavior (Sophos “SIP module”) interfering with NAT traversal
UDP session timeouts that are too short for real-world VoIP
DoS/IPS protections dropping high-rate UDP voice streams
QoS is not applied correctly, so voice competes with bulk traffic
This post is written for MSPs, IT admins, and VoIP resellers who want a repeatable Sophos baseline that works well with cloud VoIP.
Quick note: All Sophos XG Series hardware appliances reached end-of-life/end-of-support after March 31, 2025. If you’re still deploying XG hardware, you should plan a migration to XGS.
What breaks VoIP behind Sophos firewalls
Baseline call quality targets
Before making any changes, confirm that the network can actually support real-time voice. Standard voice guidance commonly targets:
One-way delay: 150 ms or less
Jitter: 30 ms or less
Packet loss: 1% or less
If your WAN is already exceeding these thresholds during peak usage, firewall tuning will help, but QoS and bandwidth planning become mandatory.
Common symptoms and what they usually mean
Calls drop randomly, or audio cuts out: UDP sessions timing out too fast (very common)
One-way audio: RTP blocked, NAT mapping issues, VPN behavior, or IPS interference
Phones register but behave weirdly after changes: conntrack/NAT table entries, SIP helper behavior
Choppy audio during downloads/backups: voice not prioritized, no traffic shaping policy applied
Problems start when DoS protection is enabled: UDP flood thresholds dropping legitimate VoIP
Why Sophos is “special” for SIP
Sophos includes a SIP helper called the SIP module. It is on by default, uses UDP 5060, performs NAT translation that updates SIP headers, and dynamically opens voice channels.
That sounds helpful, but it can be counterproductive for many cloud VoIP deployments, especially when:
Your provider expects endpoints to handle NAT keepalives
You are using SIP over TCP/TLS
The helper makes assumptions that don’t match your provider’s SBC behavior
Also important: Sophos notes that the SIP helper doesn’t support SIP/SDP messages spanning more than one packet (which can occur with SIP over TCP). Their stated workaround is to use SIP over UDP for control traffic. (docs.sophos.com)
In practice, that often translates to: if you are using SIP over TCP/TLS, keep the SIP module unloaded.
Step-by-step: Sophos XG / Sophos Firewall configuration for cloud VoIP
Step 0: Gather the info you need first
Before you touch the firewall, collect:
How your endpoints connect
Desk phones, softphones, ATAs
Voice VLAN subnet(s)
Provider requirements
SIP signaling ports (often 5060 UDP or 5061 TCP/TLS, but confirm)
RTP media port range (provider-specific)
SBC IP ranges or FQDNs (best practice is to restrict destinations if your provider supports it)
Your Sophos context
Firmware version (SFOS)
Whether IPS, TLS inspection, SD-WAN, or DoS protections are enabled
Step 1: Check and disable the SIP module (SIP helper)
Sophos provides CLI commands to view status and load/unload the SIP module.
Open the CLI (SSH or from admin > Console in the web admin).
Choose Option 4: Device Console. (docs.sophos.com)
Run:
system system_modules show
If SIP shows as loaded and you want to disable it:
system system_modules sip unload
Sophos states the change is persistent across reboots.
When should you NOT disable it?
Only if your VoIP provider specifically requires it for their environment.
If you disable it and see immediate failures, roll back and test provider-guided settings.
But for most cloud VoIP deployments, disabling SIP helper behavior is a common stability win, and Sophos’ own VoIP troubleshooting flow explicitly references unloading SIP in certain problem states.
Step 2: Increase UDP timeout stream (this fixes a lot)
Sophos documents that the default UDP timeout stream is 60 seconds, and recommends 150 seconds for VoIP reliability (or whatever your provider recommends).
From Option 4: Device Console:
Check current settings:
show advanced-firewall
Set UDP timeout stream to 150 seconds:
set advanced-firewall udp-timeout-stream 150
Sophos explicitly recommends 150 seconds as a baseline.
Operational guidance:
Start at 150 seconds.
If your provider recommends a higher number, follow their recommendation.
Avoid “maxing it out” without reason. Longer timeouts can increase state table usage.
Step 3: Review DoS settings (UDP flood can break VoIP)
Sophos documents that an unstable VoIP connection can occur when DoS settings for UDP rate are applied, and specifically points to UDP flood settings causing VoIP traffic to drop.
In the Sophos web admin:
Go to Intrusion prevention > DoS & spoof protection
Under DoS settings, clear Apply flag for UDP flood (or tune the thresholds carefully)
Sophos community guidance also explains that when “Apply Flag” is on, SFOS enforces per-host limits and may drop legitimate high-rate UDP traffic. VoIP is explicitly called out as a common UDP-heavy protocol that can trigger these limits.
Step 4: If IPS/VPN is involved, disable SIP preprocessor patterns
Sophos documents that VoIP call issues over site-to-site VPN or with IPS can be improved by disabling the preloaded SIP IPS patterns:
set ips sip_preproc disable
If you use IPsec tunnels, Sophos also notes a related setting to prevent connection flushing when tunnels come up:
set vpn conn-remove-tunnel-up disable
This matters in real deployments where:
Phones are behind a site-to-site VPN
Or you backhaul voice over VPN instead of local breakout
Step 5: Create a clean firewall rule for VoIP (and keep NAT simple)
At a minimum, you need a rule that allows SIP signaling and RTP media from your voice subnet to your provider.
Sophos troubleshooting guidance emphasizes verifying that you have a firewall rule for SIP and that destination networks are correctly set.
Recommended approach (cloud VoIP)
Outbound rule from Voice VLAN/LAN zone to WAN
NAT: Masquerade (SNAT) outbound
Do NOT create inbound port forwards unless your provider explicitly requires it (most hosted endpoint registration does not)
Rule design tips
Source: Voice VLAN subnet(s) or phone IP host group
Destination: Provider SBC IPs/FQDNs where possible (avoid “Any” if you can)
Services: SIP + RTP (provider ranges)
Log: Enabled initially (turn down once stable)
Security scanning: Keep minimal on this rule if it causes false positives (especially IPS rules that touch SIP/RTP)
Step 6: QoS, DSCP, and traffic shaping on Sophos
There are two different goals people mix up:
Marking packets (DSCP) so upstream gear prioritizes voice
Shaping traffic (QoS/traffic shaping) so voice gets bandwidth under congestion
DSCP marking on Sophos Firewall
Sophos states that the firewall only marks outgoing traffic with the DSCP value configured in the firewall rule so upstream routers can prioritize it. It also notes that when incoming traffic already has a DSCP value, Sophos overwrites it with what you configured in the rule.
Common DSCP choices:
RTP media: EF (46)
SIP signaling: often AF31 (26)
Sophos lists EF (46) and AF31 (26) as standard DSCP values.
Practical recommendation:
Prefer having phones/switches mark DSCP correctly.
Use Sophos DSCP marking only if you need to enforce consistent tags leaving the firewall.
Traffic shaping policy (QoS) on Sophos
Sophos documents how to create traffic shaping policies under System services > Traffic shaping.
Create a policy:
Go to System services > Traffic shaping and click Add
Policy association: choose Rules (so you can apply it to your VoIP firewall rule)
Rule type:
Guarantee if you want voice to always get a minimum share (recommended)
Limit is usually not what you want for voice
Priority: allocate to real-time traffic (Sophos notes this is the default priority behavior)
Bandwidth units: Sophos shows values in KBps, and notes speed tests are in kbps, so you must convert (1 KB = 8 kb). Apply it:
Edit your VoIP firewall rule and under Shape traffic, select the traffic shaping policy.
Key note:
Sophos notes global traffic shaping settings apply to outgoing traffic forwarded to the WAN zone, and default settings apply when no policy matches.
Step 7: TLS inspection and “security profiles” caution
If your VoIP signaling is encrypted (SIP TLS) and/or media is SRTP, avoid applying SSL/TLS inspection or aggressive application inspection policies to that traffic unless you have a specific validated design. Encrypted VoIP should generally be treated like a real-time business application, not like web browsing.
(Keep this simple: build a dedicated VoIP rule and apply only what you need.)
Validation and troubleshooting checklist
A. Validate after every change (in this order)
Phones stay registered for 30 to 60 minutes (no flapping)
Place outbound calls (local and long distance)
Inbound calls ring consistently
No one-way audio (both directions)
Leave an active call up for 10+ minutes (watch for mid-call drops)
B. Look at Sophos logs the right way
Filter firewall logs by the phone subnet
Confirm VoIP traffic hits the intended rule (not a generic “LAN to WAN” rule)
If you changed the SIP module or UDP timeouts, retest after the endpoints re-register
Sophos’ troubleshooting guidance also calls out that misbehavior can relate to conntrack state and that verifying the correct firewall rule match is part of the resolution steps.
C. Troubleshooting matrix (fast diagnosis)
Symptom | Likely cause | What to check/fix |
|---|---|---|
Calls drop, poor quality, intermittent audio | UDP timeout stream too low | Set udp-timeout-stream to 150+ per Sophos guidance |
VoIP unstable when security features enabled | DoS UDP flood thresholds dropping packets | Disable Apply flag for UDP flood or tune thresholds |
VoIP issues over VPN or with IPS enabled | SIP IPS preprocessor interference | |
SIP weirdness, header/NAT problems | SIP module interfering | |
Voice quality tanks during downloads | No traffic shaping policy | Create “Guarantee” shaping policy and apply to VoIP rule |
DSCP not behaving as expected | Marking behavior misunderstandings | Sophos marks outgoing only; can overwrite inbound DSCP |
D. What to send your VoIP provider (or Viirtue support) to resolve fast
Sophos model + SFOS version
Whether SIP module is loaded or unloaded
Current show advanced-firewall output (sanitized)DoS settings state (especially UDP flood Apply flags)
Provider destination IP/FQDN restrictions you are using
A packet capture from WAN during a failed call (SIP + RTP)
Final Thoughts: Make Your Sophos Firewall VoIP-Ready
When VoIP issues show up behind a Sophos Firewall, the root cause is usually configuration, not the cloud provider. The good news is that once you address the SIP module behavior, increase UDP timeout stream values, tune DoS protections, and apply proper traffic shaping, most instability disappears.
A clean, dedicated VoIP rule with minimal interference and validated QoS gives you predictable, repeatable performance across deployments. If you are still running legacy XG hardware, now is the time to modernize and standardize your firewall baseline. Build it right once, document it, and your future self and your support team will thank you.
If you are interested in how Viirtue can support you through our various partner programs, find more information or schedule an introductory call today.
FAQ: Sophos Firewall Configuration Guide
Do I need to port forward SIP ports on Sophos for a cloud VoIP platform?
Usually no for hosted endpoints, because phones register outbound and RTP is negotiated outbound. Only port-forward if your provider explicitly requires inbound delivery to a PBX you host on-prem.
Should I disable the Sophos SIP module (SIP ALG)?
In many cloud VoIP deployments, yes. Sophos provides commands to unload it, and their troubleshooting guidance references disabling it in certain scenarios. (docs.sophos.com)
If your provider requires it, follow provider guidance and validate with test calls.
What UDP timeout stream should I set on Sophos Firewall?
Sophos documents a default of 60 seconds and recommends 150 seconds as a baseline (or your provider’s recommendation). (docs.sophos.com)
Can DoS protection break VoIP?
Yes. Sophos specifically documents VoIP instability when UDP flood settings are applied, and community guidance explains how per-host DoS enforcement can drop legitimate high-rate UDP traffic like VoIP. (docs.sophos.com)
How do I configure QoS on Sophos for VoIP?
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Does Sophos mark DSCP both directions?
Sophos documents that DSCP marking is applied to outgoing traffic based on firewall rule configuration, and it does not mark reply traffic. (docs.sophos.com)
I’m still on Sophos XG hardware. Is that a problem?
Yes from a lifecycle/support standpoint. Sophos states XG Series hardware reached end-of-life/end-support after March 31, 2025 and recommends migrating to XGS. (community.sophos.com)
