I have also noticed that NordVPN changes resolv.conf to whatever DNS I have set, but on disconnect Network manager does not revert resolv.conf to what it was, but to
nameserver 192.168.0.1
nameserver fe80::1%enp0s31f6
I have also noticed that NordVPN changes resolv.conf to whatever DNS I have set, but on disconnect Network manager does not revert resolv.conf to what it was, but to
nameserver 192.168.0.1
nameserver fe80::1%enp0s31f6
hmm I had accidentally ran routel instead of route!
this is what route shows:
no VPN:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default dsldevice.lan 0.0.0.0 UG 100 0 0 enp0s31f6
default dsldevice.lan 0.0.0.0 UG 1002 0 0 enp0s31f6
192.0.0.0 0.0.0.0 255.0.0.0 U 100 0 0 enp0s31f6
192.0.0.0 0.0.0.0 255.0.0.0 U 1002 0 0 enp0s31f6
with VPN on, it is just empty, that is the command hangs until I ctrl+c it.
If I run route -n, I get:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 1002 0 0 enp0s31f6
0.0.0.0 192.168.0.1 0.0.0.0 UG 20100 0 0 enp0s31f6
192.0.0.0 0.0.0.0 255.0.0.0 U 100 0 0 enp0s31f6
192.0.0.0 0.0.0.0 255.0.0.0 U 1002 0 0 enp0s31f6
Hmmm, it is weird/not right that the command hangs with the VPN connected…
Try the following:
ip route
…both with the VPN connected and not, the same as before.
both with VPN on and off I get the same:
default via 192.168.0.1 dev enp0s31f6 proto dhcp src 192.168.0.4 metric 1002
default via 192.168.0.1 dev enp0s31f6 proto dhcp src 192.168.0.4 metric 20100
192.0.0.0/8 dev enp0s31f6 proto kernel scope link src 192.168.0.4 metric 100
192.0.0.0/8 dev enp0s31f6 proto dhcp scope link src 192.168.0.4 metric 1002
If you get the same both times it means your traffic isn’t being routed through the VPN when it’s connected. But let’s confirm it with a last test:
Run, and return the output of, the following both with and without the VPN being connected, same as before:
dig +short txt ch whoami.cloudflare @1.0.0.1
This will just give the public-facing IP address, which should be different when using to the VPN than not.
That is a known issue - discovered long time ago and documented more than 2 years ago - the following topic is from September 2021.
TLDR:
sudo pacman -R openresolv
sudo systemctl enable --now systemd-resolved
sudo mv /etc/resolv.conf /etc/resolv.conf.bak
sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Can see I don’t use it.
I definitely get a different IP address when connected to the VPN.
As a matter of fact, I believe this problem began when I hadn’t used Manjaro for like 3 months, after I booted up and updated what had to be, this is when the problem appeared (at least if memory serves me right because I do not recall having this issue prior to the mass-update) Bulk update is never a good idea I guess.
Anyway, after removing resolv.conf, still no luck. I think that resolv.conf.bak had wrong DNS as well so if that command replaces resolv.conf with resolv.conf.bak, then essentially it does nothing.
how do I revert it back as now it is a symlink and I cannot edit it?
You should always stay updated with Manjaro. I susspect it’s what you consider “bulk update” is a normal update for Manjaro, and perhaps something changed so that the Nord VPN client doesn’t work like it did…
Anyway, the link provided by @linux-aarhus should sort you:
welp, I did run the commands but now I get 192.168.0.1 as DNS servers
I want to edit resolv.conf but can’t since it is a symlink now.
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.0.1
DNS Servers: 192.168.0.1
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google
Link 2 (enp0s31f6)
Current Scopes: DNS LLMNR/IPv4 mDNS/IPv4
Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1
DNS Servers: 192.168.0.1
Link 3 (wlp4s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 10 (nordlynx)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
Current DNS Server: 1.0.0.1
DNS Servers: 1.0.0.1 1.1.1.1
DNS Domain: ~.
Besides, the problem with Steam persists.
Right, so after I restarted the PC, I am fairly confident the problem is gone. I had to also disable IP6, not sure if this contributed but I got a lot of errors when running journalctl -xeu NetworkManager.service prior to disabling IP6. I think NordVPN just does not support IP6, so there’s that. Anyway, thanks for the help, I am marking the problem as solved!
One problem persists which is when I use NordVPN recommended DNS servers 103.86.96.100 103.86.99.100, google-dot-com does not work and when I ping google-dot-com it goes to 192.0.0.88…
What is even stranger, when I run:
nslookup google.com
I get:
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: google.com
Address: 192.0.0.88
Name: google.com
Address: 2a00:1450:4009:820::200e
Why is the DNS server showing as 127.0.0.53?
EDIT: aaaand the issue with Steam is back…
there is obviously something that happens when connecting or disconnecting to the VPN which messes up the system in a very specific way but I am not sure what. Another symptom is I sometimes get notification messages in the tray saying limited connectivity (though still having internet access)
This is what you get when you use DoH config for pihole. Is this a DoH problem maybe?
I won’t intervene, there are ppl way better at this than me in this thread, but the port 53 made me react.
I think it has more to do the way systemd-resolved works. But then again, I have a laptop running Ubuntu 22.04, using NordDNS on it I can open Google-com without issues.
running nslookup google.com I still get the same result as on Manjaro however, with the same weird IP 192.0.0.88
I am honestly baffled.
The general consensus seems to be to reinstall the Steam client:
Internet searches reveal there have been random discussions on this topic for many years. I doubt there is much more that the Manjaro community can add.
Additionally, I seem to recall reading that Steam discourages the use of a VPN. Perhaps that’s a point worth consideration.
i’ve delved into things I do not understand completely and I somehow managed to shaft my internet connection.
Is there a way I can restore the configurations to default?
What is happening right now is every time after reboot I have internet connection for 2 minutes, it appears that after systemd-networkd-wait-online.service kicks in 2 minutes after the OS starts, the internet connection completely disappears.
I have tried resetting the ip tables
I think the issue has something to do with the symlinks
I do not know how to revert the configuration back to the original.
I even went as far as deleting systemd, dhcpcd and networkmanager, then reinstalling them through chroot from a live usb.
Please help.
I just dont understand why it is so hard to revert the configs back to their default. I can literally brick my entire OS but cannot edit some config files manually.
To be perfectly honest, there isn’t really a lot that I changed, I remember deleting the resolv.conf and stub-resolv.conf files in /etc and in /run/systemd/resolve/ and the symlinks but they reappread anyway after I reinstalled systemd-resolved.
Prior to that I ran this command:
rm -f /etc/resolv.conf
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
I think I somehow made two separate symlinks for resolv.conf and stub-resolv.conf?
Currently when I open resolve.conf, it redirects to /run/systemd/resolve/resolv.conf which is managed by systemd-resolved and the content is
nameserver 192.168.0.1
search .
Well … what did you do?
The simple configuration is having systemd-resolvconf
installed (and for openvpn vpns I might suggest openvpn-update-systemd-resolved
as well).
Beyond that you should get rid of or back up /etc/resolv.conf
and make that path a symlink to /run/systemd/resolve/stub-resolv.conf
By default this would normally land you with the 1.1.1.1 DNS resolver … so it pointing to a local IP means theres something else at work like dhcp or something.
You can see a workout of what I do (and how to configure DNS) here:
I dont even know I would go that far … its not so much a problem (as in bug) as it is that resolvconf is old and should be considered deprecated, but manjaro ships with it by default, while most VPNs assume you are using the systemd variant.
I know I wrote a guide explaining it in reference to controlling DNS like 2 forums ago.
the reason I started messing with this is because I remember connecting to nordvpn right after boot. Ever since I started messing around, now nordvpn service is inactive (dead) for 2 minutes after reboot, it used be active pretty much instantly beforehand. then I saw that systemd-networkd-wait-online.service takes 2 minutes to load for some reason (I think it just times out) and only then I could use nordvpn
Maybe
https://man.archlinux.org/man/NetworkManager.conf.5#CONNECTIVITY_SECTION
So, in my case, I’ve blanked it out:
/etc/NetworkManager/conf.d/20-connectivity.conf
[connectivity]
uri=
#uri=https://www.archlinux.org/check_network_status.txt
Oh, and I also just disabled the service;
systemctl disable --now systemd-networkd-wait-online.service
$ systemctl status systemd-networkd-wait-online.service
○ systemd-networkd-wait-online.service - Wait for Network to be Configured
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd-wait-online.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd-wait-online.service(8)
strangely, it says that the service does not exist