AmneziaWG

AmneziaWG is a fork of WireGuard-Go. It inherits the architectural simplicity and high performance of the original implementation, while removing the identifiable network signatures that make WireGuard easy for Deep Packet Inspection (DPI) systems to detect.

Version 1.5 took obfuscation to the next level: traffic could be disguised as common UDP protocols, such as QUIC, DNS, and others.

Version 2.0 extends this approach to full "mimicry": traffic becomes less recognizable to DPI not only when the connection starts, but also while data is being transmitted, thanks to constantly changing headers and packet sizes. This reduces the likelihood of VPN traffic being identified by characteristic patterns and makes heuristic analysis more difficult.

Version 3.1 was developed in response to widespread blocking in Russia in June and July 2026, which showed that masking individual traffic characteristics was no longer sufficient. The new version makes statistical analysis of connections more difficult by varying packet sizes, packet sequences, timing intervals, and some protocol metadata. This makes different sessions less repetitive and reduces the likelihood of AmneziaWG being identified through a combination of characteristics.

The predecessor of AmneziaWG, WireGuard, has established itself as a fast and reliable VPN protocol thanks to its compact codebase and high efficiency. However, its fixed packet headers and predictable packet sizes create an easily recognizable signature. DPI systems can identify such packets and immediately terminate the connection, which is a serious problem in countries with internet censorship.

AmneziaWG 1.5 addressed this issue through multi-level obfuscation at the transport layer: it modified packet headers, randomized handshake message sizes, and allowed traffic to be disguised as popular UDP protocols.

AmneziaWG 2.0 further strengthens obfuscation: it uses dynamic ranges for headers instead of static values, adds random bytes to special WireGuard packets, and extends the signature CPS packets before the handshake to mimic UDP protocols more convincingly. At the same time, the fundamental cryptographic core of WireGuard remains unchanged, preserving its performance and security.

AmneziaWG 3.1 protects traffic from detection not only by individual headers or packet sizes, but also by the behavior of the connection as a whole: new mechanisms hide some protocol metadata, add random padding to the content, change the timings of service events, and reduce the repeatability of packet flow. This version also makes WireGuard cookie behavior less recognizable, since it can be used during active probing as an additional fingerprint. This makes protocol detection by DPI systems and behavioral analysis more difficult, while keeping the WireGuard cryptographic core unchanged.

Key Advantages

DPI resistance - dynamic headers from specified ranges and randomized packet sizes.
Protocol masking - imitation of QUIC, DNS, SIP, and other UDP protocols.
High performance - runs as a Linux kernel module, while encryption uses the same single-pass AEAD ChaCha20-Poly1305 algorithm with SIMD optimization as WireGuard.
Energy efficiency - Go code runs in user space without heavy cryptography, making it suitable for mobile devices and routers.
Cross-platform support - support for all major operating systems.
UDP transport - all traffic is transmitted over UDP, which helps bypass blocking and reduces latency.
Ease of configuration - it is enough to specify the signature of the masking protocol; the remaining parameters are filled in automatically.
Backward compatibility - when masking parameters are disabled, the AmneziaWG configuration is fully compatible with WireGuard.

How It Works

The following are the main mechanisms that AmneziaWG 3.1 uses to change the characteristic patterns of WireGuard traffic and make it less recognizable to DPI.

Dynamic headers for all packet types (H1-H4)

During tunnel initialization, the library generates a set of random values from specified ranges, which are applied to each of the four WireGuard packet formats: Init, Response, Cookie, and Data. These values:
- replace predictable WireGuard packet identifiers;
- shift the offsets of Version/Type fields;
- change reserved bits.
For each outgoing packet, a random value is selected from the range; on reception, any value from the range is accepted. This makes the header unpredictable even for the same packet type.

Important: H1-H4 ranges must not overlap.

As a result, two different clients do not have matching headers, making a universal DPI rule impossible to write.
Packet length randomization (S1-S4)

In WireGuard, the Init packet is exactly 148 bytes, Response is 92 bytes, Cookie is 64 bytes, and Data has a variable payload size. AmneziaWG adds pseudorandom prefixes S1, S2, S3, and S4 (from 0 to 32/64 bytes):
```
len(init) = 148 + S1
len(resp) = 92 + S2
len(cookie) = 64 + S3
len(data) = payload + S4
```
These prefixes hide the standard sizes of WireGuard messages and shift service fields deeper into the packet.

Obfuscation packets I1-I5 (Signature Chain) and CPS (Custom Protocol Signature)

Before the handshake (every 120 seconds), the client can send up to five different UDP packets fully described by the user in CPS format. The main element, I1, contains a hex snapshot of a real protocol, such as QUIC Initial handshake, which can also be randomized. The remaining I2-I5 packets increase entropy through a counter, timestamp, and random data.

We call this format CPS - Custom Protocol Signature:

i{n} = <tag1><tag2><tag3>...<tagN>

Tag types

Tag	Format	Description	Constraints	Example
b	`<b hex_data>`	Static bytes for protocol imitation	Arbitrary length	`<b 0xf6ab3267fa>`
t	`<t>`	Unix timestamp (32-bit, network byte order)	Unique within the sequence	Unix time
r	`<r length>`	Cryptographically secure random bytes	length ≤ 1000	`<r 20>`
rc	`<rc N>`	Random ASCII letters `[A-Za-z]` for imitating text protocols	N ≤ 1000	`<rc 10>` -> "aBcDeFgHiJ"
rd	`<rd N>`	Random decimal digits `[0-9]` for imitating numeric fields	N ≤ 1000	`<rd 5>` -> "13654"

Example of a CPS packet:

i1 = <b 0xd100000001><rc 8><t><r 50>

The example above only demonstrates CPS syntax and is not an example of a signature. Do not use it as the value of the I1-I5 parameters.

Packets I1-I5 are sent independently, in order from I1 to I5. For each configured parameter, the corresponding packet is sent. If one parameter is missing, the other configured packets are still sent. If none of the I1-I5 parameters are set, CPS packets are not sent.

Junk-train (Jc)

Immediately after the I-packet chain, Jc pseudorandom packets are sent with lengths from Jmin to Jmax. They blur the beginning of the session in time and size, making handshake detection even more difficult.
Header Protection

AmneziaWG 3.1 introduces Header Protection. This mechanism additionally hides unencrypted service parts of WireGuard packets that can be used as static protocol fingerprints.

ChaCha20 is used for obfuscation. The nonce is taken from the first 12 bytes of the corresponding S1-S4 prefix, and the key is specified by the HeaderProtectionKey parameter.

Note: when using Header Protection, it is recommended to leave H1-H4 at the standard compatibility values: H1 = 1, H2 = 2, H3 = 3, H4 = 4. In this mode, the custom header mechanism is disabled, and the message type is hidden by Header Protection.

Header Protection is applied to the following parts of packets after Sx:
```
Init     - 148 bytes
Response - 92 bytes
Cookie   - 64 bytes
Data     - 16 bytes
```
To use Header Protection, S1-S4 values must be at least 12 bytes, and HeaderProtectionKey must be set.
Content Padding

WireGuard pads transport data to a size that is a multiple of 16 bytes. This repeating pattern can be used in statistical analysis.

The ContentPaddingAddition parameter adds a random number of bytes from a specified range to transport packets. The padding uses the available space up to the internal MTU and does not exceed it.
Custom Timings

WireGuard uses fixed intervals for re-handshake, keepalive, timeout, and repeated connection attempts. In AmneziaWG 3.1, these values can be specified as ranges.

When the protocol needs to set one of these timers, it selects a random value from the specified range. This makes the behavior of different sessions less repetitive over time.
Random Trailers

Even when S1-S4 are used, packet sequences can remain similar in size. For example, the Handshake Initiation + Handshake Response sequence can repeat in a fairly stable way.

RandomTrailers adds a random number of bytes to the end of packets. For handshake packets, random data is added; for transport packets, zeroes are added to the end of the internal IP packet.

The trailer size is selected with the current UDP window in mind. This window changes during data exchange between the two sides, preventing violations of the MTU of both sides.

When using RandomTrailers, it is recommended to set the same values for S1, S2, S3, and S4. This reduces the risk of incorrect packet type detection. This is because packets have random sizes and may be interpreted incorrectly.
Disabling Cookie Reply

In WireGuard, the Cookie Reply mechanism is used to protect against DoS attacks: instead of a normal Handshake Response, the receiving side can send a special Handshake Cookie Reply message.

Under normal conditions, this mechanism works well, but in censorship environments cookie behavior can be used during active probing and become a separate protocol fingerprint.

The DisableCookies parameter disables only the sending of Handshake Cookie Reply messages. Incoming cookie messages and other cookie-related mechanisms continue to work the same way as in the original WireGuard implementation.

Configuration Parameters

range<uint16> and range<uint32> are numeric ranges. They can be specified as a-b or as a single fixed value a. uint16 accepts values from 0 to 65,535; uint32 accepts values from 0 to 4,294,967,295.

Parameter	Type / value	Purpose
I1-I5	`CPS-description`	Obfuscation packets before handshake
S1-S4	`uint16`	Random prefixes for Init, Response, Cookie, and Data
Jc	`uint16`	Number of junk packets
Jmin, Jmax	`uint16`	Minimum and maximum junk packet size
H1-H4	`range<uint32>`	Custom message type identifiers
HeaderProtectionKey	32-byte key	Key for Header Protection
ContentPaddingAddition	`range<uint16>`	Random addition to the transport payload
RekeyAfterTime	`range<uint16>`	Interval before re-handshake
RekeyTimeout	`range<uint16>`	Handshake timeout
RejectAfterTime	`range<uint16>`	Interval after which the connection initiates a new handshake if no data is received
KeepaliveTimeout	`range<uint16>`	Interval before sending keepalive
MaxHandshakeAttempts	`range<uint16>`	Maximum number of handshake retries
RandomTrailers	`on` / `off`	Adds random trailers to packets
DisableCookies	`on` / `off`	Disables sending Cookie Reply

If a mechanism's value is 0, off, or the 0-0 range, the mechanism is disabled and standard WireGuard behavior is used.

For H1-H4, a separate compatibility rule applies:

H1 is disabled when set to 1
H2 is disabled when set to 2
H3 is disabled when set to 3
H4 is disabled when set to 4

Security

AmneziaWG 3.1 does not change the cryptographic core of WireGuard. Key exchange, user data encryption, and the basic security model remain the same as in WireGuard: Noise_IK, Curve25519, and AEAD ChaCha20-Poly1305.

The new AmneziaWG mechanisms operate at the transport obfuscation layer. They hide or change the external characteristics of the connection: message types, packet sizes, service packet sequences, and timings. This helps make protocol detection by DPI systems more difficult, but does not replace the main WireGuard encryption.

Header Protection uses ChaCha20 to additionally hide service parts of the packet. This mechanism is not intended to protect the user payload; it reduces the number of stable characteristics that can be used to identify the protocol.

Since the cryptographic foundation of WireGuard remains unchanged, existing WireGuard security analyses remain applicable to AmneziaWG. The new parameters should be considered mechanisms for masking and DPI resistance, not a separate cryptographic scheme.

Additional Resources

Native AmneziaWG Clients

AmneziaWG configuration files can also be used in specialized clients if the client supports the protocol version for which the file was released:

AmneziaWG

Key Advantages​

How It Works​

Configuration Parameters​

Security​

Additional Resources​

Native AmneziaWG Clients​