I haven't heard of this behavior before. Could you elaborate or link to some evidence of it?

I think it is the opposite google allows some apps from opting out of VPN.

care to elaborate?

IPSec suffers from the "it can do everything" syndrome.

Storytime: 15 years ago I co-founded a startup to build easy-to-use infrastructure management for AWS. At that time, it did not have cross-region VPC peering or routing, so you couldn't easily and safely have apps that communicate between regions.

So I started working on creating an overlay network. My idea was to use IPsec, it even has an RFC that documents its kernel interface. So that when a host wants to send a packet to the secure network, the kernel goes to my userspace daemon, that in turn goes to the central server that provides it the key for the given host pair.

And it turned out that the interface lacked a crucial part - on-demand key negotiation for incoming packets. It had this for _outgoing_ packets, but not incoming. The only sane way to make it work was to create a proactively updated database of all the hosts.

Well, I did that. It also did not work (tm). I found so many issues with broken MTU handling, broken NAT traversal, etc.

I eventually gave up on that idea and started working on a simple TUN/TAP-based overlay. I almost made everything work, but our startup got acquired by AWS, and this line of work was abandoned.

I don't think this really follows. Negotiation would be problematic, but you can just version the protocols and do WireGuard v1 and WireGuard v2, with v2 in a PQ configuration. As long as the configuration about which to use is static, you're not running up against the IPSEC problem.

I don't think there's anything necessarily complicated about MLKEM that would make this too difficult.

Switching to IPSEC loses you other WireGuard benefits; the wins don't end at "just one carefully curated set of cryptography primitives", but extend into things like DoS prevention and a design that admits to processing incoming frames without dynamic allocation.

(Tailscale cofounder) I’m a little more optimistic; wireguard was always going to need a v2 eventually, that’s just the nature of cryptography. It’ll always be simpler than IPsec as long as it avoids live negotiation (you need to specify your suite up front for each node you talk to; v1 and v2 are the only suites) and continues to go over UDP instead of IPsec’s “it’s a different transport protocol!” madness.

Things like Google’s PSP already achieve that while still being hardware acceleratable: https://github.com/google/psp

Post-quantum negotiation will kinda suck but you don’t have to sacrifice everything.

But then consider ipsec being backdoored by the NSA. As it came out of the Snowden leaks.

Apple TV has an OS level issue where it will kill apps that do too much background activity at random, the Tailscale guys can’t really change that.

> Has hardware-offload (for AES et al) got faster still, or that keeping CPU busy in the data path for 100gbps workloads is not ideal, or something else?

What is referred to by the term "hardware-offload"? For NICs:

> ConnectX NICs offload and accelerate encryption/decryption at speeds up to 400Gb/s.

* https://www.nvidia.com/en-us/networking/ethernet-adapters/

There have been MACsec implementations at 800Gb/s for several years:

* https://www.rambus.com/blogs/rambus-launches-800g-macsec-mul...

* https://semiengineering.com/the-evolution-of-ethernet-to-800...

And 1.6T/3.2T as well:

* https://www.rambus.com/security/protocol-engines/macsec-ip-3...

> The WireGuard website claims ChaPoly is at least as fast as hardware-accelerated AES.

I haven’t used WireGuard but I have easily doubled OpenSSH performance by switching back to AES.

Why do public keys need to be distributed out of band?

By that logic, we should avoid TCP as the Linux kernel implementation has had plenty of CVEs. Thankfully our expert critical thinking helps us acknowledge that as silly.

(Tailscale cofounder) That’s a good callout on DoH support, thanks.

That said, note that if you run your own DNS server on your tailnet, the regular UDP DNS is automatically private because it’s carried over Tailscale. That’s the most common setup for non-SaaS DNS servers. DoH doesn’t really add anything in that arrangement. (And it’s more fiddly because you need to get and refresh a TLS cert.)

Tailscale's netstack is barely even WireGuard and they aren't compatible whatsoever. It's all marketing at this point.

So it's not that simple: it's impossible for Tailscale to use any existing kernel or accelerated WireGuard implementation. They could derive inspiration, but a kernel module for Linux won't fix Windows & Mac. With that said, I feel they have enough funding to maintain a few platforms (:

Kernel networking is not automatically faster then userspace.

> Just fucking stop doing userspace wireguard on linux - issue has been open for 6 years

If they would have taken that advice, tailscale instances would have been pwned by copy.fail

I followed a similar trajectory for similar reasons. I was playing with wireguard around 2020 when I learned of Tailscale and since then haven't looked back.

Just the other day I was able to set my sister up with access to my Plex server and the ability to piggyback on my UK internet connection to stream BBC/Channel 4 content from Australia. It took all of 5 minutes to get it working.

I have an openwrt router running wireguard. I use it to provision the peer keys and routes. I also use openwrts cloudflare ddns which is super simple to setup. Any new client I want to add I jump into the wireguard interface in the GUI, go to the peer tab, and it does everything for me there.

There are no certificates to share with Wireguard. Nothing to rotate if you don't want to. Once it works, it works.

I've even got a backup wireguard server running on a Pi 1b. Works fine. We currently run wireguard on our router (and it seems more and more routers are supporting it).

There are keys to configure for each client, but once you have the configuration for one client, the rest come very quickly and easily.

I should add that I don't have any experience with Tailscale, but compared to OpenVPN and other VPN solutions, Wireguard is lightweight, simple, and easy to setup/configure.

We use it on all our mobile devices (phones, laptops, tablets) to tunnel our traffic through our home network with all the filtering it offers (along side access to private services we host).

I used https://wgportal.org/latest/

Once you install it you can then do everything from a UI to onboard new users.

It supports OIDC so you can avoid mangling with password and delegate that to an iDP such as google, github etc.

Get a Unifi system. It's built in. Works great!

I use an Island Router with Wireguard server built in, it handles DDNS and even the base Island router is beefy enough to give me up to 954mbps or so of Wireguard to right inside my home network. It took 2 minutes to set up.

That being said, I do understand the appeal of Tailscale and have used it.

Yes, except peer relays require the peer not to be behind NAT instead of being behind traversable NAT.

What I'm thinking of is something far more opportunistic; the way to piggyback on an existing peer (or a set of such) as a pseudo-relay, if and only if network conditions allow, and this is actually something that is worth doing in the given situation.