Talk:WireGuard
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.0.0.0/0,::/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 route0.0.0.0/0&::/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.0.0.0/0;::/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 0.0.0.0/0, 192.168.1.0/24 in the AllowedIPs clause for that to work.
-- Chippey5 (talk) 08:33, 13 April 2020 (UTC)
- Are you saying that you can't reach 192.168.1.0/24, which is behind a Windows peer, with only 0.0.0.0/0 in AllowedIPs? Or is it the other way around, that the Windows peer can't reach 192.168.1.0/24 through another peer which is added with only 0.0.0.0/0 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 https://www.reddit.com/r/WireGuard/comments/gp250z/need_help_vpn_setup_one_of_the_clients_is_only/ , 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:
/etc/systemd/network/20-wired.network
[Match] Name=en* [Network] DHCP=ipv4 IPForward=ipv4
/etc/systemd/system/wireguard-iptables.service
[Unit] Description=Wireguard iptables forwarding rules After=network.target [Service] Type=oneshot 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 RemainAfterExit=yes [Install] WantedBy=multi-user.target
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)
I'm not sure Lahwaacz understands what 'example' means. And 'IPForward=ipv4' is a mandatory setting. Finoderi (talk) 20:00, 26 May 2021 (UTC)
Add a section of troubleshooting about how Secure Boot can prevent from using Wireguard
I had this issue, where `ip` was yelling `ip link add wg0 type wireguard Error: unknown device type`
Typing this error into google was not helping, and thanks to a coworker, I finally got it to work. My UEFI (Aorus X470 Ultra Gaming Mainboard) was configured with CSM support enabled. I switched to UEFI only, then deactivated SecureBoot. But I know some BIOS out there that even with secureboot disabled, you can't boot a installation media, so the other solution would be to manually add keys for Wireguard to work, but it require doing so every update.
--KrenoDeno (talk) 10:10, 31 December 2021 (UTC)
Loop routing
[This](https://wiki.archlinux.org/index.php/WireGuard#Loop_routing) gave the clearest explanation of the issue, but without a solution.
I've stumbled upon more information about it and felt it appropriate to put it here:
https://utcc.utoronto.ca/~cks/space/blog/linux/LinuxIpFwmarkMasks
Is the best entry point I could find. It has context for wireguard and refers to
https://utcc.utoronto.ca/~cks/space/blog/tech/IPRecursiveRoutingProblem Nrbray (talk) 23:45, 17 January 2024 (UTC)