My configuration for nm-cli does not work as I would expect (probably an issue from my side), so i need help to figure out how to fix it.
Networking Setup
Local connection connected through Ethernet.
Wireguard VPN to a remote server (non local network).
DNS (PiHole) through the Wireguard connection.
Expected
Computer connect to ethernet
Wireguard connect to the server
DNS works.
Actually
Computer connect to ethernet
Wireguard connect to the server
DNS does not works.
Workaround
After logon
Turn down the wireguard connection
Turn up the wireguard connection
So I have a feeling that the problem comes from wireguard being turned up before the ethernet is. (but then it should still be able to work once the ethernet is turned on!
Few info (from commands I gathered from other posts)
Not Working (After logon)
~ > ping google.com
ping: google.com: Temporary failure in name resolution
~ > traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 _gateway (REDACTED/LOCAL GATEWAY) 0.342 ms 0.312 ms 0.337 ms
2 REDACTED (REDACTED) 30.570 ms 30.557 ms 30.540 ms
3 REDACTED (REDACTED) 12.261 ms 12.719 ms 12.237 ms
4 142.250.160.73 (142.250.160.73) 15.707 ms 15.695 ms 15.766 ms
5 * * *
6 8.8.8.8 (8.8.8.8) 16.419 ms 12.484 ms 12.468 ms
~ > traceroute google.com
google.com: Temporary failure in name resolution
Cannot handle "host" cmdline arg `google.com' on position 1 (argc 1)
~ > resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eno1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: IPV6-REDACTED
DNS Servers: IPV6-REDACTED IPV6-REDACTED
DNS Domain: REDACTED REDACTED
Link 4 (stratus)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: PIHOLEIP
DNS Servers: PIHOLEIP
DNS Domain: ~.
Working (After turning the wireguard connection Down and Up)
~ > ping google.com
PING google.com(lga15s49-in-x0e.1e100.net (2607:f8b0:4006:80d::200e)) 56 data bytes
64 bytes from lga15s49-in-x0e.1e100.net (2607:f8b0:4006:80d::200e): icmp_seq=1 ttl=110 time=166 ms
64 bytes from lga34s36-in-x0e.1e100.net (2607:f8b0:4006:80d::200e): icmp_seq=2 ttl=110 time=160 ms
64 bytes from lga15s49-in-x0e.1e100.net (2607:f8b0:4006:80d::200e): icmp_seq=3 ttl=110 time=159 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3005ms
rtt min/avg/max/mdev = 159.437/161.619/165.720/2.901 ms
~ > traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 _gateway (REDACTED/LOCAL GATEWAY) 0.390 ms 0.288 ms 0.281 ms
2 REDACTED (REDACTED) 14.215 ms 14.146 ms 14.187 ms
3 REDACTED (REDACTED) 15.294 ms 15.231 ms 15.255 ms
4 142.250.160.73 (142.250.160.73) 16.598 ms 16.535 ms 16.565 ms
5 * * *
6 dns.google (8.8.8.8) 17.065 ms 16.825 ms 16.918 ms
~ > traceroute google.com
traceroute to google.com (142.250.80.110), 30 hops max, 60 byte packets
1 _gateway (REDACTED/LOCAL GATEWAY) 0.343 ms 0.306 ms 0.390 ms
2 REDACTED (REDACTED) 12.943 ms 13.656 ms 13.633 ms
3 REDACTED (REDACTED) 13.621 ms 13.610 ms 13.599 ms
4 142.250.160.73 (142.250.160.73) 16.820 ms 16.809 ms 16.798 ms
5 * * *
6 216.239.43.50 (216.239.43.50) 17.288 ms 172.253.70.182 (172.253.70.182) 17.417 ms 108.170.242.129 (108.170.242.129) 15.123 ms
7 108.170.242.177 (108.170.242.177) 17.375 ms 108.170.242.146 (108.170.242.146) 16.649 ms 108.170.242.98 (108.170.242.98) 17.350 ms
8 209.85.249.241 (209.85.249.241) 35.887 ms 209.85.249.18 (209.85.249.18) 14.674 ms 209.85.244.37 (209.85.244.37) 14.595 ms
9 216.239.63.134 (216.239.63.134) 23.250 ms 142.250.213.6 (142.250.213.6) 19.325 ms 216.239.63.134 (216.239.63.134) 23.122 ms
10 172.253.79.52 (172.253.79.52) 103.981 ms 172.253.79.46 (172.253.79.46) 130.026 ms 133.763 ms
11 * * 142.250.213.71 (142.250.213.71) 152.182 ms
12 216.239.59.1 (216.239.59.1) 164.671 ms * 162.814 ms
13 216.239.62.194 (216.239.62.194) 166.500 ms 142.251.69.0 (142.251.69.0) 167.033 ms 164.556 ms
14 108.170.248.97 (108.170.248.97) 162.555 ms 108.170.248.33 (108.170.248.33) 163.854 ms 108.170.248.97 (108.170.248.97) 160.370 ms
15 142.251.65.115 (142.251.65.115) 161.550 ms 161.488 ms 164.138 ms
16 lga34s36-in-f14.1e100.net (142.250.80.110) 163.535 ms 164.873 ms 163.333 ms
~ > resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eno1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: IPV6-REDACTED
DNS Servers: IPV6-REDACTED IPV6-REDACTED
DNS Domain: REDACTED REDACTED
Link 5 (stratus)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: PIHOLEIP
DNS Servers: PIHOLEIP
DNS Domain: ~.
The only difference is just that the DNS setting (from wireguard) does not seems to be applied at logon.
nmcli setting:
eno0 connect automatically with priority 999 (was -999 by default without any change)
stratus connect automatically with priority 0
Any ideas on how to make it work ? (starting wireguard connection as a service works, but it’s not managed by nm-cli).
Configure the timing for when wireguard is started to wait until after the network is fully active. Since wg depends upon funtional networking that seems a logical process. If wg is started as a service then make it start ‘After=network-online.target’ in the .service file.
Wireguard is not started as a service, as I want it to be configured through network manager (so it’s a one stop option for me to manage my connections).
But when I tried as a service, it did work as intended.
So the question is how can I get wireguard to wait for the networking to be functional through network manager?
Network manager doesn’t consider wireguard as a VPN, and I have not seen any option for delay startup, just the priority one which doesn’t seems to be doing enough.
You can write a script in /etc/NetworkManager/dispatcher.d calling “wg-quick up” if argument1 = eno1 and argument2 = up. Of course no problem to prepend wg-quick with a sleep of one or more seconds.
To make it clean, you can add a second script calling “wg-quick down” if the second argument is pre-down and place it in the pre-down.d subfolder.
The funny thing is, at least on Mate-desktop, that nm-applet “sees” wireguard, even when started via wg-quick, and on mouse-over it displays “VPN connection active”.
I don’t see a difference in the resolvectl output before/after reactivation of the WireGuard profile. What is the difference? What does wg show say? Did you configure the peer’s endpoint as IP address or DNS name?
Sidenotes:
autoconnect-priority only matters if you had multiple profiles that could connect at the same time. It does not delay the activation.
I am not sure that it’s necessary for the WireGuard profile to activate after the ethernet. Why would that be? Sure, you have a problem that needs investigation and fixing, but the solution may not be “activate WireGuard later”.
if you are willing to write a dispatcher script that calls wg-quick up, you could at that point just as well call nmcli connection up wg0. But I think it would be better to first understand the deeper problem, instead of trying to workaround it by manually activate the WireGuard profile later.
You can write a script in /etc/NetworkManager/dispatcher.d calling “wg-quick up” if argument1 = eno1 and argument2 = up. Of course no problem to prepend wg-quick with a sleep of one or more seconds.
To make it clean, you can add a second script calling “wg-quick down” if the second argument is pre-down and place it in the pre-down.d subfolder.
Thanks I will keep that in mind.
I don’t see a difference in the resolvectl output before/after reactivation of the WireGuard profile. What is the difference?
Exactly the only difference is that on logon the DNS does not work, while on restarting the wireguard, DNS work, the diffrence is in the ping and traceroute not in the resolvectl.
What does wg show say?
I will upload it after I can reboot.
Did you configure the peer’s endpoint as IP address or DNS name?
DNS name (in case I decide to transfer the wireguard server to another VPS)
Thanks you for the information, it’s good to know and so not the problem (since I only have one profile)
I would think the same things, but at the moment the ‘only’ (known to me) difference between working and not working, is either or not I manually do it (so connected to eth) or it’s automatic (I don’t know when it happen)
I am happy to have learned about the dispatcher option, and would prefer finding the actual root of the problem too. But the dispatcher option could be more useful if I ever switch to a laptop with wifi (that would solve a different problem).
So happy to try things and figure out a solution (and learn more about Linux Networking and Network Manager in the same time)
NetworkManager “only” configures your system. So if something doesn’t work (e.g. resolving names), then you can look at the system what is, and understand where it fails. Then, in a second step ask how to change something in NetworkManager to get the desired behavior.
It would seem, that you use systemd-resolved. From resolvectl output, it also seems that the configuration there is the same. Can you ping the configured nameservers? If not, check the routing tables (ip route), which for WireGuard is a bit more complex, because it uses policy routing (ip rule; ip route show table all, see Understanding modern Linux routing (and wg-quick) . Also, check the WireGuard setup (wg show).
For completeness a summary with a few points discussed earlier on this forum,
I do not know whether anything applies:
wg-quick and wireguard service are equivalent
I have the impression that NetworkManager wireguard is better in setting up wireguard server/concentrator than client.
wg-quick allows to setup DNS servers for the link. Do not combine this with “SaveConfig”, the DNS setting will be lost upon link restart in Fedora.
wg-quick allows (Post,Pre)(Up,Down) commands/scripts. If the VPN is only for pihole DNS, you probably need this to change the DNS settings of the main link. So with nmcli you probably need dispatcher scripts calling resolvectl anyhow.
Never set a gateway in nmcli’s Wireguard IPv4 settings. There is a risk of killing the escape route for the encrypted packets, blocking wireguard and may be the whole internet access.
There have been other issues in this forum where a vpn activated automatically started too soon and the network was not fully up so it did not get properly configured.
In that case the delay enabled it to start cleanly with no issues and this seems like a similar problem. The network has to be fully active so the vpn can get all its config from the remote server.
interface: stratus
public key: REDACTED
private key: (hidden)
listening port: 51820
peer: REDACTED
preshared key: (hidden)
endpoint: IP-SERVER-PORT
allowed ips: VPN-DOCKERS-IPS
latest handshake: 1 second ago
transfer: 396 B received, 372 B sent
So it seems that wireguard is not connected but active at logon, and since my DNS goes through wireguard when wireguard is active.
Since my wireguard config has the server as a domain name and not ip. could it be that wireguard try to connect too early, so active but not connected, which change my dns, which when my ethernet is then connected, wireguard still cannot connect as it cannot resolve the domain name.
I may not fully understand, but I believe that is what I have done, I had my all setup working (including with wg-quick as a service), but while trying to setup a networking widget for awesomewm, I found out that i can gather and control all the network connection with nmcli, so I decided to switch to it. nmcli did see my wireguard connection but couldn’t control it as it was not a Network Manager connection.
So i know that the problem comes from the autostart of the wireguard connection with nmcli, as manual connection always works, and auto connections through other methods (services / scripts) works.
I am going try changing my the wireguard conf to use the server IP instead of Domain Name, and see if that would comes from there.
OK so all of your questions (especially the wg show one) helped me try different things.
Here is the exact combinaison that does not work:
Wireguard config using domain name for the server
Network Manager: All users may connect to this network ticked (default option)
Solutions that works(in my use case, of single user and ethernet connection)
Wireguard config using IP of the server (removing the whole DNS problem in the first place.
Wireguard config with multiple DNS, Using a public DNS (like cloudfare) as a backup. Bonus point: if my pihole fail, I will still be able to be on internet)
Network Manager: All users may connect to this network unticked. Forcing it to be loaded after the regular network I guess.
I have implemented the last two (I still prefer to use domain name over IP for the server).
Thanks for the help and also for always add extra information so i can learn more about how it works.