How Cyberghost VPN CLI might break your internet

The following post is aimed at new customers of cyberghostvpn as well as users that desperately search the web for answers why their internet on Ubuntu does not work as intended. In the latter case you might have this or a similar problem and this post will give some insight into offline trouble shooting. This procedure might seem obvious for experienced Linux users, but might help people like me.

Yesterday I installed CyberghostVPN CLI on my Ubuntu 22.04.1 system. It was all fun and games until I restarted my PC today only to find out, that I seemed to have a connection, but was not able to visit any websites.

seeing this puzzled me

I am not a longtime Linux user (roundabout 2 years) but I already had the common problems here and there. The first thing I did, as would every reasonable person, was looking whether others had similar problems. I googled phrases such as “Ubuntu suddenly no wired connection” and “Ubuntu no connection after installing VPN”.

After some aimless stumbling and reading lots of threads I remembered. I had a similar problem a while back and it turned out, that good old pinging could give me more information. So I tried the following:

ping -c 5 8.8.8.8

which then returned


The above told me, that I was able to transmit and receive packages to/from the ip 8.8.8.8 which is the well known IP of google.com. I only have a fundamental understanding about networks, but the idea is, that google.com is just a name, which is easier for us to remember whereas 8.8.8.8 is the “real address” of the website.

Usually our system first asks a so called Domain-Name-System or DNS for short, what the real address given a name is and then redirects us to the latter. No comes the funny part, the DNS also needs to be addressed via its “real address” and if you do not already have a DNS you have to know this address.

A short history of Ubuntu DNS handling:

  1. First there was resolvconf, it was great and handled your DNS just fine, the important file that this package managed was /etc/resolv.conf
  2. Then came the era of systemd-resolved, it handled DNS differently and had another configurationfile.
  3. At last there was this new package resolvectl which now handles domain name resolution.

Turns out that the install.sh file, that Cyberghost provides you, does the following:


So now I had two packages which tried to manage my DNS lookup and or the configuration files (I did not carry out further research). All I know is, that the IP in /etc/resolv.conf was not pingable so I shorthandedly replaced it by 8.8.8.8 which also happens to function as a DNS-Server. Then I removed the newly installed package resolvconf.

I later used stat to find out which of my files in /etc/ were created newly and did some careful cleanup (i.e. first renamed every file that was newly added at the time I installed cyberghost). I also relinked /etc/resolv.conf to the appropriate configuration of resolvectl aka

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

That was my small story about CyberghostVPN messing with me. Below is a more streamlined approach for troubleshooting this and similar issues:

Using

less /var/log/syslog

And then typing

/Warning

highlights all warnings in the systems journal. With N and Shift+N one could have searched through those warnings and in my case there is this rather interesting warning:

Jan 30 21:19:12 <NAMEDESPCS>: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

This could have given me a hint, that resolv.conf had a problem. Via

less /var/log/dpkg.log

and searching for /2024-01-30 21:19 it would then be the next logical step to look whether any new package was installed at that point in time and yes, there is:


Then I would have had all the information at hand to google for somebody with the same problem.

this is why I always use a custom DNS and don’t let any program/service change my resolv.conf

fyi: resolvectl is actually the command line interface for systemd-resolved.

Thank you, I’ve definitely spent about 3 hours looking for a solution until I stumbled upon your post. Thanks!!!

Oh you are right, I actually meant systemd-resolve (without the ‘d’ at the end) which was the CLI for systemd-resolved before Ubuntu 20.04 at least according to the one source I skimmed over.

I think your source is very confused.

No,actually I think they are right, the systemd update 239 changelog states:

" The systemd-resolve tool has been renamed to resolvectl (it also remains available under the old name, for compatibility), and its interface is now verb-based, similar in style to the other ctl tools, such as systemctl or loginctl."
(ll.8529ff, https://github.com/systemd/systemd/blob/main/NEWS#L8529)

Thanks for the correction.