+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!)
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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."
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
> 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)
[+] [-] entangledqubit|1 year ago|reply
[+] [-] franga2000|1 year ago|reply
[+] [-] Piisamirotta|1 year ago|reply
[+] [-] filterfish|1 year ago|reply
[+] [-] thefz|1 year ago|reply
[+] [-] ww520|1 year ago|reply
[+] [-] leetrout|1 year ago|reply
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.
[+] [-] paravz|1 year ago|reply
[+] [-] smw|1 year ago|reply
[+] [-] kccqzy|1 year ago|reply
[+] [-] opk|1 year ago|reply
[+] [-] OptionOfT|1 year ago|reply
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 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 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
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
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
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
[+] [-] srockets|1 year ago|reply
[+] [-] ahalimah|1 year ago|reply
[+] [-] gonzo|1 year ago|reply
DCO is available for Linux, FreeBSD and Windows.
[+] [-] wirewarden|1 year ago|reply
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
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
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
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
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
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
[+] [-] adamcharnock|1 year ago|reply
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.
[+] [-] tjoff|1 year ago|reply
[+] [-] mrbluecoat|1 year ago|reply
[+] [-] ghthor|1 year ago|reply
[+] [-] rudasn|1 year ago|reply
Genuinely asking, never tried myself but seems plausible.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] graton|1 year ago|reply
[+] [-] bsder|1 year ago|reply
Again, you wind up creating a huge list of exact IPs and creating the routing rules is a PITA.
[+] [-] pm2222|1 year ago|reply
[+] [-] logicziller|1 year ago|reply
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
[+] [-] tomjen3|1 year ago|reply
[+] [-] n4bz0r|1 year ago|reply
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
[+] [-] derkades|1 year ago|reply
[+] [-] teleforce|1 year ago|reply
We have plenty of books on IPSEC but for Wireguard it's a rarity.
[+] [-] rmrf100|1 year ago|reply
How to know this?
[+] [-] dangoodmanUT|1 year ago|reply
[+] [-] flemhans|1 year ago|reply
[+] [-] aborsy|1 year ago|reply
[+] [-] qeternity|1 year ago|reply
[+] [-] imsurajkadam|1 year ago|reply