Wireguard taking forever for dns replies

[josevillani]

Hi,

A though one IMHO. I’ve been experimenting on this for months.

I have openvpn and wireguard client configs and use either as need be. Both work perfectly on debian and windows. openvpn client works also very well on fedora.

The problem is with the wireguard client on fedora and that seems to be fedora specific. Whenever I issue a dns request, the reply takes 20 seconds to arrive. It’s unusable. I’ve been experimenting with a lot of different dns servers to no avail.

So it’s not a function of which dns server I’m querying. All behave identically. Even my own bind server on 192.168.167.10 or my dnsmasq server on Fedora (192.168.167.1) when I use it.

I tried the wg-quick approach and the NetworkManager approach as well. The wg-quick is faster for tests.

And my wireguard config is identical on debian, windows and fedora so the problem must be elsewhere, possibly with systemd-resolved however, I need systemd-resolved masked for openvpn to behave properly with dnsmasq as a NetworkManager plugin.

Needless to say, I already have disabled all those dnsmasq settings and re-enabled systemd-resolved to test wireguard in order to have the simplest possible configuration.

Any hints?

[barryascott]

I think you have a misconfiguration somewhere with the wireguard networking. The 20 second I think is the result of a timeout to a non-working dns server.

Debug your dns setup using resolvectl and the dig commands.

Check that the dns servers are correct with resolvectl.

Tell dig to use each configured dns server by ip address and see if you get timeouts for any of them.

You may also need to check that the routes are as you expect, see ip route.

[josevillani]

Hi,

Thanks for your reply!

I tried dig@server google.com on all the IPs I use and nothing special to report. It was expected as it works perfectly when wireguard is not in use.

resolvectl showed nothing special unless I’m missing something:

For openvpn:

$ sudo /usr/bin/resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported
  resolv.conf mode: foreign
       DNS Servers: 127.0.0.1 127.0.0.1

Link 2 (enp1s5)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 3 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1

For wireguard:

$ sudo /usr/bin/resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported
  resolv.conf mode: foreign
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1

Link 2 (enp1s5)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 4 (ca1624)
    Current Scopes: DNS
         Protocols: +DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported
Current DNS Server: 103.86.99.100
       DNS Servers: 103.86.99.100 103.86.96.100

Note that I added Nordvpn servers for wireguard to add redundancy.

127.0.0.1 is my dnsmasq plugin for NetworkManager as I noticed without it, there was an extraordinary large number of dns requests made. On the contrary to windows, there is no dns caching mechanism in Fedora. On debian, I use a bind server and on fedora, dnsmasq is configured to query my bind server on the lan.

More info:

$ sudo resolvectl show-server-state
Server: 127.0.0.1                                  
                              Type: system
            Verified feature level: UDP+EDNS0
            Possible feature level: UDP+EDNS0
                       DNSSEC Mode: allow-downgrade
                  DNSSEC Supported: no
Maximum UDP fragment size received: 1141
               Failed UDP attempts: 0
               Failed TCP attempts: 0
             Seen truncated packet: no
          Seen OPT RR getting lost: no
             Seen RRSIG RR missing: yes
               Seen invalid packet: no
            Server dropped DO flag: no
                                                   
Server: 103.86.99.100                              
                              Type: link
                         Interface: ca1624
                   Interface Index: 4
            Verified feature level: UDP+EDNS0
            Possible feature level: UDP+EDNS0
                       DNSSEC Mode: allow-downgrade
                  DNSSEC Supported: yes
Maximum UDP fragment size received: 512
               Failed UDP attempts: 0
               Failed TCP attempts: 0
             Seen truncated packet: no
          Seen OPT RR getting lost: no
             Seen RRSIG RR missing: no
               Seen invalid packet: no
            Server dropped DO flag: no
                                                   
Server: 103.86.96.100                              
                              Type: link
                         Interface: ca1624
                   Interface Index: 4
            Verified feature level: UDP+EDNS0+DO
            Possible feature level: UDP+EDNS0+DO
                       DNSSEC Mode: allow-downgrade
                  DNSSEC Supported: yes
Maximum UDP fragment size received: 1139
               Failed UDP attempts: 4
               Failed TCP attempts: 0
             Seen truncated packet: no
          Seen OPT RR getting lost: no
             Seen RRSIG RR missing: no
               Seen invalid packet: no
            Server dropped DO flag: no

For whatever reason, and that’s why I’d like to determine, wireguard works, kinda. It’s just abnormally slow due to the time it takes to reply to dns queries.

Openvpn:

$ ip address list
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:4c:69:1f:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.167.1/24 brd 192.168.167.255 scope global dynamic noprefixroute enp1s5
       valid_lft 82967sec preferred_lft 82967sec
    inet6 fe80::8e0c:ca6c:4a20:4cbe/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.100.0.2/24 brd 10.100.0.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::4b03:ba8d:3c6:b34a/64 scope link stable-privacy proto kernel_ll 
       valid_lft forever preferred_lft forever
$ ip route
default via 10.100.0.1 dev tun0 proto static metric 50 
default via 192.168.167.11 dev enp1s5 proto dhcp src 192.168.167.1 metric 100 
10.100.0.0/24 dev tun0 proto kernel scope link src 10.100.0.2 metric 50 
45.88.190.108 via 192.168.167.11 dev enp1s5 proto static metric 50 
192.168.167.0/24 dev enp1s5 proto kernel scope link src 192.168.167.1 metric 100 
192.168.167.11 dev enp1s5 proto static scope link metric 50

Wireguard:

$ ip address list
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:4c:69:1f:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.167.1/24 brd 192.168.167.255 scope global dynamic noprefixroute enp1s5
       valid_lft 82907sec preferred_lft 82907sec
    inet6 fe80::8e0c:ca6c:4a20:4cbe/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
6: ca1624: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.5.0.3/32 scope global noprefixroute ca1624
       valid_lft forever preferred_lft forever
$ ip route
default via 192.168.167.11 dev enp1s5 proto dhcp src 192.168.167.1 metric 100 
192.168.167.0/24 dev enp1s5 proto kernel scope link src 192.168.167.1 metric 100 
$ sudo wg
interface: ca1624
  public key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  private key: (hidden)
  listening port: 51820
  fwmark: 0xcb98

peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  endpoint: 45.88.190.xxx:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 25 seconds ago
  transfer: 124 B received, 7.08 KiB sent
  persistent keepalive: every 25 seconds

[barryascott]

@josevillani

It was expected as it works perfectly when wireguard is not in use.

I not clear on what tests you performed.
Did the DNS look work with wireguard is up?
Can you reproduce the 20s delay with a host <name> lookup?
Then do the dig for each server that resolvectl reports?

Also what is the ca1624 interface?
I expect to see a wg0 for wireguard, but you do not have one.

[josevillani]

I reproduced the dig tests below. It’s not always the same. This time 192.168.167.10 is problematic.

$ dig @103.86.99.100 google.com

; <<>> DiG 9.18.26 <<>> @103.86.99.100 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		60	IN	A	192.0.0.88

;; Query time: 6 msec
;; SERVER: 103.86.99.100#53(103.86.99.100) (UDP)
;; WHEN: Tue Jul 09 18:04:54 EDT 2024
;; MSG SIZE  rcvd: 55

$ dig @103.86.96.100 google.com

; <<>> DiG 9.18.26 <<>> @103.86.96.100 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50493
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		60	IN	A	192.0.0.88

;; Query time: 5 msec
;; SERVER: 103.86.96.100#53(103.86.96.100) (UDP)
;; WHEN: Tue Jul 09 18:05:00 EDT 2024
;; MSG SIZE  rcvd: 55

$ dig @127.0.0.1 google.com

; <<>> DiG 9.18.26 <<>> @127.0.0.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23923
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		60	IN	A	192.0.0.88

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Jul 09 18:05:08 EDT 2024
;; MSG SIZE  rcvd: 55

$ dig @192.168.167.10 google.com

; <<>> DiG 9.18.26 <<>> @192.168.167.10 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4429
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b3c4e33438e13ee401000000668db41dd6e6f974eb1b6c55 (good)
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		60	IN	A	192.0.0.88

;; Query time: 3261 msec
;; SERVER: 192.168.167.10#53(192.168.167.10) (UDP)
;; WHEN: Tue Jul 09 18:05:17 EDT 2024
;; MSG SIZE  rcvd: 83

Now the host tests. The 2 external dns servers and 182.168.167.10 are problematic. Not always the case though. Intermittent. Not always 20 seconds, but 5 or 10 certainly.

$ time host google.com 103.86.99.100
;; communications error to 103.86.99.100#53: timed out
;; communications error to 103.86.99.100#53: timed out
;; no servers could be reached


real	0m10,046s
user	0m0,015s
sys	0m0,012s

$ time host google.com 103.86.96.100
;; communications error to 103.86.96.100#53: timed out
Using domain server:
Name: 103.86.96.100
Address: 103.86.96.100#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m5,081s
user	0m0,015s
sys	0m0,010s

$ time host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m0,035s
user	0m0,011s
sys	0m0,013s

$ time host google.com 192.168.167.10
;; communications error to 192.168.167.10#53: timed out
Using domain server:
Name: 192.168.167.10
Address: 192.168.167.10#53
Aliases: 

Host google.com not found: 2(SERVFAIL)

real	0m10,036s
user	0m0,015s
sys	0m0,012s

ca1624 is how I named what is supposed to be named wg0. It’s ca1624 on all my other computers. Being relatively new to fedora, I kept the same name. I’ve been on debian for 30 years…

$ sudo ls -l /etc/wireguard
total 32
-rwxr--r-- 1 root root 689 14 oct  2022 ca1555.conf
-rwxr--r-- 1 root root 677 10 oct  2022 ca1555.conf2
-rwxr--r-- 1 root root 690 13 avr  2023 ca1606.conf
-rw------- 1 root root 692  9 jui 12:48 ca1624.conf
-rwxr--r-- 1 root root 677 16 sep  2022 ca1625.conf
-rwxr--r-- 1 root root 689 24 oct  2022 ca1636.conf.dont-use-it-breaks-gmx
-rwxr--r-- 1 root root 678 27 jui  2022 ca-us66.conf
-rw-r--r-- 1 root root 246 13 avr  2023 commands.txt

$ sudo ls -l /etc/NetworkManager/system-connections/ca1624.nmconnection 
-rw------- 1 root root 559  9 jui 17:49 /etc/NetworkManager/system-connections/ca1624.nmconnection

Now, Host results with openvpn instead of wireguard.

$ time host google.com 103.86.99.100
Using domain server:
Name: 103.86.99.100
Address: 103.86.99.100#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m0,077s
user	0m0,013s
sys	0m0,014s

$ time host google.com 103.86.96.100
Using domain server:
Name: 103.86.96.100
Address: 103.86.96.100#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m0,051s
user	0m0,010s
sys	0m0,014s

$ time host google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m0,142s
user	0m0,014s
sys	0m0,014s

$ time host google.com 192.168.167.10
Using domain server:
Name: 192.168.167.10
Address: 192.168.167.10#53
Aliases: 

google.com has address 192.0.0.88
google.com mail is handled by 10 smtp.google.com.

real	0m0,065s
user	0m0,014s
sys	0m0,013s

[vgaetera (Vladislav Grigoryev)]

@josevillani

there is no dns caching mechanism in Fedora

That’s wrong:

> resolvectl query example.com | tail -n 1
-- Data from: network

> resolvectl query example.com | tail -n 1
-- Data from: cache

resolved.conf: Network Name Resolution configuration files | systemd-resolved File Formats | Man Pages | ManKier

@josevillani

I added Nordvpn servers for wireguard to add redundancy.

This adds randomness resulting in uncertainty and possible inconsistency and should not be used until the issue is properly isolated and resolved.

@josevillani

Server: 103.86.96.100                              
               Failed UDP attempts: 4

This looks like a problem.

@josevillani

The 2 external dns servers and 182.168.167.10 are problematic. Not always the case though. Intermittent. Not always 20 seconds, but 5 or 10 certainly.

You should remove those unreliable resolvers.

In addition, test the relevant NSS backends:

time getent -s dns hosts example.com
time getent -s resolve hosts example.com

[josevillani]

Thanks a lot for your reply.

There was some unknown interaction between NetworkManager, resolveconf and dnsmasq, some kind of dns loop:

When I don’t use NetworkManager for the configuration to start it, but use wg-quick instead, all goes perfectly well. I guess I can live with it.

The only thing I would add is a conditional to have the following available for openvpn config:

$ cat /etc/NetworkManager/conf.d/00-use-dnsmasq.conf 
#[main]
#dns=dnsmasq

I’ve disabled it for wireguard to function normally, but I’d like to have it for openvpn.

[vgaetera (Vladislav Grigoryev)]

It is problematic to change the global configuration without restarting or reloading the service, and to be honest there’s normally no need for such a hassle, since with the right settings it should work correctly using the same DNS processing mode for all connections.

[hmmsjan (h.janssen)]

The strange thing is: 10.5.0.2 and 103.86.96.100 look perfectly correct when captured from the wireguard interface, but why should the same question 4 asked times before answer arrives? It’s UDP, so in case of no answer ask again, but why? Is it DNS config or some connection issue? Is a file transfer possible via wireguard or is that also very slow ?

I do not like the dnsmasq/systemd-resolved combination. Do you setup NordVPN by app or ovpn file? By app you can do nothing, but after import ovpn into NetworkManager DNS should be handled correctly without dnsmasq.

Did you import the wireguard config with “nmcli conn import type wireguard file xxxx.conf”?
IP address and DNS land in the IPv4 config tab.

[josevillani]

@vgaetera

It is problematic to change the global configuration without restarting or reloading the service, and to be honest there’s normally no need for such a hassle, since with the right settings it should work correctly using the same selected DNS processing mode for all connections

Certainly. It does work like this in Debian. I’m new to avahi, NetworkManager, resolveconf. My debian config is still based on /etc/network/interfaces, openvpn client is started with ‘openvpn’ and wireguard clients with ‘wg-quick’.

Changing my openvpn DNS in the config to match wireguard should get openvpn clients to work without dnsmasq.

However I’ve interrogated some IA like phind.com and blackbox.io and they gave me conditional settings for the network manager config. None of them worked or I did not apply them properly. Their replies were pretty cryptic.

Thanks for your time, quite appreciated!

My nordvpn subscription is about to expire and i wanted to have both wireguard and openvpn setup properly before giving a try to mullvad.

[josevillani]

The strange thing is: 10.5.0.2 and 103.86.96.100 look perfectly correct when captured from the wireguard interface, but why should the same question 4 asked times before answer arrives? It’s UDP, so in case of no answer ask again, but why? Is it DNS config or some connection issue? Is a file transfer possible via wireguard or is that al so very slow ?

Conflict between stock configuration, networkmanager’s, dnsmasq, /etc/systemd/resolved.conf.d/custom.conf and resolv.conf I would say. Also a 127.0.0.1 dns loop quite possibly. File transfer is normal, in fact usually faster with wireguard than openvpn, when properly setup.

I do not like the dnsmasq/systemd-resolved combination. Do you setup NordVPN by app or ovpn file? By app you can do nothing, but after import ovpn into NetworkManager DNS should be handled correctly without dnsmasq.

No app. Only conf files for both openvpn and wireguard.
openvpn configs work perfectly with dnsmasq; wireguard do not.

Did you import the wireguard config with “nmcli conn import type wireguard file xxxx.conf”?
IP address and DNS land in the IPv4 config tab.

Precisely. And that caused the problem. So reverted to wg-quick instead of networkmanager to start wireguard client:

$ sudo systemctl status wg-quick@ca1682
● wg-quick@ca1682.service - WireGuard via wg-quick(8) for ca1682
     Loaded: loaded (/usr/lib/systemd/system/wg-quick@.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (exited) since Wed 2024-07-10 07:16:55 EDT; 1h 36min ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 1641 ExecStart=/usr/bin/wg-quick up ca1682 (code=exited, status=0/SUCCESS)
   Main PID: 1641 (code=exited, status=0/SUCCESS)
        CPU: 87ms

jui 10 07:16:54 xxx wg-quick[1641]: [#] ip -4 address add 10.5.0.2/32 dev ca1682
jui 10 07:16:54 xxx wg-quick[1641]: [#] ip link set mtu 1420 up dev ca1682
jui 10 07:16:54 xxx wg-quick[1700]: [#] resolvconf -a ca1682 -m 0 -x
jui 10 07:16:55 xxx wg-quick[1641]: [#] wg set ca1682 fwmark 51820
jui 10 07:16:55 xxx wg-quick[1641]: [#] ip -4 route add 0.0.0.0/0 dev ca1682 table 51820
jui 10 07:16:55 xxx wg-quick[1641]: [#] ip -4 rule add not fwmark 51820 table 51820
jui 10 07:16:55 xxx wg-quick[1641]: [#] ip -4 rule add table main suppress_prefixlength 0
jui 10 07:16:55 xxx wg-quick[1641]: [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
jui 10 07:16:55 xxx wg-quick[1641]: [#] nft -f /dev/fd/63
jui 10 07:16:55 xxx systemd[1]: Finished wg-quick@ca1682.service - WireGuard via wg-quick(8) for ca1682.

[hmmsjan (h.janssen)]

I downloaded a NordVPN zip with an awful lot of ovpn files. They contain no script to change DNS, which means that your original DNS is still used with VPN on. Did you provide your own up-down script to manipulate the dnsmasq settings somehow?

After import into NetworkManager, the DNS server pushed from the openvpn server, if any, should be set by NetworkManager. The listing you showed with tun0 DNS 127.0.0.1 shows that dnsmasq is used, but gives no indication about the upstream server.

Still no idea why your DNS is so bad, while the wireguard connection is apparently fine.

Edit: please neglect my note about Mullvad VPN which is present in the mails the forum sends as not written. That applies to some other VPN, not Mullvad.

[barryascott]

@hmmsjan

but why should the same question 4 asked times before answer arrives

The simple answer is: Because you have an unreliable network.
Somewhere the UDP packet is being dropped.

[josevillani]

They contain no script to change DNS, which means that your original DNS is still used with VPN on. Did you provide your own up-down script to manipulate the dnsmasq settings somehow?

Kinda

#!/bin/bash

connections=$(nmcli connection show | grep nordvpn | awk '{print $1}')
#connections=$(nmcli connection show | grep nordvpn | grep -v ca16 | grep -v ca15 | grep -v ca-us | awk '{print $1}')

# Pour chaque connexion VPN
for connection in $connections
do
  # Supprimer la connexion
  ionice -c 3 nmcli connection delete id $connection
done

#configs=$(ls /etc/openvpn/ovpn_udp/ca1[567]*)
configs=$(ls /etc/openvpn/ovpn_udp/ca1[56]* /etc/openvpn/ovpn_udp/ca-us6* /etc/openvpn/obfuscated/ca153[0-3].nordvpn.com.tcp.ovpn)

# Pour chaque fichier de configuration OpenVPN
for config in $configs
do
  # Importer le fichier de configuration à NetworkManager
  ionice -c 3 nmcli connection import type openvpn file $config
done

# Récupérer la liste de toutes les connexions VPN
connections=$(nmcli connection show | grep nordvpn | awk '{print $1}')

# Pour chaque connexion VPN
for connection in $connections
do
  # Modifier les informations d'identification
  ionice -c 3 nmcli connection modify id $connection vpn.secrets 'password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
  #echo $connection
done

sudo sed -i "s/mtu=1500/mtu=1500\nusername=xxxxxxxxxxxxxxxxxxxxxxxxxxxx/g"  /etc/NetworkManager/system-connections/ca*nordvpn*
sudo sed -i ':a;N;$!ba;s/auto/ignore/2' /etc/NetworkManager/system-connections/ca*nordvpn*
sudo sed -i 's/password-flags=1/password-flags=0/g' /etc/NetworkManager/system-connections/ca*nordvpn*
#sudo sed -i "s/\[ipv4\]/[ipv4]\ndns=192.168.167.10;103.86.96.100;103.86.99.100;\nignore-auto-dns=true/g" /etc/NetworkManager/system-connections/ca*nordvpn*
sudo sed -i "s/\[ipv4\]/[ipv4]\ndns=127.0.0.1\nignore-auto-dns=true/g" /etc/NetworkManager/system-connections/ca*nordvpn*

sync
sudo reboot

The listing you showed with tun0 DNS 127.0.0.1 shows that dnsmasq is used, but gives no indication about the upstream server.

It’s configured to a bind server on my lan which uses the nordvpn dnses as resolvers.

[barryascott]

@josevillani

NetworkManager, resolveconf and dnsmasq

I suggest that you simplify your setup, remove dnsmasq and see if you can make it stable.
What are you using dnsmasq for?

[josevillani]

I suggest that you simplify your setup, remove dnsmasq and see if you can make it stable.
What are you using dnsmasq for?

It’s currently disabled, thanks. wireguard doesn’t use it and is now super stable.

I could use it for openvpn clients as it results in less dns requests being made. Only an hypothesis. I’ll review the openvpn part another day. I was on the computer reading and trying settings for wireguard for 15 hrs yesterday and I need a break before going on with openvpn and dnsmasq. Ideally I would drop it completely.

New config:

$ sudo /usr/bin/resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/unsupported
  resolv.conf mode: foreign
Current DNS Server: 127.0.0.1
       DNS Servers: 127.0.0.1

Link 2 (enp1s5)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6
         Protocols: -DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/supported

Link 3 (ca1682)
    Current Scopes: DNS
         Protocols: +DefaultRoute LLMNR=resolve -mDNS DNSOverTLS=opportunistic DNSSEC=allow-downgrade/unsupported
Current DNS Server: 192.168.167.10
       DNS Servers: 192.168.167.10
        DNS Domain: ~.

$ sudo resolvectl show-server-state
Server: 127.0.0.1                                  
                              Type: system
            Verified feature level: n/a
            Possible feature level: UDP+EDNS0+DO
                       DNSSEC Mode: allow-downgrade
                  DNSSEC Supported: yes
Maximum UDP fragment size received: 512
               Failed UDP attempts: 2
               Failed TCP attempts: 0
             Seen truncated packet: no
          Seen OPT RR getting lost: no
             Seen RRSIG RR missing: no
               Seen invalid packet: no
            Server dropped DO flag: no
                                                   
Server: 192.168.167.10                             
                              Type: link
                         Interface: ca1682
                   Interface Index: 3
            Verified feature level: UDP+EDNS0
            Possible feature level: UDP+EDNS0
                       DNSSEC Mode: allow-downgrade
                  DNSSEC Supported: no
Maximum UDP fragment size received: 1139
               Failed UDP attempts: 0
               Failed TCP attempts: 0
             Seen truncated packet: no
          Seen OPT RR getting lost: no
             Seen RRSIG RR missing: yes
               Seen invalid packet: no
            Server dropped DO flag: no

[hmmsjan (h.janssen)]

OK, so with OpenVPN you are using NetworkManager, modified to ignore the pushed DNS server and pointing to your own DNS server elsewhere cached by dnsmasq. In principle no problem, unless you do not like dnsleaks. wg-quick definitively sets the DNS server for the wireguard to 103.86.99.100, which is owned by NordVPN and gives immediate answer from here. Which I did not expect, because I have no relation with NordVPN.
But OK, still no explanation but it works correctly now with wg-quick or it’s service, which is the same.

Then it’s better to look to OpenVPN conig and get rid of dnsmasq (nothing against it because its a great program but complimentary to systemd-resolved concerning DNS).
/etc/resolv.conf should become a symlink to /var/run/systemd/resolve/stub-resolv.conf
and you have the choice to define your own dns server the way you did already or set everything to automatic and use the server-pushed one. Functionality is identical, systemd-resolved is a cache.

[josevillani]

Totally agree. This will be my next step.

[barryascott]

@josevillani

I could use it for openvpn clients as it results in less dns requests being made.

Systemd-resolved will do the caching for you. No need to add in dnsmasq.