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.
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.
Wireguard running on my router (Unifi Dream Machine Pro) - but I have a static IPv4 address, as well as a routed /48 IPv6 block.
Anything that needs to be exposed to the internet (which was essentially TeslaMate during setup) through a cloudflare tunnel, which terminates on a server behind my router.
I’m using an internal machine for the VPN server and port forwarded to it from the router. I also have Tailscale set up but if I remember correctly Tailscale requires all devices participating in its VPN to install its software, which is too much.
> I also have Tailscale set up but if I remember correctly Tailscale requires all devices participating in its VPN to install its software, which is too much.
This isn't true. You can use Tailscale "Subnet Routers" to access devices within a network without the Tailscale software installed. You still need one device to act as SR, but that would be a requirement for leveraging any traditional VPN as well.
Unbound is perfect. The CLI is very handy as it allows you invalidate specific domains from the local cache. I have had a good experience with dnsmasq and dnscrypt2 as well.
A pretty common setup is to have a public VPS/dedicated server with wireguard/openvpn hosted at some trusted company and use that as an entry/exit point. It's basically what Tailscale is (massively simplified, obviously).
As far as I understand it, that's not how Tailscale works most of the time. The actual connection is established between the VPN nodes, and actual traffic doesn't travel through Tailscale's servers.
The VPS solution is usually the hub of a star-shaped network, so everything has to go through it, which may be limiting, given that, at least where I live, gigabit fiber is fairly widespread and reasonably priced. Most VPSs I see have less bandwidth than that.
I think what the original post was referring to was using their home (dynamic IP) network instead of a public VPS/dedicated server. That’s what I used to do — I’d use Cloudflare’s dynamic DNS to keep my home IP up to date and have a dedicated VM running at home that handles Wireguard connections.
Now, I have found it easier to manage devices using Tailscale. Also, Tailscale makes it very easy to manage some very dynamic routing (managing connections to external VPNs that mandate different non-wireguard clients).
Sadly, I’ve hit some issues with using tailscale’s DNS provider (my work configured Mac doesn’t like to have the DNS server changed), so I still have some work to do on that side.
> I think what the original post was referring to was using their home (dynamic IP) network instead of a public VPS/dedicated server.
Personally, I wouldn't let incoming traffic hit my home IP/router by itself, that's why I suggested having something in-between public internet and your local network.
But, any way that works obviously works, the rest is just details :)
I prefer Zerotier approach in relation between account and devices.
In Zerotier for each device added, no need to login to Zerotier account. Just add the network ID and approve it from the account.
In Tailscale I have to login from each device to add it to the network.
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.
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.
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.
There are a number of ways you could handle this, but none of them make wireguard seem user friendly for this use case.
If you're using WireGuard for point to point or to access a specific subnet, this isn't an issue.
But a common use case is to use WireGuard like you'd use Mullvad or Nordvpn and tunnel all traffic through it. And if you need exceptions for private address ranges or specific services, you end up having to generate a CIDR list (the WireGuard mobile app can do this for you if you check the "exclude private addresses" checkbox, but no such checkbox exists for wireguard tools on Linux, and it's a hardcoded list anyway), or add routes yourself, or fiddle with firewall rules.
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.
Tailscale (also using wireguard for transport) and similar overlay networks kind of do that.
With Tailscale there is a central server, you can sign in with single-sign-on, that server enables automatic mesh configuration and helps nodes communicate specifics for port knocking, routing, dns, etc. And there are derp servers (think of them like TURN servers) that can be used as proxies when direct communication can't be established.
Altogether this is easier to set up than Wireguard, but the central server is not open source (but there is Headscale, and open source implementation), and it is not as well supported on routers (it is supported on OpenWRT though and probably can be set up using containers on Mikrotik).
Yeah, that's the biggest pain point I think. Syncing configs once changes are made (new peers, new access rules, pre shared key rotation etc).
It's one of the reasons I'm working on wirehub[0], as a way to distribute configs to both end users (share a link) and machines (have a script to periodically pull from wirehub).
Not the perfect solution, but one that does not require additional clients/agents/software to be installed.
Probably because networking itself is arcane. If you're used to everything around it, wireguard itself is really simple. If you're not, all the rest of it is going to drag you down.
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.
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.
for example https://freedns.afraid.org/dynamic/ + cron job on router to periodically update dns record
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.
Wireguard running on my router (Unifi Dream Machine Pro) - but I have a static IPv4 address, as well as a routed /48 IPv6 block.
Anything that needs to be exposed to the internet (which was essentially TeslaMate during setup) through a cloudflare tunnel, which terminates on a server behind my router.
I’m using an internal machine for the VPN server and port forwarded to it from the router. I also have Tailscale set up but if I remember correctly Tailscale requires all devices participating in its VPN to install its software, which is too much.
> I also have Tailscale set up but if I remember correctly Tailscale requires all devices participating in its VPN to install its software, which is too much.
This isn't true. You can use Tailscale "Subnet Routers" to access devices within a network without the Tailscale software installed. You still need one device to act as SR, but that would be a requirement for leveraging any traditional VPN as well.
[0] https://tailscale.com/kb/1019/subnets
Is that true? I’m not 100% sure, but I think I’ve printed while I was away from home and I only have Tailscale software installed on my AppleTV.
Unbound is perfect. The CLI is very handy as it allows you invalidate specific domains from the local cache. I have had a good experience with dnsmasq and dnscrypt2 as well.
A pretty common setup is to have a public VPS/dedicated server with wireguard/openvpn hosted at some trusted company and use that as an entry/exit point. It's basically what Tailscale is (massively simplified, obviously).
As far as I understand it, that's not how Tailscale works most of the time. The actual connection is established between the VPN nodes, and actual traffic doesn't travel through Tailscale's servers.
The VPS solution is usually the hub of a star-shaped network, so everything has to go through it, which may be limiting, given that, at least where I live, gigabit fiber is fairly widespread and reasonably priced. Most VPSs I see have less bandwidth than that.
There's headscale which allows setting up tailscale with a private server: https://github.com/juanfont/headscale/
I think what the original post was referring to was using their home (dynamic IP) network instead of a public VPS/dedicated server. That’s what I used to do — I’d use Cloudflare’s dynamic DNS to keep my home IP up to date and have a dedicated VM running at home that handles Wireguard connections.
Now, I have found it easier to manage devices using Tailscale. Also, Tailscale makes it very easy to manage some very dynamic routing (managing connections to external VPNs that mandate different non-wireguard clients).
Sadly, I’ve hit some issues with using tailscale’s DNS provider (my work configured Mac doesn’t like to have the DNS server changed), so I still have some work to do on that side.
> I think what the original post was referring to was using their home (dynamic IP) network instead of a public VPS/dedicated server.
Personally, I wouldn't let incoming traffic hit my home IP/router by itself, that's why I suggested having something in-between public internet and your local network.
But, any way that works obviously works, the rest is just details :)
Just give in and use tailscale, life is so much better on the dark side!
I prefer Zerotier approach in relation between account and devices. In Zerotier for each device added, no need to login to Zerotier account. Just add the network ID and approve it from the account. In Tailscale I have to login from each device to add it to the network.
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...
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.
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.
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.
Can't you do that with a prerouting firewall rule?
Genuinely asking, never tried myself but seems plausible.
There are a number of ways you could handle this, but none of them make wireguard seem user friendly for this use case.
If you're using WireGuard for point to point or to access a specific subnet, this isn't an issue.
But a common use case is to use WireGuard like you'd use Mullvad or Nordvpn and tunnel all traffic through it. And if you need exceptions for private address ranges or specific services, you end up having to generate a CIDR list (the WireGuard mobile app can do this for you if you check the "exclude private addresses" checkbox, but no such checkbox exists for wireguard tools on Linux, and it's a hardcoded list anyway), or add routes yourself, or fiddle with firewall rules.
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.
Tailscale (also using wireguard for transport) and similar overlay networks kind of do that.
With Tailscale there is a central server, you can sign in with single-sign-on, that server enables automatic mesh configuration and helps nodes communicate specifics for port knocking, routing, dns, etc. And there are derp servers (think of them like TURN servers) that can be used as proxies when direct communication can't be established.
Altogether this is easier to set up than Wireguard, but the central server is not open source (but there is Headscale, and open source implementation), and it is not as well supported on routers (it is supported on OpenWRT though and probably can be set up using containers on Mikrotik).
NordVPN meshnet is just like that.
Yeah, that's the biggest pain point I think. Syncing configs once changes are made (new peers, new access rules, pre shared key rotation etc).
It's one of the reasons I'm working on wirehub[0], as a way to distribute configs to both end users (share a link) and machines (have a script to periodically pull from wirehub).
Not the perfect solution, but one that does not require additional clients/agents/software to be installed.
[0] https://wirehub.org
why is this not basic for me? yes I am tech guy!
Probably because networking itself is arcane. If you're used to everything around it, wireguard itself is really simple. If you're not, all the rest of it is going to drag you down.
No affiliation with them but Tailscale is awesome.