WireGuard is a VPN protocol and implementation that carries encrypted IP packets between peers over UDP. It identifies peers with public keys and establishes temporary traffic keys through a Noise-based handshake; routing, DNS policy, account management, and traffic blocking still require surrounding software and configuration.［1］［2］

Key Takeaways:

WireGuard transports IP packets, rather than only the requests of one proxy-aware application.

Public keys identify peers; the handshake establishes separate temporary data keys.

ChaCha20-Poly1305 protects tunneled packets, while UDP carries them across the outer network.

Roaming can update a peer's endpoint after authenticated traffic arrives from a new address.

Encryption does not supply obfuscation, a kill switch, DNS policy, or a provider's privacy policy.

What traffic does WireGuard carry?

WireGuard creates a network interface for IP traffic. An operating system can send selected routes into that interface, and WireGuard encrypts the packets for the appropriate peer. The other peer decrypts them and passes the inner packets onward according to its own networking configuration. The ordinary Internet path between those peers sees an outer UDP connection.［1］

The inner IP packet and the outer UDP packet serve different purposes. An application can use TCP inside the tunnel even though WireGuard uses UDP outside it. The figure represents a peer-to-peer tunnel; reaching the wider Internet additionally requires forwarding and an appropriate exit setup.

An interface is not a complete privacy product

Installing a tunnel interface does not automatically select every route. A private-network deployment may carry only an organization's internal ranges, while an Internet-exit deployment may arrange default routes. Both use the same protocol, but their traffic scope differs because the operating system and configuration decide which packets enter the interface.

The distinction also applies to IPv4 and IPv6. A route that covers one address family says nothing by itself about the other family. DNS lookup behavior must be examined separately: a resolver address is not proof of the path a query takes. The general VPN guide places the tunnel alongside those wider privacy decisions.

How do public keys identify WireGuard peers?

A peer is another WireGuard participant identified by a public key. Each participant keeps its own private key and shares the public key with the participants permitted to communicate with it. A public key is not a username, billing account, or certificate issued by a VPN provider. Distribution and authorization of those identities belong to the surrounding deployment.［1］

The protocol associates peer identity with permitted inner IP addresses, a design described as cryptokey routing. For outgoing packets, the destination address helps choose a peer. For incoming decrypted packets, the source address must belong to the permitted set for that authenticated peer. This is more than a list of outer server addresses, but it is not a complete operating-system firewall.［1］［3］

Separate identity, endpoint, and inner address

These three values answer different questions. A public key identifies the peer you intend to trust, an endpoint tells the outer network where to send its UDP packets, and an inner address identifies traffic carried through the tunnel. Sharing a public key does not hide the endpoint from network observers, and changing the endpoint does not create a new cryptographic identity.

Reading a configuration becomes easier once these roles are separated. Our WireGuard endpoint explanation discusses the address field, while the routing checklist for a connected tunnel covers configuration problems. Those are separate tasks from understanding what the protocol is.

What happens in the WireGuard handshake?

The WireGuard handshake authenticates peers and derives temporary keys for data transfer. Its Noise construction combines long-term peer keys with newly generated ephemeral keys. The normal exchange contains an initiation and a response; the established sending and receiving keys then protect subsequent transport data. This description is a model of the normal exchange, not a guarantee that the network delivers each message immediately.［2］

ChaCha20-Poly1305 is the authenticated-encryption construction used for data packets. ChaCha20 provides encryption, and Poly1305 supplies an authentication tag that allows invalid or modified ciphertext to be rejected. Curve25519 participates in key agreement, while BLAKE2s and related derivation operations have other roles. These names should not be flattened into a single “encryption strength” score.［2］

Temporary data keys versus lasting peer identity

WireGuard renews traffic keys and uses counters and replay protection for transport packets. A long-term peer key is therefore different from the data key protecting a particular period of communication. The AES and ChaCha20 encryption explanation separates cipher selection from key exchange, so an algorithm name does not stand in for the entire security design.［2］

Forward secrecy concerns recorded data after later compromise of long-term keys, under the protocol's assumptions and correct key handling. It does not erase data already stored at an endpoint or protect a currently compromised device. Read the forward-secrecy model for VPN sessions for that narrower property.

WireGuard's limitations page also distinguishes forward secrecy of data from forward secrecy of identity hiding. If a responder's static private key is later compromised, recorded earlier handshakes can expose which initiator identities contacted it, without revealing the contents of the earlier data packets merely for that reason. “Forward secret” should therefore always name the property being discussed.［4］

Why does WireGuard UDP matter?

WireGuard sends handshake and transport messages over UDP. UDP avoids requiring the outer tunnel to implement a second reliable byte stream around an application's existing TCP stream. The protocol does not have a built-in TCP transport mode; any additional carriage mechanism belongs to another layer.［2］［4］

This creates a practical dependency: if the network does not pass the required UDP path, the peers cannot establish or maintain that path merely because their keys are correct. A public key match proves nothing about packet delivery through a firewall, NAT, or restricted access network. Likewise, application traffic failing after a handshake points to a different question from a handshake that never arrives.

Encryption does not disguise the protocol

WireGuard focuses on a compact encrypted tunnel rather than traffic obfuscation. Packet structure and traffic behavior can remain recognizable. It is therefore inaccurate to promise that selecting WireGuard makes VPN use invisible or indistinguishable from ordinary web browsing. Its cryptographic security goal and a network classifier's ability to recognize a protocol are separate matters.［4］

The protocol and obfuscation layer guide explains that separation. The VPN protocol overview provides context for other designs without turning this definition into a speed ranking. We make no claim about availability on a particular country's networks.

What does WireGuard roaming actually preserve?

WireGuard roaming allows a peer's remembered outer endpoint to change when valid authenticated traffic arrives from a new source address and port. The peer's public-key identity can remain the same while the device moves from one network to another. An endpoint address is thus a current delivery location, not the identity itself.［1］［3］

For example, moving from Wi-Fi to a mobile connection may change your outer IP address. If both networks allow the required path and valid traffic reaches the other peer, the tunnel can continue using the existing peer relationship. That conditional behavior is different from guaranteeing uninterrupted downloads, preserving every application session, or ensuring that an operating system never sends traffic outside the tunnel during a transition.

Mobility has a surrounding-system boundary

The client still needs an operational interface, routes, and an available network path. Applications can time out while the network changes, and NAT or firewall behavior may affect delivery. A kill switch, if required, must cover those transition states through the client or operating system rather than being inferred from the protocol's roaming mechanism.

The known limitations also discuss endpoint redirection by an active network intermediary. Such redirection does not by itself decrypt the authenticated data. It does show why endpoint movement and confidentiality are different security properties, and why network restrictions can be relevant in deployments with fixed peers.［4］

Which features belong to the protocol and which belong elsewhere?

A short feature list can hide several owners. The table separates what WireGuard specifies from the surrounding decisions needed to turn it into a usable service. It is an editorial scope map, not the result of a product test.

Requirement	WireGuard's contribution	Additional owner or decision
Packet confidentiality and authentication	Authenticated encryption between peers	Trusted endpoints and protected private keys
Peer identity	Public-key authentication	Key distribution, authorization, and revocation policy
Traffic scope	Peer address mapping and tunnel interface	Operating-system routes and IPv4/IPv6 coverage
DNS behavior	Carries IP packets when routed into it	Resolver selection and query routing
Blocking traffic after failure	No universal kill-switch policy	Client and operating-system firewall behavior
Service privacy	No billing or logging policy	Provider operations and independently supported evidence

For a managed service such as AethoVPN, evaluate the documented client routing behavior separately from this protocol's peer authentication; an application mode and a protocol name answer different questions about traffic coverage. The tunnel-versus-proxy comparison is a useful next step when the requirement is an IP tunnel or selected application forwarding, without inferring a service's underlying protocol.

Shadowsocks' application proxy model starts at another layer. Comparing the two accurately requires knowing which applications and destinations must be covered, not assuming that the presence of encryption makes their scope identical.

Summary

WireGuard encrypts selected IP packets between public-key peers over UDP.
Handshake keys, data keys, endpoints, and inner addresses have different jobs.
Roaming updates a delivery endpoint under suitable network conditions.
Routes, DNS, failure blocking, account management, and provider privacy need separate evidence.

FAQ

Is WireGuard a VPN or a proxy?

WireGuard is an IP tunnel protocol and implementation. It carries packets selected by routing, while an application proxy starts with particular application requests; a usable VPN service adds further operational features.［1］

Does WireGuard use AES-256?

WireGuard uses ChaCha20-Poly1305 for authenticated data encryption, rather than offering AES-256 as a selectable cipher. Comparing those algorithms alone does not establish the security of a complete VPN service.［2］

Can TCP applications use a WireGuard tunnel?

TCP application packets can travel inside WireGuard's encrypted IP tunnel. The outer transport remains UDP, so this does not mean that WireGuard itself has a native TCP mode.［4］

Does WireGuard automatically route my entire device?

The protocol does not automatically choose complete device coverage. Operating-system routes, address-family handling, DNS behavior, and the client configuration determine which traffic actually enters its interface.

Does a public key identify a person's account?

A public key identifies a cryptographic peer, not necessarily a person or subscription. Any association with a billing account or real-world identity is established by the deployment outside the protocol.

Does WireGuard roaming guarantee no traffic leaks?

Roaming updates a peer's delivery endpoint after valid traffic arrives. It does not define a universal kill switch or prove that routes and firewall behavior prevent direct traffic throughout every network transition.

Does WireGuard encryption prevent protocol detection?

WireGuard does not focus on obfuscation, and encryption does not promise that its traffic is unrecognizable. A recognizable encrypted tunnel can still protect its packet contents while facing network restrictions.［4］

Sources

Sources checked 5 October 2026.

What Is WireGuard? How It Works and Where It Fits