How WireGuard works on Android (and why we picked it)

WireGuard is the VPN protocol TuxlerVPN Mobile uses to move your traffic between your phone and one of our gateways. It is not the only choice we could have made (OpenVPN and IKEv2/IPsec are still in wide use), but it is the choice that, in our reading, gives the best balance of code surface, performance on mobile, and clarity about what is going on inside the tunnel. This post walks through what WireGuard is, how an Android app actually hosts it, and what changes for your traffic when the tunnel is up.

What WireGuard is, briefly

WireGuard is a layer-3 VPN protocol with a deliberately small design. The cryptographic primitives are fixed rather than negotiated: Curve25519 for key agreement, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing, and Noise as the handshake framework. The reference Linux kernel implementation is on the order of 4,000 lines of code. The userspace wireguard-go implementation that runs on Android is somewhat larger, but still small relative to OpenVPN’s TLS-based stack.

The practical consequences are that there are fewer knobs to misconfigure, fewer ciphersuites to argue about, and a smaller body of code for an attacker or auditor to read. The trade-off is that WireGuard does not negotiate algorithms, so when the consensus on a primitive eventually shifts, the protocol version itself has to change. We think that trade is worth taking on a mobile client where simplicity and battery cost matter.

How an Android app hosts a tunnel

Android does not let an app intercept network traffic from other apps directly. The mechanism a VPN uses is the platform VpnService API. When you tap connect:

1. The app requests VpnService permission. The first time you connect, Android shows the system VPN-consent dialog. After that, the app holds the consent until you revoke it.
2. The app builds a VpnService.Builder describing the virtual network interface: its IP addresses, its MTU, the routes it should claim, and the DNS servers that should be used inside the tunnel.
3. The OS hands the app a file descriptor for that virtual interface. The app reads outgoing packets from the descriptor and writes incoming packets back.
4. Inside the app, the userspace wireguard-go runtime takes those packets, encrypts them with the session key established with the gateway, and ships the resulting UDP datagrams out on the phone’s real network interface.

Two things follow from this. First, every packet that leaves your phone for the open internet has to pass through the app while the tunnel is up. That is what “VPN” means on Android. Second, the OS retains control over the virtual interface itself. The app cannot, for example, escalate privileges by virtue of being the VPN holder.

In TuxlerVPN Mobile’s case the userspace runtime is wireguard-go, loaded at startup as the native library libwg-go.so and addressed by the backend class GoBackend.java. The MTU we hand to the OS defaults to 1280 when the server config does not specify one. That is small enough to live comfortably inside common path-MTU constraints on mobile carriers and consumer-Wi-Fi gear.

What lives in a wg-quick config

Every WireGuard tunnel is described by a short text file with two sections. Each line in the config maps to a behavior you can reason about:

• [Interface] describes your side of the tunnel: your private key, the IP address the OS should assign to the virtual interface, the DNS servers to advertise inside the tunnel, and optionally the MTU.
• [Peer] describes the gateway: its public key, its UDP endpoint (host:port), and the AllowedIPs list.

AllowedIPs is the line that controls which packets get routed into the tunnel. With AllowedIPs = 0.0.0.0/0, ::/0, every IPv4 and IPv6 packet your phone wants to send is matched and handed to WireGuard for encryption. This is the configuration TuxlerVPN Mobile uses. With a narrower AllowedIPs, only packets to specific subnets would enter the tunnel. That is how split-tunnel VPNs are built.

DNS inside the tunnel

If the OS continued to send DNS queries to the local Wi-Fi router after the tunnel came up, the network operator would still see every domain you were looking up, even though the resulting traffic was encrypted. This is the classic “DNS leak.”

When the app constructs the virtual interface via VpnService.Builder, it calls addDnsServer(...) for each DNS resolver named in the WireGuard config’s [Interface] DNS = ... line. Android then routes resolver queries through the virtual interface, so they travel inside the encrypted tunnel and exit at the gateway. We discuss what the gateway can and cannot see in What an Android VPN can see about you.

What the app cannot see, even when it owns the tunnel

A common misreading of the VPN model is that the app can see everything you do. In the typical case it can see less than people expect:

• TLS-encrypted payloads stay encrypted. The VPN encrypts the outer envelope. The inner HTTPS payload was already encrypted by your browser or app. The TuxlerVPN Mobile gateway sees your TLS handshake metadata (notably the Server Name Indication) and the destination IP, but not the request body, the response body, or the cookies.
• Other apps’ contents are opaque. WireGuard sees IP packets, not application state. Your messaging app’s keys, your email client’s IMAP credentials, and your password manager’s vault never enter our process.
• Per-process attribution is limited. At the gateway we see source IP (your tunnel address) and destination IP, not “this packet came from app X on phone Y.” The mapping from tunnel address back to a specific user is governed by what we choose to retain, and our retention list is intentionally narrow, as documented in Logging & Retention Data.

Why we picked WireGuard

Three reasons, in plain terms:

1. Smaller surface to read and review. A short, opinionated codebase is easier to hold in your head than a TLS-based protocol with many decades of options. We think this matters more on a mobile app, where the surface that has to be defended is constrained anyway.
2. Better behavior on flaky mobile networks. WireGuard’s stateless UDP design and short handshake mean reconnects after a network change tend to be quick. There is no long renegotiation when you walk between Wi-Fi and LTE.
3. Predictable performance budget. ChaCha20-Poly1305 runs well on mobile CPUs that lack AES-NI, which is most of the Android device population we serve.

None of this means WireGuard is the right choice for every product. It does mean it is the choice that fit ours.

FAQ

Is WireGuard “more secure” than OpenVPN?

The honest answer is: it is differently designed. Both can be configured to provide strong, modern cryptography. WireGuard’s surface is smaller and its primitives are fixed. OpenVPN’s surface is larger and more flexible. We picked the simpler one because, in our judgment, simplicity is a security property in itself for a mobile client.

Does WireGuard leak my real IP?

The protocol does not, in normal operation. Leaks at the OS layer (for example, IPv6 traffic escaping an IPv4-only tunnel) have been a recurring class of bug across VPN clients generally. Our Android app uses Android’s VpnService defaults plus the AllowedIPs = 0.0.0.0/0, ::/0 configuration so both IPv4 and IPv6 enter the tunnel. We test for leaks in the cases we control. We cannot speak to misconfigurations on your device or by other apps that hold network privileges.

Where can I read more about what we retain?

In Logging & Retention Data and the related no-logs explainer.