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?
As someone living in Russia, it indeed works to trick complex DPI systems. Unlike classic Wireguard, it works.
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.
DPI?
Deep Packet Inspection
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.
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 package insertion.
This baby’s built for deep penetration, not speed!
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.
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:
- No need to install anything manually, just direct Amnezia VPN client to a blank Linux server or VPS
- You can install all sorts of protocols in this manner, not only AmneziaWG. Options include OpenVPN (basic and over Shadowsocks/Cloak), classic Wireguard, IPsec, Xray.
Disadvantages:
- It doesn’t show the SSH terminal as it goes installing things on your server and goes fully automatic, reducing user control and troubleshooting capabilities.
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:
Fewer Letters More Letters HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
5 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.
[Thread #217 for this comm, first seen 6th Apr 2026, 13:00] [FAQ] [Full list] [Contact] [Source code]
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.
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
Hey, saw your PR #43 - the QEMU build matrix is a solid start. Left a comment there about two things: the /output mount path issue in the CI workflow, and the awg-tools version question (the PPA arm64 build might still be 1.x). Are you working on those, or would it help if I tested on my end?
Working on it! I should have an update later today
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.
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
Blocking has to happen real-time on every packet — a DPI box needs a fixed pattern to match. AWG shifts its headers per install, so there’s no stable rule to write. Statistical detection (what litchralee described above) is possible but too slow and expensive to run inline at ISP scale - you’d need to collect and analyze flow data over hours before making a call. By then the connection is long gone.
Working on it! Will have an update for you later today
