+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.
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.
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.
I'm intrigued. Could you please elaborate on your setup, what Apple TV provides in this mix and how it is used? Is the Apple TV always powered on (24x7)?
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 :)
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've been very pleased with powerdns for my self hosted internal DNS services. It implements basically everything you want for even the most esoteric DNS setups, and IMO, quite sanely.
I've tried many times to setup PowerDNS and never complete it because I get bogged down in the complexity. I saw they had an ansible / terraform script for deployments. Do you just use the team's docs or something else?
You can also just setup a pihole adblocker on a vm. It has a local dns feature as well (that is nothing more that a textfile containing all your local records). Super easy to setup and maintain :)
Yeah just the PDNS docs. They're excellent. I'll admit my personal setup isn't particularly complex, but I'm not sure how much more complex it can get. I've just got an authoritative server for `lan.` and two secondaries, all 3 using sqlite as their database.
I just added their debian repo and apt install'd the two packages (dnsdist and pdns-server). Set the respective config files appropriately (dnsdist is a little hard, but googling got me there) and bam. I've got dnsdist serving DoH, DoT, and plain port53 DNS with some ACLs, was really easy IMO.
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.
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.
Yeah but you don't use the external IP for the purpose of accessing your VPN (not via a DNS record anyway). I am also unclear on the purpose of the dynamic DNS.
Your external IP is dynamic because the ISP can rotate it. You want to reach your home's external IP to VPN in. One common way is to create a public DNS record that's dynamically updated (by a cronjob or whatever) to always contain whatever IP your ISP last handed you.
That's what I do. Just a cronjob on my TrueNAS server to query my IP and update my subdomain's A record if my IP has changed. That way when a power outage happens and my IP gets rotated, it makes no difference.
Imagine, if you will, the following scenario: I have a wireguard endpoint on my home router. The home router uses a residential ISP connection and I don't want to pay $10/mo for a static IP because my ISP is cheeky and expensive. I want to have my phone connect to said wireguard endpoint to establish a secure link. I don't want to have to change my wireguard configuration on my phone every time my home IP changes.
So, I set my phone to peer with the wireguard endpoint on `home.denk.moon:1234`. Every time my home router's external IP changes, it sends a dynamic DNS update to my DNS server such that `home.denk.moon` reflects the new IP for my router. Now, whenever my phone attempts to connect to wireguard, it will resolve that domain name, get the latest IP for my router, and connect.
To find your private network when you're away and plugged into a public one and the former's IP may have changed. I gather the OP is talking about discovering their public-facing address, not doling out IP's on their internal VPN.
Don't ask next "Why do you need to know your home IP address?"
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.
That's a good thing. The higher up the stack you go, the less value there is in standardizing, and more painful the costs (of being constrained in implementation).
Also: it is much simpler than IPSEC. Pretty much everybody can get WireGuard working in minutes. It's approximately as easy as setting up SSH. That's simply not true of IPSEC.
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.
To me this is actually one of the attractive aspects of Wireguard compared to some other VPNs, it doesn't try to manage everything within the tool and delegates to the host's normal routing mechanisms. However it still by default conflates AllowedIPs and the routing table -- you can actually separate them (Table=off with wg-quick) and then manually add routes.
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 don't understand. Having a specific list of IPs they want to route over Wireguard is the one that is easy today. It's the inverse (everything except these IPs) that's hard.
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.
When a public Internet client connects to my VPS, WG routes the port traffic like 443 to the WG client here at home, then through Apache reverse proxy then to a node in my kube cluster running a spring boot app which is my main site. The logs shows the IP of the incoming public Internet client.
The response is routed all the way back out to the Internet client.
Is what I'm describing not achieving what you're discussing?
Happy to post a sanitized version of my server and client config.
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).
Would be great if someone made something with the polish of Tailscale and made it completely free and open source, but I don't think it is happening any time soon. Wireguard itself has been an unbelievably great gift to the whole IT ecosystem and Jason will forever be cemented in my hall of fame.
But he did intend for Wireguard to be used in all sorts of solutions and Tailscale is one of them.
Tailscale apps themselves are open source for open source platforms (linux, android) and the 3rd party management server Headscale is open source, enabling you to maintain control.
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.
I've built a proof-of-concept WireGuard VPN for work (SSO with mTLD portal/OIDC, BGP/WG tunnels to link edge servers into the network) and the team love it - better than the Cisco VPN they'd have to use otherwise.
Only problem is the config - I'd love a simple alternate WG app (for macOS/Windows) that could pull a config from a remote endpoint (checking signing) and bring up a WG tunnel with the config presented.
I've written a Golang client which shows up in the macOS menu bar and handles all this, but it's using the Brew WireGuard command line tools and needs sudo, etc., etc., so it's not really suitable for the average user.
There are quite a few open source wg clients out there, maybe you can get some ideas from those. Defguard, netbird come to mind.
I just want to avoid all that custom client stuff.
I don't have a solution, but I was experimenting on having a unique network url that would show different content depending if you're hitting it via the wireguard connection or not. Pretty basic stuff, just firewall rules and nginx proxying. Add the (hub) endpoint to client's AllowedIPs and route traffic on the hub depending on the networ interface and port the traffic is coming from.
So the client would connect to the wg network and open up the network page (eg. home.rudasn.wirehub.org).
If the connection is established, they would see a welcome message or whatever (if they need to update their config maybe a link to get their new one).
If the connection is not via the wg tunnel, they would see a message to first connect to the wireguard vpn. And if it's their first time, directions on how to install the official client and get their config from their admin (via wirehub.org or whatnot).
It's nice to have that automated via a custom client, but I don't think it's such a huge issue - if you would only update configs for client devices sporadically and have the server peers polling for updates every x seconds.
The downside of custom client apps is another security layer to consider, which nobody has the time for.
> 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)
The reason that peer-to-peer tools tend not to work well behind NAT is because peers can't initiate inbound connections to you.
So your router gets 1.2.3.4 as an external IP. And it assigns you 192.168.1.10 as an internal IP, and handles NAT for your outbound connections. You start your torrent client and it advertises "hey, I have all these Linux ISOs, and I'm at 1.2.3.4:50000, come connect to me". Peers try to connect to 1.2.3.4:50000, and your router says "who the hell is this".
This is what UPNP and related tools attempt to solve. UPNP works by allowing your computer to say to your router "hey, I'm going to want inbound connections on port 50000, so if you get any, send them to me".
Other methods like STUN/TURN/etc use different techniques to get around the issue.
This makes perfect sense on paper, but I disabled UPNP in router settings at some point just to see what happens and the torrents still work to this day. No issues with no apps whatsoever. That got me confused and I assumed that NAT masquerading is responsible for such "port forwarding" (having the address translation table and all that).
I'm currently using Mikrotik router with the latest RouterOS and Transmission/qBitTorrent for the clients if that helps. Any idea why is this the case?
And if (just in case) Mikrotik's implementation of NAT does in fact do "UPNP", why add separate UPNP settings? By the looks of things, I would assume that, when disabled, UPNP still works, but with some default rule set, and when enabled, you get to fine tune the interfaces. But that's just a wild guess. No mentions of such behaviour in the official wiki.
Sorry, Mikrotik does some arcane things so learning network concepts on RouterOS often leaves one with more answers than questions :')
I do not think the Tailscale software implements everything described in that article. For example, the article says
> Now speak STUN through the NAT64 to discover your public ip:port on the NAT64, and you’re back to the classic NAT traversal problem — albeit with a bit more work.
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.
reply