QOS options for firewalls at endpoint location

(David Johnson) #1

I have read through a bunch of posts talking about QOS and almost all that I have seen were directed at the PBX side. I have a PBX in a hosting center with very high speed internet. My issue is some of my clients have crappy broadband services with limited upload speeds in the order of 10Mbps. With the computer traffic on the same line even minimal office work frequently interferes with voice quality. I have many offices on better services like FTTI and only my broadband users have issues. I am looking for more information on what ports I should be enabling on the firewall QOS settings? Although any information is better than none I am hoping for some direction specific to my sonic wall customers.

I am only concerned with sending QOS settings from the perspective of the firewall as I have plenty of download speed and I believe my issue is purely an upload issue. I can see some of the phones in EPM that typically have response times in the order of 50-60ms often go above 100ms and in a few cases as high as 1000ms. Obviously this is an issue as some of the phones deregister and then call flow suffers, people randomly cant use their phones other times calls go straight to VM.

SO unless I am misunderstanding something I want all traffic to my pbx to be given a priority. I am somewhat confused though about the call flow and once a call is in progress does the phone talk directly to my SIP provider or does it still go through the pbx? Do I need to add my SIP provider to the QOS too?


It’s possible to configure Asterisk so voice packets flow directly between endpoints, but that’s usually undesirable. Among other things, you can’t record the call, listen for DTMF, transcode, encrypt/decrypt, or capture traffic for debugging. If Direct Media (pjsip) or canreinvite (chan_sip) are set for both extension and trunk and the endpoints behave as if on a public IP, media will flow directly.

IMO, just prioritizing all traffic to the PBX is a good solution; the SIP traffic is small compared to the media and shouldn’t cause any trouble.

I believe that with SonicWALL, like with most firewalls, you must set a total bandwidth for the connection that is somewhat lower than what the provider accepts e.g. 9 Mbps in your case, so the priority traffic can go ahead of other packets queued in the firewall. If they get queued in the modem, it’s too late.

(Aaron) #3

You need something at the customer site that will dedicate bandwidth for voice traffic. So 10/2 connection. Limit non voice traffic to 8/1. Etc.

This is how I do it with mikrotik

  1. Mark any connections to pbx source and dest
  2. Set the dscp priority for those connections
  3. Based on those connections mark packets as voip
  4. Setup a queue for data and limit it to non marked packets.

Sonicwall has Bandwidth management too. Its not as good but you can likely figure it out.

(David Johnson) #4

Thanks, the connection is 245/12.5. I’m only worried about the 12.5 up as thats the issue. Anyone have suggestions on Sonicwall settings for this? The sonic wall admin added a QOS and said it had to have q803 tagging to work but when he applied his config all the phones lost connection so we backed it out.

(Aaron) #5

There are plenty of white papers on sonicwall qos. Ideally youd set your bandwidth on the wan port. Then on your data rules set max and guaranteed bandwidth for upload and download. Create a for data going to or from the pbx and set its guarenteed and mac bandwidth. Along with proper udp timeouts on those rules not the sonicwall default 30 second timeout.

Dscp or 802 whatever tagging he was talking about isnt bandwidth shaping. You need to limit the data side traffic.

Honestly Id just put a miktotik as a qos switch either behind or in front of the sonicwall since I dont really like sonicwalls QOS.

Pretty sure in newer sonicwall firmware versions You can tag different rules with dscp values and then specify bandwidth based upon the dscp values.

To be fair qos is his job not yours but I do a lot of stuff thats not my job.


Do some tests after hours so you understand what’s going on. Make sure the line is relatively idle and not being heavily loaded by cloud backup or other background tasks.

  1. Make a call between extensions in different rooms. Play music (from a smartphone, radio, etc.) into one phone. Listen carefully on the other extension for dropouts or other anomalies. If the quality isn’t near perfect, stop and investigate – it’s probably not a QoS issue.

  2. With the call still in progress, run a speed test on a PC. During the upload phase, you would expect obvious dropouts and a reading close to 12 Mbps (the two voice channels are using less than 0.2 Mbps).

  3. Set up bandwidth management on the firewall. Initially choose a relatively low egress speed, e.g. 8 Mbps. Confirm that a speed test now shows slightly less than 8 Mbps upload.

  4. Give priority to all UDP packets destined for the PBX IP address. If this is working properly, a speed test should no longer cause voice quality problems, but should still show at least 7.5 Mbps.

  5. If all of the above are successful, try setting a higher egress limit e.g. 11 Mbps and confirm that voice quality is still good during heavy upload.


First, you need to figure out what QOS tags the endpoints are applying to the SIP (typically EF) and control (typically CS3, but sometimes others) packets. Once you determine that…

Second, you need to configure your firewall to give priority to those packets over all other packets. In other to do that effectively, you need to know your total bandwidth and how to configure your router to do so.

(David Johnson) #8

I did do diagnostics, the phones work perfectly fine when no one is on the computers. I can also see in my PBX EPM the response times for phones from from 40-50 ms to 100-1000ms when the office is busy doing computer work. Its a small office (actually an eyeglass store) with only a few people and 7 phones. Before people come in and start using the computers I have no issues with any phones. Will pass your QOS suggestions on to the sonicwall admin.


More robust Mikrotik recipe,


(Franck Danard) #10

You must have a QoS every where.

  • Side your customer. He have to setting up a QoS in his LAN / WAN, (RTP, + SIP protocol).
  • Side you PBX server of course.
  • Side the providers as well. Because, if the provider is not transparent (QoS passthrough), then you are dead to get the QoS.

The best practice to use a good QoS, is to separate the VOIPs and DATAs on two distinct VLAN and apply the QoS on the VOIPS VLAN

  • VLAN 0 = DATA
  • VLAN 10 = VOIP

Side the customer, if the QoS is applied and his provider is not transparent with the QoS, It’s like your QoS was not really used here.

You can check that with Wireshark, if you see any DSP tag.

(David Johnson) #11

Thanks for all the help everyone. Please note, although I love the Mikrotek solutions, and I have customers that use Mikrotek devices, this customer doesn’t. I can not switch to a Microtek as its not my network. My customer has their own IT department and they use sonicwalls in ALL their stores and I will NOT be able to get them to use a new devices. I cant even get in to see the firewall, I can only make suggestions to the IT group that manages the devices. With that said, I was hoping some one out there had some sonicwall experience with setting up a QOS. The managing companies idea of solving this was to enable tagging which they claim will allow the priorities already set in voip traffic to flow through. After doing some research I found this fantastic video https://www.youtube.com/watch?v=_coaJwU2kg0 that shows how to setup exactly what I need! We will try on Monday and I will let you know how it goes.


I took a look at the video and was underwhelmed.

First, he prioritizes an IP phone by IP address. This is not a scalable solution, though for your present case with only seven phones it’s not awful. Implied, you have to set up DHCP for each phone so the IP addresses don’t change.

Next, the service group doesn’t include RTP ports (the only thing that’s important). This might be handled by SIP ALG but in my experience enabling SIP ALG on a firewall often causes trouble.

(This shouldn’t be all that complicated. Just prioritize all UDP packets destined for the PBX.)

Finally, he doesn’t even mention setting up the total egress bandwidth for the connection, required for prioritization to have any effect.

(David Johnson) #13

I understand he has other videos, my sonicwall guy was already setting via IP’s so I choose this one. He is setting it up so ALL traffic to my PBX IP will be in the prioritized BW. In the video He chose the voip phone from the network objects list obviously you could create/choose any other option like services, network, IP block, etc. At least it went through all the steps so we know what has to be configured.

(Aaron) #14

You are wrong about mikrotik and it not being your network. You can actually do cool things like put it in as a dumb “edge switch” that does qos either before or after the sonicwall. Thats its only purpose is bandwidth management. Regardless sonicwall qos is not that hard. Also dscp values are great but only get applied after the network is already congested. You need to do bandwidth shaping. Exactly the same as you would on a mikrotik queue. If data upload is limited to 9M for anything non voip you no longer have a problem. If this is too complicated for them. Require a second internet connection. Doesnt have to be expensive. $50. Solves all of your problems.

(David Johnson) #15

no I think you missed the point. I know how a Mikrotik can be used, we have them and I have many customers who use them to extend our network elsewhere. We also have plenty of setup where we install internet and then use Mikrotik to extend the service over dishes to another location before they connect to the customers network. The point you are missing is that “ITS NOT MY NETWORK”. I sold the phones and phone service and another company owns and manages the network infrastructure that they are plugged into, all of it and we dont touch it.

(Aaron) #16

Sounds like their network isnt your problem then. Let their IT figure it out or require a second dedicated internet connection. Done.

(Aaron) #17

I was merely stating Ive put MK’s where the ISP comes in before their network. I never touch their network. I touch their internet connection. The same as an ISP would if they vlaned off their fiber line for phones. They wouldnt run two fiber lines in or maybe they would but at somepiint their is a device splitty off the traffic.

Once again if their IT is inadept to understand basic networking then require a second Intetnet connection. There is no point in asking for sonicwall tutorials when you cant touch their network.

(David Johnson) #18

I provided the sonicwall video to them any they were very appreciative. They made all the changes in the sonicwall per the video and out configuration. Ill find out on monday if it works.


That will work – until you move your PBX to a different data center at some time in the future.

I prefer to have each endpoint set DSCP on SIP and RTP, typically AFxx and EF respectively. AF31 seems to be the most common choice for SIP. The remote firewall would then use DSCP to enqueue the SIP and RTP traffic. Simplification: Use EF for both SIP and RTP and add 5% to the required RTP bandwidth to cover the SIP traffic.

Disclaimer: I know nothing about Sonicwall, so this may not be applicable.