WireGuard: Beyond the most basic configuration(sloonz.github.io)
sloonz.github.io
WireGuard: Beyond the most basic configuration
https://sloonz.github.io/posts/wireguard-beyond-basic-configuration/
114 comments
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...
+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!)
Thank you! This looks useful. Bookmarked.
Their blog is an incredibly useful resource for so many different scenarios.
Wow, thanks.
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.
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
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.
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)?
There isn't much to say. The AppleTV is like any other computer. I installed Tailscale, set it as an exit node and turned on subnet routing.
The AppleTV is always powered on, but it only uses 0.3 watts while idle.
The AppleTV is always powered on, but it only uses 0.3 watts while idle.
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/
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/
Tailscale will fallback to tuns servers which are dumb "cloud" relays if direct connection can't be established.
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.
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 :)
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.
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 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.
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.
@smw just says that tailscale is more convenient than dynamic DNS.
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.
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?"
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.
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 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 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.
interface wg-server
{
AdvDefaultLifetime 0;
AdvSendAdvert on;
prefix fdf4:a694:0e43:c0de::/64 {
AdvOnLink on;
AdvAutonomous on;
};
};
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.
Does this work for you with more than one client connected ? How did you configure the routing table ?
There's a chicken-egg-like problem involved with that based on the cryptokey routing that wireguard does.
The, a bit unfortunately named, 'allowed-ips' parameter determines to which peer wg routes a packet.
If you imagine three peers connected to your one central vpn server then for this to work you have to have an allowed-ips parameter set to the same /64 network for each of them from the point of view of the server, which creates a conflict.
There is a project to configure allowed-ips dynamically but it's not active any more unfortunately https://github.com/WireGuard/wg-dynamic/blob/master/docs/ide...
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...
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.
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."
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
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
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.
Anyways, I think the jury is in on this one.
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.
Anyways, I think the jury is in on this one.
> Pretty much everybody can get WireGuard working in minutes.
You can get anything working in minutes, even IPSEC if you are using static keys with no authentication or authorization involved
You can get anything working in minutes, even IPSEC if you are using static keys with no authentication or authorization involved
If you've done it a bunch before. People coming to WireGuard cold can get it set up in minutes. That's why it won: because it's much, much simpler.
I like Defguard for this https://defguard.net/
Not played with this yet, but https://github.com/firezone/firezone is another example.
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.
DCO is available for Linux, FreeBSD and Windows.
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.
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?
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?
> is this a limitation of Wireguard?
Wireguard and Tailscale aren't the same thing, and "Tailscale Magic DNS" has absolutely nothing to do with Wireguard.
This is a great example of why "just use Tailscale" is bad advice. It has some great features, but if you don't need those features then you're needlessly locking yourself into a tightly integrated networking stack which is going to get in your way anytime you want to stray from the beaten path.
If your application really is personal, my advice is to ditch Tailscale and just use Wireguard. Any halfway decent router software, like OpenWRT or pfSense, will be able to run Wireguard as a virtual network interface and a local DNS server allowing you to set up static records, delegation, etc. however you want. You'll have to deal with certificates yourself, but that will be true anyway if you try to get some local DNS thing to play nicely with Tailscale.
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.
[0]: https://garrido.io/notes/tailscale-nextdns-custom-domains/
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/
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.
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.
If you have a domain, you simply a dns record for the Tailscale IP.
You can also run your own dns server, like a pihole or AdGuard, on your Tailscale network. There you define any dns record.
You can also run your own dns server, like a pihole or AdGuard, on your Tailscale network. There you define any dns record.
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.
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.
Calculator for the workaround:
https://www.procustodibus.com/blog/2021/03/wireguard-allowed...
I wonder if you can add a peer to your config and set these excluded ips there, then never connect it.
Can't you do that with a prerouting firewall rule?
Genuinely asking, never tried myself but seems plausible.
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.
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.
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.
[deleted]
I think you need to use `Table = off`. With that you probably can get what you want.
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.
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.
ip route to blackhole works.
ip rule works.
ip/nftables works.
tc works.
ebpf works.
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.
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.
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.
Please post your configuration... Thank you!
[deleted]
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 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?
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.
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.
[0] https://wirehub.org
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
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.
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.
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.
NordVPN meshnet is just like that.
> 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)
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.
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'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 :')
Because this misunderstanding and limitation is so common, BitTorrent has workarounds in place.
See https://superuser.com/a/1548724
See https://superuser.com/a/1548724
> The first thing to notice is that my hosting provider has assigned to me a whole /48 network for my account (2001:aaaa:bbbb::/48)
How to know this?
How to know this?
Enable IPv6 on your router. It should show you what prefix your ISP assigned you such as /56 or /48 assuming your ISP can do ipv6.
Also check out slack's nebula, easier to understand and configure IMO, and it has ACLs natively
Micromanaging keys and IP addresses is my biggest issue with WG.
Is Wireguard the best piece of software made in the last decade?
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
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
> 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
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.
[deleted]