maybe if you use Mullvad with wireguard, but even then I would not suspect the kernel.
I do use it with wireguard.
BUT the problem exists whether it’s a wireguard or OpenVPN connection (it’s toggleable in the VPN client).
So it is a problem with your VPN software. It does not set a DNS server.
To be clear, the VPN only adds its DNS server to /etc/resolv.conf if I run sudo dhcpcd. : o Instead of a bug with the VPN, I would assume it’s a bug with my system in not running dhcpcd like (if?) it’s supposed to, but I don’t know much about these things.
I would assume I should systemctl enable dhcpcd.service, but I understand Manjaro already uses NetworkManager, which is an analogous service, so I shouldn’t?
Also, that it’s “masked” seems scary:
$ systemctl status dhcpcd.service
● dhcpcd.service
Loaded: masked (Reason: Unit dhcpcd.service is masked.)
Active: inactive (dead)
But blocks Mullvad 8.8.8.8 and 1.0.0.1 ?
I think Mullvad only runs with its DNS server, to prevent DNS leaks, so it wouldn’t work with the pre-existing DNS servers there.
So it blocks the connection to 8.8.8.8 ? Using 8.8.8.8 with a VPN is not what DNS leaks mean. A DNS leak is using your local DNS sever form your Internet Provider. A DNS quiery to 8.8.8.8 will go thru the VPN.
But you should not need to run dhcpcd, because the VPN Software needs to do this. And it needs to add a DNS server to /etc/resolv.conf . The only purpose of using a third party VPN Software is to set the VPN up. It is responsible to set up the VPN tunnel and make sure DNS works.
Btw. you should try to find out why you see
# Generated by resolvconf
before you connect to the vpn. Maybe do a reboot just to be sure. Because by default it should see
So it blocks the connection to 8.8.8.8 ? Using 8.8.8.8 with a VPN is not what DNS leaks mean. A DNS leak is using your local DNS sever form your Internet Provider. A DNS quiery to 8.8.8.8 will go thru the VPN.
Ah, okay. Would a “query” count as a ping? Pings to 8.8.8.8do always work. See below.
Maybe do a reboot just to be sure.
For reference, I’ve been doing reboots this whole time (I figure I have to to reset dhcpcd).
Also, if this sheds any light, I tried pings, digs, and reporting the contents of /etc/resolv.conf on a fresh boot across the state space:
no sudo dhcpcd
vpn disconnected
Can connect to websites dig A google.com @8.8.8.8 works dig A google.com @10.64.0.1 fails
[▓▓▓▓▓▓▓ 14:32:43 ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 1.0.0.1
[▓▓▓▓▓▓▓ 14:34:39 ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=4.21 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=4.12 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.118/4.162/4.207/0.044 ms
[▓▓▓▓▓▓▓ 14:34:47 ~]$ dig A google.com @8.8.8.8
; <<>> DiG 9.16.11 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49704
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 135 IN A 172.217.9.206
;; Query time: 3 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 11 14:34:50 EST 2021
;; MSG SIZE rcvd: 55
[▓▓▓▓▓▓▓ 14:34:50 ~]$ dig A google.com @10.64.0.1
; <<>> DiG 9.16.11 <<>> A google.com @10.64.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached
vpn connected
CAN’T connect to websites dig A google.com @8.8.8.8 fails dig A google.com @10.64.0.1 works
[▓▓▓▓▓▓▓ 14:33:02 ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 1.0.0.1
[▓▓▓▓▓▓▓ 14:33:50 ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=23.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=23.7 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 23.666/23.760/23.854/0.094 ms
[▓▓▓▓▓▓▓ 14:33:55 ~]$ dig A google.com @8.8.8.8
; <<>> DiG 9.16.11 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached
[▓▓▓▓▓▓▓ 14:34:15 ~]$ dig A google.com @10.64.0.1
; <<>> DiG 9.16.11 <<>> A google.com @10.64.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60495
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 735ea12bf45d405429b0dee0602586bdf6c7af41d6388f6c (good)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 270 IN A 64.233.177.100
google.com. 270 IN A 64.233.177.113
google.com. 270 IN A 64.233.177.139
google.com. 270 IN A 64.233.177.102
google.com. 270 IN A 64.233.177.138
google.com. 270 IN A 64.233.177.101
;; AUTHORITY SECTION:
google.com. 142516 IN NS ns2.google.com.
google.com. 142516 IN NS ns3.google.com.
google.com. 142516 IN NS ns4.google.com.
google.com. 142516 IN NS ns1.google.com.
;; Query time: 23 msec
;; SERVER: 10.64.0.1#53(10.64.0.1)
;; WHEN: Thu Feb 11 14:34:20 EST 2021
;; MSG SIZE rcvd: 235
aftersudo dhcpcd
vpn disconnected
Can connect to websites dig A google.com @8.8.8.8 works dig A google.com @10.64.0.1 fails
[▓▓▓▓▓▓▓ 14:33:38 ~]$ sudo dhcpcd
dhcpcd-9.4.0 starting
dev: loaded udev
DUID 00:04:8c:56:1a:5f:d9:04:38:f5:db:4a:04:d9:f5:38:db:49
enp5s0: waiting for carrier
enp6s0: IAID f5:38:db:49
enp6s0: soliciting an IPv6 router
enp6s0: rebinding lease of 172.16.93.142
enp6s0: leased 172.16.93.142 for 28800 seconds
enp6s0: adding route to 172.16.93.0/24
enp6s0: adding default route via 172.16.93.1
forked to background, child pid 4177
[▓▓▓▓▓▓▓ 14:35:32 ~]$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 8.8.8.8
nameserver 1.0.0.1
[▓▓▓▓▓▓▓ 14:35:45 ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=4.35 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=4.19 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 4.190/4.270/4.350/0.080 ms
[▓▓▓▓▓▓▓ 14:35:50 ~]$ dig A google.com @8.8.8.8
; <<>> DiG 9.16.11 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22251
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 218 IN A 172.217.9.206
;; Query time: 3 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Feb 11 14:35:53 EST 2021
;; MSG SIZE rcvd: 55
[▓▓▓▓▓▓▓ 14:35:53 ~]$ dig A google.com @10.64.0.1
; <<>> DiG 9.16.11 <<>> A google.com @10.64.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached
vpn connected
Can connect to websites dig A google.com @8.8.8.8 fails dig A google.com @10.64.0.1 works
[▓▓▓▓▓▓▓ 14:36:54 ~]$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 10.64.0.1
nameserver 8.8.8.8
nameserver 1.0.0.1
[▓▓▓▓▓▓▓ 14:37:21 ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=23.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=24.5 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 23.734/24.137/24.540/0.403 ms
[▓▓▓▓▓▓▓ 14:37:27 ~]$ dig A google.com @8.8.8.8
; <<>> DiG 9.16.11 <<>> A google.com @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached
[▓▓▓▓▓▓▓ 14:37:51 ~]$ dig A google.com @10.64.0.1
; <<>> DiG 9.16.11 <<>> A google.com @10.64.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8380
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fc66a43b38f1b26ee2c730d86025879b3b99d0af5ca19b2a (good)
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 64 IN A 108.177.122.101
google.com. 64 IN A 108.177.122.102
google.com. 64 IN A 108.177.122.113
google.com. 64 IN A 108.177.122.138
google.com. 64 IN A 108.177.122.139
google.com. 64 IN A 108.177.122.100
;; AUTHORITY SECTION:
google.com. 146346 IN NS ns1.google.com.
google.com. 146346 IN NS ns2.google.com.
google.com. 146346 IN NS ns3.google.com.
google.com. 146346 IN NS ns4.google.com.
;; Query time: 23 msec
;; SERVER: 10.64.0.1#53(10.64.0.1)
;; WHEN: Thu Feb 11 14:38:04 EST 2021
;; MSG SIZE rcvd: 235
So, when the VPN is connected, dig with 8.8.8.8 fails but 10.64.0.1, the VPN’s DNS, works.
When the VPN is disconnected, it’s the other way around.
Connecting to websites works in all cases except where the VPN is connected but its DNS, 10.64.0.1, is not added to /etc/resolv.conf upon VPN connection, and sudo dhcpcd is necessary to make sure it is added.
Also, neither:
systemctl enable systemd-resolved.service and reboot systemctl enable dhcpcd@.service (it was only available with the @; not sure why) and reboot
and getting Mullvad to reconnect at startup (I suppose it connects before the dhcpcd service runs):
mullvad reconnect # run at startup
# I plopped it into a personal systemd service for this
(Initially, I tried just running sudo dhcpcd or just dhcpcdin my systemd service, which runs as root, alongside the Mullvad command, but this didn’t work.)
After some time trying to find out, I’m still not sure how to do that. The only thing I can think of is greping the journal for the filename, and, after my fix, I see:
$ journalctl --no-hostname | grep resolv.conf
Feb 11 16:33:58 mullvad-daemon[988]: [talpid_dbus::network_manager][DEBUG] /etc/resolv.conf differs from reference resolv.conf, therefore NM is not managing DNS
Hehe. Damn right it’s not; dhcpcd is managing DNS now! I guess. Which works. For reasons.
Short of a better solution dropping into my lap, I have to turn to other things. I don’t understand why I have to enable the dhcpcd service all of a sudden. I don’t like solutions I can’t understand to problems I can’t understand, but it works for medical science.
Can connect to websites
CAN’T connect to websites
