PopOS "sudo" commands / opening links has extreme delay when connected to VPN

[Seltonu]

Distribution (run cat /etc/os-release):

NAME="Pop!_OS" VERSION="21.10" ID=pop ID_LIKE="ubuntu debian" PRETTY_NAME="Pop!_OS 21.10" VERSION_ID="21.10" HOME_URL="https://pop.system76.com" SUPPORT_URL="https://support.system76.com" BUG_REPORT_URL="https://github.com/pop-os/pop/issues" PRIVACY_POLICY_URL="https://system76.com/privacy" VERSION_CODENAME=impish UBUNTU_CODENAME=impish LOGO=distributor-logo-pop-os

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

Private Internet Acces VPN (all versions, latest v3.2)

Issue/Bug Description:

Being connected to the VPN causes some OS behaviors to happen extremely slowly.

1. Using any "sudo" command in the terminal (i.e. "sudo apt update") takes about ~5-10 seconds delay to begin loading. Disconnecting from the VPN causes it to begin loading instantly with no delay.
2. Clicking links in applications (i.e. Discord chat) takes an extremely long time to be sent to the web browser. For example clicking "https://www.google.com/" in Discord takes a full 11 SECONDS before Firefox begins to open a new tab and process the request. Disconnecting from VPN and clicking a link, opens a new tab and begins loading the page instantly. This is not an issue with VPN network speed. This is an issue with some "handoff" happening in the OS taking an extremely long time/failing

Steps to reproduce (if you know):

Install any version/latest of Private Internet Acces VPN (requires an account). Restart PC. Connect to VPN and attempt to run any sudo command ("sudo apt update"), and/or try to open any link from a random program such as Discord. This is 100% reproducible for me, across multiple machines, multiple PopOS versions, multiple reinstalls.

Expected behavior:

Sudo commands are executed with no delay. Clicked links are sent to the default browser (i.e. firefox) with no delay.

Other Notes:

This bug is NOT about internet speed. This is about a processing delay that occurs IN THE OS while the VPN is active. This is 100% reproducible for me, across multiple machines, multiple PopOS versions, multiple reinstalls. I have dealt with this bug for 3 years now, but am frustrated enough now to report it.

I am reporting this here rather than with Private Internet Access support for two reasons:

• PIA does not officially support PopOS, only Ubuntu :( Reported a few months ago and was turned away
• This bug does NOT occur on Ubuntu, making me believe it is PopOS specific in the way the OS handles sudo commands / link "handoff" between programs

[cdrcqnts]

I have the same issue. When Mullvad VPN is running, opening a browser link via the app launcher takes up to 20 seconds. As soon as i deactivate the VPN, links open instantly via the app launcher.

[jacobgkau]

I wonder if it's related to https://github.com/pop-os/pop/issues/773. Does running sudo dpkg-reconfigure resolvconf fix the issue?

(Also reminds me of symptoms from https://github.com/pop-os/systemd/issues/5, although I don't know why it would be related unless the VPN client is changing the hostname.)

[cdrcqnts]

Thank you, that actually fixed the issue for me!

I wonder if it's related to #773. Does running sudo dpkg-reconfigure resolvconf fix the issue?

(Also reminds me of symptoms from pop-os/systemd#5, although I don't know why it would be related unless the VPN client is changing the hostname.)

[Seltonu]

Wow this is awesome - this fixed it for me as well! I'm noticing an error is thrown with sudo commands while the VPN is on, but it doesn't seem to affect the results, i.e. running sudo apt update && sudo apt upgrade throws the error sudo: unable to resolve host marshmallow: Name or service not known yet proceeds to update just fine.

Otherwise, sudo commands as well as clicking links in Discord now execute immediately with no delay. I've been frustrated by this for about ~3 years, thank you so much! Should I mark this issue as closed and refer to it in #773?

[jacobgkau]

Glad to hear! It is linked from within https://github.com/pop-os/pop/issues/773 now, so yes, you can close this one as a duplicate and add any info you see missing there if you'd like.

I think we're wanting to change the default symlink so third-party VPN apps work easier out-of-the-box. It looks like a simple change, but it still needs to be investigated/tested further (and it would only take effect for new installs, since the symlink is created in the installer.)

[diegoalarc]

Thanks a lot, this actually helps me to solve the same issue in POP_OS 22.04

[niels0n]

Hey there! I have the same issue, but when I do sudo dpkg-reconfigure resolvconf like suggested I get

dpkg-query: package 'resolvconf' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files.
/usr/sbin/dpkg-reconfigure: resolvconf is not installed

I'm not sure why it is not installed on my Pop_OS, I'm 100% sure I haven't uninstalled it. Should I install resolvconf in order to fix the issue?

[Seltonu]

@niels0n it looks like based on the comment here, resolvconf may have been replaced with systemd-resolvconf. I'm not quite sure what next steps would be, but by the sounds of it removing/renaming your /etc/resolvconf/interface-order should force the system to use systemd-resolvconf if it's installed

If you modify/remove any config files, make sure you have a backup. Installing Timeshift is an easy way to roll back your system (I believe you can even use it from a live usb if your OS completely dies)

[niels0n]

hey, thank you. the problem here is that I don't have the folder /etc/resolvconf at all, but I still have the delay problem. do you have any idea how I should proceed?

[jacobgkau]

@niels0n This issue was closed in favor of #773, as I stated in February 2022. That issue was closed when it was fixed in April of last year, by https://github.com/pop-os/desktop/pull/118 that @Seltonu linked to. resolvconf is no longer installed by default; systemd-resolvconf is now installed by default (and installing resolvconf manually now gives you the correct configuration to actually use it, instead of the broken configuration that used to be the default).

My colleague tested a number of VPN services with the fix and found no issues during that testing: https://github.com/pop-os/desktop/pull/118#pullrequestreview-1431464471 It was a while ago, though. What specific VPN provider are you using? Do you know that the VPN client is actually trying to make configuration changes by calling the resolvconf command, or are you just guessing based on the symptom?

[niels0n]

@jacobgkau I tried the official Mullvad VPN client, the official IVPN one and Mullvad through OpenVPN. I always had the same result, which is the exact problem described here. No, I don't know what the VPN is actually doing, I was just assuming that it was the same issues described here since the symptoms seems to be identical (long delay after sudo commands, and browsers taking like 20 seconds to launch). I did not have this problem on other distros, so I think it must be something specific about PopOS

[jacobgkau]

@niels0n I found a related issue in NixOS for Mullvad: https://github.com/NixOS/nixpkgs/issues/262681

By default, mullvad ignores the resolvconf configuration, replacing /etc/resolv.conf by itself and putting the old contents in /etc/resolv.conf.mullvadbackup.

That probably wouldn't work since systemd-resolved is exporting configuration to /etc/resolv.conf and not listening to that file for configuration to actually apply, at least by default.

• First of all, can you check if that /etc/resolv.conf.mullvadbackup file exists after you connect to the VPN?
• Second, if you manually install resolvconf with sudo apt install resolvconf (which, according to my testing back then, should make systemd-resolved actually listen to /etc/resolv.conf for changes), then reboot and try connecting to the VPN again, does the issue still occur?

[niels0n]

can you check if that /etc/resolv.conf.mullvadbackup file exists after you connect to the VPN?

It doesn't.

BUT...

if you manually install resolvconf with sudo apt install resolvconf (which, according to my testing back then, should make systemd-resolved actually listen to /etc/resolv.conf for changes), then reboot and try connecting to the VPN again, does the issue still occur?

This does solve the issue! Installing resolvconf automatically uninstalls systemd-resolvconf (this is exptected, right?), and after a reboot the vpn works fine and the file /etc/resolv.conf.mullvadbackup is actually there! That's great, thank you so much @jacobgkau.

[jacobgkau]

Sounds like you may want to report to Mullvad that their client had an issue with systemd-resolved. Glad that worked, though.

[niels0n]

As I said I had the same problem with IVPN and Mullvad through OpenVPN, so I'm not sure...I'll try, though.

Will be a problem for me to use resolvconf instead of systemd-resolvconf?

[jacobgkau]

As I said I had the same problem with IVPN and Mullvad through OpenVPN, so I'm not sure...I'll try, though.

VPN tooling that needs to change resolver configuration should ideally detect if you're using systemd-resolved and, if so, use the resolvectl command instead of resolvconf or the /etc/resolv.conf file. (The next-best thing is using the resolvconf command, which we still support via systemd-resolvconf, rather than editing that file directly.)

It's possible there's some kind of recent systemd-resolved bug, but I'd need logs from the VPN client and/or resolved when you're connecting and when the issue's occurring to have a chance at being able to tell.

Will be a problem for me to use resolvconf instead of systemd-resolvconf?

Not at all.

[niels0n]

Got it, I'll report it then and see. Thank you again.