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.
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.
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 :)
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/
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.
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 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.
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.
Don't ask next "Why do you need to know your home IP address?"
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.
Genuinely asking, never tried myself but seems plausible.
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.
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.
Again, you wind up creating a huge list of exact IPs and creating the routing rules is a PITA.
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).
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.
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.
> 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 like the randomisation that normally happens to make it invisible which phone/device in the subnet made each 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.
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.
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...
All posts and writeups we've found trying to shoehorn RBAC into Wireguard ultimately ends up with people saying "don't do this."
DCO is available for Linux, FreeBSD and Windows.
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
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.
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'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)
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 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.
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.
We have plenty of books on IPSEC but for Wireguard it's a rarity.
For IPSEC you’re going to need a bookshelf.
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?
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.
You can also run your own dns server, like a pihole or AdGuard, on your Tailscale network. There you define any dns record.
How to know this?