Connecting to a VPN breaks the internet?


New Member
Aug 3, 2021
Reaction score
It seems that when this happens a restart of some sort of network service is restarted which resets the DNS server used in resolv.conf
This is honestly it's own issue that probably is a simple fix, and while help would be greatly appreciated with that issue, that's not really the reason this thread was made(although seriously, if you do know why this is, it would be much appreciated. only dhcpcd and NetworkManager are installed as network services under systemctl, as this is a fresh install, so there shouldn't be any reason afaik that would cause such an issue.)
Now, when the VPN is connecting, /etc/resolv.conf is reset and provides a nameserver that is either the router or "::6" or something. There has to be something that saved the DNS configuration for NetworkManager between restarts, although I haven't really been forced to confront the issue head on because any sensitive information has been communicated over tor. protonvpn-cli can connect(albeit after about a full thirty seconds of attempts) but no internet connection in a web browser or from the arch repositories seems to be able to be connected to. I can go into /etc/resolv.conf and add "nameserver" to the end of the file but that seems to point back to the current location of the computer, without the VPN even seeming to notice. the resolv.conf file seems to be nuked by protonvpn-cli due to the addition of "::6" to the /etc/resolv.conf file but oddly enough, subsequent attempts to reconnect to the VPN appear to "fail for an unknown reason". this isn't a bug in protonvpn's code because the error is displayed while attempting to connect to expressvpn also. pinging the intranet and google both work fine without the vpn connected. ofc I looked through the wiki

G'day happy, Welcome to

Surely, this is a problem for protonvpn ?

If you are using their free service, then do get what you pay for. In this case, nothing.

If you are paying for their service then it is definitely their problem
G'day happy, Welcome to

Surely, this is a problem for protonvpn ?

If you are using their free service, then do get what you pay for. In this case, nothing.

If you are paying for their service then it is definitely their problem

thanks for the reply, much appreciated. I'm decently sure that the issue isn't with protonvpn because expressvpn is seemingly having the same issue.
VPN software will usually configure their own (preconfigured) DNS servers. (check the VPN software for a DNS setting) This occurs because you are connecting to a secondary network that may have its own internal DNS. It also helps because in your case, you're looking to cover your tracks it appears and you definitely do not want to be using your local DNS which would "leak" your DNS requests and tell people on the local network exactly what sites you are attempting to get to.

So, let's wade into some of the possible issues here. As I'm not a Linux Desktop user, I immediately disable NetworkManager on my server. (Managing it from the cli is... yeah, it sucks)

Second, it sometimes seems to have a mind on its own that breaks what I'm trying to do.

That said, from Linux Desktop users I know. They tend to like the click-to nature of NetworkManager. How this affects VPNs I heard can be a positive for desktops, but my servers do not have VPNs installed on them. The VPNs they use are network devices powered site-to-site VPNs.

You noted ::6. I really don't have much experience with IPv6, but I believe you meant ::1 (1 not 6) This is "localhost" for IPv6. is the equivalent for IPv4.

Unless your ProtonVPN is forcing you to use IPv6, I doubt this is your problem. If they are and they set your DNS to ::1, then the local VPN client might be trying to act as your DNS server.

Other things to consider:
  • VPNs are known to jack-up local DNS from time to time to the point that rebooting becomes necessary. My work VPN (OpenVPN) does this on my home desktop, though not on my work laptop. (though my home desktop has a lot of non-standard modifications I've made to it)
  • Proton VPN could possibly be trying to block DNS that isn't their own. (I don't know, I don't use them) They may want you to use *their* DNS servers and you are attempting to override that. (yeah, bleep that)
  • As noted above, NetworkManager could be fighting with ProtonVPN as it pertains to your DNS settings and ends up wiping out your settings. Reboot, disable NetworkManager, then connect to your VPN and see what happens.
  • When you are connected to your VPN and it's not working. Try pinging an IP address and see if that works. (ping or ping This bypasses DNS and will send a raw packet onto the net directly to the IP. If this doesn't work either, then your VPN isn't passing packets and is DEFINITELY the problem.
Good luck,
ah, hahaha, what a goof, the attempt to use ipv6 would, at the moment, appear to be the issue because I had disabled ipv6 for the interface. also, you were right, that it is "::1". not "::6". where I went wrong is in the assumption that the linux kernel wouldn't have it's own method of handling the network hardware(doy) and the reason why NetworkManager and other similar services come bundled with most distros is because it is required. building from the ground up certainly is useful in ironing out any misconceptions a person may have about the internal infrastructure of linux. I disabled NetworkManager and also dhcpcd for DNS reasons, but it didn't really help. the package is reporting that it can not access NetworkManager with this error:

org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager was not provided by any .service files

afaik atm, proton never explicitly said that NetworkManager is a dependency for protonvpn-cli. enabling it required NetworkManager to be running. that being said, when the package is run and the server is selected, this is the return:

Setting up ProtonVPN.
Connecting to ProtonVPN on NL-FREE#6 with TCP.

Unable to connect to ProtonVPN: ProtonVPN connection failed due to unknown reason.

a similar message is returned for expressvpn. the way the error was worked around before was by having it attempt to connect to the server, and then starting protonvpn-cli from a different tts, oddly enough. it doesn't seem like proton's issue(other than a blatant disregard for a verbose option, but I digress) because of the return message for expressvpn. going to try expressvpn with a mix of the two services enabled in order to see if the problem is reproduced over there.

OKAY. found the culprit. turns out that NetworkManager was in conflict with protonvpn-cli while protonvpn-cli wasn't outputting an error message or giving a verbose option. expressvpn, when NetworkManager is disabled, works but requires dhcpcd for the first startup in order to set nameservers in /etc/resolv.conf

something for the devs to consider: does NetworkManager play well with dhcpcd when a package is trying to configure a custom DNS? also, the devs of protonvpn-cli should consider adding a verbose option

now everything is working splendidly, although I will play with the configuration a bit to see if expressvpn requires dhcpcd in general. turns out, dhcpcd is only necessary for expressvpn during the first connection, and not at any other time.

thanks for the help

Members online