logoalt Hacker News

tptacek • yesterday at 10:07 PM • 5 replies • view on HN

Not sure why you'd vibe-code a new VPN protocol, double ratchet or otherwise, when you can just take WireGuard and make a new transport for it.

WireGuard by itself is not a stealth VPN, but the things that make a VPN "stealthy" are all things you'd layer on top of a WireGuard design, not thread through the middle of it. A datagram-based protocol can run under any obscured transport.

We did this at Fly.io when we discovered that, for one reason or another, 5% of our users simply couldn't reliably use UDP. It was a one-day project to run it under WebSockets instead, and that was before coding agents.


Replies

drum55 • yesterday at 10:10 PM

Wireguard is both really useful and pretty frustrating as a user. As a developer it's amazing that you can do things like relay packets through a bouncer with authentication to get around NAT without ever having to think about the protocol level safety, as a user it's near impossible to configure without the confused "why are no packets working", and as you had here it just doesn't make it through a lot of restrictive networking conditions. I'd love some middle ground between wireguard and tailscale in terms of complexity, their clients have way too much stuff in them.

The parent is obviously just Claude making a fancy website and some sort of unreviewed networking protocol that's dressed up to look as if it's a real project. Github really needs to start showing commit cadence and repo birthdates.

➕ show 1 reply
nirui • today at 1:05 AM

WireGuard by itself is bare. Currently it don't have a "proper" ("official") way to make custom transport for it. Thus if you have to do it, the task is no different than writing a UDP proxy.

But that UDP proxy is then an independent program, with no awareness on the states of the WireGuard instance, thus the proxy have to run in a very dumb/blind way. That's not ideal.

If you want to write a network proxy, it's the best for the proxy to know as much user intent as possible, so for example it knows which request should be retried, which should be given up as fast as possible if encountered a fault, and which request should just be rerouted to another server, etc.

➕ show 1 reply
nyeki • yesterday at 11:09 PM

Yeah, I just forwarded my wireguard connection through websockets with this and even though it's way slower it works just fine. Not even 1000 loc i think.

https://github.com/nekidev/tow

➕ show 1 reply
aborsy • yesterday at 11:12 PM

If you wrap wireguard or build a layer on top of it, it's no longer wireguard that first listens to packets on public interface, it's your wrapper. The security properties of wireguard don't hold (potential for RCE before packets reach wireguard). That's a problem with projects like wstunnel or udp2raw.

You want wireguard to be the software that takes the packets first.

➕ show 3 replies
WhyNotHugo • yesterday at 10:46 PM

> Not sure why you'd vibe-code a new VPN protocol, double ratchet or otherwise, when you can just take WireGuard and make a new transport for it.

Why TFA explains it, it's also in the title: "stealth". WireGuard is trivial to detect and block, and has no aspirations at being stealth.

➕ show 2 replies