Configure QoS and Bandwidth Prioritization on a SonicWall (SonicOS 7)

Before you run this

This guide configures Bandwidth Management (BWM) on a SonicWall running SonicOS 7 so that chosen traffic — VoIP, a line-of-business app, backups — gets a guaranteed or higher-priority slice of your WAN link, and everything else yields to it. BWM is the SonicWall's own internal QoS engine; it shapes traffic as it crosses the firewall. (The separate 802.1p / DSCP marking features ask downstream switches and your ISP to honour a priority tag — that is a different, additive topic I'll point to but not walk through.)

This is all done in the SonicWall web management GUI, so you need a full administrator login (the built-in admin account or an account in the admin group). There is no sudo or OS shell involved. There is a limited SonicOS CLI, but BWM is a GUI procedure and the GUI is the normal, documented path.

Treat this as a production-affecting change. Specifically:

• Back up the running configuration first. In SonicOS 7, go to DEVICE | Settings > Firmware and Settings and export/create a settings backup (a local .exp export, and the on-box backup, both work). This is your rollback.
• Keep an out-of-band path open. Getting the interface available bandwidth numbers wrong (see below) can throttle live traffic to a crawl, and a bad access-rule change can affect management reachability. Have console access (the physical console port) or a second admin session from a different network ready so a mistake doesn't leave you locked out while also strangling production.
• Do it in a maintenance window, and change one rule at a time.
• Test the scope first. Apply BWM to a single, narrow test rule (one test host, one service) and confirm behaviour before you touch rules that carry everyone's traffic.
• Rollback path: if a change misbehaves, re-import the settings backup you made (DEVICE | Settings > Firmware and Settings), or disable BWM on the specific access rule you edited. BWM changes are reversible — nothing here deletes data — but a wrong bandwidth figure degrades traffic immediately, so correct it or restore the backup.

I'm writing for SonicOS 7.0/7.1 on a TZ or NSa appliance with X1 as the WAN and X0 as the LAN. SonicOS 7 reorganised the menus into the top tabs MONITOR / DEVICE / NETWORK / OBJECT / POLICY. Menu labels shift between point releases, so where I name a path, confirm it against the SonicOS 7 Administration Guide section on Bandwidth Management if your build differs.

How SonicWall QoS actually works

Three things have to line up, in this order:

1. BWM type — the firewall must be in a BWM mode that lets you shape traffic (Advanced or Global). The default is often None, which means any per-rule BWM settings you make are ignored.
2. Interface available bandwidth — BWM allocates percentages and guarantees of a number you give it. The firewall does not know your real circuit speed, so you tell it the egress and ingress bandwidth of the WAN. Get this wrong and every percentage is wrong.
3. Where the policy is applied — an access rule (security policy) carries the BWM setting and the direction it applies to.

I'll use Advanced BWM, which is the flexible, mainstream method: you build reusable bandwidth objects (guaranteed %, maximum %, priority) and attach them to rules. The alternative, Global BWM, gives you eight fixed priority queues you tune once and select per rule — simpler, less granular. Pick one mode; they are not mixed on the same traffic.

Step 1 — Set the BWM type

In SonicOS 7, the Bandwidth Management type selector lives in the firewall/bandwidth settings area. I won't guess the exact click path for your build — open the SonicOS 7 Administration Guide, find the Bandwidth Management section, and set the type to Advanced. Save.

If BWM type is left at None, nothing in the later steps takes effect. This is the single most common reason "QoS isn't working" on a SonicWall.

Step 2 — Tell the firewall your real WAN speed

Measure or confirm your committed WAN rate first — use your ISP's provisioned figure, not a one-off speedtest. If you have a symmetric 200 Mbps circuit, both numbers are ~200000 Kbps; asymmetric links get different up/down values.

1. Go to NETWORK | System > Interfaces.
2. Edit the WAN interface (X1).
3. On the Advanced tab, enable bandwidth management for the interface and enter the available egress and available ingress bandwidth in Kbps. (Egress = upload/outbound, ingress = download/inbound.)
4. Save.

Set these a little below your line rate (say 90–95%) so the SonicWall holds the queue rather than the ISP's buffer — that's what actually keeps latency down for voice. Confirm the exact field labels on the Advanced tab against the admin guide; don't invent a value for a field you can't see.

Step 3 — Create bandwidth objects

With Advanced BWM, a bandwidth object defines a guarantee, a ceiling, and a priority. Create them under the OBJECT tab (look for Bandwidth Objects — confirm the exact sub-menu in your build). Make at least two:

• BWM-Voice-Priority — e.g. Guaranteed 20%, Maximum 100%, Priority 0 (highest). Voice is low-volume but latency-sensitive, so a modest guarantee at top priority is right.
• BWM-Bulk-Low — e.g. Guaranteed 0%, Maximum 50%, Priority 6 or 7 (low). For backups or updates that should get out of the way.

BWM-Voice-Priority and BWM-Bulk-Low are placeholder names and figures — substitute your own. Priority 0 is the highest and 7 the lowest.

Step 4 — Apply BWM to an access rule

This is where traffic actually gets matched and shaped.

1. Go to POLICY | Rules and Policies > Access Rules.
2. Create or edit the rule that matches the traffic you want to prioritize — for voice, that's typically LAN → WAN with the source being your phone/VLAN and the service being your SIP/RTP service object. Build the service object first under OBJECT if it doesn't exist.
3. In the rule, open the BWM (traffic shaping) section, enable Bandwidth Management, and select the bandwidth object for the relevant direction:
   • Egress (outbound, LAN→WAN) → BWM-Voice-Priority
   • Ingress (inbound) → BWM-Voice-Priority if you also want to shape return traffic.
4. Save, and repeat for your low-priority rule with BWM-Bulk-Low.

Order matters: SonicWall applies the first matching access rule. Make sure your specific voice rule sits above any broad allow-all rule, or the general rule will match first and your BWM object never applies.

Verify it worked

Confirm, don't assume:

• Live traffic view: MONITOR has real-time and connection monitors. Watch the connections for your voice/app traffic and confirm they're mapped to the expected rule and priority while the link is busy.
• Generate contention: start a large download or backup (your bulk traffic), then place a test VoIP call. The call quality should hold and the bulk transfer should back off. That behavioural test is the real proof.
• Rule hit counters: in POLICY | Rules and Policies > Access Rules, confirm the packet/connection counters on your BWM rules are incrementing — that tells you traffic is matching the rule you think it is.
• Log view: check MONITOR logs for any BWM or rule-related messages if a rule isn't matching.

Undo / rollback

• Per-rule: edit the access rule and disable Bandwidth Management (or clear the object selection). Effect is immediate; nothing is deleted.
• Objects: bandwidth objects can be deleted once no rule references them.
• Everything at once: re-import the settings backup from DEVICE | Settings > Firmware and Settings. The appliance restarts into the restored config.
• Turn it all off: set the BWM type back to None — this neutralises every per-rule BWM setting without having to unpick each rule.

If you later want your ISP or internal switches to honour priority end-to-end, read the DSCP / 802.1p QoS mapping section of the SonicOS 7 Administration Guide — it layers marking on top of the BWM you've just built, but only helps if the devices beyond the firewall actually act on the marks.