It's always worked for me, on all the big five. I've just tested it now (having disconnected from my PIA VPN) and it worked fine.
The VPN works too (obviously). I do sometimes find that switching to TCP (which should make it slower due to overhead) makes it faster, but it's ISP dependent, which implies the OpenVPN UDP traffic is being throttled.
Does this also work if you're using the generic OpenVPN client to connect to the VPN? I've used a bunch of different VPN providers over the years, but they usually just offer an OpenVPN configuration that you can use with the normal client. I'm not aware of this also allowing them to send traffic the other way, but maybe it does?
My VPN activities run on a old Windows box, and I did not want to trust the VPN clients to not fail and blast my data in the open for a day or two before I noticed. I ended up writing a SafeVPN Windows service that kills processes within 30 seconds of VPN failure.
I used PIA for a couple of years without issue, but then it went into some kind of decline for me, always driving network traffic to zero after a few hours. After changing hardware and reinstalling the OS with no effect, I finally tried AirVPN and things went back to normal. AirVPN is a bit more expensive, but their client is light years ahead of the PIA client.
Using it since a couple of years. They never seem to be the bottleneck, but it is hard to test since I am too cheap to get anything else than the lowest bandwidth (30/30). I get 2.2MB/s down and a bit less up, which is about the same as I get without VPN.
The app is nice (at least on Linux), but for environments where it doesn't work they provide openvpn files.
I just run an OpenVPN server on a VPS that I use for other stuff as well. It works well, but I really only use it to secure public wifi and to keep my ISP out of my traffic since they started ridiculous policies like 6strikes.
I always assumed that a VPN would significantly degrade connection speeds, but it's turned out to only be a change of 20ms or less.
Interesting. I've not noticed performance issues beyond those expected due to signal quality when using work's VPN over a tethered phone using EE. That VPN is using OpenVPN with a UDP transport. Then again it doesn't get used for anything with high throughput so perhaps they only throttle when it looks like bulk transfers are happening or the effect of the throttle just isn't apparent for my interactive use-cases.
> or have you found a way around this?
If they are throttling UDP for your use case then you could try a TCP based VPN (OpenVPN supports this), though there are potential issues with layering TCP inside TCP particularly on high-latency connections so this is not usually recommended. Might be worth a try to compare/contrast though.
I have a play with mine both ways when I finally get round to adding it to my current phone (mainly to use the network level ad-blocker running at home) and see if I can see a measurable difference with each variant.
Tried them out yesterday and they give about 10% of my Internet speed on any server. So my 400 Mpbs connection slowed down to 40 Mbps, which is a pretty rough drop. And I haven't been able to find an OpenVPN connection that could handle more than that 40 Mbps.
I've used commercial VPN with acceptable (think ~100Mbps) but not amazing throughput.
But for BT I just set up a secondary on-demand network interface on my Linux server specifically for OpenVPN (just need a shell script to add a couple ip(8) rules, and stick that shell script into the up command of ovpn config). Then I bind my transmission-daemon to that specific interface (bind-address-ipv4 option). This way all BT traffic goes through OpenVPN, but other traffic is not affected. Works for any OpenVPN provider.
That's not been my experience with OpenVPN. It's setup to reconnect to the VPN and only route traffic via the VPN (separate box, actually a repurposed old laptop). Take a look at ping and ping-restart options
It works great on mullvad for me, never any issues. I just installed the PPA for Ubuntu 18.04 and everything else was easy peasy. Some people say it's faster for them but I don't see that on my Gigabit connection, just a bit less CPU compared to openvpn, but neither really uses all that much, it's a fraction of a single processor on my 6 core machine.
I've heared the claim that TCP over TCP doesn't work well countless times. I've been using OpenVPN in tcp mode for at least 5 years on a daily basis and never noticed a problem. I've even done SIP over a TCP OpenVPN configuration without a noticeable problem.
It makes sense to me that it should perform badly, and it probably does for uses cases with a lot of traffic, but for an average user on a laptop, a TCP based VPN is fine.
Anyone know if there's something weird about OpenVPN that makes it particularly bad? You'd think crypto + UDP encapsulation at consumer internet speeds would be pretty straightforward to implement performantly in this day and age.
The VPN works too (obviously). I do sometimes find that switching to TCP (which should make it slower due to overhead) makes it faster, but it's ISP dependent, which implies the OpenVPN UDP traffic is being throttled.
reply