ANDROID NAT-T KEEPALIVE OFFLOAD BYPASSES VPN LOCKDOWN

# Android 16 VPN Lockdown Bypassed by a Simple App via NAT-T Keepalive Offload

**A newly disclosed vulnerability in Android's NAT-T keepalive offload mechanism allows ordinary applications to leak network identity and traffic presence outside an active VPN lockdown, affecting most Android 12+ devices.**

Security researchers have uncovered a critical flaw in Android's Always-on VPN and "Block connections without VPN" implementations that permits unprivileged applications to emit packets directly to the physical network, completely bypassing the VPN boundary. The vulnerability, confirmed across multiple OEM devices including Pixel, Samsung, and Nothing hardware, exploits Android's public NAT-T socket-keepalive API to send fixed-format UDP/4500 packets outside the encrypted tunnel while VPN lockdown remains active. The finding represents a device-class exposure affecting potentially billions of devices.

## The Vulnerability: VPN Lockdown Bypass Through Public API

Android’s Always-on VPN combined with the "Block connections without VPN" setting creates a security boundary that users rely on to ensure their traffic never leaves through non-VPN paths. A normal application with standard networking permissions can cross this boundary through Android's public NAT-T socket-keepalive API, causing clear, fixed-format UDP/4500 packets to reach the physical router outside the VPN path.

The attack leverages documented public application programming interfaces and does not require root access, ADB, hidden APIs, JNI operations, or dangerous runtime permission prompts. The validated public-API path requires only standard permissions like INTERNET and ACCESS_NETWORK_STATE, making it trivially exploitable by any installed application.

## How the Exploit Works: The Technical Breakdown

The attack follows a documented sequence that any developer can access through Android's official SDK. An application creates an IpSecManager.UdpEncapsulationSocket and asks ConnectivityManager.createSocketKeepalive() to maintain a NAT-T mapping. Internally, this path passes a duplicated file descriptor and an IpSec resource ID to IConnectivityManager.startNattKeepaliveWithFd(), which then reaches ConnectivityService, KeepaliveTracker, a NetworkAgent, and transport-specific Wi-Fi keepalive machinery.

The critical weakness lies in the framework's failure to authenticate the fd/resource pair or enforce the caller UID's effective VPN policy before offload. The Wi-Fi offload path can emit keepalive frames without waking the application or performing a new socket write for each packet. Once framework admission occurs, the final emitter operates below the ordinary application socket path that VPN lockdown normally controls.

## Root Cause: Collapsed Trust Model in Android's Keepalive Architecture

The vulnerability traces to a collapsed trust model in startNattKeepaliveWithFd(), a privileged raw-fd API that evolved into a public UdpEncapsulationSocket path. Source history reveals that resource validation was briefly added to the implementation, validating caller UID ownership, pinning the encap socket for the keepalive lifetime, and rejecting duplicate active use. However, this validation was reverted due to service dependency and deadlock concerns.

The reverted protection was replaced with per-UID/per-network quotas that limit resource exhaustion but do not authenticate the fd/resource pair, preserve IpSec lifetime leases, or enforce VPN policy. A privileged raw-fd API became publicly accessible without maintaining the security checks that its privileged status originally justified.

## Runtime Evidence: Three OEMs Confirmed

Controlled testing produced compelling evidence across three distinct device manufacturers:

**Pixel 8 Pro (Broadcom Wi-Fi):** A controlled access-point capture recorded packets at the public minimum 10-second interval while Always-on VPN and lockdown were enabled. The test used researcher-controlled Wi-Fi infrastructure with an external physical-interface capture, providing the most authoritative confirmation of the bypass.

**Samsung SM-F966B (Qualcomm):** VPN Leak Guard selected the physical IPv4 default gateway, observed the active callback, and recorded a continuous router-directed active-slot lease for 24 hours and 32 minutes. This independently confirmed the same public path on Qualcomm WLAN hardware.

**Nothing A059 (Qualcomm):** The same implementation selected the physical gateway and recorded one active Wi-Fi slot, confirming public-path admission on a third OEM. While no independent packet capture was collected for this device, the active-slot observation validates the vulnerability's cross-manufacturer reach.

## Device-Class Exposure: The Scale of the Problem

The affected class includes Android 12+ devices exposing app-visible Wi-Fi NAT-T keepalive offload with usable unprivileged slots. The firmware/source census identifies keepalive or offloaded-packet support surfaces across all seven tracked Android WLAN stack families: Qualcomm, Broadcom/Cypress, MediaTek, Unisoc/Spreadtrum, Samsung S.LSI/Exynos, and Huawei/HiSilicon. These mapped WLAN families represent 91.24% of estimated Android/AOSP-derived shipments from 2021Q4 through 2026Q1.

Android 10's 2019 Compatibility Definition Document requires devices that expose Wi-Fi keepalive offload to support the SocketKeepalive API and at least three concurrent Wi-Fi keepalive slots. Slot/resource checks found no manufacturer overlay that deliberately zeroed the relevant defaults, meaning vulnerable configurations are factory-standard.

## Security Implications: What the Attack Actually Leaks

The direct attacker value is repeated real-network identity disclosure. A destination controlled by the attacker can learn the source IP address as seen from the physical Wi-Fi network, the fact that the device remains online, and packet timing while the keepalive remains armed. Depending on the network, the source IP can imply ISP, organization, travel state, or correlation between a device expected to be behind a VPN and a non-VPN access network.

The value of the leak comes from the user-visible lockdown promise: covered applications are expected to fail closed rather than reveal non-VPN network identity to attacker-chosen destinations. Even without payload exfiltration, a periodic signal can support presence checks, IP correlation, and timing correlation against other observations.

## The Researcher's Recommended Fix

Security experts recommend separating privileged raw-fd requests from public UdpEncapsulationSocket requests as the primary remediation. Raw-fd callers must require PACKET_KEEPALIVE_OFFLOAD permission, while public callers require caller-owned resource validation, fd identity checks, lifetime pinning, and duplicate-use rejection. Both paths require effective VPN-policy authorization before NetworkAgent or HAL admission and revalidation when relevant network or VPN state changes.

Until these checks are complete, unprivileged NAT-T offload should fail closed. The platform should deprecate the public app-facing IPsec, IKE, and NAT-T surface and make the framework functionality system-privileged. Authenticated carrier, IWLAN, VCN, and platform VPN consumers should remain, as their current roles are legitimate.

## Conclusion: A Wake-Up Call for Android Security

This vulnerability demonstrates that Android's VPN enforcement mechanisms remain fragile against determined attackers. The NAT-T keepalive bypass represents a fundamental architectural weakness in how Android handles delegated packet emission, and it affects the vast majority of Android devices currently in use. Until Google implements the recommended fixes, users with strict VPN requirements should consider using VPN-enforcing external routers that tunnel the phone's upstream traffic, reducing dependence on Android's VPN enforcement alone. The security community will be watching closely to see how Android addresses this critical gap in its VPN lockdown protections.