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)

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 added this note to make this more clear in the subsection. Graysky (talk) 09:40, 23 November 2019 (UTC)

The only thing that makes a specific peer into a server is that another peer is routing all traffic (, ::/0) to it and sets it as the DNS server, and maybe that the server has a DNS record. That's it. I think creating a top level section with multiple subsections just to state this simple fact is too much and it gives the impression that WireGuard setup is more complicated than it actually is. It could be simple explained in WireGuard#Usage, possibly in one subsection of it. Also the WireGuard#Usage and WireGuard#Specific use-case: VPN server separation makes it seem like you either just connect the individual peers or setup a server and other peers router all traffic to it. There's not limit to which and from which peer you route & ::/0.
Personally I use WireGuard through NetworkManager and I have two almost identical connections (wg0.nmconnection and wg1.nmconnection), the only difference is that wg1 routes;::/0; to peer 1.
-- nl6720 (talk) 10:47, 23 November 2019 (UTC)

Additional routes subsection is not working

Internal addresses can't be reached unless you also specifically add the correct CIDR for the network when using Windows as peer. So in my case I have to use, in the AllowedIPs clause for that to work. -- Chippey5 (talk) 08:33, 13 April 2020 (UTC)

Are you saying that you can't reach, which is behind a Windows peer, with only in AllowedIPs? Or is it the other way around, that the Windows peer can't reach through another peer which is added with only in AllowedIPs? -- nl6720 (talk) 08:34, 19 April 2020 (UTC)

Add subsection in troubleshooting for other MTU issues

I'd like to add a section under "Troubleshooting" on a problem I've been bashing my head onto for a few hours.

I've been having this issue with two peers communicating over IPv6. Handshakes and small packets would go through. If I curl-ed the other host I could see the TCP handshake and the last part of the HTML, but not the big chunks. I eventually did some quick math and figured an MTU of 1380 should be enough to account for IPv6, UDP and WireGuard headers + some extra bytes to be on the safe side on an interface with a default 1500B MTU. It did work.

I would like some advice on wording to keep the page quality and accuracy good, and to avoid stuff like my discussion above. 1380 (or rather 1500 - around 120) works for me, though I wouldn't throw that magic number into the page without a proper technical explanation.

Depau (talk) 21:30, 3 January 2020 (UTC)

Improvements to the Specific use-case: VPNserver section

This should contain a note that you need to set up NAT if you want the VPN to not only connect to the "server" but also allow access to the network its in (which is how OpenVPN behaves) something like that would have saved me from spending hours with crappy incomplete guides first trying to figure out, how to correctly set up NAT for this. I finally managed to piece it together (mostly with Wireshark and the article on Internet sharing), but I would like to spare people who come after me from that. Any objections against me adding something like that? Flo Grauper (talk) 05:04, 17 April 2020 (UTC)

Then contribute to the article. Nobody is going to do this for you. Foxboron (talk) 10:44, 19 April 2020 (UTC)

Why use /24 address in VPN config?

Why does the address in WireGuard#Server_config and WireGuard#Client_config use /24 mask as opposed to /32? I noticed that when I posted in , both seem to work but I don't understand the potential need for /24. --Trougnouf (talk) 11:47, 23 May 2020 (UTC)

That's how IP layer works. Basically you must define subnets and gateways when you assign IPs because this is the network standard and that's what all good people do. /32 means a single allowed IP and /24 - is a subnet of 254 hosts. You can lower that number if you want, e.g. use /29 if a subnet of only 6 peers would be enough for you. —This unsigned comment is by Finoderi (talk) 07:16, 28 August 2020‎. Please sign your posts with ~~~~!

MTU correction

The article states when the MTU is too low, one can set it to a different value. Most people (including me) do not know what the MTU is, and will probably not know what to look for. For me, running ip -a allows me to see the MTU used by my NIC. Subsequently using that value in the Wireguard config solves the problem... at least I regard this as a better solution than arbitrarily trying various MTU values, including the one denoted in the article.

Is this a good way of solving it and is it worth mentioning in the article to do it this way? Irunarchbtw (talk) 09:39, 3 October 2020 (UTC)

Improve systemd-networkd forwarding implementation

An alternative I've found is using a separate systemd service to implement the rules at startup. Also, sounds like you don't need the IPMasquerade line at all then, @Finoderi? Ultimately I think it would be optimal if we have a way to tie this to the actual wg0 network, as a pre-up/post-down execution like we can with wg-quick:

Warning: You must still enable IP Forwarding and IP masquerading rules in order provide working internet to Peer B:

Description=Wireguard iptables forwarding rules

ExecStart=/usr/bin/iptables -A FORWARD -i wg0 -j ACCEPT
ExecStart=/usr/bin/iptables -A FORWARD -o wg0 -j ACCEPT
ExecStart=/usr/bin/iptables -t nat -A POSTROUTING -o enp5s0 -j MASQUERADE
ExecStop=/usr/bin/iptables -D FORWARD -i wg0 -j ACCEPT
ExecStop=/usr/bin/iptables -D FORWARD -o wg0 -j ACCEPT
ExecStop=/usr/bin/iptables -t nat -D POSTROUTING -o enp5s0 -j MASQUERADE


Cotsuka (talk) 00:00, 1 April 2021 (UTC)

Yes, for now 'IPMasquerade' does nothing in this case. Imho adding forwarding and masquerading rules to a firewall directly is better. If somebody didn't enable iptables.service this unit won't work and then you have to mention it as well, and the list of instructions grows bigger and bigger. I think the suggestion that's already there should be enough. ('Assumes ufw, but you could do the same with iptables by using the rules outlined in the Server config section').
And 'In order to provide' - small typo.Finoderi (talk) 07:11, 1 April 2021 (UTC)