SonicWALL Advanced BWM, Not So "Advanced".

  • Home
  • SonicWALL Advanced BWM, Not So “Advanced”.

Note: Article written based on SonicWALL Gen 6 running firmware

This post comes directly from the field, hopefully it will save someone some time. I manage about 30 SonicWALL devices and have spent the last year or so converting from traditional site to site VPNs to tunnel interfaces with OSPF. This gives us the flexibility of moving networks around the organization for DR purposes without having to touch any router configs.

My approach to configuring Bandwidth Management (BWM) on SonicWALL devices prior to tunnel interfaces and OSPF was to use Global mode. This mode has some great benefits. For those who are not familiar, basically you set throughput maximums in the WAN interface config. Global BWM only applies to traffic traversing the WAN. Once the firewall is aware of the WAN up/down speed, you can start assigning types of traffic based on buckets 0 through 7. See below screenshot.

Notice that in Global mode, percentages of overall available speed are used. This percentage is calculated directly from the WAN interface up/down speed you’ve programed. This is great especially if you have multiple WAN circuits that run at different speeds. Any traffic you haven’t classified by firewall rule to a particular category is set as “Medium” by default.

For example if you have two internet circuits and your primary was 100Mbps synchronous with a backup circuit of 20Mbps synchronous. A single firewall rule classifying traffic with “Low” priority at a maximum of 26%, would dynamically update limits from 26Mbps on primary to 5.2Mbps on the backup.

Advanced BWM on the other hand doesn’t use this grid (screenshot above) or percentages at all. Instead you now create “bandwidth objects” where you must program a static maximum and guaranteed throughput allocation. You get the benefit now of applying BWM policies to traffic traversing more interfaces than just the WAN, but you’ve lost percentages. This is an absolute awful set of tools when trying to manage traffic traversing WAN interfaces of different speeds.

So that’s a brief overview of Global vs Advanced BWM. Now for the problem I ran into when converting from traditional site-to-site VPNs to tunnel interfaces with OSPF. Originally I left things at Global BWM. My only goal for using BWM was to throw priority traffic into classifications which would override standard internet usage under instances of congestion. To accomplish this, I had various sets of firewall rules between VPN connected sites. For example, VoIP traffic between the LAN to VPN zone might be classified as bucket 0 or Realtime and guaranteed a certain amount of bandwidth. While another LAN to VPN firewall rule might apply only to SMB traffic and limit it to a certain percentage of the WAN circuit. Sounds easy right? You’d be WRONG!

Turns out that when you create a tunnel interface, SonicWALL calls this a “numbered” interface. To quote the SonicWALL tech from my open case 43560004.. “Global BWM is meant to apply to an interface -The key point here is that it needs to be enabled on the interface itself. On your configurations they are using Numbered tunnel interface policies, what this means is that you went to Network > Interfaces and created a virtual interface bound to the VPN policy, most likely due to advanced routing configurations. -Unfortunately BWM cannot be enabled on VLANs or Virtual Interfaces which is why it is not applying to this traffic when using Global -Global BWM would work if you used Unnumbered tunnel interfaces VPNs, so not creating the virtual interface under the Network > Interfaces”

So why does this matter after my move to tunnel (numbered) interfaces with OSPF? Well, it means that all of my carefully crafted LAN to VPN BWM rules DIDN’T WORK ANYMORE!

So just move to Advanced BWM mode right? Well that is my only option, but let me walk you through this little piece of purgatory.

I already mentioned above that with Advanced BWM you lose percentages. So in the case you have multiple WAN circuits and you need one set of BWM maximums applied under normal conditions vs another under failover conditions, you are just out of luck. The only way to accomplish this is to apply a firewall policy for every single tunnel interface individually. You see each tunnel interface is tied to a VPN, and that VPN uses one WAN interface or the other. In my case, I have about 30 tunnel interfaces on each core router. An absolute mess to manage this many firewall rules, when a simple LAN to VPN rule should be something you can leverage.

To take this a step further, there doesn’t seem to be any provision for cumulation of each rule. For example, let’s say my WAN circuit is only 20Mbps and I want to make sure VoIP traffic always has 2Mbps. If I create 30 firewall rules granting 2Mbps guaranteed, I’ve just allocated 60Mbps of bandwidth. 3 times what I actually have available.

When SonicWALL support was posed with this conundrum, they said something like, “oh, that’s okay. Under instances of network congestion, the assigned “Traffic Priority” will step in and ensure important traffic classified as higher priority takes precedence regardless of traffic throughput allocation.” See screenshot above showing “Bandwidth Object Settings” text. This again is the prompt you get when configuring a Bandwidth Object for use with advanced BWM.

As you might venture to guess, my reaction was along the lines, “Prove it”. I did a full lab on this scenario specifically and found some alarming facts about how this actually works. Basically if the traffic is flowing over numbered tunnel interfaces, traffic priority means nothing. Heck if the traffic is flowing over tunnel interfaces, it doesn’t even respect the maximum throughput you’ve configured on the WAN interface.

LAB Findings with Advanced BWM
1. WAN interface BW settings only respected when used with firewall rule + BW object. Guaranteed vs max, if max goes over interface limit, traffic throttled at interface limit, not BW object limit.
2. BW object with firewall rule also works without interface BW setting configured at all.
3. This is not the case for traffic between two virtual interfaces (tunnel interface). Maximum BW firewall rule (BW Object) will be used even if it is higher than WAN circuit BW setting. Ie.. The device appears not to consider WAN circuit congestion in any way making traffic priority with tunnel (numbered) interfaces useless.

So, like I said. An absolute mess. Basically my only option at this point is to never use circuits of different speeds for failover (Yea right, we live in the real world) and to create static firewall rules classifying ALL unimportant traffic to a specified limit. Any traffic that you want “prioritized”, don’t apply a BW object to. In theory, this will at least allow unimportant traffic to be throttled while important traffic isn’t. Not an elegant solution at all and is indicative of how the SonicWALL product is not for use in the enterprise. I’d love to go through this same scenario with a Fortigate or Palo Alto product and compare results.

Update 20210507: After my support case being open 6 months, SonicWALL support finally has broken down and created what they call an RFE. Basically an enhancement request sent to engineering to update the code. I’m really surprised it took 6 months of pushing, here are the RFEs for reference:

  1. Request ID 3854 – Add percentages to BWM object or bring back global BWM option (Gen 7 OS)
  2. Request ID 4250 – Ability to set Guaranteed BW and Maximum BW based on “percentages” in BWM object (Gen 6 OS)
  3. Request ID 4255 – WAN interface BWM threshold should apply to Numbered Tunnel Interface traffic so that the Advanced BWM Traffic Priority can be used.

Best part is that the oldest RFE has already been open for months. It’s my (the customers) responsibility to call in every so often and badger them for status. Terrible experience.

I did manage to disprove my statement above regarding Advanced BWM rules being cumulative. I had to find this myself mind you, no SonicWALL tech ever pointed it out which is also maddening. Especially given the time spent on support calls with them.

When you go to create a “Bandwidth Action” there is a drop down called “Bandwidth Aggregation Method” with “Per Policy” or “Per Action” as selectable options. Basically if you create multiple access rules using the same action object and you want them to share bandwidth, you choose Per Action. SonicWALL’s official explanation.

  • Per Policy Method – The bandwidth limit specified in a policy is applied individually to each policy 
    Example: two policies each have an independent limit of 500kb/s, the total possible bandwidth between those two rules is 1000kb/s
  • Per Action Aggregate Method – The bandwidth limit action is applied (shared) across all policies to which it is applied
    Example: two policies share a BWM limit of 500kb/s, limiting the total bandwidth between the two policies to 500kb/s

Obviously there are still huge issues with SonicWALL Advanced BWM, but at least it is boiled down a bit at this point through the existing RFEs. Whatever those are. I’m thinking it stands for “Reclusive Frustrating Experience”, sounds about right.

Leave a Reply