rVPN – stealth VPN with end-to-end encryption
rvpn.org
rvpn.org
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.
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.
netbird's a thing to check out if you want an alternative to tailscale you can self-host.
You want wireguard to be the software that takes the packets first.
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.
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.
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.
That's why wireguard over TCP is not as secure as wireguard UDP.
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.
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.
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 TFA explains it, it's also in the title: "stealth". WireGuard is trivial to detect and block, and has no aspirations at being stealth.
> 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.
Hmm... It just ain't true.
---
For those who need a "stealth VPN", use <https://github.com/XTLS/Xray-core/> or its GUI version <https://github.com/2dust/v2rayN/>
Not at all. China, Russia, and Iran are the three biggest markets for VPNs.
In China about 150 million people use a VPN, in Russia about 60 million, about half the population
Most VPN companies are incredibly sus, outside of Mulvad they're mostly all incredibly suspicious imo. Western intelligence is desperate to enable the use of such tools in enemy territory so they can bombard enemy culture with American culture and make the populations eager to adopt American/Western customs and as a byproduct install leaders who are pro western ideology and less likely to be adversarial. VPNs when marketed to these countries should be seen as tools of propaganda dissemination l, in my opinion.
The EFF will talk a big game about how this tech is about freedom of information, human rights and democracy.but really they're founded by a bunch of US Naval Research guys who are basically tasked with building the "cyber" infrastructure to ideologically invade adversial countries so they can be psychologically colonized. They then launder that mission with discussions about free speech and democracy.
The original US Army's Psychological Operations Unit, was called the "Ghost Army" they used a patch with a ghost hovering over an implied target shooting electricity from its hands.
https://upload.wikimedia.org/wikipedia/commons/7/75/Ghostarm...
The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
The reason that China, Russia and Iran have nation state firewalls is because the US is so good at this, and the US wants to control any country who has any potential of competing with it. Its not because they hate freedom or something, its because anyone the US has deemed an economic or ideological opponent will be targeted in this way. We will beam signals through whatever means/protocol into a country to gain a psychological foothold in their culture, we will then convince them to kill their leaders and install US puppets.
I routinely say that Starlink should make its logo the Ghost Army patch, because thats what it was built for. While it functions as a cool business, and does provide value, it was created as the ultimate propaganda dissemination tool
(eventually atleast, it will be very hard to mitigate against if they can pull off some sort of cellular implementation of Starlink, which they're actively working towards).
TOR and VPN companies attempted to serve this purpose, when this paradigm failed to be a general purpose tool for bypassing nation state firewalls they had to find another way so they helped Elon bootstrap a literal satallite constellation for this purpose. Its literally the Ghost in the sky waving its hand over a population with few ways to prevent its use.
The VPN industry in China, Russia and Iran are weapons for this agenda.
> The ghost on the patch is symbolic for beaming in signals into enemy territory to brainwash, intimidate and control an enemy population.
Any source that support your claims?
From wikipedia (https://en.wikipedia.org/wiki/Ghost_Army):
> The Ghost Army was a United States Army tactical deception unit during World War II officially known as the 23rd Headquarters Special Troops. The 1,100-man unit was created to deceive the Axis forces and mislead them as to the size and location of Allied forces, while giving the actual units elsewhere time to maneuver.
> ... During their tenure, the Ghost Army carried out more than 20 deception campaigns, putting on a "traveling road show" using inflatable tanks, sound trucks, fake radio transmissions, scripts and pretense.
Also the description on the patch:
> Ghost Army insignia, not used by the actual unit, but associated with the unit after the war
Like, it's a FBI honeypot or it's a CIA op to help dissidents?
Not sure what this means. AFAIK all VPNs have end-to-end encryption. Stealth ? will need to read to see what that means.
The typical use case for this is usually malicious btw, and the means to do this are residential proxies, which again are usually maliciously obtained
However, if someone claims (or as good as) that "encrypted over TLS on 443" intrinsically pos5esses this property, they demonstrate that they
• do not understand the state-of-the-art in L7 firewalls as of 2010, let alone today
• don't understand common enterprise and state-level controls like HTTPS decrypt (which instantly break this)
• haven't read any of the last decade of papers on detecting protocols like obfsproxy
• haven't even bothered to look at existing takes on this (like tor) and the compromises that they make
---
From the whitepaper:
> Desktop, CLI, and Android clients use BoringSSL to mimic a Chrome TLS 1.3 ClientHello fingerprint, helping evade deep-packet inspection.
Do you set an SNI / eSNI? No? Trivially detectable. I believe Palo Alto AppID would flag this instantly as non-HTTPS masqueraded traffic.
Go fire this up behind China's golden shield, and see how many minutes your tunnel stays performant before they tarpit you; then come write a whitepaper.
And because the idea is rather obvious-- one of OpenVPN's original raison d'etres, decades ago, was evading detection-- L7 firewalls for corporate and state customers have been rather keen to shore up their detections for all manner of meek, snowflake, obfsproxy, and obscure VPNs.
My understanding as of a decade ago was that China's golden shield, on seeing mysterious multiminute encrypted "HTTPS" sessions, tarpit it and attempt scans / DOS attacks on the other end. How's your rVPN going to hold up when baidu LOICs your endpoint?
Then instantly gives you a shell script that it pipes to `sudo bash`. The irony isn't lost here.
Such a tired trope. If you want to do it the hard way, you are welcome to build by hand https://github.com/PDG-Global/rVPN-core#building
Criticism doesn't expire or saturate, if something is wrong, and people continue to do it, it's still wrong thereafter
> [...] verifies checksum [...]
Phew, good thing it verifies that, otherwise piping unverified output to a sudo shell could be dangerous!
Yes I think its really just the latter.
> Many flows. One connection shape
Shape, shape... shape.
I feel up until AI, nobody with their right mind would refer to the shape of a connection.
Does anyone have a guide on getting wireguard + stunnel set up to evade DPS firewalls?