Traffic Shaping with VoIP/RDP over Ipsec
-
Hello!
After many unsuccessful tries to do traffic shaping properly in our scenario, I'm asking if anyone has got a clue on how to do it the right way.
First of all, our network setup:
We have two offices connected via Ipsec.
Office A (192.168.11.0/24, pfSense) has got a PBX (192.168.11.215, SIP 192.168.11.216). There is an additional VLAN (192.168.111.0/24) where WLAN capable machines can connect to. This VLAN is completely isolated from the normal LAN and allows only WAN connections.
Office B (192.168.13.0/24, FritzBox 7490) has got 4 phones which are connected to the office A PBX and a few computers establishing RDP connections to computers at office A.The internet speed in office A is about 1,6Mb/s down and 1Mb/s up (the provider calls it "DSL 16000"), the internet speed in office B is ~7Mb/s down and 3,5MB/s up.
There is another thing that requires special attention: Calls which are dropped at office B will first go to the FritzBox at office B. This is a provider limitation. Then the office A PBX picks them up via SIP and then calls are redirected to the telephones at office B. If someone calls out of office B, it's the same procedure just reversed. So every call will go in 2 directions until it lands on the phone.
The current situation is that speech quality is very bad when the internet connection at office A is under load and RDP slows down from time to time as well.
To roughly explain the plan:
VoIP calls should ever have the needed bandwith, they shouldn't be affected by other network traffic.
RDP should also be of high priority, it should only be queued if VoIP would suffer from it.
All other internet traffic can share the remaining bandwith. If this is needed, the WLAN VLAN could have an even lower priority.What I've done so far is creating a traffic shaper with the wizard, entering 16384Kbit/s and 1024Kbit/s as download and upload speeds. I enabled the VoIP feature and assigned 150Kbit/s as download and upload speeds. In addition I created firewall rules to run all traffic of the PBX in the qAck/qVoip queues. I also enabled the penalty box with 15% and put the WLAN VLAN subnet as an alias in it. The last thing I've done is enable the "other traffic" priorisation and set RDP to higher priority and created a firewall rule in the ipsec section to pass RDP traffic to qAck/qOthersHigh.
This is what "pfctl -s queue" tells me after running the wizard:
queue root_pppoe1 on pppoe1 bandwidth 1.02Mb priority 0 {qInternet} queue qInternet on pppoe1 bandwidth 1.02Mb hfsc( red ecn upperlimit 1.02Mb ) {qACK, qDefault, qVoIP, qOthersHigh, qOthersLow} queue qACK on pppoe1 bandwidth 143.36Kb hfsc( red ecn ) queue qDefault on pppoe1 bandwidth 71.68Kb hfsc( red ecn default ) queue qVoIP on pppoe1 bandwidth 32Kb hfsc( red ecn realtime 150Kb ) queue qOthersHigh on pppoe1 bandwidth 71.68Kb hfsc( red ecn ) queue qOthersLow on pppoe1 bandwidth 153.60Kb hfsc( red ecn ) queue root_bge1 on bge1 bandwidth 1Gb priority 0 {qLink, qInternet} queue qLink on bge1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) queue qInternet on bge1 bandwidth 16.38Mb hfsc( red ecn upperlimit 16.38Mb ) {qACK, qVoIP, qOthersHigh, qOthersLow} queue qACK on bge1 bandwidth 2.62Mb hfsc( red ecn ) queue qVoIP on bge1 bandwidth 32Kb hfsc( red ecn realtime 150Kb ) queue qOthersHigh on bge1 bandwidth 1.31Mb hfsc( red ecn ) queue qOthersLow on bge1 bandwidth 2.46Mb hfsc( red ecn )You can see that it thinks my download speed is 16.38Mb (Mbit/s? Mb/s?) and the upload speed is 1.02Mb. Is this correct? In the wizard, I correctly entered the Kbit/s values.
The specific traffic ends up in the queues but calls are still very bad when the network is under load. If there is no network activity, calls are not affected in any way.
Do you have any suggestion?
Thanks,
Marc -
You have to put some rules for voip traffic on Ipsec interface itself
-
Hi ermal!
Thanks for your answer!
I already created a rule on the ipsec interface. It puts TCP/UDP traffic which goes to the PBX at office A in the qVoip queue.
On the queue status page, I can see packets in the qVoip queue when there are calls to office B. All other queues are empty if there is no other traffic going on so I'm quite sure that pfSense puts the traffic in the right queue but there are still package drops in the qVoip queue when the internet connection is under load. -
Because you need to prioritize even IKE traffic
-
Can you go deeper on that?
You mean setting the whole ipsec traffic to "higher priority" in the wizard?
What I've already done is prioritize VoIP on the ipsec interface, as I said.BTW: We use HFSC for the queues. Is this possible with HFSC or should we switch to PRIQ or even CBQ?
-
I already created a rule on the ipsec interface. It puts TCP/UDP traffic which goes to the PBX at office A in the qVoip queue.
On the queue status page, I can see packets in the qVoip queue when there are calls to office B. All other queues are empty if there is no other traffic going on so I'm quite sure that pfSense puts the traffic in the right queue but there are still package drops in the qVoip queue when the internet connection is under load.Did you use "match" on the rules and not "pass" ?
I think I ended up putting my rules in the floating rules.
-
That's what I did now. Removed every queue rule from the interfaces and added floating rules, then resetted states.
Attached, you can see the floating rules. VoIP_hosts includes the office B phones, the office B router and the PBX adresses.I also changed some queue bandwith values:
queue root_pppoe1 on pppoe1 bandwidth 900Kb priority 0 {qInternet} queue qInternet on pppoe1 bandwidth 900Kb hfsc( red ecn upperlimit 900Kb ) {qACK, qDefault, qVoIP, qOthersHigh, qOthersLow} queue qACK on pppoe1 bandwidth 135Kb hfsc( red ecn ) queue qDefault on pppoe1 bandwidth 135Kb hfsc( red ecn default ) queue qVoIP on pppoe1 bandwidth 315Kb hfsc( red ecn realtime 315Kb ) queue qOthersHigh on pppoe1 bandwidth 270Kb hfsc( red ecn ) queue qOthersLow on pppoe1 bandwidth 45Kb hfsc( red ecn ) queue root_bge1 on bge1 bandwidth 1Gb priority 0 {qLink, qInternet} queue qLink on bge1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) queue qInternet on bge1 bandwidth 15Mb hfsc( red ecn upperlimit 15Mb ) {qACK, qVoIP, qOthersHigh, qOthersLow} queue qACK on bge1 bandwidth 2.25Mb hfsc( red ecn ) queue qVoIP on bge1 bandwidth 5.25Mb hfsc( red ecn realtime 5.25Mb ) queue qOthersHigh on bge1 bandwidth 4.50Mb hfsc( red ecn ) queue qOthersLow on bge1 bandwidth 750Kb hfsc( red ecn )Is this the correct way of doing it or do you have some more tips? There are still some issues with voice quality.
-
I believe the last rule that matches gets applied unless you check the "Quick" box in the rules (I think that tells it to stop processing the rules when it matches that specific rule).
So I think all your rules are written backwards.
-
Ah, thanks for the hint!
We are running the new configuration for 3 days now and it looks quite smooth. Sometimes, calls are interupted for about a second. You then can't even hear the static noise in the call.
It only happens when the internet connection is used very much. Do you have another hint on what to check?
The queues are still the same as before. -
Are you sure 150Kb/s is enough for your VoIP? HSFC realtime will penalize you for going over your allotted amount. If you have it set to 150Kb/s and you start using more, the amount more that you use will count negatively towards your future realtime bandwidth, reducing it below 150Kb/s. The goal is never to use link share for realtime traffic.
It rarely hurts to allocate more bandwidth to low bandwidth traffic, since any unused bandwidth gets shared out anyway.
This is probably due to some of my lack of understanding of HFSC, but personally, I stopped using Realtime specifically because it gets punished for using any link share. Rule of thumb is a link is at saturation when it reaches 80% load. At this point, jitter starts to become common place. For traffic that doesn't care about jitter or latency, like bulk transfers, they can use 100% can not care. For VoIP traffic, it cares. Find your target bandwidth and add 25% more.
Of course, if your issue is lack of bandwidth, there is nothing you can do but add more. All traffic shaping does is allow your to chose winners and losers in a well defined way when fighting for a limit resource.
-
I think you've missed the newer configuration, posted earlier but not in the first post.
queue root_pppoe1 on pppoe1 bandwidth 900Kb priority 0 {qInternet} queue qInternet on pppoe1 bandwidth 900Kb hfsc( red ecn upperlimit 900Kb ) {qACK, qDefault, qVoIP, qOthersHigh, qOthersLow} queue qACK on pppoe1 bandwidth 135Kb hfsc( red ecn ) queue qDefault on pppoe1 bandwidth 135Kb hfsc( red ecn default ) queue qVoIP on pppoe1 bandwidth 315Kb hfsc( red ecn realtime 315Kb ) queue qOthersHigh on pppoe1 bandwidth 270Kb hfsc( red ecn ) queue qOthersLow on pppoe1 bandwidth 45Kb hfsc( red ecn ) queue root_bge1 on bge1 bandwidth 1Gb priority 0 {qLink, qInternet} queue qLink on bge1 bandwidth 200Mb qlimit 500 hfsc( red ecn default ) queue qInternet on bge1 bandwidth 15Mb hfsc( red ecn upperlimit 15Mb ) {qACK, qVoIP, qOthersHigh, qOthersLow} queue qACK on bge1 bandwidth 2.25Mb hfsc( red ecn ) queue qVoIP on bge1 bandwidth 5.25Mb hfsc( red ecn realtime 5.25Mb ) queue qOthersHigh on bge1 bandwidth 4.50Mb hfsc( red ecn ) queue qOthersLow on bge1 bandwidth 750Kb hfsc( red ecn )I assigned 35% of my upload bandwidth (~ 900 Kbit/s) to VoIP which is 315 Kbit/s. From what I've seen, one VoIP call consumes about 100-150 Kbit/s.
-
Are you sure 150Kb/s is enough for your VoIP? HSFC realtime will penalize you for going over your allotted amount. If you have it set to 150Kb/s and you start using more, the amount more that you use will count negatively towards your future realtime bandwidth, reducing it below 150Kb/s. The goal is never to use link share for realtime traffic.
It rarely hurts to allocate more bandwidth to low bandwidth traffic, since any unused bandwidth gets shared out anyway.
This is probably due to some of my lack of understanding of HFSC, but personally, I stopped using Realtime specifically because it gets punished for using any link share. Rule of thumb is a link is at saturation when it reaches 80% load. At this point, jitter starts to become common place. For traffic that doesn't care about jitter or latency, like bulk transfers, they can use 100% can not care. For VoIP traffic, it cares. Find your target bandwidth and add 25% more.
Of course, if your issue is lack of bandwidth, there is nothing you can do but add more. All traffic shaping does is allow your to chose winners and losers in a well defined way when fighting for a limit resource.
Kinda maybe, but it is a moot point since it is near impossible (I tried; failed) to exclusively set real-time in pfSense. "Bandwidth" is link-share, meaning real-time's value will be exceeded as link-share will proportionally make use of all excess bandwidth.
-
With pftop, confirm that everything is going to the proper queues. This is usually my problem.
Queue bitrates on sending interface must be the lowest bitrate of the route. (I think you have success already)
What you have seems like it should work.
I dunno crap about IPSEC/VPN.