In this case it is hosted PBX. Phones at remote site with pepwave. Servers at data center with balance 710 or larger. pepvpn between them.
As far as I can tell, with all the testing I have done, what you mentioned really does not do anything. Again, seems like you can successfully manage bandwidth WITHIN the VPN, or outside the VPN, but not actually reserve bandwidth for the VPN. If someone nails the WAN with a big download quality suffers.
We have a somewhat similar setup. We use a SIP server at each site rather than hosted SIP, but the servers talk to each other through the VPN for site to site calls so we are putting SIP traffic through the VPN. Its reasonably reliable. I have several priority features, not sure which one gets it done.
The SIP servers are Managers with reservation as described above. You would have to make all the phones Managers. Sounds like you’ve already tried that.
Network > QoS > Application. Select all supported VoIP protocols and set to high.
Network > QoS > Custom 5060-5064 set to high (likely a duplicate of above)
. Network > QoS > Custom 1000-20000 set to high (likely a duplicate of above)
Nothing else should be set to QoS high
If you are using multiple WAN sources for either end of the VPN, try using just one source. I never got reliable voice with multiple sources, probably because one of my WAN sources is DSL, and latency is terrible. I have my Speed Fusion sources set to priority 1, and priority 2 (DSL) instead of making them equal. That means DSL is not working in the VPN unless WAN1 fails. It also unfortunately means there is a disocnnect while the other source reconnects.
if all else fails you could restrict the individual non-VoIP users with Bandwidth Control > Individual Bandwidth.
Question - is there anything NOT running over the VPN that can eat all the bandwidth? If not, you may not be running into the issue I am. Because everything you described sounds like it would be doing QOS within the VPN, but not protecting the VPN or what is travelling over it from general WAN congestion. In my testing, that it the issue…at the point where the QOS needs to be working to protect the voice it does not SEE 5060 or 1000-20000 traffic, because it is already hidden in the VPN.
Difficult to say, since it is very hard to tell what the QOS is doing at any given moment, but this is why I am asking to just protect the VPN itself. And my preference is to make it simple: I want to be able to dedicate bandwidth to the VPN.
My situation is pizza restaurant. three things use bandwidth: Phones, POS system and public wi-fi. POS uses very little and is not very sensitive to congestion. Phones use a little more and of course are very sensitive. Phones run over VPN. POS straight to internet. public wi-fi straight to internet. that damn public wi-fi is the problem. There are a lot of ways to fix this:
Again pushing for this one. I would really like to be able to reserve some fixed bandwidth for the speedfusion VPN connection itself. Not play with QOS within it, but protect the VPN from other straight-to-the-Internet traffic.
+1 for me, peplink team can we get this feature added?
So - This feature was added for me in a custom build 7.0.1s061 build 2696 which works GREAT. It basically gives priority to the PRPVPN traffic itelf, so other WAN traffic cannnot congest the VPN traffic. No control for it - it is just on.
To avoid wasting time, let me pre-answer the people who will respond “Buy you can prioritize services inside the VPN”: Yes, without this change you can
I have seen a dramatic impact on customers with either poor interne speeds or just too much traffic, such as sports pubs with 80M down/10M up internet, but on game day they had quality issues just because the public wi-fi was congesting the WAN.
Went to this version - no issues. It is not perfect (no bandwidth control ever really is), but it is damn good.
And in my home office, where I have a total crap Windstream DSL line (25M down, 800K up on a good day) I had a lot of trouble. If I sent a large email, or was using screen share people heard distortion. So I would bring up the cellular and have my speedfusion prefer that just to have clear audio.
Installed this version - works great. no audio issues.
But…for some reason this is not getting rolled into production. I really need this, as I cannot go to current firmware otherwise.
This is one of those “why would EVERYONE not want this feature” features.
I would use that feature
I really like the sound of being able to prioritise PepVPN traffic for managed services… +1 from me.
This is in GA as of 7.1. At least, I have been told that it is there. Since it is not a control, just “on” the only way to tell is test by congesting a WAN. I can tell you that it works very, very well.
we have hundreds of sites with IP phones that connect over PepVPN, plus regular traffic and public Wi-Fi going out the WAN.
Before this feature, the public wifi would regularly crush the VPN traffic and cause bad audio - just because the WAN was congested.
With this feature the pepwave does it’s best to give priority to the VPN tunnel itself over other WAN traffic. I would say that complaints of bad audio dropped by at least 95%, and the remaining ones are usually when the WAN is just bad.
“This is in GA as of 7.1”.
What is GA? Where is this setting?
Don GA refers to “General Availability” which would be the standard firmware available to all users. Most of the cutting-edge stuff is “Beta” and not available as a standard firmware update. Hope that helps.
OK, so where is the setting to reserve bandwidth for VPN?
Unfortunately it is not a setting - it is just on. I do not see why you would need to turn it off, but of course I DID ask for it to be a setting. They just did not implement it that way.
Would be good to define the priority within subtunnels of a speedfusion. Otherwise we fall back on the same issue…
Hi all,
We target to implement this on v7.1.1. We will keep posted the update.
Did this get included in 7.1.1 beta?
You can find this option under “Network > QoS > Application > PepVPN Traffic Optimization” in 7.1.1 beta.
No. Priorities between subtunnels is not implemented yet.