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.

  • krakenfury@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    30 days ago

    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.

    • jcarax@beehaw.org
      link
      fedilink
      arrow-up
      1
      ·
      30 days ago

      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.

      • Kraven_the_Hunter@lemmy.dbzer0.comOP
        link
        fedilink
        arrow-up
        2
        ·
        30 days ago

        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.

        • jcarax@beehaw.org
          link
          fedilink
          arrow-up
          1
          ·
          29 days ago

          And I think it’s probably not in resolv.conf, that’s a stub that kind of redirects things to systemd-resolved. So I think it’s in the forwarder config of that.

          Be careful, I was just looking over the Arch docs I linked you to, and I think the configs have changed substantially in the last few months. There’s a good chance that the configs in Mint look substantially different.

          • Kraven_the_Hunter@lemmy.dbzer0.comOP
            link
            fedilink
            arrow-up
            1
            ·
            9 days ago

            No, unfortunately. It consistently works when connected to Mullvad on both wireless and cellular networks. It briefly worked without Mullvad after a routine software update but its back to its old ways.

            What I should probably do next, just to be thorough, is boot Mint or Tails from USB and see if it all works.

            Since I dont keep anything on this device, reinstalling wont be a major pain. Ive just had enough other things going on that this hasn’t bubbled to the top of my list.

            • jcarax@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              9 days ago

              If you wanted to, you could post your /etc/resolv.conf and /etc/systemd/resolved.conf here. I don’t know if there might be a configuration directory option for systemd-resolved, so keep an eye out for a potential directory like /etc/systemd/resolved.d that might have the configs instead.

              • Kraven_the_Hunter@lemmy.dbzer0.comOP
                link
                fedilink
                arrow-up
                2
                ·
                24 hours ago

                I went into the Mullvad settings a bit deeper to see why my Surface might be using wireguard tunnels while my desktop doesn’t. I didn’t see anything related to that, but I did notice that Mullvad has a “Lockdown Mode” which requires you to be connected to Mullvad in order to access the internet. I don’t have that active, but I wonder if it is in that mode anyway. I did a quick enable/disable of it to no avail.

              • Kraven_the_Hunter@lemmy.dbzer0.comOP
                link
                fedilink
                English
                arrow-up
                2
                ·
                1 day ago

                I took a bit to reply because I wanted to wait for the next update to Mullvad. I just installed it this morning and even though I haven’t re-started the program, my network connection is dafaulting to go through the Mullvad wireguard servers which is letting everything work. I’m not sure why I have so many copies of the same wg0-mullvad server in my list so that seems suspicious.

                Here are the resolv.conf and systemd/resolved.conf files… really nothing unique other than calling back to 127.0.0.53 for the nameserver like I showed before. My desktop has the same settings and nameserver though. The only difference is that Mullvad on my desktop is not using wireguard servers, so maybe that is causing the issue on my Surface?

                resolv.conf
                # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
                # Do not edit.
                #
                # This file might be symlinked as /etc/resolv.conf. If you're looking at
                # /etc/resolv.conf and seeing this text, you have followed the symlink.
                #
                # This is a dynamic resolv.conf file for connecting local clients to the
                # internal DNS stub resolver of systemd-resolved. This file lists all
                # configured search domains.
                #
                # Run "resolvectl status" to see details about the uplink DNS servers
                # currently in use.
                #
                # Third party programs should typically not access this file directly, but only
                # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
                # different way, replace this symlink by a static file or a different symlink.
                #
                # See man:systemd-resolved.service(8) for details about the supported modes of
                # operation for /etc/resolv.conf.
                
                nameserver 127.0.0.53
                options edns0 trust-ad
                search .
                
                systemd/resolved.conf
                #  This file is part of systemd.
                #
                #  systemd is free software; you can redistribute it and/or modify it under the
                #  terms of the GNU Lesser General Public License as published by the Free
                #  Software Foundation; either version 2.1 of the License, or (at your option)
                #  any later version.
                #
                # Entries in this file show the compile time defaults. Local configuration
                # should be created by either modifying this file (or a copy of it placed in
                # /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
                # the /etc/systemd/resolved.conf.d/ directory. The latter is generally
                # recommended. Defaults can be restored by simply deleting the main
                # configuration file and all drop-ins located in /etc/.
                #
                # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
                #
                # See resolved.conf(5) for details.
                
                [Resolve]
                # Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
                # Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::10
                01#cloudflare-dns.com
                # Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
                # Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
                #DNS=
                #FallbackDNS=
                #Domains=
                #DNSSEC=no
                #DNSOverTLS=no
                #MulticastDNS=no
                #LLMNR=no
                #Cache=no-negative
                #CacheFromLocalhost=no
                #DNSStubListener=yes
                #DNSStubListenerExtra=
                #ReadEtcHosts=yes
                #ResolveUnicastSingleLabel=no
                #StaleRetentionSec=0
                
                • jcarax@beehaw.org
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  14 hours ago

                  Ok, so the resolv.conf is being used to put systemd-resolved in the forwarding path, with it listening on 127.0.0.53. That’s how Mint does things, so don’t touch that file.

                  Your resolved.conf has no DNS servers or fallback DNS servers configured, so it should just use the DNS servers handed out by DHCP. Either your DHCP servers isn’t handing out a DNS server (unlikely, since other machines work), NetworkManager was configured to not use DHCP DNS servers, or you’re hitting some bug causing the same. I suspect you may have configured NetworkManager for this, maybe it was overriding the VPN DNS. Or maybe you accidentally set the NetworkManager DNS backend to dnsmasq, when it should be systemd-resolved in Mint.

                  You could try uncommenting that FallbackDNS line and adding a couple space separated DNS servers, maybe your router IP. Mine looks like this:

                  #DNS= FallbackDNS=1.1.1.1 1.0.0.1 #Domains=

                  That will hopefully allow VPN DNS to work when it’s connected, and fall back to other DNS servers when not. If not, we could try taking a look at NetworkManager configs. It’s been a bit, I use systemd-networkd now, but I could spin up a VM.