[SOLV] Using a VPN connection on Arch is very slow or does not connect

Big Scorpio · 2024-12-15 23:29:32

Hi Arch Friends,

I have a problem with using a VPN on Arch and that is that web browsers load either slow like its the year 2001, not at all ("connection could not be established") or on rare occasions it loads as fast as not using a VPN.
I captured a short video for you all to see what I see.

This problem DOES NOT happen on my Windows System (dual booting here) nor on my Android Smartphone - both are using OpenVPN and then I switched up for Wireguard. So it is most likely not going to be a networking problem from my end.

What's also strange is that this problem on Arch is not happening when doing non-browser internet activities such as installing the latest or new packages such as OBS and pinging other servers works normally. The pings response times range between 75ms - 125ms, be it Google or Hornpub.

Technical details:

- I tested this on 3 web browsers: Firefox, Brave, Tor
- I am using KDE Plasma as my Desktop Environment and NetworkManager
- I installed Arch Linux myself from the image archlinux-2024.11.01-x86_64.iso and then naturally performed pacman -Syu
- Currently I do not have a Firewall installed in order to isolate the problem

Here are the things I have tried to to no avail:

- Play with every setting in the Network VPN Tab
- Installed VirtualBox and then Arch Linux in that VM using the same image - same problem
- Same as above but with the image 2024.10.01
- Using OpenVPN instead of Wireguard
- Downgrade NetworkManager to the version, that Debian 12.8.0 has (it'll make more sense later)
- Overwrite resolv.conf with the DNS IP's from my VPN provider. I resorted then back to have it automatically being generated by NetworkManager. I see 3 nameservers: 10.x.y.z (from my VPN provider), 2001:something (the IPv6 from my VPN provider, 192.168.x.y from my local Router)
- Disable IPv6
- Used 2 different VPN providers, one of them with 2 different server regions
- Disabled DoH in Firefox

What I also tried is installing Debian 12.8.0 in a VM, one time with GNOME and one time with KDE Plasma. The VPN connection with Wireguard worked perfectly. Even with DoH enabled on Firefox. It simply worked out of the box.
I am thinking of trying it with EndeavorOS and KDE to test next but I think it's a long shot in the dark at this point.

Arch Mates, what can i do to have a normally functioning VPN on my Arch System? Am I missing something? I don't want to drop Arch Linux only because of an inconvenient networking problem, that doesn't have to be.

With kindest regards,

Last edited by Big Scorpio (2024-12-16 17:47:44)

-thc · 2024-12-16 06:16:19

This definitely sounds like a MTU problem.

Please lower the MTU value in the VPN setup in 16 bytes steps and check your connectivity.

seth · 2024-12-16 09:30:07

While I agree on the MTU cause, I'd go for a different strategy and radically lower the MTU (1280 is usually a safe bet) and bisect my way to the limit (so try 1390 next, then 1445 etc)
Your VPN provider will typically also have a record on MTU requirements.

Ftr: there was non-dial-up internet in 2001

dakota · 2024-12-16 13:18:40

seth wrote:

Ftr: there was non-dial-up internet in 2001

I was still using dial-up in 2004.

Big Scorpio · 2024-12-16 17:46:40

Unbelievable. Was that really such a huge secret in Arch over the many years I wonder? I mean I searched left and right, duckduckgo, youtube, chatgpt to find no one having that problem like I had and only here I am told to manually set the MTU values just like seth suggested and then my VPN internet connection works like a charm now. Speedy browsing with little overhead.

Speedtest with VPN

But I still don't get why. The MTU values were left blank (or I can't remember seeing those in Windows and Android). And I left the MTU values blank on my Debian tests.

Still, this solved it for me. We'll mark this as [SOLVED]. Thanks Arch mates!

seth · 2024-12-16 17:59:40

Errhemm

-thc was the first one who wrote:

This definitely sounds like a MTU problem.

seth just thinks it's way too tedious to walk them down to maybe at the end of the road even figure it wasn't the MTU all along and instead prefers to test some solid ground and then narrow in on functional values as fast as possible

The reason is that VPNs add some overhead to the packages, getting them above them above the MTU of your router - this is a pretty common situation, but I'm not surprised that ChatGPT hasn't figured it.
(Ping works because the icmp packages are way smaller anyway)

If you used some VPN-provider issued software to setup the VPN on windows/android, it'll most likely have done this for you.
No idea about Debian, but where did you leave the MTU values "blank"? NM config dialog?
"ip l" will tell you every NICs current MTU.

One more thing

dual booting here

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Big Scorpio · 2024-12-16 22:54:35

I settled for 1400 MTU as 1420 MTU (the common and normal value) is starting to cause this problem.

seth wrote:

If you used some VPN-provider issued software to setup the VPN on windows/android, it'll most likely have done this for you.

Unless you count Wireguard as the VPN Software and not something like a downloadable NordVPN executable. I guess the MTU values were set by the VPN server upon connecting.

seth wrote:

No idea about Debian, but where did you leave the MTU values "blank"? NM config dialog?
"ip l" will tell you every NICs current MTU.

In Debian KDE there is a NetworkManager Settings section for VPN and the MTU value is an input textbox, which by default is blank. It worked normally.
In Debian GNOME i didn't look for MTU input field anywhere. I simply imported the vpn_name.conf file using a nmcli command, that i don't remember anymore and it connected automatically. Why go digging for MTU if there are no problems?

vpn settings

seth wrote:

One more thing
dual booting here
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

I wonder if that is applicable in my case? You see I have a dual boot system that consists of 2 SSD's, SSD 1 is housing the Windows OS + it's Windows Boot Manager while SSD 2 is housing the Arch Linux OS + GRUB, so that effectively isolates both bootloaders on their respective SSD's. If I want to boot into Shmindows I press the Functional Key to summon the BIOS boot menu and this way it already feels fast. It might be a Newbie way to have a dual boot system or a "not wrong" way to keep both bootloaders separate and still keep the benefit of Shmindows Fast Boot. What do you say?

Last edited by Big Scorpio (2024-12-17 00:14:48)

seth · 2024-12-17 08:21:38

I simply imported the vpn_name.conf

You might wanna look at that file - and the resulting "ip l" mtu.
This isn't somehow OS specific.
If the VPN slaps stuff onto the default 1500 bytes and you exceed that and your physical link sn't ok w/ higher MTUs, you'll run into this.

I have a dual boot system that consists of 2 SSD's

The involved storage is completely irrelevant - the problem is the ACPI/BIOS/UEFI.
If this is a wifi connection, it'd be the most common victim of that condition (but since you can already pin it onto the VPN, it's less likely relevant to the immediate problem)

Big Scorpio · 2024-12-17 22:30:23

Well, here it is from my Windows OS. MTU has been set to 1420 automatically.

FluxBB bbcode test

seth wrote:

The involved storage is completely irrelevant - the problem is the ACPI/BIOS/UEFI.
If this is a wifi connection, it'd be the most common victim of that condition (but since you can already pin it onto the VPN, it's less likely relevant to the immediate problem)

I don't understand. What's the point to disable Windows Fast Start then?

seth · 2024-12-17 22:34:43

What's the point to disable Windows Fast Start then?

Running one OS while another one is hibernating borders running two OS at the same time w/o a hypervisor, leading to undefined HW states and in case of parallel NTFS data loss at worst.
Just because it'S not responsible for *this* problem doesn't mean it doesn't cause several other issues you'll learn about along the wisdom that there're only two kinds of users: those with backups and those with plans for backups

Disable it.

Big Scorpio · 2024-12-17 22:41:51

Understood. I'll take your word for it.

Arch Linux

#1 2024-12-15 23:29:32

[SOLV] Using a VPN connection on Arch is very slow or does not connect

#2 2024-12-16 06:16:19

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#3 2024-12-16 09:30:07

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#4 2024-12-16 13:18:40

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#5 2024-12-16 17:46:40

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#6 2024-12-16 17:59:40

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#7 2024-12-16 22:54:35

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#8 2024-12-17 08:21:38

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#9 2024-12-17 22:30:23

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#10 2024-12-17 22:34:43

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

#11 2024-12-17 22:41:51

Re: [SOLV] Using a VPN connection on Arch is very slow or does not connect

Board footer