AmneziaWG config patcher

[zimbabwe 22]

I've made a Linux shell script for batch-conversion of WireGuard .conf files making them AmneziaWG (awg) compatible:
https://github.com/zimbabwe303/awg_conf_patch

When patching it shuffles the H1..4 parameters; to re-shuffle you can just re-run it over the same files again. It also can shorten .conf file names generated with the AirVPN config generator to facilitate their usage with the 3rd-party smartphone WireGuard clients such as WG Tunnel (which uses AmneziaWG instead of the vanilla WireGuard).

[H12345h12345 0]

You are a king, thank you so much

[Nonsense 1]

@zimbabwe, wow, didn't realize AirVPN could work with AmneziaWG.
So, the difference seems to be just this block of variables in the [Interface] section?

Jc = 50
Jmin = 5
Jmax = 1500
S1 = 0
S2 = 0
H1 = 2
H2 = 4
H3 = 1
H4 = 3

Is this all part of Wireguard, or is this a custom extension by Amnezia?
Are these variables officially documented somewhere?
 

[zimbabwe 22]

On 12/5/2024 at 10:10 PM, Nonsense said:

@zimbabwe, wow, didn't realize AirVPN could work with AmneziaWG.
So, the difference seems to be just this block of variables in the [Interface] section?

Jc = 50
Jmin = 5
Jmax = 1500
S1 = 0
S2 = 0
H1 = 2
H2 = 4
H3 = 1
H4 = 3

Is this all part of Wireguard, or is this a custom extension by Amnezia?
Are these variables officially documented somewhere?
 

It's the custom extension by Amnezia.
Here are their forks of the WireGuard daemon, kernel module and tools:

https://github.com/amnezia-vpn/amneziawg-go (daemon)
https://github.com/amnezia-vpn/amneziawg-linux-kernel-module (optional, works slightly faster)
https://github.com/amnezia-vpn/amneziawg-tools (CLI tools)

Here is the description of the parameters:

Jc=50      # Junk packet count
Jmin=5     # Junk packet minimum size
Jmax=1500  # Junk packet maximum size
S1=0       # Init packet junk size
S2=0       # Response packet junk size
H1=1       # Init packet magic header
H2=2       # Response packet magic header
H3=3       # Transport packet magic header
H4=4       # Underload packet magic header

To use the S1 and S2 parameters you have to have the forks installed on the server as well, thus they are set to 0 to make it work with the original Wireguard server daemons.

The method which is used here is basically the same that is used by many VPN-less DPI circumvention tools popular in Russia (GoodbyeDPI, ByeDpi, Zapret, SpoofDPI, etc.): putting junk packets before the actual handshake. The method is crude, of course, but works, at least for the today's generation of DPI boxes. It's good that WireGuard uses UDP only, for TCP a lot more is needed, hence all the intricate methods used by GoodbyeDPI, ByeDpi and especially Zapret.

[Nonsense 1]

@zimbabwe, this is quite educational, thanks
During my time in Russia, I was using my own VPS with Amnezia containers installed, not knowing I could use AirVPN.

Alas, I'm not sure AmneziaWG is gonna hold out for much longer.
By the end, it was no longer working on my mobile carrier connection (still worked via home ISP though) and I had to switch to XRAY.
Here's hoping VPN providers start focusing more on obfuscation, because censorship is only gonna tighten everywhere...

[Stalinium 50]

Hello I would like to give my personal recommendations to help with network censorship in Russia. I may not have time to write a authoritative, proper guide, but wanted to share this. Everything "clicked" once I read a comment how the DPI works to determine a new connection.

Preface

IP and subnet blocks came first. They completely blackhole all traffic to blocked IP addresses. The only thing you can try is IPv6 in place of IPv4. Some Air servers are blocked by IP.

The Deep Packet Inspection (DPI) is a required installation for residential ISPs and (as of late) industrial networks like data centers. It works to dynamically block known protocol traffic, anything "forbidden" that's not yet in IP blocklists from above. This system was put in law many years ago. Nevertheless, the networks across the country are at various stages of rollout and their capabilities will differ. Real example: residential ISP did not block OpenVPN->Air, yet the mobile carrier did. Yet in 2024 the residential ISP upgraded their DPI system and started blocking OpenVPN too.

Common methods of circumvention

1. Mangle traffic locally to fool the DPI systems. It will allow you to connect to servers not blocked by IP (TLS SNI name detection).
2. Proxy/VPN server: A prerequisite is an outside server, it must not have been blocked by IP. If it's a private server and OpenVPN or Wireguard work - you're lucky. However be prepared to still get blocked by DPI any day for using a VPN protocol.

There are many proxy tools, especially developed to combat the Great Firewall of China. They don't run directly on Air, so this is something for self-hosting or other services to provide. We're talking about Air, so let's get that VPN working.

Everything below requires you to find a reachable Air server (no direct IP blocks). The configuration server used by Eddie is IP blocked, so it won't work at all. I suggest you to generate all server configs in advance and see which are reachable from Russian networks. Airvpn.org seems to be reachable though.
 

OpenVPN over SSH to Air

It is possible to set this up on mobile, however the connection is reset after 10-30 seconds due to a lot of traffic being pushed. I used ConnectBot and it didn't restart the SSH connection properly, anyhow OpenVPN and ConnectBot had to be reconnected manually each time --> unusable. Since both apps are easily downloadable from app stores/F-Droid, this can be enough to generate and download configs from AirVPN's website in a dire situation.
This connection type works like this:

1. SSH connects to Air server, forwards a local port -> Air (internal_ip:internal_port)
2. OpenVPN connects to local_ip:local_port and SSH sends the packets to Air's OpenVPN endpoint inside this tunnel
3. Once the connection is established, it works like a regular OpenVPN on your system

 

OpenVPN over stunnel to Air

I haven't tried, desktop only?

OpenVPN (TCP) over Tor to Air

While connecting to Tor will be another adventure, do you really need a VPN if you get Tor working for browsing? If yes, I suppose it could work. I haven't tried.

 

 

OpenVPN (TCP) to Air

May start working after hours on Android, if the connection was established initially. Until then you'll see a lot of outgoing traffic but almost zero incoming traffic (NOT ZERO though!) It is unclear to me whether this is because Android keeps reconnecting after sleeping or sometimes it pushes so little traffic over the established connection that DPI forgets or clears the block for this connection only.

OpenVPN (UDP) to Air

Doesn't work.

Wireguard to Air

Doesn't work, it's always UDP and very easily detected.

AmneziaWG client to connect to standard Wireguard Air servers

This worked for me almost flawlessly. The trick of AmneziaWG is to send random trash packets before starting the connection sequence. This is what the new parameters are and some of them are compatible with standard Wireguard servers. The DPI only checks traffic within the initial traffic size window of the connection. If it doesn't find VPN connection signatures (and it doesn't due to random data) then it whitelists the connection. Wireguard then sends its connection packets and connects to Air. Full speed ahead, no throttling. The VPN connection works!

What's the catch? The AmneziaWG packet configuration must be right. This worked for me across all networks I encountered:

• MTU: 1320 (safe value, higher MTU will give better bandwidth, if it works at all and doesn't begin to fragment packets)
• Junk Packet count (Jc): 31
• Junk Packet minimum size (Jmin): 20
• Junk Packet maximum size (Jmax): 40
• Init packet junk size (S1): none (afaik only with AmneziaWG server; delete from config or try to set 0)
• Response packet junk size (S2): none (afaik only with AmneziaWG server; delete from config or try to set 0)
• Magic header settings changeable afaik only with AmneziaWG server:
  • Init packet magic header (H1): 1
  • Response packet magic header (H2): 2
  • Underload packet magic header (H3): 3
  • Transport packet magic header (H4): 4

And how would you know what numbers to set? This single insight:

Quote

The DPI analyzes the first few packets in a stream. If the bandwidth increases quickly, this may be considered as a sign of a VPN connection. If the VPN connection sequence is detected at the beginning of this new connection, it will obviously be blocked.

This means flooding small random UDP packets at the beginning is the winning strategy. That's how I optimized someone's config from "sometimes it works, sometimes it doesn't" to "works 100% of the time, everywhere". You actually don't want to blast big packets and be blocked because of it. Smaller random packets are good for mobile traffic too.

How would you setup AmneziaWG to connect to Air (Android)?

1. Generate and download AirVPN Wireguard configs, for each individual server, try different entry IPs too. DO NOT USE THE DEFAULT (OFFICIAL) WIREGUARD PORT. We don't want long-term logging to highlight the working servers for the next round of IP blocks.
2. Download AmneziaWG VPN client (the Android edition is actually a fork of the official Wireguard app): amnezia.org or https:// storage.googleapis .com/kldscp/amnezia.org or https://github.com/amnezia-vpn/amnezia-client/releases/
3. Import Air's configs in the app
4. Apply "Junk Packet" settings from above
5. Try to connect

Try different entry IPs and servers if the connection doesn't work. See if the server IP is completely blocked either with:

• ping "<entry IP>"
• nc -zv -w 10 "<entry IP>" "<port 80 or 2018 for OpenVPN TCP>"
  • This is GNU netcat

Keep in mind: on Android the safest way to avoid any traffic leaks is to go to system settings, Connection & sharing > VPN, or search for "VPN", click on (i) for advanced settings, Enable: "Stay Connected to VPN" & "Block All Connections not Using VPN". If you ever disconnect from VPN by using Android's system notification, you'll need to re-enable these settings.
If you switch between VPN apps (like Eddie -> AmneziaWG), I suggest to make sure these settings are always enabled like this:

1. Turn off Wi-Fi (or mobile data)
2. For previous VPN app disable: "Stay Connected to VPN" & "Block All Connections not Using VPN"
3. For next VPN app enable: "Stay Connected to VPN" & "Block All Connections not Using VPN"
4. Turn on Wi-Fi / connect using next VPN app

Thanks for reading. Big politicians are not your friends, stay strong and propagate what you truly believe in.

[zimbabwe 22]

One more tip from my experience: AmneziaWG with AirVPN worked great until about two months ago when I started noticing degradation in website responsiveness, especially for the first connect to any domain, while the download speeds remained great. About a week ago the browsing experience became so bad (TLS handshakes started to timeout), so I had to look into this problem. I quickly found out that the problem was caused by slow DNS response when it was done through AirVPN's native DNS server and only when using IPv4. I don't know where this problem comes from exactly, but the solution was to install dnsproxy (which is smaller and easier to setup than dnscrypt-proxy) and set it up to use the 3rd party DNSCrypt servers. The problem is not present with WG Tunnel for Android, I presume because it uses IPv6. I plan to try to set up IPv6 on my home PC as well but my ISP provides only IPv4, so I'll probably have to use some IPv6-to-IPv4 tunnel.