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)
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)
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)