1

I am using mullvad vpn, and I am connected - see status:

jpc@home:~/mullvad-vpn$ mullvad status -v
Connected to se-got-wg-005 (185.209.199.2:7457/UDP) in Gothenburg, Sweden
Tunnel type: WireGuard
Quantum resistant tunnel: no
Tunnel interface: wg-mullvad

When I exclude a process from mullvad, it works perfectly fine:

jpc@home:~/mullvad-vpn$ mullvad-exclude ping google.com
PING google.com(ord38s31-in-x0e.1e100.net (2607:f8b0:4009:81a::200e)) 56 data bytes
64 bytes from ord38s31-in-x0e.1e100.net (2607:f8b0:4009:81a::200e): icmp_seq=1 ttl=116 time=21.2 ms
64 bytes from ord38s31-in-x0e.1e100.net (2607:f8b0:4009:81a::200e): icmp_seq=2 ttl=116 time=16.6 ms
64 bytes from ord38s31-in-x0e.1e100.net (2607:f8b0:4009:81a::200e): icmp_seq=3 ttl=116 time=16.0 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 16.028/17.940/21.237/2.340 ms

However running the same command through mullvad fails:

jpc@home:~/mullvad-vpn$ ping google.com
ping: google.com: Temporary failure in name resolution

This recently started happening even though I've been using mullvad successfully for months.

I was able to "fix" the DNS issue by temporarily updating /etc/resolv.conf to use nameserver 8.8.8.8. However this is not ideally, and just led to another problem:

jpc@home:~/mullvad-vpn$ sudo vim /etc/resolv.conf
jpc@home:~/mullvad-vpn$ sudo systemctl restart systemd-resolved.service
jpc@home:~/mullvad-vpn$ ping google.com
PING google.com(arn09s20-in-x0e.1e100.net (2a00:1450:400f:80d::200e)) 56 data bytes
From 2601:401:100:e1a:e80e:4746:2e04:8900 (2601:401:100:e1a:e80e:4746:2e04:8900) icmp_seq=1 Destination unreachable: Port unreachable
From 2601:401:100:e1a:e80e:4746:2e04:8900 (2601:401:100:e1a:e80e:4746:2e04:8900) icmp_seq=2 Destination unreachable: Port unreachable
From 2601:401:100:e1a:e80e:4746:2e04:8900 (2601:401:100:e1a:e80e:4746:2e04:8900) icmp_seq=3 Destination unreachable: Port unreachable
From 2601:401:100:e1a:e80e:4746:2e04:8900 (2601:401:100:e1a:e80e:4746:2e04:8900) icmp_seq=4 Destination unreachable: Port unreachable
^C
--- google.com ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3004ms

Anyone have ideas what's going on? This just started happening in the last couple of days


Edit - more information here (size is too large to add to the body of this): https://paste.jpc.io/snippet/2d8fdc8a-2075-461b-bc97-4755f4f0674e

4
  • Maybe it's because Mullvad implements some kind of "kill switch", while the physical link still have a link DNS server set in resolved, resulting in DNS requests "leaked but not leaked" from time to time. Add the untampered /etc/resolv.conf and output of resolvectl after the VPN connection is brought up, preferably with the output of iptables-save and nft list ruleset. (Personally I clear the link DNS server of the physical link temporarily with resolvectl when I connect to my personal wg server, and revert the setting when I disconnect. (wg-quick allows up/down actions).
    – Tom Yan
    Commented Jun 1 at 17:09
  • Thanks for looking into this, I've added the output of all those things to this paste (the output is too large to include in my post): paste.jpc.io/snippet/2d8fdc8a-2075-461b-bc97-4755f4f0674e
    – johncorser
    Commented Jun 1 at 17:28
  • Well, first of all, I'd suggest that you delete the current /etc/resolv.conf (which is a symlink) and recreate one that links to /run/systemd/resolve/stub-resolv.conf (or /usr/lib/systemd/resolv.conf, if that doesn't exist). Then preferably just reboot and check cat /etc/resolv.conf and resolvectl again, before and after bring up the mullvad respectively (and create a paste again with the four outputs). Btw, does your physical link have IPv6 connectivity? And does the Mullvad tunnel offers IPv6 connectivity?
    – Tom Yan
    Commented Jun 1 at 18:05
  • If you can't afford to reboot, bring down the mullvad first, and bring down whatever network manager you use (e.g. systemd-networkd), maybe also flush the IP addresses on the physical link, then change the /etc/resolv.conf symlink, then restart systemd-resolved and the network manager, then perform the checks / dumping I mentioned above (with bringing up mullvad again in between).
    – Tom Yan
    Commented Jun 1 at 18:08

0

You must log in to answer this question.

Browse other questions tagged .