Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

> I'd love some middle ground between wireguard and tailscale in terms of complexity, their clients have way too much stuff in them.

netbird's a thing to check out if you want an alternative to tailscale you can self-host.

Netbird also, at least to me, has much too much stuff in it, perhaps even more. I would love to be able to connect to everything reliably no matter the network, the daemon doesn't need a reverse proxy, Ai agent routing and billing, in browser SSH client, it's all just attack surface. Tailscale allows you to compile a lot of it out as of a couple of weeks ago, but it's still an awful lot of code.

The most minimal possible alternative to tailscale and netbird is https://github.com/tjjh89017/stunmesh-go

I contributed some features to it and switched

Netbird doesn’t have proper network isolation, due to its shared policy space compared to one gateway interface per customer/organization. Which is not an issue if you are the only user, but if you are building a service for customers to use, and there’s a potential scale up, it will be an issue, either having multi account mode which will results in many resources you need to deploy or containers per customer, or, having them all shared policy that could potentially allow customer to customer access if misconfiguration happens, alternatively, building a gateway in the middle to broker it all but traffic must pass through which is operational cost plus extra latency, and even privacy concerns.

Pangolin is a similar project to Netbird and Tailscale/Headscale in that it's automatically managing wireguard tunnels but it is natively multitenant by design. Even as the super-admin I have to pick which tenant I want to be "connected to" at any given time to access private resources while my SSO still gets me access to all the secured "public" resources no matter what (if any) tenant I'm connected to.

Pangolin is great, I love it and I use it in my homeserver, but it’s only useful in those scenarios, like clients-sites. If your usecase is site-site (Like my case edge computing) it won’t work, also their newt client is being phased out for the cli, and also they don’t have “headless” setup so it can’t be used as a core of your saas for example, it will be a separate extra dashboard to deal with, and last I remember when I checked their license changes if you make $100k revenue. Headscale and tailscale clients also have single tailnet per server, and is policy file based. What I opt for in my use case (think of robotics and embedded) is iroh and build from scratch, since none of the existing solution worked well, the closest was netbird besides the issues I had above.

> If your usecase is site-site (Like my case edge computing) it won’t work

Isn't that what the "machine" client mode is for? You can grant it access to any resources in its organization.

> also their newt client is being phased out for the cli

Not sure I'd call this a downside, setting up Newt on every system was part of why I stopped setting up my test environment a year and a half ago, having Pangolin CLI when I returned to it was literally what made me start using it more widely. It's still using Newt under the hood as far as I'm aware, and my sites set up with Newt still work just fine.

> also they don’t have “headless” setup so it can’t be used as a core of your saas for example

Version 1.17 actually added this a few months ago: https://pangolin.net/news/1-17-release#site-provisioning-key...

> it will be a separate extra dashboard to deal with

True, though there is an API if that matters to you.

> and last I remember when I checked their license changes if you make $100k revenue

Not as far as I've seen. If you want to go over 50 users/100 sites self-hosted or 250 of either on their cloud service you step in to "Enterprise" licensing which has "Custom" pricing and I'm sure sucks, but I see nothing about revenue being relevant to anything.

I'm using it in a MSP context where I have literally three users but over 100 sites so I'm going to be sticking to the AGPL version unless I have a really compelling reason to change but even that's very powerful.

I also love the fact that they give me a single flag I can set to make all of the "this feature exists but only with a commercial license" stuff disappear.

Thanks for the details, I actually revisited my notes I had when made the architicture of what I am building and checked why I rejected it, and if pangolin now is a choice, that would save me the time of building from scratch on iroh.

>Machine clients

so that's partially right: their docs explains client-site, I don't see anything about site-site, except using a client (now CLI), so if an operator wants to access a machine, this machine-mode works well, but if machine1 wants to access machine2, it needs a client, which is pangolin CLI as a machine client. Newt's native mode and remote-node routing exist, but the docs link them to routing a sites network and to Pangolin Cloud's (or your own server maybe) remote nodes, I can't find anything about site-site unless you have other docs about it, that means V2V still needs client and newt's cli. Additionally, the traffic by default goes through the centerlized server, direct happens by punch holing with fall back to centerlized one, you can't control which is which, and this will have big impact on latency, think of realtime robotics work not just connected machines, every 1ms counts. Lastly, it also grant the permission per resources, not pair of devices.

https://docs.pangolin.net/manage/remote-node/backhaul https://docs.pangolin.net/development/system-architecture

>newt and cli

Actually I mixed it as I was recalling from memory, Olm that being phased out, newt is still there but accessable by the cli

>Version 1.17 actually added this

That's great update actually, it's very similar to netbird in this update. Regarding the API, you are right, but it's its own users, org, and roles, and if your usecase (like mine) where pangolin is only part of the platform, and you have other authintication system, your tenant isolation lives in two seperate systems and you need to mirror both.

I also have other notes I had listed on why I rejected it, so they have no docs about post quantum for the tunnels, netbird has rosenpass, iroh has the hybrid handshake. Also, newt is built by Golang, and it's big for certain boards with 64-128MB. And also more moving parts to maintain (Pangolin, Gerbil, Traefik) compared to netbird or iroh.

>license above 100K revenue

probalby my wordings were not accurate, but the Enterprise Edition features are free only below $100k gross annual revenue; above that they need a paid license https://docs.pangolin.net/self-host/enterprise-edition

The good thing about Pangolin is the login-protected access to web apps and services, which works well in your MSP and also in my server setups, but not in other use cases, where for example you don't expose anything to start with.

Which is why I am building my stuff around iroh instead.

Maybe check out Nebula? (I'm involved in the project.)

yeah, seconded. i'm always shocked people leave nebula out of discussions like this

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.

This isn't true. You don't lose the security properties of WireGuard just because you wrap it in some other transport. There is no particular virtue to it "taking the packets first".

>The security properties of wireguard don't hold

That's plain wrong. The first thing a normal wireguard faces is... the wild network of the Internet, with many servers and hordes of malicious agents. This is what makes is an "encrypted VPN", it's expected to withstand being transmitted by garbage media.

>potential for RCE before packets reach wireguard

There is no such thing as "rce packets". Moreover, every wireguard implementation has a different surface for RCEs (bugs), it's not a property of wireguard, it's a property of the implementation, of which there are at least three.

> There is no such thing as "rce packets".

I mean, that depends quite a bit on the code reading the packets, no?

My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.

>My interpretation of OP is that they trust Wireguard’s code to be secure - random wrappers, somewhat less so.

There is not such thing as "wireguard code". Wireguard is a protocol, and "the security of wireguard" is the inability of the attackers to read the contents of the stream. This is not affected by the wrapper, because a wrapper is no more hazardous than the high seas, i.e. the Internet.

Speaking of implementation code. There are three wireguard implementations that I am aware of: Go, Linux, and OpenBSD. I am quite sure that none of those are bug-free, but adding a wrapper around wireguard packets has NO effect on the security of the implementation. The implementation is receiving packets from "something". This something can be either the net, or the wrapper, or even /dev/urandom

> because a wrapper is no more hazardous than the high seas, i.e. the Internet.

Unless that wrapper is running on the same machine as my Wireguard code - and then the wrapper becomes a potential weak point in the system.

I see where you're coming from and agree with you - in theory, a wrapper is usually thin and shouldn't impact the overall security posture of the system. But this is 2026. AI is regularly curb stomping any notion we had that we write good code and someone just discovered that my SSH server has gone the last decade allowing a login to anyone that pounds out enough 'A' into the password prompt [1].

Given that, I have a fair bit more trust that Jason's Wireguard code (the implementations you mention) correctly handles random packets off the Internet than a wrapper running in the same context.

[1] https://news.ycombinator.com/item?id=50378228

>>someone just discovered that my SSH server has gone the last decade allowing a login to anyone that pounds out enough 'A' into the password prompt

You have ssh server without PAM?

Seriously?

Trivially, any layer on top very much influences the security. It usually runs on the same server, and in fact is often combined with wireguard code into a new VPN. In fact there are additional layers: firewall code, networking stack code, VPN, rest of OS. Just recently there was a critical vulnerability in Linux kernel TCP connection handling code. It wouldn't matter if OpenVPN listens to TCP connections on the same server: attacker may become root before meeting the VPN.

You can write a bare wapper in few hundreds lines of python, but it won't be robust to resume connections etc. The next step up is something like ProxyGuard referenced in this post, but look at repo to see the size of the code. It's this software that listens to open port, and if it has vulnerabilities, there will be remote code execution on the wireguard server. Then we have more featureful software such as wstunnel that are much bigger.

Most if not all software changes with platform. That's trivial.

I have dealt with this issue for a while.

Update: It seems you acknowledge the issue when you say in another comment "as long as the remote attacker does have sudo privilege". First, remote attacker may get root. Second, even if someone runs as a non root user on the same wireguard server, that's equivalent to that person bypassing the wireguard plus logging in as that user, which is worse. Authenticating to the server is an additional step that they would have to do even if they bypass the VPN.

You didn't get it. It would be more clear if you implement it.

With these wrappers, peers also install and run wrapper and unwrapper services, to encapsulate udp packets into websocket frames and vice versa. For example, the software that proceses incoming packets from the internet could be wstunnel listening on 443/TCP. This layer converts the websocket TCP traffic to wireguard UDP, which wireguard would then decrypt. Wireguard could even listen to local host.

In popular implementations, this layer could have notable attack surface, particularly because it often provides additional features, such as obfuscation behind https, authentication, TLS client certificate validation, etc. I recall Debian has a minimal package which does only UDP to tcp parsing and conversion, which is written in C and not maintained. That layer could be insecure, and may lead to code execution on server before wireguard is even involved.

No, the parent commenter's logic is sounder than yours. WireGuard in its natural configuration can't trust incoming packets at all, so there's nothing to subtract by layering things on top of it.

Obviously, all software creates an opportunity for a bug, so even though this is pretty low-risk as attack surface goes, if you're making a choice between plain natural WireGuard and WireGuard wrapped in WebSockets, the "plain" version has marginally less attack surface.

But if your choice is between WireGuard wrapped in WebSockets or an entire new VPN protocol, clearly the new protocol drastically increases the attack surface.

In any case: wrapping WireGuard with something else does nothing at a design level to put WireGuard's security at risk. That's not how it works.

In your implementation, you wrote software that listens to public internet, takes as input websocket traffic and outputs UDP. Right there, there is potential for vulnerabilities and code execution. This piece has nothing to do with software that would next process UDP.

That's why wireguard over TCP is not as secure as wireguard UDP.

This makes no sense. It's marginally less safe to accept UDP packets than TCP packets, for which you at least need to complete a 3WH to deliver frames. I don't think you've thought this through.

IIUC the parent's point is that if you first have to unwrap incoming, say, HTTPS traffic to obtain the Wireguard UDP packets, that unwrapping code might contain vulnerabilities, so an attack compromising the machine Wireguard is running on might occur before the packets ever reach the Wireguard implementation. From where I stand that's a somewhat academic scenario, though. (Unwrapping correctly & safely is usually not that difficult. Just don't use a memory-unsafe language for parsing & unpacking maybe.)

I address that at length 2 comments back.

No you did not.

Wrapping-Unwrapping code is irrelevant to the security of wireguard. Even if your wrapper-unwrapper is an outright remote shell without authorization, it would do nothing to compromise wireguard itself, as long as that shell has no sudo.

But in any case, that wrapper-unwrapper is usually just a packet rewriter, port-to-port, runs as a disabled user with no login privileges, no shell, and in a chroot. The only thing your RCE can do is to exit(1) the rewriter itself.

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

Congratulations, DPI marked your connection as... WireGuard and blocked it.

I'd say you are now double safe - there is could be no RCE if there is no packets at all.

> 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.

He literally acknowledged that:

> 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.

Please read the full comment before replying.

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.

Why is it best for the proxy to "know as much user intent as possible"? You can get that with WireGuard either way, but it's not at all clear to me that's true. We ran a rather huge deployment of WebSockets-encapsulated WireGuard, and I believe Tailscale has as well, and the fact that WireGuard was oblivious to it caused no problems I'm aware of.

I think there is value in undisciplined projects like this one because we may find protocols that beat incumbents by pure chance.

Reply on news.ycombinator.com