Choose your own IP (opens in new tab)

That episode aired in 2001. I wonder if the NAT quote is inspired by that?

I can't upvote this enough. It is my experience that IPv6 advocates deflect hard when this gets brought up.

The vibe I get is people stuck with IPv4-only IPSs are insignificant and unimportant. They simply do not matter.

Nice! Learning ipv6 is on my bucket list, any resources that you like to recommend?

There are many more IPv6-centric solutions to their problem. Sounds like they didn't even try to think of alternatives and instead reached straight for NAT. That wasn't necessary, at least from the amount of information we can glean from this one post.

I see this as a feature not a bug. Use dynamic DNS if you need a stable endpoint here.

> The idea that a home user ca setup a desktop and share anything I want via IPV6 another person without the need for a middle man “cloud” provider just didn’t happen.

You can, you likely just need to change the default firewall settings on a typical ISP provided router.

> Corporate greed / government control have severely limited any usefulness of IPv6 at least here in the US

I don't see how either of those have to do with this.

https://github.com/juanfont/headscale/commits/main/

For me the headache of running my and maintaining my own server isn’t worth it (+ would still require a GCP/AWS account)

But yes, someday, maybe we’ll laugh at the current state of things and the shortage of IPs.

The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.

> Wireguard walk-through to bridge two separate LANs

Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).

If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).

And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.

Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).

You could use Headscale, which is an open-source/self-hosted reimplementation of Tailscale control plane, so you can eat your cake and have it too.

Curious to know, why does distrust towards Tailscale come up so often around here? They seem extremely transparent about their strategy and incentives.

You don't have to use their service to implement what they describe, in most cases.

There are tools to automate this like wg-quick and systemd-networkd, depending on your preference.

I've never configured Wireguard from scratch but I have managed an OpenVPN deployment in the past. One of the most fabulous aspects of Tailscale is that it's very self-served; we configured our Tailscale account to allow email addresses from our main domain name with O365 integration. When someone wants to bring a new node online, they log in with their O365 credentials and magically new keys are assigned to the node and associated with the user who created them. In the past with the OpenVPN deployment, it would usually take me 15-30 minutes to get a new node online (generating keys, getting them handed off to the user, helping them debug, etc); now it takes me 0 minutes because the user can just generate their own keys and I can be completely hands off, while still having a nice view that I can use to revoke keys if needed.

If you're a home user, the advantage to Tailscale is that it's going to "just work", with a couple clicks, on any supported device (of which there are lots). There's no configuration to get started and, for a lot of users, no configuration ever after that. The onboarding experience is spooky; it's upsettingly good.

If you're a corporate user, the advantages are drastically greater: you get SSO integration (this is historically one of the annoying pain points of corporate access VPNs, to the point where a significant fraction of pre-Tailscale netsec teams just punted on this problem and hand-provisioned VPN creds for people, which is a nightmare) and trivially simple group-based access control.

I personally haven't deployed it though I've toyed with it, but I think as well as UI and integrations a core topology differentiator is that, like Nebula, Tailscale does/can do meshing. Plain vanilla Wireguard is pure classic hub-and-spoke, which is 100% fine for a basic VPN use case like "I'm out somewhere on the WAN and want to talk to this LAN stuff" or "I want to tunnel some/all my traffic through some specific alternate exit".

But say you've got main site A which has a public static IP and is where support is for administrating others, site B which has a full backup server but no public IP, and then sites C/D/E/etc where people are doing work and having significant on-site storage and comms needs, all of which are behind typical ISP NAT from multiple different ISPs with no static IPs. Everyone wants to be able to do high bandwidth things like video chat directly together, or back up/restore to site B. Plain WG could do that, but would funnel it all through site A's link which isn't very scalable and likely to become a choke point in a hurry. A meshing VPN can let two private sites talk directly with a public address only serving to facilitate hole punching and setting up the connection each time. It's definitely of real value. Another thing would be not bandwidth but latency. If you're within a few hundred miles on land that probably is irrelevant. But if different sites/people are across continents adding an unnecessary extra hop may become a very big deal even for simple web apps. Resiliency also enters the equation, what if site A goes down? A mesh can help with those too.

Then Tailscale adds a lot of cool QoL on top. Meshing does raise new challenges in terms of access control vs when everything is funneled through a single convenient point. But regardless, other topologies can be of basic interest too even without extra sugar.

The VPN clients for Mac and iOS are on the App Store, which may not mean much, but having developed VPN apps for both, what it means is: it is far less likely break or muck with your OS's networking in practice because it's sandboxed and can only use Apple's SDK for interfacing with the OS. This is compared to every OpenVPN client I've used on various platforms, which must run as root and often is setting up and tearing things down with shell scripts that can get hairy as you add more complexity / moving parts.

(Note that this is also true for Wireguard's client, just not OpenVPN)

The first three users are always free, so we're able to demo it easily. It's also listed on AWS marketplace, so as we move to start buying some licenses, it's billed through our AWS bill (i.e. I don't need an act of Congress to get a credit card number entered and a new monthly invoice reconciled within my company).

You can configure how often it forces reauthentication, which is probably the biggest benefit over vanilla Wireguard. Wireguard doesn't have mechanisms for expiring and replacing keys, so it solves that.

There's also an open source implementation of the master service (called headscale) that you can run on your own, and I was able to fairly easily set it up and get the existing Tailscale apps from the App Store to be reconfigured to utilize.

Honestly it's the cleanest VPN experience I've had if you need to deal with any kind of SSO and/or dynamic user/client provisioning. If you're just setting up point-to-point between a few of your own servers and clients that won't change, maybe just stick to Wireguard. But once you start needing anything more than that--I'd give Tailscale a shot first.

SSO for Auth: before we had to go through the key exchange process for every employee and then manually update the Gateways wg conf. Now it’s just: login here with your work account and you’re done.

Authorization config: I like the ACL abstractions on top of Wireguard. It’s a part is completely missing and building it yourself would be a nightmare. I also don’t want to manage iptables for every device.

All of the nice little feature that they provide:

Funnel Kubernetes operator Magic DNS

Less battery life on your iPhone. :)

I have both in my home network and love both.

At work, I have used Tailscale in my Kubernetes clusters to allow devs to get into the private subnets, so that is awesome, and way better than trying to give a group wireguard key pairs.

A technical person who’s familiar with what a VPN is and does but has never configured one can have it working on a bunch of their devices in like 30 minutes flat, with no notable ongoing maintenance to worry about.

If you’re already configuring your home networking with Ansible or Helm or something, it’s probably not a win.

Here is what I will say. I manually setup wireguard for my home network, it was annoying but doable. Then when tailscale started to get interesting I just decided try it out using a free account and rolled back my wireguard configuration... and never went back. It's so much less fiddly.