If you're sold on Tailscale due to them "being open" (as they semi-officially support the development of Headscale), keep in mind, that at the same time some of their clients are closed source and proprietary, and thus totally controlled by them and the official distribution channels, like Apple. Some of the arguments given for this stance are just ridiculous:

> If users are comfortable running non-open operating systems or employers are comfortable with their employees running non-open operating systems, they should likewise be comfortable with Tailscale not being open on those platforms.

https://github.com/tailscale/tailscale/issues/13717

A solution like this can't really be relied in situations of limited connectivity and availability, even if technically it beats most of the competition. Don't ever forget it's just a business. Support free alternatives if you can, even if they underperform by some measures.

I just set this up the other day, and I got my ping to drop from 16 to 10ms, and my bandwidth tripled, when connecting from a remote natted site to a matter desktop my house. Together with Moonlight/Sunshine I can now play Windows games on my Linux desktop from my MacBook, with 50mbps/10ms streaming. So far so good!

Not a single port forwarded, I just set my router up as peer node.

How does Tailscale make money? I really like their service but I'm worried about a rug pull in the future. Has anyone tried alternative FOSS solutions?

Also, sometimes it seems like I get rate limited on Tailscale. Has anyone had that experience? This usually happens with multiple SSH connections at the same time.

I haven't really dived into Tailscale et al because I'm still using Tinc; and the bulk of this discussion continues to make me not want to.

What's the big deal here? Any good reason to switch (besides Tinc's obscurity?)

UDP support in peer relays is crucial. DERP relies solely on TCP, which causes latency-sensitive applications like game streaming and voice to experience head-of-line blocking along with poor routing. With peer relays using UDP on your own nodes, the fallback path becomes effective for real-time traffic when direct WireGuard fails. Additionally, you can easily enable this feature on an existing subnet router without the need to set up and manage a separate DERP instance, making it much simpler to operate.

The shift from managed DERP to decentralized Peer Relays is a massive win for self-hosters with difficult NAT situations. I’m curious if this significantly reduces Tailscale's own egress costs or if the primary goal was just improving latency for users who can't establish a direct WireGuard tunnel. Either way, removing the 'hassle' of setting up a custom DERP server is a great UX improvement.

I'm having a hard time understanding how this is different from a bastion server, where you're tunneling through an intermediary server that you've deployed in the target network.

I guess the difference is the fact that the intermediary server doesn't need a port open (as standard nat punching will work)? Or are there other big differences?

Oh that's really cool! I hope it alleviates some pressure on the DERP servers, whenever I notice the connection on tailscale is bad, it's usually because the device is connecting over DERP.

I wonder if someone might indulge me by answering a question or two about Tailscale. I have a self-managed wireguard network which works, but probably isn't very smart or elegant.

From what I can gather, Tailscale does a lot of "magic" things to accomplish its goals, and some of them actually have "magic" right in the name. As a system administrator by trade, I have been bitten SO MANY TIMES by things that try to automagically mess with DNS resolution, routing tables, firewall rules, etc in the name of user-friendliness. (Often, things that even ship with the OS itself.)

Are there any documentation or articles detailing exactly what it's doing under the hood? I found https://tailscale.com/docs/concepts but it doesn't really cover everything.

If I have a virtualization host with, let's call it a "very custom" networking configuration, how likely is it to interfere with things? Is it polite and smart about working around fancy networking setups, or does it really only handle the common cases (one networking interface, a default route, public nameserver) elegantly?

Real-world CGNAT use case that might be relevant here: I'm running an industrial AI monitoring system (computer vision on live RTSP camera feeds) deployed on Google Cloud Run. The cameras are behind an ISP that blocks port forwarding entirely — a common apartment/SMB situation. Tailscale solved this completely. The Cloud Run container joins the tailnet, the camera's RTSP server gets a 100.x.x.x address via MediaMTX, and the container reads the stream over the private mesh as if everything were on the same LAN. No public exposure, no ISP negotiation, no port forwarding rules. The Peer Relay announcement matters for this setup specifically: my Cloud Run instance spins up fresh containers under load, and DERP relay fallback was occasionally adding latency during the NAT traversal handshake on cold starts. Peer Relays distributing that relay burden to edge nodes should reduce that.

One question for the Tailscale folks: for ephemeral compute (Cloud Run, Lambda, Fly.io), where containers may spin up/down frequently, how does peer relay selection work when the relaying node itself might be transient?

I wish I could read this but got this[0] guy on mobile with no close button, won't close when you click outside the modal.

0: https://i.postimg.cc/14h3Q9mD/Screenshot-20260219-001356-Chr...

Edit: Nvm, found it. Weird place to put it.

I looked into tailscale in the past as a way to host a game server such as minecraft on my local machine publicly without port forwarding . It seems that tailscale is mostly configured only to work with people you know and trust. I was hoping that Peer Relays would help alleviate some restrictions with tailwind funnel. Does anyone know any alternatives?

I really like Tailscale. Recently though I’ve been having some hard-to-diagnose slowdowns even on a direct (non DERP) connection. I’m not sure if it’s something to do with MTUs or my ISP.

I have my homenas set up with Node Proxy Manager container forwarding requests to different docker machines:ports e.g. I have some TTS/STT/LLM services locally hosted. To increase bandwidth to internet facing nodes, would you use this or some other simpler solution?

Is peer relay essentially a custom relay which was previously available, except now it’s one command?

So it runs a STUN server or similar, for discovery and relaying.

I’m so confused. What is the difference between a peer relay and a DERP server that is self hosted?

Tailscale simp here, been using this feature since it launched in beta, can't believe it didn't exist earlier.

This solved every last remaining problem of my CGNAT'd devices having to hop through STUN servers (with the QoS being noticable), now they just route through my own nodes.

Tried the other day, honestly so far surprised by the good results!

It's a bit disingenuous to present solutions like Tailscale as more secure than opening a VPN port on one's on machine. The latter solution should always be preferred when available just because you don't want your infrastructure to depend on a "free" service which might cease to be free tomorrow.

I never brought my self to use tailscale because it has a login screen and I absolutely despise that even as a concept for a private NAT. I know headscale exists, but it doesn't seem to even support the features I really want.

The peer relay approach is interesting because it essentially turns every node in your tailnet into a potential relay for other nodes. This is a meaningful architectural shift from relying on Tailscale's centralized DERP servers.

For anyone worried about the "rug pull" concern raised in another comment — this actually makes me more optimistic, not less. By distributing relay infrastructure to the edges, Tailscale is reducing its own operational cost per user while improving performance. That's the kind of flywheel that makes a generous free tier more sustainable, not less. Each new node potentially helps the whole network.

Are you guys using this for OpenClaw or what?