I’ll preface this by saying that these issues are on a Surface Tablet that I’ve been using to play around with, so I haven’t been too diligent in documenting what changes were made when.
I’ve got a Surface Go 2 tablet with the LTE modem that I installed Linux Mint onto several months ago. When I first made the switch, cellular connectivity seemed very “touch and go” but Wi-Fi had been solid.
At some point in time (roughly 6 months ago), I switched my home network to using Control D for DNS resolution for about 2 months until I decided it wasn’t what I wanted and went back to my default setup which is a Unifi UCG Max gateway using the AdGuard public DNS servers coupled with the built-in ad blocking of the Unifi gateway. This feeds to a separate Wi-Fi mesh network in my home.
About a month ago I noticed that I could no longer reach internet locations on my tablet when connected to my home Wi-Fi network, but I could still access other computers on my LAN just fine, so Wi-Fi was working. Cellular connectivity seemed to have stopped working entirely even though I ran the “lte_modem_fix” that is on github and was seeing several bars of connectivity in the status bar.
Even though websites were inaccessible (Firefox gave me an error saying there was no network connection), in my attempt to try anything I found that I could visit the Control D website even though I stopped subscribing months ago.
On a lark I pulled up my Mullvad VPN app which I have an active subscription to and it let me connect to a server. As soon as I did this, ALL internet sites became available.
Next I took the tablet with me away from home, disabled Wi-Fi and activated the cellular network. Again the bars appeared but I couldn’t access any sites. I loaded up Mullvad and was able to connect, after which I could reliably connect to all internet sites. Again, cellular connectivity was never 100% but Wi-Fi was.
How do I even begin troubleshooting and fixing this? Needing a VPN isn’t the end of the world, but when at home it gets in the way of accessing local computers so I’d like to get to where the tablet works on Wi-Fi or cellular, with and without a VPN active.
Ok, so something setup 127.0.0.53 as your DNS server, and isn’t removing it correctly. I think it’s safe to say it’s Mullvad, since it works using that DNS server IP when connected. Is that IP in your resolv.conf, or is resolv.conf maybe a stub, and you’re using systemd-resolved?
127.0.0.53 is the local stub used by systemd-resolved, so OP should pull this thread and comb the docs. If systemd-resolved is installed and not being used, it will cause conflicts with openresolv (most likely alternative).
Interesting that it works when the VPN is connected, though. I also believe that systemd-resolved is installed on just about any system using systemd, but often isn’t enabled, without problem. Enabling it would generally involve a resolv.conf symlink and a config, so maybe that config was hijacked by Mullvad (or OP configuring Mullvad), and there’s no upstream DNS server available when the VPN isn’t connected.
I missed that it’s Linux Mint in the original post, and it looks like Mint has started using systemd-resolved. The Arch wiki might be useful to OP on how things are configured:
https://wiki.archlinux.org/title/Systemd-resolved
I’m reaching here because I don’t know the first thing about Mullvad, but it probably has some script that takes care of it’s own DNS needs. I remember the before times, when you had to write up and down scripts that would update resolve.conf directly, then configured OpenVPN to run them on connecting/disconnecting.
It’s possible it could be a box checked or config option in Mullvad that broke it by not fixing DNS on it’s way down?
OP also said they don’t fully remember what was done, so they may have disabled systemd-resolved or installed openresolv or who knows what else.
Fortunately, in this case, they should be able to follow the systemd-resolved docs from the beginning to end up with it working.
Agreed, though I don’t think they disabled systemd-resolved, because it still works using 127.0.0.53 when they’re connected to the VPN. So the daemon must be running, unless Mullvad itself has a DNS forwarder using the same loopback. I suspect they either hard coded some upstream DNS server for Mullvad, because Mullvad might not have supported systemd-resolved yet. Or maybe they set a permission on the configs, and something changed with the user context of Mullvad processes.
Thanks for the info, I’ll read through the docs and hopefully get this up and running again in the near future. Fortunately, nothing here is mission critical and I can still use the machine with VPN active. Getting resolv.conf back in working order appears to be the right solution.