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.
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?
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.
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?"
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.
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.
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.
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.
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.
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.
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'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 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.
> 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.
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.
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.
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...
Their blog is an incredibly useful resource for so many different scenarios.
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.
[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.
Wha... since when does Tailscale have an AppleTV subnet node!??! Those guys are on fire and I missed this.
I use mine as my Tailscale exit node.
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 :)
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?
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.
Cool! I'll have to try once more. That sounds a lot more reasonable than going straight to postgres.
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.
Dynamic IP. Hard coding an address is exactly what we want to avoid.
Let's go one level deeper. Why do you need dynamic IP in your own private network?
There is a dynamic IP on the external address, from their ISP.
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.
Really?
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.
How do you connect your VPN with your phone when you travel on the road?
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?"
for example https://freedns.afraid.org/dynamic/ + cron job on router to periodically update dns record
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.
Staying with Wireguard. The article, by the way, is about Wireguard, not an opinion piece comparing alternative technologies.
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.
I don’t think you could write that thick of a book about wireguard.
For IPSEC you’re going to need a bookshelf.
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.
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.
I agree completely with the sentiment, though I never actually mess with the routing tables.
See https://github.com/tailscale/tailscale/issues/11717#issuecom...
I think you need to use `Table = off`. With that you probably can get what you want.
Calculator for the workaround: https://www.procustodibus.com/blog/2021/03/wireguard-allowed...
ip route to blackhole works. ip rule works. ip/nftables works. tc works. ebpf works.
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.
Ah right.
Yeah it would be nice to have a negated allowed ips list, or adding an ! to signify "not this one". Wonder how difficult that would be to implement.
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.
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.
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.
> The point of the WireGuard design is to be agnostic to "upper-layer" concerns like this;
And there will probably never be any standard (non-commercial) "upper-layer" because of this.
The project prides itself on being much simpler than IPSEC etc but that's easy when you leave out half of the functionality
There’s a very good implementation of Wireguard with RBAC. It’s called Tailscale.
I like Defguard for this https://defguard.net/
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.
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.
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.
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.
This is the answer. I too ran into the same issue. Took me awhile to figure this part out.
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.
Is UPNP still a security nightmare in practice? If so, does this article's use of it avoid the usual problems?
It's a "security nightmare" because clients can make holes in your firewall. If you're fine with that, then it's okay.
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.
> 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.
Also check out slack's nebula, easier to understand and configure IMO, and it has ACLs natively
No affiliation with them but Tailscale is awesome.
Their article on how NAT traversal works is an epic piece of work in its own right too:
https://tailscale.com/blog/how-nat-traversal-works
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.
I don't think the Tailscale software does this step. You can find several GitHub issues about this, such as https://github.com/tailscale/tailscale/issues/11438 or https://github.com/tailscale/tailscale/issues/11437
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).
With Wireguard I own or control everything. Why would I surrender any of that to Tailscale?
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
NordVPN meshnet is just like that.
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.