Wireguard vs OpenVPN on NordVPN with T-Mobile Home Internet on Debian GNU/Linux. Bonus: T-Mobile Home Internet Nokia modem has bad WiFi defaults.

NordVPN offers Wireguard and OpenVPN, but defaults to OpenVPN on Linux and Wireguard on Windows.

Windows networking is awful. Like truly catastrophic.

Before Private Internet Access went to hell, I once spoke to their former tech support people about Windows 10 in their IRC chat room, and “Max-P” told me that writing VPN software for Windows was the worst part of the job. He said that preventing “leakage”, that is, where your kill switch doesn’t work and your traffic spills out onto the open internet, which is what you bought the VPN to avoid, is very difficult to ensure on Windows.

Furthermore, it’s hard to get any decent sort of throughput on a VPN in Windows, because Windows doesn’t have any sort of usable and secure VPN tech included in the OS. In fact, NordVPN says that if you try using IKEv2 in Windows 10, it will sabotage it by using weak cryptography. (“Note: the Windows system configuration downgrades the cipher to the weaker 3DES-CBC encryption.“)

Most Windows VPN software use “WinTun” to route traffic around and are essentially rate limited and use a ton of CPU time for overhead. That is, doing nothing important at all and tying up system resources. Creating more bottlenecks due to inherently bad design.

The VPN situation on Linux is….better. If it doesn’t make your networking stack great again, it’ll at least help make it tolerable. You can set up NetworkManager and bypass VPN software entirely, and use OpenVPN binaries from your Linux distribution, or you can use something like NordVPN’s client which makes things a little bit simpler, hopefully, with commands like “nordvpn c”, “nordvpn d”, “nordvpn set autoconnect on”, “nordvpn set killswitch on” and so on.

It takes but a few minutes to understand how to use NordVPN’s Linux software, and unlike the Windows version, there isn’t all sorts of nasty stuff going on behind the scenes. The killswitch is just firewall rules. There doesn’t need to be a lot of crazy stuff going on that can make your internet connection unusable if the connection drops out until you reboot the computer, which is what often happens on Windows 10. Also, their client for Linux doesn’t pop up notifications to go read their blog posts.

That being said, their support for Wireguard actually is less than ideal.

Wireguard got merged as a Linux kernel module back in Linux 5.6, which means that any VPN software could just use this module and avoid context switching overhead between a wireguard client operating as a normal program outside the kernel’s networking stack.

This would especially be beneficial these days, since Intel’s buggy CPUs required hacks like Kernel Page Table Isolation to prevent data leakage attacks. Depressingly, as of Tiger Lake, Intel’s 2020 CPU lineup, most of these Meltdown and Spectre-like vulnerabilities are still there and exploitable at the chip level without firmware and OS mitigations in place, and if you care about security you won’t turn them off.

However, NordVPN doesn’t use wireguard’s kerenl module. It uses their own, in userspace, and as such I’ve been unable to figure out any real benefit of “NordLynx” over OpenVPN in throughput.

In fact, my ISP, T-Mobile, has issues with VPNs period in the way of performance that are well known and all over the web.

They keep pushing new firmwares to the only gateway device that’s authorized on their network (the Nokia “Trash Can”), but things have only marginally improved, and I experience more technical difficulty with Wireguard in general than with OpenVPN.

In fact, while I was writing this, I managed to sort out some of the technical difficulties I’ve been experiencing with the Trash Can itself, including the fact that it has a 2.4 GHz network and a 5 GHz network, and broadcasts the same SSID (network name) for both, so this sometimes results in your 5 GHz capable devices landing on the much slower and more congested 2.4 GHz channel, and with weaker WPA security (2, not 3). While I was in the modem’s web configuration interface, I separated the WiFi SSIDs so there’s clearly a 2.4 and a 5 version, and then connected all of my devices to the 5.

This also seems to have fixed some intermittent connection issues that NetworkManager complained about on Debian. (Intel Wireless driver complaining about unexpected missing frames and deauthorization from the network!)

It’s tempting to just blame Intel for everything, and I was because they’ve shown themselves to be too incompetent to be trusted to design hardware that works as expected in the past 5 years or so (Skylake was unreasonably bad and they haven’t improved a lot.), but then I noticed that T-Mobile’s Nokia modem is also such a piece of crap that it was factory-locked to Channel 1 on the 2.4 GHz network, instead of “Auto” mode, which can tell if there’s too much congestion on a channel and try to switch to a better one to clean up the signal. So not only might you actually end up on the 2.4 GHz network with modern equipment, thanks to the trash can, you also might not get a good channel for it. And of course, you will never hear this from a T-Mobile tech support agent.

It’s a shame, because Wireguard really is much simpler and if this stupid modem and T-Mobile would cooperate with it, I’d be using it. But OpenVPN isn’t really THAT bad as NordVPN implements it. They pretty much take all of the configuration options that could get you into serious hot water away and all you can really control is whether it uses TCP, which runs like crap on T-Mobile, or UDP. So between that and T-Mobile’s Wireguard problems, it’s an easy choice for me. I only have one, and it’s the default anyway.

What I’d like to see going forward, other than T-Mobile getting their shit together, is NordVPN leveraging what’s inside Linux anyway and hopefully bringing a better experience to all Linux users going forward. At some point, carrying around a Wireguard module of their own will only complicate their software.

VPN companies should be handling protocols like drivers on Linux, where every VPN has their own software, but they all use the same kernel modules. When you use Linux, the kernel _is_ most of the drivers as well. This has many advantages for the user because they get a consistent experience where unexpected problems in vendor implementations and mismatching ABIs and other horrors, like what plays out on Windows with the drivers, are avoided.

Nobody who uses hardware supported by the Linux kernel needs to worry about whether they have Intel Bluetooth 22.6.0.3.7 and whether Linux will clobber it with something too old to work properly with the operating system, like Windows would, and install 20.4.0.1 and cause their mouse and airpods to stop responding. I mean, this is what happens in Windows when vendors are responsible for drivers, and Microsoft moves at a glacial pace with Windows Update’s drivers, and pushes out old crap to overwrite your drivers.

Nobody in the Windows world takes responsibility for anything, and when nobody is responsible for anything, nobody fixes anything, and the disaster just keeps rolling along. I’m beside myself in disbelief that there could be anything organic coming out in the “tech media” praising Windows, much less “Windows 11”.

No, people, we’ve heard this all before and we’ll hear it all again. When the Google-bombed fake praise for themselves, bought from the media, which launders PR blurbs as piece work, on outfits like ZDNet subsides, it’ll be Windows Vista or Windows 10 all over again.

If more VPN providers choose to unlearn their nasty development habits from Windows, and leverage the Wireguard kernel module in Linux, you’ll start to see less redundancy, higher performance for the user, and less complexity, because sooner or later everyone bumps their Linux kernel. If Wireguard changes, you just give everyone a reasonable amount of time to update and then drop support for the old version on the server end.

Anyway, the first version of Wireguard is VERY tiny and well-defined, so the odds of breaking changes are lower than OpenVPN anyway, which has 100 times as much code.

Further, a NordVPN tech support person told me that right now their 3.10 client is having connection issues, and that they’ve revived the 3.8 series and advise downgrading to that, because, well, you guessed it. Inconsistent OpenVPN client behavior. Someone brought in a new OpenVPN client in 3.10, and it’s giving some of their servers issues.

OpenVPN has never been part of Linux, and it’s hard to see it ever becoming part of Linux in the same way Wireguard has.

I agree with Linus Torvalds, that just looking at code, you can see where OpenVPN is a coding horror. Nobody should be using DES/3DES (they date back decades, the NSA certainly corrupted them to begin with, and there are modern replacements) in a VPN, or even have that option available, and with the upstream OpenVPN client, using that or any number of other seriously bad options is possible.

Luckily, most major VPNs, like NordVPN, take away the bad options so you can’t turn them on.

Hopefully, T-Mobile and NordVPN work out their own issues that are contributing to a sub-optimal VPN experience, but you can work out the ones that involve the OS and bad default settings on a modem.

In the mean time, simply due to different defaults, T-Mobile users would just have a better experience on NordVPN than their Windows counterparts, due to the fact that the Windows client defaults to NordLynx which doesn’t get along as well with the ISP. Had everything with NordLynx been working perfectly when I was on Windows and suddenly stopped working well on Linux, I’d have suspected it was an issue on Linux. OpenVPN UDP connections are pretty darned stable and I get something at least close to my underlying internet connection speed.

For now, I’ll just keep using OpenVPN.

1 thought on “Wireguard vs OpenVPN on NordVPN with T-Mobile Home Internet on Debian GNU/Linux. Bonus: T-Mobile Home Internet Nokia modem has bad WiFi defaults.

  1. Pingback: Links 29/9/2021: Further Microsoft Declines in Servers, Godot 3.3.4 RC 1 | Techrights

Comments are closed.