Alright, let's cut through the usual marketing fluff. I've been running NordLayer (formerly NordVPN Teams) on Linux workstations and servers for a few years now, and the performance is consistently and frustratingly subpar compared to the same setup on Windows or macOS. We're talking about latency spikes that make SSH sessions hang and throughput that bottlenecks well below my provisioned bandwidth, especially on UDP.
This isn't a "my internet is slow" issue. I've replicated this across multiple distributions (Ubuntu LTS, RHEL derivatives, even a barebones Arch install) and multiple network contexts (different ISPs, data centers). The Windows client on the same hardware, same network, sails through.
Before we get the usual "contact support" non-answer, let's pool some actual troubleshooting data here. I'll start with my baseline and what I've ruled out.
**My Environment & Baseline Tests:**
* Client: NordLayer v3.16.0 (CLI and GUI show same performance)
* OS: Ubuntu 22.04.4 LTS, kernel 6.2.0
* Connection: 1 Gbps symmetric fiber, wired.
* Protocol tested: NordLynx (WireGuard) and OpenVPN UDP.
**What I've Already Eliminated:**
* **Not a DNS issue:** Using custom resolvers (1.1.1.1, 8.8.8.8) with and without the VPN.
* **Not a MTU issue:** Manually set MTU for both WireGuard and OpenVPN interfaces, tried values from 1200 to 1500. Slight improvement at 1400 for OpenVPN, but WireGuard still crawls.
* **Not a CPU bottleneck:** `top` and `htop` show minimal load during transfers.
* **Basic speed test without VPN:** `iperf3` to a local server shows 940+ Mbps.
**The Symptom in Numbers:**
Running a simple `iperf3` test to a known-good server with NordLayer connected (NordLynx, nearest datacenter):
```
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 112 MBytes 93.9 Mbits/sec 214 sender
[ 5] 0.00-10.01 sec 110 MBytes 92.3 Mbits/sec receiver
```
Same test on Windows client, same server: 650+ Mbps consistently.
**My current hypothesis:** The Linux client's implementation of the WireGuard protocol (NordLynx) or its network stack interaction is inefficient. The overhead is massive. I've also noticed high `sar -n ETCP 1` retransmit counts when the VPN is active.
I want to see if others are experiencing this, and more importantly, what concrete workarounds or fixes have been found. Please post:
* Your distribution and kernel version.
* NordLayer client version.
* The protocol you're using (NordLynx or OpenVPN).
* Output of `ip link show` for your VPN interface (e.g., `nordlynx`).
* Any custom `sysctl` tweaks you've applied to `net.core` or `net.ipv4`.
* Results of a basic throughput test (`iperf3` or `curl -o /dev/null` of a large binary file).
This is a tool we need to work reliably. Let's figure out if the problem is in our configs or if we need to collectively pressure for a better client.
You've ruled out the usual suspects, which means we're probably looking at a client-side inefficiency or a kernel interaction quirk. Since NordLynx is just WireGuard under the hood, the problem likely sits between their app's implementation and the Linux kernel's WireGuard module.
Have you compared raw WireGuard performance using wg-quick against NordLynx on the same server? That would isolate whether it's their connection management/overhead causing the bottleneck. I've seen similar issues where VPN clients add unnecessary packet processing layers that Windows handles better by default.
Also, check if you're getting CPU pinning or proper multi-queue support on the virtual interface. Single-threaded encryption can tank throughput.
Show me the bill
Good call starting with the baseline tests. Since you've already ruled out DNS, the next logical step is to check the MTU on your tunnel interface. NordLynx sometimes doesn't negotiate this well on Linux, and fragmented packets will murder your latency and throughput, especially for UDP.
Try setting a lower MTU manually on the NordLynx interface and see if the hanging stops. I've had to drop it to 1300 on some networks.
ian
Thanks for laying out such a clear baseline. It's very helpful for narrowing this down. Since you've already ruled out DNS, I'm leaning toward the earlier suggestions about kernel-level interactions or MTU.
Have you tried running `perf` or `bpftrace` on the NordLayer process to see where it might be spending CPU cycles during those latency spikes? Sometimes the user-space management around the WireGuard tunnel can introduce overhead that's more pronounced on Linux.
Also, which init system are you using? I've seen cases where the service file's limits or the way the process is sandboxed can affect network performance, even if the same config works fine on another OS.
Yeah, the Windows vs Linux performance gap is real. I had the same problem on a cheaper VPS. Ended up dropping NordLayer for a plain WireGuard config. It's not just you.