Fire-and-Forget Android VPN Lockdown Bypass: NAT-T Keepalives Every 10 Seconds | Armin Šupuk<br>Fire-and-Forget Android VPN Lockdown Bypass: NAT-T Keepalives Every 10 Seconds<br>Short Version<br>[1] Android&rsquo;s “Block connections without VPN” setting, known as VPN lockdown, should stop traffic unless it uses the chosen VPN. A Network Address Translation Traversal (NAT-T) keepalive is a small fixed packet sent periodically to keep an IPsec connection, one common kind of VPN, usable through a router. Here, traffic escapes the VPN every 10 seconds and can expose the physical network&rsquo;s real public IP address.<br>[2] Hardware offload means handing packet transmission to Wi-Fi hardware so it continues while the requesting app sleeps. An ordinary installed app without special system privilege can request this NAT-T work and choose its destination. I confirmed the bypass on all three tested Android 16 phones: Google Pixel 8 Pro, Samsung Galaxy Z Fold7, and Nothing Phone (3a).<br>[3] Android should verify that the requesting app owns the live connection used for a keepalive and remains authorized. Android added that ownership protection and then removed it. Per-app and per-network limits restrict the number of repeated transmissions; they do not prove authorization or enforce VPN lockdown.<br>[4] Searches found zero open-source apps using Android&rsquo;s public IPsec, Internet Key Exchange (IKE), or NAT-T features. In the Google Play study, only 2 of 9 acquired APKs used those APIs; the other 7 did not. Android&rsquo;s IPsec, IKE, and NAT-T methods and classes should be privileged-only and never accessible to normal apps.<br>[5] Stock Android leaves two VPN leaks open to ordinary apps: one abuses a QUIC connection-close message, the other NAT-T keepalives. I consider them the two most severe VPN-lockdown failures of the past decade, yet Google has fixed neither.<br>[6] I sell VPN Leak Guard for both still-unpatched leaks. It checks the QUIC connection-close and NAT-T keepalive paths, mitigates NAT-T by reserving slots, and reports supported bypasses.<br>[7] VPN Leak Guard remains closed source while stock Android is vulnerable, and I prefer serving a smaller customer base with focused support at a price that makes the work sustainable.<br>Why This Bypass Is Different<br>[8] Normal app traffic identifies its sender, letting Android route each packet through the VPN or block it. NAT-T offload changes the sender: after one app request, trusted Android networking components and the Wi-Fi hardware transmit repeatedly on the app&rsquo;s behalf. The app controls the destination, but later sends occur below its normal traffic path. Android must apply VPN lockdown when accepting the request, before handing transmission to the hardware.<br>[9] The result is a fixed, fire-and-forget signal, not a tunnel for arbitrary data. The active keepalive technically ends if its process dies, but a good implementation can restart and re-arm it; VPN Leak Guard demonstrated practical survival for more than 24 hours , sending every 10 seconds. Its keepalive continued in the background, behind a locked screen, under Battery Saver, while Doze reduced background work on an idle phone, and while the process freezer paused cached apps. On GrapheneOS, a security-focused Android operating system, it survived a relock to the Before First Unlock state, where user data stays unavailable until the next unlock. Force-stop, uninstall, network loss, or reboot ends it.<br>From Windows 7 to Seven Firmware Families<br>[10] This offload design predates Android&rsquo;s public feature. Windows 7 supported low-power protocol offload in 2009; public Qualcomm Android firmware exposed Wi-Fi and IPsec keepalives by 2014; and Android 6 contained hidden NAT-T support in 2015. Firmware is the low-level code controlling the Wi-Fi chip. In 2019, Android 10 required supporting devices to provide at least three hardware slots, each holding one repeated transmission. In 2021, Android 12+ is the shared vulnerable generation examined here.<br>[11] On the three Android 16 phones, the ordinary-app request selected the direct Wi-Fi route, obtained a hardware slot, and sent outside the VPN. The phones span Google, Samsung, and Nothing hardware using Broadcom and Qualcomm Wi-Fi chips. The observed transmission lasted beyond 24 hours: Samsung&rsquo;s slot remained active for 24 hours 32 minutes, and repeated Google Pixel 8 Pro runs also exceeded 24 hours.<br>[12] Source and firmware evidence extends the finding across seven Wi-Fi hardware families: Qualcomm QCA/CLD3/FastConnect, Qualcomm WLAN/QDSP6 WCNSS, Broadcom/Cypress, MediaTek, Unisoc/Spreadtrum, Samsung S.LSI/Exynos, and Huawei/HiSilicon. Those families map to 91.24% of estimated Android-derived device shipments from late 2021 through early 2026. The remaining 8.76% is unresolved; that is not evidence of safety. Only three phones were tested directly, so the wider estimate rests on the shared Android path and family firmware, not direct tests of every model.<br>How...