Android NAT-T keepalive API lets ordinary apps send packets outside VPN lockdown

An app-level bypass of VPN lockdown

A security researcher has shown that an ordinary Android app can push traffic out through the device's physical network even when the user has enabled Always-on VPN and the "Block connections without VPN" lockdown setting. According to a paper by Armin Šupuk that reached the Hacker News front page on 12 September 2026, the route runs through a public platform API for NAT-traversal keepalives, and the exposure it creates affects most devices running Android 12 or later.

The two settings exist to make covered apps stop rather than fall back: when the tunnel is unavailable, their traffic should not use the underlying Wi-Fi or cellular network, and the device's real network address should stay hidden from anything outside the tunnel. Šupuk's finding is that a normal app, holding no special privileges, can break both promises.

How the bypass works

The path uses two public APIs. An app opens an IpSecManager.UdpEncapsulationSocket, then asks ConnectivityManager.createSocketKeepalive to maintain a NAT mapping. The request travels internally to startNattKeepaliveWithFd in the framework's connectivity service, passes through the keepalive tracker and the active network agent, and ends at the Wi-Fi hardware abstraction layer and chipset firmware, which transmits UDP packets on port 4500 over the physical link.

Two properties make this a problem, per the paper. The emission is offloaded below the ordinary socket layer, so packets leave without a fresh socket write by the app — and outside the per-UID routing, fwmark and firewall checks that lockdown normally applies. And while the platform fixes the packet's format, the caller chooses its destination within the API's routing constraints.

Šupuk traces the root cause to an eroded trust model: a keepalive entry point that once accepted a privileged raw file descriptor was widened to the public UdpEncapsulationSocket path; a validation step for the IpSec resource was added and later reverted; and admission today neither proves that the file descriptor and resource ID belong together nor checks the calling app's current VPN policy before offload.

What was measured

The runtime evidence covers three OEMs, all on Android 16:

• On a Pixel 8 Pro (build CP1A.260505.005), a capture taken at the access point recorded the UDP/4500 packets arriving at the public minimum interval of ten seconds while Always-on VPN and lockdown were both on. The paper also maps the behaviour across backgrounding, screen lock, Doze, battery saver, the restricted standby bucket and the Binder freezer, and across force-stop, uninstall, network-loss and reboot boundaries.
• On a Samsung SM-F966B, the same public path exposed one active Wi-Fi keepalive slot. The paper's VPN Leak Guard setup selected the physical IPv4 default gateway, observed the active callback, and logged a continuous router-directed slot lease lasting 24 hours and 32 minutes.
• On a Nothing A059, the implementation likewise selected the physical gateway and found one active Wi-Fi slot. Šupuk notes that no independent packet capture or duration measurement was taken for this device, so it serves as confirmation of the admission path on a third OEM rather than a full replication.

On the firmware side, the paper counts seven WLAN families representing 91.24% of estimated Android-derived shipments, with the remaining 8.76% unresolved — the basis for its class-wide conclusion about Android 12+ devices.

Ecosystem scan and earlier signals

Šupuk also scanned 4,679 distinct stored Git origins from F-Droid and IzzyOnDroid and detected no use of Android's framework IPsec, IKE or NAT-T APIs; a manual audit counted 73 apps using VpnService. As the paper presents it, no ordinary legitimate app appears to depend on this particular keepalive path.

Nor is the area entirely unexamined: the paper cites earlier Android Automotive access-control work that flagged a permission inconsistency, in which a related keepalive API required the PACKET_KEEPALIVE_OFFLOAD permission while the fd-based variant did not. That research reported the inconsistency, Šupuk writes, but did not follow it to the public UdpEncapsulationSocket trust gap or to physical Wi-Fi emission under lockdown.

Why it matters

VPN lockdown is treated as a hard boundary, by privacy-focused users and by enterprise policy alike. This research shows it is enforced at the app socket layer while a lower, delegated emission path remains reachable by any installed app. The leaked packets carry a fixed payload, but they repeatedly disclose the device's physical source address and timing to a destination the app picks — after the user has explicitly forbidden traffic outside the tunnel.

The reach makes it worse: on the paper's firmware figures, most Android 12+ devices across multiple OEMs are exposed, and because the framework itself grants the offload, the behaviour lacks the usual network-level signs of a misbehaving app. The diagnosis also points to where a fix belongs: restoring ownership checks on the file descriptor and IpSec resource pair, and consulting the caller's effective VPN policy before any keepalive is handed to the hardware.