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.
Ok, I’m curious as to the DPI claims. Fortunately, AmneziaWG describes how it differs from WG here: https://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?
Referenced your comment in my top-level reply - you got the mechanism right. One thing worth adding on the statistical angle: building a baseline requires known AWG traffic to train on first. CPS (I1-I5) randomizes packet timing and cadence on top of headers, which makes even gathering that training data harder. Per-target surveillance is real but it’s a different threat model from what the tool addresses.
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.
Glad to see this! And thanks for getting back to me.
Btw, is there a presence for the project on Mastodon? I’d like to follow along on new stuff in this space. Or even an RSS feed that can be pulled by a bot on Mastodon?
No dedicated Mastodon account yet. For updates, GitHub Releases works as an RSS/Atom feed: https://github.com/bivlked/amneziawg-installer/releases.atom - subscribe in any feed reader. Considering fosstodon.org as a future home if there’s enough interest.
WireGuard is blocked by DPI in 10+ countries now.
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?
Been running it from Russia where stock WireGuard stopped working mid-2025.
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.
