top | item 42229299

WireGuard: Beyond the most basic configuration

326 points| rzk | 1 year ago |sloonz.github.io | reply

109 comments

order
[+] entangledqubit|1 year ago|reply
Not to hijack but last time I was setting up wireguard, I found this site to be super useful: https://www.procustodibus.com/blog/2020/10/wireguard-topolog...
[+] franga2000|1 year ago|reply
+1 for this, any time I or a colleague have a wireguard issue that smells of "you're using it wrong" I come back to this set of articles (don't miss the links to separate detailed posts for each configuration!)
[+] filterfish|1 year ago|reply
Their blog is an incredibly useful resource for so many different scenarios.
[+] ww520|1 year ago|reply
Setting up a dynamic DNS record to map a hostname to my home network’s dynamic IP actually makes private VPN usable. It’s really a game changer to be able to access all the local services and resources on the road without exposing them to the public internet.
[+] leetrout|1 year ago|reply
Are you using an internal or external service? Curious what you or others recommend...

I've done a bit of both... I used CloudFlare which works fine and then I moved over to tailscale when playing with pxe / netboot and I've not decided on what to use beyond tailscale's magic dns. Unbound looks pretty nice.

[+] smw|1 year ago|reply
Just give in and use tailscale, life is so much better on the dark side!
[+] kccqzy|1 year ago|reply
Why would you need a dynamic DNS record though? Within the VPN you should feel free to hard code any address you want. You control the network after all. In my own VPN I've never had a need to have IP addresses changed.
[+] opk|1 year ago|reply
This article implies that you have to use NAT with Wireguard which really isn't the case at all. Normal subnet routing works fine provided your destination hosts know to use the wireguard server as the gateway for the wireguard subnet. Just configuring a static route on the normal default router is generally enough. Certainly, there are cases where NAT is useful, for example I redirect attempts to use public DNS to my local DNS.
[+] OptionOfT|1 year ago|reply
Since the post mentions IPv6, I thought I'd put out a BIG footgun that the WireGuard app to this date hasn't solved.

Imagine a situation with 464XLAT, e.g. on T-Mobile in the USA. You only have an IPv6 address. When you want to communicate to a server that only has an IPv4 endpoint you go over a proxy owned by T-Mobile. The traffic leaving your device is always IPv6, unlike say CGNAT, where there is IPv4 traffic between your device and the NAT gateway.

Problem with the default WireGuard app on iOS is that when it is set up to connect to a DNS name which offers both A and AAAA they default to the A one, which means on T-Mobile the connection goes over this proxy and constantly breaks, as the proxy connection times out after a while. So things like Push notifications stop working.

The fix is to create a separate config with the IPv6 address and connect to that one. No more middle-man, and push notifications keep on working, even when you disable KeepAlive.

[+] t0mas88|1 year ago|reply
I'm using wireguard with ipv6, the only thing that I never got to work is for wireguard to do ipv6 prefix delegation allowing devices to pick (and change) their own address like they do on a normal ethernet subnet.

I like the randomisation that normally happens to make it invisible which phone/device in the subnet made each request.

[+] jeroenhd|1 year ago|reply
I don't know about PD, but I found that native clients will accept RAs over WireGuard just fine. I only have a /64 at the moment unfortunately, so I can't really use this mechanism at the moment, but I did set up a ULA by giving radvd the following config:

    interface wg-server
    {
        AdvDefaultLifetime 0;
        AdvSendAdvert on;
        prefix fdf4:a694:0e43:c0de::/64 {
            AdvOnLink on;
            AdvAutonomous on;
        };
    };
    
I use the equivalent of fdf4:a694:0e43::/48 across all interfaces to make the ULA routable without too much effort.

I don't see why you wouldn't be able to set up a normal IPv6 SLAAC config, assuming you have the address space to advertise a full /64 on the interface.

[+] yosamino|1 year ago|reply
There's a chicken-egg-like problem involved with that based on the cryptokey routing that wireguard does.

The, a bit unfortunately named, 'allowed-ips' parameter determines to which peer wg routes a packet.

If you imagine three peers connected to your one central vpn server then for this to work you have to have an allowed-ips parameter set to the same /64 network for each of them from the point of view of the server, which creates a conflict.

There is a project to configure allowed-ips dynamically but it's not active any more unfortunately https://github.com/WireGuard/wg-dynamic/blob/master/docs/ide...

[+] 0x00_NULL|1 year ago|reply
I don’t know if the spec supports that on its own. Although, it’s a good feature request.

You’d have to update the WG configuration each time a new IPv6 address connected. So, you would probably need to connect through something like a client that could push a config update and restart the service.

Not impossible, but that’s another layer of complexity to maintain.

[+] icelancer|1 year ago|reply
No RBAC is sad, though understandable. Wireguard is so much faster than OpenVPN. We use Wireguard for S2S but unfortunately need OpenVPN for our employees and contractors due to RBAC.

All posts and writeups we've found trying to shoehorn RBAC into Wireguard ultimately ends up with people saying "don't do this."

[+] tptacek|1 year ago|reply
The point of the WireGuard design is to be agnostic to "upper-layer" concerns like this; it's a fast (optionally) kernel-resident secure transport that you can build whatever you'd like on top of. WireGuard isn't about RBAC and doesn't have a "don't do RBAC" position.
[+] srockets|1 year ago|reply
There’s a very good implementation of Wireguard with RBAC. It’s called Tailscale.
[+] gonzo|1 year ago|reply
Kernel wirguard may be (and often is) faster than OpenVPN without DCO, but OpenVPN with DCO is oftent substantially faster than kernel WireGuard.

DCO is available for Linux, FreeBSD and Windows.

[+] wirewarden|1 year ago|reply
Nice article, cool ideas.

I rely on IPv6 for my infrastructure: my home network and servers are all publically routable via IPv6.

I use something similar to OP's IPv6 setup to provide my smartphone with IPv6 connectivity too, so smartphone is able to reach my infra.

It's not clear what OP is getting by exposing public servers using Wireguard internally. Why not just assign servers IPv6 addresses at layer 3 and route as normal?

Given the vast majority of my infra has publically routable IPv6, it would be nice if I could keep/use that addressing layer, but benefit from Wireguard (it's modern crypto, and stateless design) without having to adopt the Wireguard addressing layer.

I guess I'm looking for something like Wireguard-without-addressing, or IPsec-transport-mode-but-stateless.

[+] zaptheimpaler|1 year ago|reply
Im trying to set up a personal server with services that may be accessible from the web with a real domain name or only via Tailscale. I got the web part working with Caddy and mapping subdomains to services, but the problem is Tailscale Magic DNS doesn't support subdomains. I could try to host services on paths like "blah.blah.ts.net/svc1" and strip the paths in Caddy but that causes all sorts of problems that you have to debug per service - like maybe links breaking, websockets breaking etc. So it seems subdomains are the only clean solution.

I don't know much about this stuff but it seems the best way to circumvent this limitation is to create a private DNS server that can resolve any subdomains I want to the tailscale IP, so i'm working on getting pihole setup to do that.. is this a limitation of Wireguard? How do people set up this kind of network?

[+] caconym_|1 year ago|reply
> is this a limitation of Wireguard?

Wireguard and Tailscale aren't the same thing, and "Tailscale Magic DNS" has absolutely nothing to do with Wireguard.

This is a great example of why "just use Tailscale" is bad advice. It has some great features, but if you don't need those features then you're needlessly locking yourself into a tightly integrated networking stack which is going to get in your way anytime you want to stray from the beaten path.

If your application really is personal, my advice is to ditch Tailscale and just use Wireguard. Any halfway decent router software, like OpenWRT or pfSense, will be able to run Wireguard as a virtual network interface and a local DNS server allowing you to set up static records, delegation, etc. however you want. You'll have to deal with certificates yourself, but that will be true anyway if you try to get some local DNS thing to play nicely with Tailscale.

[+] ggpsv|1 year ago|reply
That is what I ended up doing, I wrote a blog post about it some months ago [0].

The gist of it is using private dns and exposing services only on the private network. Implementation details can vary, you decide whether to use tailscale or bare wireguard, and any reverse proxy and dns server will do. In my case, I use Tailscale, NextDNS, and Caddy.

[0]: https://garrido.io/notes/tailscale-nextdns-custom-domains/

[+] inapis|1 year ago|reply
If you don't have a lot of services to access, you can hard code the tailscale IP address in /etc/hosts.

My personal /etc/hosts is at 10 services all hard coded since the internal IP address of a machine on tailscale is static. Way cheaper and easier to deal with than setting up a separate DNS resolver.

Of course that won't work if you have hundreds or thousands of services to work with.

[+] aborsy|1 year ago|reply
If you have a domain, you simply a dns record for the Tailscale IP.

You can also run your own dns server, like a pihole or AdGuard, on your Tailscale network. There you define any dns record.

[+] sevg|1 year ago|reply
I've always been slightly puzzled about why there isn't an easy built-in way to tunnel all traffic (ie, AllowedIPs = 0.0.0.0/0, ::/0) EXCEPT for some specific IPs. You end up having to programmatically generate a massive list of CIDRs that include everything except those specific IPs.
[+] adamcharnock|1 year ago|reply
I agree that would be useful. I'm fairly sure it is because all the entries in `AllowedIPs` are just written as-is to the routing table, and the routing logic in the kernel (and most/all routers?) has no facility for 'does not match'.

Instead the solution would be to add a explicit route to state where the excluded CIDR should be sent to. That would would be more specific and would therefore be used for matching packets rather than the 0.0.0.0/0 (or whatever) routed pointed at the wireguard tunnel.

[+] ghthor|1 year ago|reply
I wonder if you can add a peer to your config and set these excluded ips there, then never connect it.
[+] rudasn|1 year ago|reply
Can't you do that with a prerouting firewall rule?

Genuinely asking, never tried myself but seems plausible.

[+] graton|1 year ago|reply
I think you need to use `Table = off`. With that you probably can get what you want.
[+] bsder|1 year ago|reply
Or the reverse, most people have specific IPs that they'd like to route traffic through the VPN but mostly don't care about the rest.

Again, you wind up creating a huge list of exact IPs and creating the routing rules is a PITA.

[+] pm2222|1 year ago|reply
ip route to blackhole works. ip rule works. ip/nftables works. tc works. ebpf works.
[+] logicziller|1 year ago|reply
One that I could not get to work properly with Wireguard is port-forwarding without masquerading.

I need the source IP to remain intact, but unless I add 0.0.0.0/0 to the AllowedIPs, the Wireguard peer will drop the packet. If I do add 0.0.0.0/0 to AllowedIPs then it adds a route which prevents the response from my application to go back to the source.

Eventually gave up on it. Nobody had a clue how to fix this or what actually needs to be in the nft or firewalld rules for this to actually work properly.

[+] mbilker|1 year ago|reply
If you are using `wg-quick`, then you need `Table = off` to disable adding routes to the system route table automatically. After that, then you can add routes manually.
[+] tomjen3|1 year ago|reply
I had hoped that this included a way to configure wireguard to get clients from some other place: It would be really nifty if you could configure it to read from LDAP or similar.
[+] n4bz0r|1 year ago|reply
> Some applications (looking at you, BitTorrent client) do not play well behind a NAT.

I've seen a number of such warnings, but never personally encountered the issue. Is that because I've been always sitting behind a router? Or that's just an ISP thing that I got lucky with? Like, my IP isn't "grey" enough? (always had dynamic IP)

[+] o11c|1 year ago|reply
Is UPNP still a security nightmare in practice? If so, does this article's use of it avoid the usual problems?
[+] derkades|1 year ago|reply
It's a "security nightmare" because clients can make holes in your firewall. If you're fine with that, then it's okay.
[+] teleforce|1 year ago|reply
Is there any good books on Wireguard that cover the principles, implementation and configurations?

We have plenty of books on IPSEC but for Wireguard it's a rarity.

[+] rmrf100|1 year ago|reply
> The first thing to notice is that my hosting provider has assigned to me a whole /48 network for my account (2001:aaaa:bbbb::/48)

How to know this?

[+] dangoodmanUT|1 year ago|reply
Also check out slack's nebula, easier to understand and configure IMO, and it has ACLs natively
[+] flemhans|1 year ago|reply
Micromanaging keys and IP addresses is my biggest issue with WG.
[+] aborsy|1 year ago|reply
Is Wireguard the best piece of software made in the last decade?
[+] qeternity|1 year ago|reply
No affiliation with them but Tailscale is awesome.
[+] imsurajkadam|1 year ago|reply
why is this not basic for me? yes I am tech guy!