vvpnbot.dev
EN中文RU
GitHub

Protocol guide / AmneziaWG 2.0

AmneziaWG 2.0: how VPN traffic obfuscation works

AmneziaWG 2.0 is a WireGuard-based VPN protocol with additional traffic obfuscation. It retains the encrypted-tunnel model while changing features that can identify the connection.

Encryption and obfuscation solve different problems

Encryption hides the contents of transmitted data. Obfuscation changes the visible characteristics of the exchange. Even when a packet’s contents are encrypted, an observer can still see its size, direction and timing.

AmneziaWG 2.0 changes characteristic packet headers and sizes. This makes traffic classification harder, but does not mean the connection becomes invisible or indistinguishable from every ordinary application.

Official documentation ↗

What happens inside the tunnel

The tunnel carries IP packets over UDP. Peers use keys and a handshake to establish a protected session. WireGuard’s cryptographic foundation uses ChaCha20-Poly1305 to protect data and Curve25519 during key exchange.

After receiving a packet from the tunnel, the server routes it toward its destination. This allows different kinds of application traffic to pass without configuring a proxy in each application, provided the system routes actually send that traffic into the tunnel.

Official documentation ↗

What H, S, J and I mean

H1–H4 specify message-type identifiers; AWG 2.0 can use ranges. S1–S4 add prefixes to different packet types. Jc, Jmin and Jmax control the number and sizes of random packets before the handshake. I1–I5 describe additional signature packets.

These settings shape the appearance of the exchange; they are not different encryption algorithms. A longer profile or more random data does not automatically mean better protection. Settings must suit the implementation and agree between peers wherever the protocol requires it.

Official documentation ↗

Why DNS and MTU are separate settings

DNS translates domain names into IP addresses. Choosing a DNS resolver does not change the AWG version or enable obfuscation. Making control traffic resemble DNS also does not mean that user requests are carried through the chosen DNS service.

MTU limits packet size on an interface. Tunneling adds overhead, so an excessively large value can cause delivery problems, while an unnecessarily small value produces more packets. There is no single optimal MTU for every network.

Compatibility with WireGuard and other AWG versions

A similar .conf format does not make protocols compatible. A standard WireGuard client does not support all AWG 2.0 extensions. The server implementation and client must understand the parameters in use.

A profile contains more than an address and keys. Removing unfamiliar fields to make import succeed can produce a file the application accepts but that cannot connect to the server. Application versions and router protocol support matter.

Official documentation ↗

Strengths and limitations

AWG suits IP-level VPN routing where ordinary WireGuard can be recognized by characteristic patterns. However, network conditions still matter: if UDP is unavailable, obfuscation alone does not create an alternative TCP channel.

Distinguish a missing handshake from an established tunnel that cannot reach some destinations. In the latter case, DNS, routing or packet size may be responsible rather than obfuscation. No preset guarantees connectivity through every provider.

Frequently asked questions

Essential answers and questions raised in community discussions. Links point to example discussions and documentation; an individual bug report does not prove that every user is affected.

What is AmneziaWG 2.0 in simple terms?

It is a WireGuard-based VPN protocol that obfuscates visible traffic characteristics. It carries IP packets through an encrypted UDP tunnel. Obfuscation makes recognition harder, but does not guarantee connectivity on every network.

Documentation ↗

Can I open an AWG 2.0 profile in ordinary WireGuard?

Do not assume this works for a profile using AWG extensions. Even a successful file import does not confirm protocol support. The client must understand the parameters in use, including header ranges and additional fields.

Documentation ↗

Why does it stay on Connecting indefinitely?

The cause may be client-side profile handling rather than the network alone. A GitHub user report describes an AWG 2.0 parameter-application error on Windows. Check logs for import and peer-creation errors, then check server reachability. One report does not mean everyone is affected.

Documentation ↗ · Community discussion ↗

Why does a profile work on a phone but not a router?

Applications and firmware differ in their support for AWG extensions. Check the exact model, firmware version and supported protocol version. Deleting unfamiliar fields from a file does not add missing support to a router.

Documentation ↗ · Community discussion ↗

Do I need to distribute an updated profile after changing I1–I5?

A previously saved file does not update itself. In the setup documented by Amnezia, newly generated files inherit changed server-side I1–I5 values. An existing client needs its configuration updated to use those settings; changing I parameters alone does not inherently require replacing cryptographic keys.

Documentation ↗