Hmm. Wonder if this is a GNOME settings thing - using nm-connection-editor lets you add DNS resolvers on top of automatic-from-DHCP… 
Just in case it does have to do with TLP (as you assumed from the beginning), please check out my post further above. Especially the Summary provided there.
Not meaning to interfere with the current train of thought, as proposed by the dear @jonathon.
I am still puzzled by the fact that before installing TLP I did not have this problem.
Also, since access works with the Hide me VPN proxy, that means it is getting the DNS resolver via that. Normally, when the proxy is disabled, the browser should get its DNS resolver via the normal way again, which obviously isn’t happening. Could that be settings affected by TLP?
What does your ip addr show in terminal?
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp7s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether e8:6a:64:b3:24:45 brd ff:ff:ff:ff:ff:ff
3: ipv6leakintrf0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 96:a6:79:5f:eb:e8 brd ff:ff:ff:ff:ff:ff
inet6 fdeb:446c:912d:8da::/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::a46b:47e6:1c6c:9112/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 48:f1:7f:42:6a:9e brd ff:ff:ff:ff:ff:ff
inet 192.168.0.5/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
valid_lft 3593sec preferred_lft 3593sec
inet6 fe80::103c:6102:a0be:f24d/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Do you - by any chance - have dnscrypt-proxy installed? Or a similar DNS related service (unbound?) routing all traffic through localhost? Must be!
Nope, sorry, I don’t.
No VPN either?
Yes, that is what I explained above. 1 of my browsers, Librewolf, has a VPN proxy installed, Hide Me. So I have internet access if the proxy is enabled, without it I don’t.
And the other browsers, which don’t have that, cannot access the internet.
What happens if you enter sudo dhclient wlan0 in terminal?
Does this change the output of ip addr in terminal?
RTNETLINK answers: File exists
Nope
Then, why not uninstall that VPN plugin from Librewolf, and restart NetworkManager.service?
Somehow, your Browser-VPN seems to have preference over the other connections alltogether.
Yep, why not. Good point.
That should be done via the terminal, but what is the exact command?
This appears to be an additional network interface, perhaps added to prevent leaking of IPv6 connections? That would have been installed manually, or perhaps as part of your VPN setup? This could well explain why network connectivity only works when connected to the VPN.
1 Like
sudo systemctl restart NetworkManager.service
I don’t use ipv6, so it was done unintentionally.
From what you are saying, it seems I should remove it. What is the terminal command for that?
Is there anything else I should do in that context?
Uninstall that VPN first, then check ip addr again! Perhaps, ipv6leakintrf0 will be gone, too. Don’t forget to restart Networkmanager…
1 Like
How do I restart it, with which command?
See my second-last post. I gave you the syntax already.
My apologies, I had not seen that bit.
Anyway, I uninstalled the VPN proxy from Librewolf, restarted the NetworkManager, and ran ip addr, but that did not change and the ipv6 bit is still there in the output.