WireGuard encrypts application traffic, but its recognizable message headers and predictable handshake sizes still give a network filter useful clues. Amnezia addressed this with AmneziaWG, changing the message identifiers and adding random padding and junk packets. With these mechanisms alone, traffic can look more like random, high-entropy data than a familiar protocol.
Our approach builds on that foundation: give those packets the outward appearance of another protocol. Instead of filling the available AmneziaWG prefix space with random bytes, we use it to imitate the visible structure of QUIC, DNS, STUN or SIP. The encrypted VPN payload stays intact.
WireSock Secure Connect shapes packets on the client side, while a separate amneziawg-proxy shapes replies on the server side and answers selected protocol probes. Together, they aim to make simple traffic classification less reliable. They do not make the tunnel undetectable or turn it into a complete implementation of the imitated protocol.
The setup below is specifically the AmneziaWG 2.0 standalone-proxy path with a kernel server backend. The project now lives in AWG Server Tools, formerly wiresock/amneziawg-install. Newer protocol generations and the native BoringTun implementation have different constraints; they are not drop-in upgrades for this arrangement.
Choose the Right Protocol Path First
| Server/protocol path | How it relates to this article |
|---|---|
| AWG 2.0 kernel backend + standalone proxy | The arrangement described here: configured S1–S4 prefixes and H1–H4 message identifiers support server-side prefix rewriting. |
| AWG 1.0 + standalone proxy | Supported by the proxy, but without the full AWG 2.0 S3/S4 extension. Do not assume identical coverage of every packet type. |
| AWG 3.x header protection | Not supported by this standalone proxy. Header protection uses prefix bytes during decryption, and the proxy cannot classify the protected headers in the same way. |
| Experimental BoringTun backend | A separate native imitation path in Server Tools. Its installer does not support placing this backend behind the standalone proxy. |
The server compatibility notes are the place to check before changing an existing installation. In particular, do not enable AWG 3.x header protection on a proxied interface. Upstream describes a separate HeaderProtectionKey and a nonce taken from the first 12 prefix bytes; those bytes are no longer disposable filler. See the AmneziaWG protocol description.
What Gives WireGuard Away?
DPI does not need to decrypt a tunnel to classify it. Standard WireGuard has four message types, fixed-size handshake messages, and a recognizable exchange of initiation, response and transport data. Packet lengths, visible header fields, timing and direction can all contribute to a classifier.
For example, the standard UDP payload sizes are 148 bytes for Handshake Initiation, 92 for Handshake Response and 64 for Cookie Reply. Transport Data has a visible header and encrypted content of variable length. These are protocol properties, not evidence that every provider uses the same detection rule. The WireGuard protocol specification describes the messages and their authentication.
Sending junk datagrams before a handshake can disturb a classifier that relies on the first few packets. It leaves the later WireGuard messages recognizable, however, and a longer observation window can still find them. Random noise and a convincing application conversation are different things.
From Random Padding to Structured Prefixes
AmneziaWG changes the visible message identifiers and prepends extra bytes. In the AWG 2.0 model used here, the fields map to packet types as follows:
| Message | Prefix length | Message identifier |
|---|---|---|
| Handshake Initiation | S1 | H1 |
| Handshake Response | S2 | H2 |
| Cookie Reply | S3 | H3 |
| Transport Data | S4 | H4 |
The S values specify prefix lengths; they are not instructions to insert bytes into the encrypted application payload. H1–H4 can specify values or ranges for the four message identifiers. The VPN endpoints must agree on the protocol and compatible parameters, and the proxy needs the server’s actual S/H settings to locate and classify messages.
S4 is especially useful to this experiment because it applies to transport packets, not just the opening handshake. If that prefix already exists, why fill all of it with random bytes? It can instead hold the leading structure of another UDP protocol.
The prefix transformer changes only the available prefix and leaves the inner AWG message after it intact. Classification uses the configured offsets, identifier ranges and expected message lengths. Unclassified packets are not transformed; zero or very short prefixes cannot provide the same imitation as a suitably sized one. This is not a generic converter that makes an ordinary WireGuard client understand an AWG profile.
Putting the Two Sides Together
On the server, the proxy occupies the public UDP endpoint and forwards traffic to the AmneziaWG backend through loopback. The backend produces ordinary AWG replies; the proxy rewrites their available prefixes before returning them to the client. The backend port must remain protected from direct external access if traffic is meant to pass through the proxy.
WireSock Secure Connect’s imitation support, introduced in the 3.5 series, supplies the other direction: client-generated cover packets and structured AWG prefixes. An ordinary compatible AWG client may still connect through the proxy, but the proxy cannot reshape that client’s packets before they cross the outside network. Server-side imitation alone is not bidirectional imitation.
The WireSock parameter reference exposes the protocol/domain/browser choices through Ip, Id and Ib; it lists SIP and STUN support from version 3.6.1.1. The 3.5 introduction does not mean every later mode exists in every 3.5 binary. The browser selector applies only to QUIC; the current guidance also calls for Jc = 0 with QUIC masking. These controls select an imitation profile; they do not create a browser session, prove ownership of a named domain or change the destination into that domain’s real service. Use an AWG 2.0 profile and client/server versions that support the same feature set.
What the Four Modes Actually Show
These captures illustrate an earlier setup and the protocol labels Wireshark assigned to its traffic. The labels help explain each imitation mode, but do not demonstrate a complete application session or a successful bypass of a particular network’s DPI.
QUIC
The QUIC capture includes Initial, Handshake and Protected Payload labels. Those labels describe what Wireshark recognized; they do not establish a complete authenticated QUIC or HTTP/3 session carrying the VPN traffic.
In the linked server implementation, the transformer uses a QUIC-style 1-RTT short header for every AWG packet type. This prefix gives the datagram a recognizable QUIC shape without the framing required for a full QUIC Initial. The enclosed data is still an AWG message, not ciphertext protected with keys negotiated by this imitated QUIC flow.
DNS
The DNS illustration shows query/response-shaped messages and resource-record labels. In the server implementation, sufficiently large response prefixes frame the remaining AWG bytes inside an experimental EDNS option. Smaller prefixes take a different fallback path; fitting a few DNS header bytes does not guarantee that the whole datagram will pass a strict parser.
DNS cover traffic also has a behavioral problem: a high-volume, long-running tunnel is not typical name resolution. Optional forwarding of genuine DNS probes to an upstream resolver is a separate function from carrying encrypted AWG bytes in DNS-shaped messages.
STUN
STUN provides recognizable Binding Request and Binding Success structures. The server prefix can include the magic cookie, transaction fields and, when space permits, attributes such as XOR-MAPPED-ADDRESS. The transformer cannot rewrite the AWG bytes after the prefix: a strict parser can distinguish those trailing bytes from the advertised STUN message. This does not provide a real WebRTC or media session.
SIP
SIP imitation uses recognizable request/status lines and signaling headers. The illustration shows how Wireshark labels those messages. Plausible text at the start of a datagram is not the same as a complete VoIP service: dialog state, body lengths, media traffic and long-term request patterns can still differ.
A Probe Response Is Only Part of the Conversation
An observer can send its own request to a suspicious UDP port. The proxy therefore has protocol-specific responders as well as the packet transformer. Those are separate paths: the receive path first checks for an AWG packet using the configured parameters, so a recognizable AWG packet with an imitation prefix is not treated as an unrelated external probe.
With QUIC handshake handling enabled, the proxy can answer a probe with the server’s opening TLS 1.3 handshake messages and a self-signed certificate. The QUIC responder stops at that server flight: it does not provide a trusted website or carry AWG traffic over HTTP/3. A stateless fallback can instead return a Version Negotiation response. That response signals that no supported version was agreed; it does not complete a QUIC handshake.
DNS probes can be forwarded when that option is enabled, with synthetic fallback behavior. STUN Binding requests have a generated response. SIP handling is method- and dialog-dependent: for example, INVITE and OPTIONS do not simply receive the same 100 Trying reply. Responses are also subject to resource and rate limits. None of these handlers implements every behavior that an active scanner could check.
This can make a shallow check less conclusive. It does not prove that the port is indistinguishable from a real QUIC, DNS, STUN or SIP service, especially when a scanner validates certificates, follows a conversation or compares it with the surrounding traffic.
Auto Mode: First Recognized Protocol, Not First Packet
In auto mode, the proxy waits until it recognizes a probe, such as a DNS query. It then uses that protocol to disguise its replies to that client. AWG traffic and unrecognized packets do not select a mode. Once chosen, the protocol stays fixed for that session.
The state is associated with the client’s UDP address and port, not a cryptographically verified peer identity. A new endpoint or expired session can therefore change the picture. The none label means no imitation protocol has been selected; it does not mean AWG encryption is disabled. Auto mode also does not discover the client’s S/H settings or make incompatible protocol generations interoperable.
Reading the Panel and the Capture Together
The enlarged detail shows two demonstration clients using quic and dns. The full dashboard also shows peer status, traffic counters and expiration dates. This is the AWG 2.0 kernel-backend setup discussed here; the clients, addresses and traffic are fictional demonstration data. The panel is optional. A proxy-session label reports the proxy’s classification state, not proof of a successful peer handshake or successful DPI bypass.
For packet-level diagnosis, capture the traffic on the public UDP side of the proxy and compare both directions. A capture of decrypted tunnel traffic answers a different question. Record the client/server versions, backend, S/H values, selected imitation settings and capture location; keep private keys out of anything you share. When validating compatibility, check both the VPN handshake and actual payload transfer, not just a protocol name in Wireshark.
Where the Approach Helps and Where It Stops
Imitation gives us more control over the traffic an observer sees. It may defeat a classifier built around fixed WireGuard headers or a small set of opening packets. Whether it helps on a particular network depends on that network’s rules and on the exact implementation and profile. The screenshots alone cannot establish that outcome.
Packet-size distributions, timings, direction, volume, certificate behavior and reactions to repeated probes remain observable. A network can block UDP, the server’s IP address or everything outside an allowlist without needing to identify WireGuard at all. Better-looking prefixes do not override those policies, and an unusual imitation can itself become a signature.
There is also a concrete cost: extra prefix bytes consume the path’s packet budget, while the userspace proxy adds socket I/O, session state and CPU work. Check the tunnel MTU, packet loss, CPU load and achieved throughput on the intended machine. This article provides no measured gigabit-throughput or overhead guarantee.
The useful idea is still simple: instead of only hiding a familiar signature in random noise, deliberately shape the visible packet structure. Keep the distinction between a plausible prefix, a coherent application conversation and demonstrated behavior on the target network. That is a useful engineering experiment even without a promise of invisibility.
The described project is an independent community development and is not affiliated with Amnezia, amnezia.org, the Amnezia VPN application, or the Amnezia Free VPN service. It uses the open AmneziaWG protocol and related tools. The names “Amnezia,” “AmneziaWG,” and related trademarks belong to their respective owners and are used here for identification purposes only.