You can relay through any other SSH server if your target is behind a firewall or subject to NAT (for example the public service ssh-j.com). This is end-to-end encrypted (SSH inside SSH):
I wonder how much reimplementation there is between this and Tailscale, as it seems like there are many needs in common. One would think that there are already low level libraries out there to handle going through NATs, etc. (but maybe this is just the first of said libraries!)
homebrewer · 1h ago
Who cares at this point, Tailscale itself is the 600th reimplementation of the same idea, with predecessors like nebula and tinc. They came at the right time, with WireGuard being on the rise, and poured millions into advertisements that their community "competitors" didn't have since most of them isn't riding on VC money.
api · 1h ago
I've met a lot of people who think Tailscale invented what it does.
Prior to Tailscale there were companies -- ZeroTier and before it Hamachi -- and as you say many FOSS projects and academic efforts. Overlay networks aren't new. VPNs aren't new. Automated P2P with relay fallback isn't new. They just put a good UX in front of it, somewhat easier to onboard than their competitors, and as you say had a really big marketing budget due to raising a lot when money was cheap.
Very few things are totally new. In the past ten years LLMs are the only actually new thing I've seen.
Shill disclosure: I'm the founder of ZeroTier, and we've pivoted a bit more into the industrial space, but we still exist as a free thing you can use to build overlays. Still growing too. Don't have any ill will toward Tailscale. As I said nobody "owns" P2P and they're doing something a bit different from us in terms of UX and target market.
These "dumb pipe" tools -- CLI tooling for P2P pipes -- are cool and useful and IMHO aren't exactly the same thing as ZT or TS etc. They're for a different set of use cases.
The worst thing about the Internet is that it evolved into a client-server architecture. I remain very cautiously optimistic that we might fix this eventually, or at least enable the other paradigm to a much greater extent.
gavinray · 19m ago
I remember running Hamachi and NoIP DUC's (Dynamic Update Client) as a kid in late 2000's to expose private server addresses for games or for multiplayer through direct network addresses
NoIP was also the recommended "easy" option for configuring RAT (Trojan) host addresses at the time IIRC.
sergiotapia · 3m ago
Hamachi was BIG in the gaming scene. I used to host a Tibia server and use it to make the server accessible to friends.
udev4096 · 34m ago
As much as hyped tailscale is, at least there is an option to fully self-host coordination server. Do you have something like that?
rollcat · 42m ago
I know it wasn't a "new" idea, but still, ZT was a paradigm shift for me. I was suddenly on the same LAN with people I cared about. Thank you for making it happen.
conradev · 28m ago
Iroh is much better suited for the application layer. You can multiplex multiple QUIC streams over the same connection, each for a specific purpose. All you need is access to QUIC, no virtual network interface.
It’s a bit like gRPC except you control each byte stream and can use one for, say, a voice call while you use another for file transfer and yet another for simple RPC.
mpalmer · 2h ago
This is made using iroh, which aims to be a low level framework for distributed software. Involves networking but also various data structures that enable replication and consistency between networked nodes.
danenania · 33m ago
Does it include reconnection logic? I presume that's not considered "low level", but it does always annoyingly have to be reimplemented every time you deal with long-lived socket connections in production.
cr125rider · 2h ago
Isn’t tailscale a wrapper around WireGuard? With some other hole-punch sprinkles?
odo1242 · 1h ago
Well, WireGuard and WebRTC, but yes.
The real feature of Tailscale is being able to connect to devices without worrying about where they are.
homebrewer · 1h ago
You might be confusing it with netbird, which is the 601st implementation of a mesh network that does use both WebRTC and WireGuard.
bradfitz · 1h ago
There's no WebRTC in Tailscale.
snapplebobapple · 42m ago
Isnt a derp server juat webrtc with minor changes?
rollcat · 40m ago
You don't need the whole of WebRTC for NAT traversal, TURN/STUN will do the job.
nine_k · 2h ago
...and DNS, and host provisioning, and SSO, and RBAC, and other stuff you need to sell to enterprises.
benreesman · 2h ago
Theres overlap but i can see complementary uses as well. It uses some of the same STUN-family of tecniques. I have no plans to stop using TailScale (or socat) but i think i use this every day now too.
TechDebtDevin · 2h ago
Connecting phones on mobile/cignat with Tailscale is really one of the few software "Aha" moments I've had.
max-privatevoid · 2h ago
iroh is meant to be this library, but there is also libp2p, which existed before iroh.
binary132 · 1h ago
Part of the problem with libp2p is that the canonical implementations are in Go which isn’t really well-suited to use from C++, JS, or Rust. The diversity of implementations in other languages makes for varying levels of quality and features. They really should have just picked one implementation that would be well-suited to use via C FFI and provided ergonomic wrappers for it.
About once or twice a year a solution comes out that does this. Here is a great one for orchestrating connections: https://docs.spacebrew.cc/
x2tyfi · 1h ago
While that may be true, the branding of this particular project seems unbeatable. A literal dumb pipe man with wacky arms. It just works.
alt227 · 1h ago
I feel it was the same for IFTTT over a decade ago. People always move on to the next shiny thing.
latchkey · 2h ago
"In 2023 it's..."
nine_k · 2h ago
I wonder how much different it is from Wireguard + netcat. Both run encrypted channels over UDP, but somehow differently. What does QUIC offer that Wireguard does not?
sethev · 9m ago
They both run over UDP and always encrypt data. Beyond that superficial similarity they are completely different.
QUIC is a transport protocol that provides a stream abstraction (like TCP), with some improvements over TCP (like built-in support for multiplexing streams on the same connection, without head-of-line blocking issues).
Wireguard provides a network interface abstraction that acts as NIC. You can run TCP on top of a wireguard NIC (or QUIC for that matter).
Wireguard doesn't, which is why tailscale took off so much, since it offers basically that at its core (with a bunch of auxiliary features on top).
Show me some wireguard discovery/relay servers if I'm wrong.
Also, QUIC is more language-agnostic. The canonical user-space implementation of wireguard is in Go, which can't really do C FFI bindings, and the abstractions are about dealing with "wireguard devices", not "a single dump pipe", so wireguards userspace library also makes it surprisingly difficult to implement this simple thing without also bringing a ton of baggage (like tun devices, gateways, ip address management, etc) along for the ride.
If you already have a robust wireguard setup, then of course you don't need this and can just use socat or whatever.
bastawhiz · 1h ago
Wireguard is a tunneling protocol. Netcat lets you write things over a socket. But netcat doesn't implement mechanisms for guaranteeing that all your packets arrive over UDP mode, so you're forced to tunnel TCP over UDP for reliability.
QUIC is all UDP, handling the encryption, resending lost packets, and reordering packets if they arrive out of order. The whole point of QUIC is to make it so you can get files transferred quickly.
WireGuard doesn't know the data you're sending, and netcat+TCP is stuck with the limitations of every packet needing to be sent and acknowledged sequentially.
kevindamm · 1h ago
Wireguard is opaque about the independent streams in its connection. So, while they both can encapsulate multiple concurrent streams in one connection, QUIC can do things like mitigate Head-of-Line Blocking and manage encryption at the transport layer. It also uses a connection ID on these substreams which helps make transitioning across network changes seamless.
appreciate this, the links on dumbpipe.dev are updated now!
ilovefood · 1h ago
iroh is fantastic tech.
I attended Rüdiger's (N0) workshop 2 weeks ago at the web3 summit in Berlin and was left super inspired. The code for building something like this is available here https://github.com/rklaehn/iroh-workshop-web3summit2025 and I highly recommend checking out the slides too :)
bob1029 · 1h ago
I've always found this path to be more compelling:
The marketing is brilliant. The name of the company (number0) is mad hackerish man, right up my alley in the words of Charlie Murphy. I'm going to try this in my GCE on bare metal "unvirtualizer" today (number0 is what a Linux kernel would call the first tuntap with number as its prefix if you had such a patch).
Prior to Tailscale there were companies -- ZeroTier and before it Hamachi -- and as you say many FOSS projects and academic efforts. Overlay networks aren't new. VPNs aren't new. Automated P2P with relay fallback isn't new. They just put a good UX in front of it, somewhat easier to onboard than their competitors, and as you say had a really big marketing budget due to raising a lot when money was cheap.
Very few things are totally new. In the past ten years LLMs are the only actually new thing I've seen.
Shill disclosure: I'm the founder of ZeroTier, and we've pivoted a bit more into the industrial space, but we still exist as a free thing you can use to build overlays. Still growing too. Don't have any ill will toward Tailscale. As I said nobody "owns" P2P and they're doing something a bit different from us in terms of UX and target market.
These "dumb pipe" tools -- CLI tooling for P2P pipes -- are cool and useful and IMHO aren't exactly the same thing as ZT or TS etc. They're for a different set of use cases.
The worst thing about the Internet is that it evolved into a client-server architecture. I remain very cautiously optimistic that we might fix this eventually, or at least enable the other paradigm to a much greater extent.
NoIP was also the recommended "easy" option for configuring RAT (Trojan) host addresses at the time IIRC.
It’s a bit like gRPC except you control each byte stream and can use one for, say, a voice call while you use another for file transfer and yet another for simple RPC.
The real feature of Tailscale is being able to connect to devices without worrying about where they are.
QUIC is a transport protocol that provides a stream abstraction (like TCP), with some improvements over TCP (like built-in support for multiplexing streams on the same connection, without head-of-line blocking issues).
Wireguard provides a network interface abstraction that acts as NIC. You can run TCP on top of a wireguard NIC (or QUIC for that matter).
Wireguard doesn't, which is why tailscale took off so much, since it offers basically that at its core (with a bunch of auxiliary features on top).
Show me some wireguard discovery/relay servers if I'm wrong.
Also, QUIC is more language-agnostic. The canonical user-space implementation of wireguard is in Go, which can't really do C FFI bindings, and the abstractions are about dealing with "wireguard devices", not "a single dump pipe", so wireguards userspace library also makes it surprisingly difficult to implement this simple thing without also bringing a ton of baggage (like tun devices, gateways, ip address management, etc) along for the ride.
If you already have a robust wireguard setup, then of course you don't need this and can just use socat or whatever.
QUIC is all UDP, handling the encryption, resending lost packets, and reordering packets if they arrive out of order. The whole point of QUIC is to make it so you can get files transferred quickly.
WireGuard doesn't know the data you're sending, and netcat+TCP is stuck with the limitations of every packet needing to be sent and acknowledged sequentially.
I attended Rüdiger's (N0) workshop 2 weeks ago at the web3 summit in Berlin and was left super inspired. The code for building something like this is available here https://github.com/rklaehn/iroh-workshop-web3summit2025 and I highly recommend checking out the slides too :)
https://github.com/samyk/pwnat
It has more edges and doesn't handle all cases, but it also avoids the need for any kind of intermediary.
https://github.com/samyk/pwnat/issues/18
https://github.com/n0-computer/iroh/blob/main/iroh/docs/loca...
These are my kind of people!