amneziawg-installer: one-command VPN server that works where WireGuard gets blocked
(github.com)
from bivlked@lemmy.world to selfhosted@lemmy.world on 06 Apr 03:49
https://lemmy.world/post/45242153
from bivlked@lemmy.world to selfhosted@lemmy.world on 06 Apr 03:49
https://lemmy.world/post/45242153
WireGuard is blocked by DPI in 10+ countries now. AmneziaWG 2.0 is a fork that makes the traffic look like random noise - DPI can’t tell it apart from normal UDP. Same crypto under the hood, negligible speed overhead.
I wrote an installer that handles the whole setup in one command on a clean Ubuntu/Debian VPS - kernel module, firewall, hardening, client configs with QR codes. Pure bash, no dependencies, runs on any $3/month box. MIT license.
Been running it from Russia where stock WireGuard stopped working mid-2025.
threaded - newest
DPI?
Deep Packet Inspection
Wasn’t sure either, looked it up quickly…
In this context it’s probably referring to Deep Packet Inspection, some technique to determine traffic type, and then blocking specific (Wireguard and/or OVPN) traffic.
Deep packet inspection. Looking for patterns in the actual headers and payload of packets. Computationally expensive.
Thanks to all replyers. My brain came up with dots per inch, which didn’t make any sense at all.
It is not as expensive as it used to be.
Deep package insertion.
This baby’s built for deep penetration, not speed!
So, explain this to me. I hear people talk about blocked VPNs, and it’s true that some websites do block most, if not all, VPN. However, you mentioned Russia, and I use Wireguard, and I have no issues accessing Russian sites. I just visited government.ru. So, is the problem getting out of Russia, or getting in?
Sounds like the issue is ISPs within Russia blocking outgoing Wireguard traffic from customers.
If the traffic exits the tunnel without hitting a Russian ISP (e.g. a Mullvad exit node in Sweden that routes the unencrypted traffic to the destination), you won’t be affected. If the exit node is behind a Russian ISP, it might get filtered by DPI depending on which direction is subject to the filter.
Right, but if you have the ability to block wireguard coming out of Russia, wouldn’t it make sense to block Wireguard or any other VPN protocol into Russia? I mean, China is rather notorious for blocking VPN usage but citizens still use them to access the internet. I would imagine Chinese citizens would use something like a combination of WireGuard with obfuscation like stunnel, cloaking, domain fronting-like setups, and proxy chains.
Read my comment again, it has the answer. Most VPN services do not provide end-to-end tunnelling. If the exit node is located outside Russia, then what enters the Russian internet will be simple HTTPS traffic.
Ok, I’m curious as to the DPI claims. Fortunately, AmneziaWG describes how it differs from WG here: docs.amnezia.org/documentation/amnezia-wg/
In brief, the packet format of conventional WireGuard is retained but randomized shifts and decoy data is added, to avail the packets with the appearance of either an unknown protocol or of well-established chatty protocols (eg QUIC, SIP). That is indeed clever, and their claims seem to be narrow and accurate: for a rule-based DPI system, no general rule can be written to target a protocol that shape-shifts its headers like this.
However, it remains possible that an advanced form of statistical analysis or MiTM-based inspection can discover the likely presence of Amnezia-obfuscated WireGuard packets, even if still undecryptable. This stems from the fact that the obfuscation is still bounded to certain limits, such as adding no more than 64 Bytes to plain WireGuard init packets. That said, to do so would require some large timescales to gather statistically-meaningful data, and is not the sort of thing which a larger ISP can implement at scale. Instead, this type of vulnerability would be against particularized targets, to determine if covert communications is happening, rather than decrypting the contents of said communication.
For the sysadmins following along, the threat of data exfiltration is addressed as normal: prohibit unknown outbound ports or suspicious outbound destinations. You are filtering outbound traffic, right?
As someone living in Russia, it indeed works to trick complex DPI systems. Unlike classic Wireguard, it works.
Awesome.
Living in Russia, im super curious about that. How is daily life? People support Putin?
They are supporting their government since Russia is under attack, but the war is unpopular. The government response is considered too weak, many want harder strikes, including against the West.
Seems like the leaders are itching to start a large scale war. Positioning themselves to grab control over oil and other forms of energy.
Daily life…it depends. Overall, things as running as usual, except for some things that cause everyone’s anxiety.
First is, obviously, heavy Internet censorship. Living without a VPN is so unbearable even older generations call the younger one for help. Government is currently high on pushing the state-controlled messenger Max, but no one, even the older folks, wanna join. So, they do everything in their power, from forcing government services to use Max as a communications platform, to blocking all other options. People keep using Telegram regardless, and find ways not only around blacklist, but even whitelist blocking. Max is nearly universally despised. VK remains a not-much-better alternative for those who didn’t yet find their way around whitelists. Unease grows about plans to use state-controlled apps to monitor VPN connections on Android phones and block respective IPs. iPhones are better protected in this respect, but other plans are devised as well.
Second is war. The last 2-3 years of it were relatively chill for most Russians, but with drone strikes appearing as far as Saint Petersburg, the war knocks back home. The unease is amplified by Russia turning mobile connections to whitelist mode when drones appear. The appearance of circumvention methods (bridging through whitelisted resources into the wider Internet), on one hand, relieves the anxieties of losing last bits of access to the world, but on the other, shows governments inefficiency at maintaining the drone defense.
Third is more broad and globally known - the cost of living crisis, which hits here just as everywhere else. Housing is practically unattainable for most, and rent goes through the roof. Food gets more expensive, and scandals arise about managing the existing supply, such as Miratorg claimed to push government’s hand in exterminating private farms’ livestock under the guise of disease prevention.
Overall, plenty of room for anxiety and sense of instability.
The Putin support has long switched from “go go Putin” to “who, if not Putin?” and then to “if Putin loses, the country is going to collapse”. So, over time it became less of actual support and more of added anxiety about war’s resolution and what it means for Russia going forward. Putin is often seen as a beacon of some, fainting, stability. But even with all that, support does indeed fade.
Its interesting to read that because its exactly the same things being pushed in the west. There is some kind of agreement being played out in my opinion. Setting the stage for splitting up things between them.
In the mean time, ordinary people like you and me are just people, having much more incommon with eachother than those so called leaders.
Absolutely. I don’t have a leader, but I do have you and others by my side.
Fuck the war. Fuck the so-called “leaders”
100% to that my friend.
Words to live by.
Alternatively, you can download Amnezia VPN client app on your phone or PC, and it has this amazing function where you provide the IP and root credentials, and it installs server software automatically.
Obviously, only use it when you don’t have other things running on your server.
Advantages:
Disadvantages:
Fair call - the client-driven install is a legit option if you want a GUI. The script is the other angle: read it before running, watch it work over SSH, no background magic. Same protocol, different workflow.
Also thanks for the “it works from Russia” confirmation further up - means more than any testing I could run myself.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
5 acronyms in this thread; the most compressed thread commented on today has 13 acronyms.
[Thread #217 for this comm, first seen 6th Apr 2026, 13:00] [FAQ] [Full list] [Contact] [Source code]
Keep in mind that the rule of law is questionable in many of these countries. While it may bypass blocking it might not bypass detection.
if they can detect it, why couldn’t they block it?
Detection can happen at a later date
Author here. Didn’t expect this post to blow up like this — thanks for all the questions.
A bug came up right after I posted, and I just pushed out v5.8.0 for it. A user couldn’t get the tunnel up on a mobile connection in Russia, and I traced it back to the H1-H4 hash ranges: turns out I was hardcoding the same four ranges into every install, so every server running this script had an identical static fingerprint. The TSPU apparently learned those defaults - my bad.
The fix: H1-H4 now get randomized per install from /dev/urandom - different values every time, no shared defaults. Each server speaks its own dialect.
On the detection-vs-blocking point (possiblylinux127, WhyJiffie): you’re right that shape-shifting headers don’t make traffic invisible, just unmatchable to a simple rule. litchralee nailed it further up - statistical analysis over time could still fingerprint this, but that’s a per-target attack, not something a national DPI box runs on everyone. For the ISP-level blocking that’s actually happening in Russia and Iran right now, per-install randomization is what matters.
Hi! Firstly, thank you for using /dev/urandom as the proper source for random bytes.
Regarding the static H1-H4 issue, does your repo have any sort of unit tests that can verify the expected behavior? I’m aware that testing isn’t exactly the most pressing thing when it comes to trying to overcome ISP- and national-level blocking. But at the same token, those very users may be relying on this software to keep a narrow security profile.
To be abundantly clear, I’m very glad that this exists, that it doesn’t reinvent the WireGuard wheel, and that you’re actively fixing bug reports that come in. What I’m asking is whether there are procedural safeguards to proactively catch this class of issues in advance before it shows up in the field? Or if any are planned for the future.
Fair question. When the H1-H4 thing happened, my first thought was “why didn’t the tests catch this?” - because there wasn’t a test for it. Now there is.
I use bats - 85 tests in 10 files. The H1-H4 fix got its own test_h_ranges.bats with 10 cases, including an INT32_MAX boundary check that runs 20 iterations. All scripts also pass shellcheck with zero warnings.
Every release gets tested on a fresh VPS - Ubuntu 24.04 and Debian 13, full install through both reboots, then every manage command. For bigger changes I get a second pair of eyes on the code - that’s how we caught a restore function not enforcing 600 perms on key files before it shipped.
No CI yet though - tests run locally and on the VPS, not on every push. GitHub Actions is next. The ARM PR (#43) is already adding CI for the ARM builds, so it’s a good time to wire up x86_64 too.
Very cool! I’m actually interested in helping with testing and porting to other architecture. Made a comment on the open issue for ARM support, happy to open a PR if you’re interested