From ArchWiki
Jump to navigation Jump to search

systemd-networkd-wait-online.service needed?

wq-quick@.service already contains Enabling the wait online service causes the whole boot process to pause while waiting for a network connection and can dramatically increase boot times. —This unsigned comment is by Smasher816 (talk) 03:54, 3 May 2018‎ (UTC). Please sign your posts with ~~~~!

I suspect the long network wait times might be caused by a lack of entropy rather than the target unit. Recommend rng-tools or haveged. Graysky (talk) 12:09, 17 November 2018 (UTC)
systemd-networkd has a timeout of 2 minutes for systemd-networkd-wait-online. See this GitHub issue: (especially this comment). I've had to explicitly tell systemd-networkd to ignore all links on one of my systems (with RequireForOnline=no), because it seems to wait for all devices to be online, not one of them. Aude (talk) 17:40, 17 November 2018 (UTC)
Just a guess based on some delays with a headless box. For some other use cases (wpa_supplicant on a raspberry pi), I needed to use an override as well. Graysky (talk) 19:33, 17 November 2018 (UTC).
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --ignore eth0
Yeah, that makes sense. I did an error and made the reply to your comment Graysky, but it was supposed to be a reply to the original poster. Sorry for the confusion. Aude (talk) 22:05, 17 November 2018 (UTC)

DNS troubleshoot

Until a proper NM plugin is released, weird interactions are going to occur between Wireguard and NM. Typically, if you create a tunnel and NM touches DNS for whatever reason (lease timeout, reconnection, etc.) I loose my connection.

I specifically focused on systemd-resolved because I find the approach much saner than the resolvconf mess. It is also supported by NM and not really "broadly" documented elsewhere. —This unsigned comment is by Gdonval (talk) 10:52, 15 September 2018‎ (UTC). Please sign your posts with ~~~~!

I'm also facing this issue after networkmanager upgrade. using wg-quick interface is up and running but after a minute it simply stops working. Problem is networkmanager changing dns lease.. I tried all possible solutions but with no results. Mohit310 (talk) 01:53, 6 April 2019 (UTC)

Move `Endpoint with changing IP` to `Tips & Tricks`

I can't justify it being under `Raw usage` as it's only a problem if you reference the server with a domain. I think it can be moved to the tips and tricks section. Foxboron (talk) 13:13, 16 December 2018 (UTC)

No objections. Graysky (talk) 14:07, 16 December 2018 (UTC)
Hey, thank you for your feedback. When I contributed this section I was unsure where I should put it, but I figured its critical enough to include it under the "Usage" section. Why can't you justify this being under "Usage", I think "server with a domain" is a pretty trivial configuration? systemd-networkd examples aren't exactly "Raw usage" either. Also I have just noted that VPN-Server Wireguard#Client_config has exactly the described issue my section covers. Note: I'm happy to move it to "Tips & Tricks", I'm just fairly new to archwiki and I'm trying to get a better understanding of common practices here. -- Insecuriy (talk) 15:12, 16 December 2018 (UTC)
The configuration describes a configuration and/or decision choice. Not something that is inherent to the configuration of wireguard. Arguably not even a common problem. If it was a "trivial configuration" the section wouldn't be needed. The systemd and config parts are examples and not explained with a lot of text and thus fits quite nicely within the "Usage" section. "Tips and tricks" also fits better for opinionated solutions or configurations tips.
Foxboron (talk) 15:19, 16 December 2018 (UTC)
I think this is a common problem, judging by seeing that "even this page" got it wrong under the "VPN Server Client Confing", maybe its a better fit under "VPN Server"? -- Insecuriy (talk) 15:26, 16 December 2018 (UTC)
It is a possible problem for both sections. Listing it under "VPN Server" would not really illustrate that very well. The usage section should be concise and to the point. Trying to fit every problem into that section would not really work in the long run.
Foxboron (talk) 15:31, 16 December 2018 (UTC)

Page is unclear on how to set up a routed network using WireGuard

When I initially started using WireGuard I started with this page, but going on I found it very misleading and usually I tell people who ask me to read the main website instead.

The problem is that it is unclear on how its cryptokey-routing mechanism works, and most of the examples in the page show configs that, in my opinion, "work by mistake".

On a regular switched network you have ARP and you usually set up a network prefix properly - an IP address and a netmask. So, if my address is (i.e. on eth0) and a program on my machine wants to contact, this is what happens:

  • The request reaches the kernel
  • The kernel (no routing involved) sees that is in the same network as the eth0 interface
  • The packet needs to go through layer 2, an ARP request is sent and the MAC address is resolved
  • An Ethernet frame is built for .2's MAC address and is sent to the network interface

Depau (talk) 17:15, 1 May 2019 (UTC)

Commenting in-line due to the size of the post and the inaccuracies contained within
This is not, in fact, what happens. Try it: empty out your routing table and try to reach anything that should be directly reachable on your LAN by IP address. You can't. No matter, however, that's not relevant to the rest of your post. MacGyver (talk) 22:47, 12 May 2019 (UTC)
I'll comment inline for the same reason.
First of all, thanks for your feedback. I must admit that I haven't actually tested some of these configuration, and wrote this out of what I remembered. Shame on me.
I'm still not convinced on this point in particular, I will definitely test it though. Depau (talk) 07:50, 13 May 2019 (UTC)

However, WireGuard is a layer 3 VPN so we have no ARP. We don't have Ethernet cables either, but we do have one or more UDP sockets and another WireGuard interface on the other end.

WireGuard has **no way** to know what IP address there is on the other end of the socket, and it defines no protocol to find it out. It still does have to pick one socket to send the packet to. It does that by using the AllowedIPs list "backwards", so:

  • When a packet is received from the WireGuard socket
    • it is dropped if it doesn't match any rule
  • When a packet is sent through the WireGuard interface
    • AllowedIPs is used as a "routing table" to pick a socket

The name "AllowedIPs" is a bit misleading: I think the wiki page should try to make this a little clearer. Depau (talk) 17:15, 1 May 2019 (UTC)

This is called CryptoKey routing and we've been having discussion on improving the documentation about that on the wireguard homepage and in the manpage itself. I don't believe it is up to us to fully explain the mechanism, but a quick mention would be in order. MacGyver (talk) 22:47, 12 May 2019 (UTC)
I also don't think the page is up to explain it fully, but yes, it should at least mention it. Depau (talk) 07:50, 13 May 2019 (UTC)

So, for example, to have a behavior that is similar to the switched network example, one would have to

  • Set IP address/netmask to
  • Set AllowedIPs for that specific peer should be set to ","

The important part here is that should *always* be added to AllowedIPs, even if other rules are more permissive. Depau (talk) 17:15, 1 May 2019 (UTC)

This is unnecessary. Without that particular address this setup works and it works intentionally. MacGyver (talk) 22:47, 12 May 2019 (UTC)

Why? Because of cryptokey routing:

  • When I receive a packet, it doesn't matter, both rules allow it

Depau (talk) 17:15, 1 May 2019 (UTC)

Actually it does matter because AllowedIPs functions on a strict rpfilter basis: It will only accept a packet if it would have been sent to that peer using that address as well. Which is why wireguard does not allow ambiguities like the one you're showing below. MacGyver (talk) 22:47, 12 May 2019 (UTC)
I will double check and update accordingly. Depau (talk) 07:50, 13 May 2019 (UTC)
  • When I *send* a packet, it's used as a routing table
    • Longest netmask wins
    • If I had multiple peers on the same network, WireGuard wouldn't know where to send the packet

Depau (talk) 17:15, 1 May 2019 (UTC)

It would, because there is absolutely no allowance for ambiguity. You've just got a misconfiguration. MacGyver (talk) 22:47, 12 May 2019 (UTC)

A real-life example where this is an issue is when I want one peer to be a gateway to the Internet, but I still want to reach all the others directly.

In this case, this is what I should have:

  • Address (wg0):
  • Gateway's AllowedIPs:,,
  • Other peer's AllowedIPs:,
  • etc.

Depau (talk) 17:15, 1 May 2019 (UTC)

This is wrong, plain and simple. You've now created an identical AllowedIPs configuration for the LAN, and it will only allow you to set it on one of them. MacGyver (talk) 22:47, 12 May 2019 (UTC)

Note that wg-quick also takes every AllowedIPs entry and adds it to the routing table. Also note that I only have to add the "" entry if I want those peers to route packets to other peers that I haven't configured on my machine.

So this is what happens now (if I use wg-quick):

  • I send a packet to
    • The kernel sees the address is in the same network as wg0, so it's sent to the WireGuard module

Depau (talk) 17:15, 1 May 2019 (UTC)

Nope. Goes through the routing table, then sees that it's supposed to go to wg0, so gets sent to wg0, which is handled by the wireguard module. MacGyver (talk) 22:47, 12 May 2019 (UTC)
    • WireGuard looks through all the AllowedIPs entries
      • They all match, but has the longest netmask so it's sent to that peer
  • I send a packet to
    • The kernel sees no interface is in the same network, so the packet needs to go through the routing table
    • wg-quick added an entry -> wg0 to the routing table, so it's sent to WireGuard
    • WireGuard looks through all the AllowedIPs entries
      • None matches except for, so it's sent to that peer

If I don't use wg-quick and I use, for example, systemd-networkd, I need to make sure I explicitly add those routes to the .network file to replicate the same behavior. Depau (talk) 17:15, 1 May 2019 (UTC)

How is this relevant to any of the above? Yes, you need to configure routing, or your network manager needs to do it for you and you need to tell it how. This page is not intended as a crash course to networking. MacGyver (talk) 22:47, 12 May 2019 (UTC)
I see, but I think it should at least be mentioned that wg-quick does set routes (if it isn't, I haven't checked) Depau (talk) 07:50, 13 May 2019 (UTC)

I decided to discuss this issue before actually editing the page. Let me know what you think about it :)

Depau (talk) 17:15, 1 May 2019 (UTC)

Good, because I think you're wrong on the point that one should always add the address of the remote peer to AllowedIPs. You should configure the AllowedIPs for multiple peers based on the actual routing mesh that you've got. (Or rather, routing tree, because of the strict rpfilter functionality I mentioned. To use wireguard in a mesh with failover you actually do need to ensure there's only one path to a peer from any other peer, so you need some active management.) Bear in mind that it's perfectly reasonable to configure no IP address at all on the wireguard interface, and only check on the traffic it routes; also bear in mind that most configurations are single-peer on the client-side and the server-side, and if the server-side is multi-peer there will usually be no overlap at all anyway. These configurations do not work "by mistake", they're correctly configured. However, I do agree that it would be beneficial to add a (correct) configuration example for the more advanced usecase of the mesh you're describing. If you need help figuring out what that configuration would be, it'd be easiest on IRC in either #archlinux or #wireguard, rather than here; and then summarize it here. MacGyver (talk) 22:47, 12 May 2019 (UTC)
I replied inline as I don't have time to actively discuss about this on IRC any time this week. Also I would like to test what you pointed out before I get back to it.
I'll come back to IRC as soon as I can. Again, thanks for your feedback :) Depau (talk) 07:50, 13 May 2019 (UTC)

Proposed merge of usage with use-case

@Nl6720 - You proposed a merge of these sections with he text, "There are no servers and clients in WireGuard, only peers." I feel breaking this out as-is and using terminology like "client" and "server" is needed for wireguard naive users. These are terms they have in their minds (e.g. openvpn) and when wanting to come over to wireguard help this transition. I will add a note to make this more clear in the subsection. Graysky (talk) 09:40, 23 November 2019 (UTC)