Fire-and-Forget Android VPN Lockdown Bypass: NAT-T Keepalives Every 10 Seconds

Short Version

[1] Android’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’s real public IP address.

[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).

[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.

[4] Searches found zero open-source apps using Android’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’s IPsec, IKE, and NAT-T methods and classes should be privileged-only and never accessible to normal apps.

[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.

[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.

[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.

Why This Bypass Is Different

[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’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.

[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.

From Windows 7 to Seven Firmware Families

[10] This offload design predates Android’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.

[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’s slot remained active for 24 hours 32 minutes, and repeated Google Pixel 8 Pro runs also exceeded 24 hours.

[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.

How Android Lost the Security Boundary

[13] Android collapsed a trust boundary by sending trusted Android components and ordinary apps through one internal NAT-T path. Trusted components need low-level control for carrier and system networking. Public features later let ordinary apps making IPsec connections reach the same path. Safe sharing required Android to distinguish callers and prove that each ordinary app owned the live connection named in its request.

[14] In April 2019, Android added checks that confirmed app ownership, rejected invalid or duplicate resources, kept the ownership link for the keepalive’s lifetime, and cleaned it up after the final stop. Engineers reverted those checks in May because networking services could depend on each other and become stuck waiting. Per-app and per-network slot limits replaced them, but limits control how many signals run, not who may start them. The security gate was removed without an equivalent replacement.

[15] A complete repair must verify that the app owns a valid, live resource; reject closed, stale, mismatched, cross-app, and duplicate requests; keep slot limits; and clean up every ownership record and slot after stops or errors. Android must also recheck the app’s current VPN policy before each start or resume, including after a network change. A slot limit can prevent resource exhaustion, but it cannot authorize traffic to leave outside a VPN.

Who uses these APIs? They should be removed

[16] F-Droid and IzzyOnDroid are catalogs of open-source Android apps. I froze their listings and counted each unique source-code repository once. The scan found zero uses across 4,679 open-source repositories of Android’s public IPsec, Internet Key Exchange, or NAT-T features. A manual review of 73 Android VPN-app repositories reached the same practical result: those apps used Android’s standard VPN interface rather than this keepalive machinery.

[17] The July 29, 2026 census found 29 candidates: 26 current listings and 3 removed apps. I acquired 9 APKs; 17 current candidates remained listing-only. DEX analysis found that only 2 of the 9 acquired APKs used the public Android IPsec, IKE, or NAT-T APIs; the other 7 did not. DEX analysis applies only to the acquired APK versions and does not show how many users enabled the functionality or whether it ran in practice. The non-privileged API is practically dead.

[18] Privileged Android components for carrier networking, system-managed mobile connections, and Android’s own VPN functions should retain internal access. Normal apps should receive none; VPN apps can use Android’s standard VPN interface. The public IPsec, IKE, and NAT-T methods and classes should be removed.

There is no war in Ba Sing Se

[19] Comparing public stock-Android VPN-lockdown research from 2016 through 2026, the QUIC registerQuicConnectionClosePayload and NAT-T startNattKeepaliveWithFd paths stand out for ordinary-app access, attacker-controlled destinations, persistence, and affected scope. Google closed the April 12 QUIC registerQuicConnectionClosePayload report as “Won’t Fix,” meaning it judged a practical repair infeasible. Five weeks later, it closed the NAT-T startNattKeepaliveWithFd report as “Duplicate,” meaning it considered an earlier NAT-T startNattKeepaliveWithFd report to cover the same problem. The Reports Are Closed. The Network Isn’t.

[20] Google’s earlier NAT-T startNattKeepaliveWithFd report resulted from broad fuzzing and found one missing gate. It did not find the full ordinary-app-to-VPN-leak chain or its impact. My NAT-T startNattKeepaliveWithFd report showed that current Android accepts the ordinary-app request and lets fixed packets persist outside the VPN; it also identified the full chain, root cause, impact, and repair requirements. One overlapping gate by no means makes reports duplicates when their exploit chains and impacts differ.

[21] GrapheneOS removed the QUIC registerQuicConnectionClosePayload path from its version of Android. The VPN provider IVPN independently reproduced the QUIC registerQuicConnectionClosePayload leak on stock Android. Google has not removed that path there, and the NAT-T startNattKeepaliveWithFd path also remains available. Stock Android exposes both ordinary-app leaks; for now, GrapheneOS still exposes the newly identified NAT-T startNattKeepaliveWithFd keepalive leak to ordinary apps.

[22] Google has not substantively answered requests to reconsider the NAT-T startNattKeepaliveWithFd “Duplicate” decision or disclose the earlier NAT-T startNattKeepaliveWithFd report. It should reopen the NAT-T startNattKeepaliveWithFd case, assess the demonstrated VPN impact, and revisit the QUIC registerQuicConnectionClosePayload “Won’t Fix” decision. While both paths remain open, Android’s “Block connections without VPN” setting amounts to “some effort,” not lockdown.

What VPN Leak Guard Does

[23] I sell VPN Leak Guard, which produced the 24h+ observation in the paper. It checks both unpatched ordinary-app VPN leaks: NAT-T keepalives and QUIC connection-close payloads. For NAT-T, it occupies available slots so another normal app cannot reserve the known slot during protection. That reservation usually holds; if another app does take the slot, VPN Leak Guard warns you instead of failing silently. This narrow fixed-signal mitigation is not an Android repair, arbitrary-traffic firewall, or promise against every VPN leak.

[24] VPN Leak Guard sends local assessment traffic only to the verified local gateway, which connects the phone’s local network to other networks on any physical transport; on Wi-Fi, that gateway is the router. Those assessment packets never leave the local network. They do not contact an Internet assessment server, so no outside assessment service receives the public IP. The app checks both leak paths, but only NAT-T receives mitigation through slot reservation, renewal after network changes, and recovery from hardware or firmware errors.

[25] After over a month of refinement, VPN Leak Guard is highly optimized: it uses very few resources, is engineered for process survival, starts protection quickly, and rapidly re-arms it after process death. It is an extremely mature implementation of the same Android path an exploit would use, but confines assessment traffic to the verified local gateway and never exposes the real public IP beyond the local network.

Why VPN Leak Guard Is Closed Source and Paid

[26] VPN Leak Guard is proprietary, closed-source software. I keep the optimized reservation, renewal, and recovery logic private because publishing it could make sustained abuse easier while stock Android remains vulnerable. This is harm reduction, not a claim that closed code is inherently safer. Given its maturity, I’m uncomfortable open-sourcing it while stock Android remains vulnerable. I may reconsider in a year or so, but remain unsure; more protections and analysis may follow.

[27] A lifetime license for three active devices costs €14.99 excluding tax. That may feel high for a narrow utility; decide whether it fits the risk of exposing your real IP in your threat model.

[28] I’d rather serve a smaller group of customers who value the care that goes into this work. That allows me to provide focused, hands-on support and guidance while charging enough to make that level of service sustainable. Maintaining and supporting security- and privacy-sensitive software is resource-intensive, demanding work, and I want to do it responsibly.