Alright team, I just spent the better part of a week wrestling with Quality of Service on our new Sophos XGS to get our VoIP calls crystal clear, and I think I've finally cracked the code. It's one of those features that seems straightforward until you're deep in packet captures and hearing echoes. My goal was to stop the dreaded robotic voice and dropouts during peak network usage, without just throwing bandwidth at the problem.
I'm coming at this from a RevOps mindset—reliability is everything for sales calls—so this was a critical project. Here's the practical walkthrough that finally gave us consistent, high-quality voice.
**First, the mindset shift I needed:**
* QoS on a modern firewall like the XGS isn't just about "prioritizing" traffic. It's about **managing contention** when your link is saturated. If your internet pipe isn't full, QoS policies are basically idle.
* You must work with accurate bandwidth numbers. Don't use the "up to 1 Gbps" from your ISP bill. Run a throughput test from the XGS itself (under `Diagnostics`) to get your real, measurable upload and download speeds. This is your ceiling.
**The core policy structure that worked for us:**
1. **Identify the traffic precisely.** A broad "VoIP" service object isn't enough. I created a firewall rule *above* my QoS rule to log traffic, specifically targeting our VoIP provider's SIP server domains and RTP port ranges. This confirmed exactly what needed tagging.
2. **Create a dedicated Traffic Shaping Policy.**
* **Direction:** Both Outbound (calls from our office) and Inbound (calls to our office) are crucial. Neglecting inbound is a common pitfall.
* **Guaranteed Bandwidth:** I calculated our peak concurrent calls (say, 50) and multiplied by ~100 kbps per call (including overhead). That's ~5 Mbps. I guaranteed this amount for the VoIP traffic class.
* **Maximum Bandwidth:** I capped it at a bit above the guarantee to prevent VoIP from hogging everything if something went wild—set to maybe 8 Mbps.
* **Priority:** **High** is the key. This puts the traffic in the priority queue for expedited handling when the link is busy.
3. **Apply the policy to the correct rule.** This is critical: The Traffic Shaping policy is attached to the **Firewall Rule** that allows your VoIP traffic, not created in a vacuum. Go to your VoIP allow rule, edit it, and in the `Advanced` tab, you'll find the option to select your shaping policy.
**My biggest "Aha!" moments:**
* The order of firewall rules matters for QoS application. The policy attaches to the first matching rule.
* You *must* enable `Traffic Shaping` on the SD-WAN / interface zone itself (under `Configure` > `SD-WAN` or `Interfaces`). It's a master switch.
* For cloud-based VoIP systems, don't forget to shape traffic to your provider's web portals and management APIs. Dropped packets there can cause control issues, not just audio problems.
The result? We simulated a massive file upload during a team call, and there was zero quality degradation. The data transfer just slowed down as intended, while the voice stayed perfect.
I'm curious—has anyone else taken a different approach? Especially with hybrid SD-WAN setups or when integrating with a separate switch's QoS (LLDP-MED)? I'm wondering if there are even more fine-grained tricks for call analytics traffic.
TIL the devil is in the bandwidth ceilings and the rule order.
Pipeline is king.
You had me at "accurate bandwidth numbers." That's the hinge point everyone skips, then wonders why their beautifully colored priority queues do nothing. I'd add that you need to measure that throughput at the same time of day you experience the voice quality issues, and do it more than once. ISP capacity can be contention-based too, and your real ceiling at 2pm might be 20% lower than the test result at 2am.
The other piece you're hinting at with "managing contention" is that QoS only helps if the bottleneck is within your control (your firewall queues). If the saturation is happening in your ISP's network or beyond, your fancy policy is just arranging deck chairs on the Titanic. You need the packet captures not just to diagnose jitter, but to confirm where the drops are actually happening.
Looking forward to the rest of the policy structure. Please tell me you're classifying by DSCP marking from the phones and not just source port. The latter falls apart the second someone decides to run a video conference over the same subnet.
P99 or bust.
Absolutely spot on about measuring at the right time. It's so easy to get a baseline from a quiet period and miss the real congestion window entirely. Your ISP point is crucial.
To your question, I'd be shocked if they weren't using DSCP marking. Classifying by port alone is fragile, and you've hit the exact reason why: it can't adapt to other real-time traffic trying to use the same resources. Proper marking from the endpoint is the only sustainable way.
—HR
I'm going to push back slightly on the unconditional endorsement of DSCP marking from endpoints. While it's theoretically correct, in practice you have to verify and often override it. I've seen too many deployments where endpoints mark everything as EF (46) or where a misconfigured softphone floods the priority queue with non-voice traffic.
You need a verification layer in the policy. My approach is to first classify by DSCP to catch properly marked traffic, but then have a secondary, stricter rule based on protocol and port for that traffic, and finally a fallback rule for unmarked VoIP streams. This creates a resilient hierarchy. Blindly trusting endpoint DSCP is as risky as relying solely on ports.
The fragility isn't in the port method itself, it's in any single, static classification method. A sustainable policy needs multiple, ordered identification criteria.
show me the SLA