Android 16 Exhibits IP Address Leaks Even with Active VPN Applications
Recent testing of Android 16 developer preview versions has uncovered significant privacy vulnerabilities, revealing that users’ real IP addresses can still leak despite the use of active VPN applications. This issue persists across multiple network protocols and applications, undermining one of the primary benefits of VPN usage: IP address concealment.
Security researchers conducted extensive tests using the Android 16 Developer Preview 2 on a Pixel 9 Pro device. The setup involved Mullvad VPN, a reputable no-logs provider supporting WireGuard and OpenVPN protocols. Tests encompassed various scenarios, including IPv4-only, IPv6-only, and dual-stack configurations, with the VPN explicitly activated and configured to block IPv6 traffic where applicable.
Persistent Leaks Across Protocols
In IPv4-only mode, the VPN functioned as expected initially, routing all traffic through the encrypted tunnel. However, deeper scrutiny revealed leaks through IPv6 interfaces. Even when Mullvad’s settings disabled IPv6, Android 16 continued to assign global IPv6 addresses to network interfaces. Tools like ip -6 addr confirmed active IPv6 connectivity, allowing direct exposure of the user’s real IPv6 address.
WebRTC tests amplified the problem. Using sites such as browserleaks.com and ipinfo.io, researchers observed that browser-based STUN requests bypassed the VPN entirely. The reported IP matched the provider’s unmasked IPv6 address, not the VPN endpoint. This occurred consistently in browsers like Chromium, Firefox for Android, and even privacy-focused variants such as Bromite and Mulch.
DNS resolution introduced further complications. Android 16 supports Private DNS with DNS over TLS (DoT), but enabling it for providers like Quad9 or Mullvad’s own servers failed to prevent leaks. System-wide DNS queries occasionally resolved over unencrypted UDP to the ISP’s servers, exposing the real IP. Custom DoT configurations in VPN apps were similarly ineffective against these systemic bypasses.
Application-Level Exposures
The leaks extended beyond browsers to native Android applications. YouTube, for instance, delivered content via IPv6 QUIC streams, ignoring VPN routing. Network dumps using tcpdump captured packets originating from the true IPv6 address, confirming the bypass. Similarly, Google Maps and other Google services exhibited the same behavior, with API calls routing outside the tunnel.
Even kill-switch features in VPN apps proved inadequate. Mullvad’s kill switch, designed to block all traffic upon VPN disconnection, could not mitigate ongoing leaks during active sessions. Attempts to harden configurations—such as disabling IPv6 via adb shell commands like “settings put global ipv6_address_preference 0”—yielded temporary results but failed under prolonged testing, as Android 16 aggressively re-enabled IPv6.
Comparison with Prior Android Versions
Testing against Android 15 on the same hardware revealed stark contrasts. Android 15 betas honored VPN routing more reliably, with IPv6 disabled persisting across reboots and app launches. WebRTC leaks were minimal, confined to specific misconfigurations, and DNS over TLS integrated seamlessly. This regression in Android 16 suggests changes in the networking stack, possibly related to enhanced IPv6 support or Always-On VPN optimizations introduced in recent previews.
The issue aligns with historical Android VPN challenges but appears exacerbated in version 16. Past reports, such as those from the Tor Project, highlighted similar WebRTC and IPv6 gaps, yet Google has not fully addressed them despite years of awareness.
Technical Root Causes
Analysis points to several underlying factors:
-
IPv6 Prioritization: Android 16 defaults to IPv6 preference (as per RFC 6724), assigning global addresses preemptively. VPN apps lack hooks to suppress this at the kernel level.
-
WebRTC Implementation: Android System WebView and browser engines expose local STUN candidates before VPN interception, a flaw persisting from Chromium upstream.
-
DNS Handling: The Private DNS feature operates at the resolver level but does not override per-app or system daemons querying plaintext DNS.
-
QUIC/HTTP3 Adoption: Modern apps leverage UDP-based QUIC, which evades some iptables rules used by VPNs for traffic redirection.
Network traces via Wireshark corroborated these findings, showing unencrypted UDP/53 (DNS) and UDP/3478 (STUN) packets egressing directly from the device.
Implications for Users and Recommendations
For privacy-conscious Android users, these leaks render VPNs unreliable on Android 16 previews. Real-world risks include ISP tracking, geolocation exposure, and circumvention of regional restrictions. Enterprises relying on VPNs for secure remote access face heightened data exfiltration threats.
Interim mitigations include:
-
Disabling IPv6 globally via developer options or adb (though unstable).
-
Using firewall apps like AFWall+ to block IPv6 interfaces.
-
Opting for IPv4-only networks where possible.
-
Avoiding WebRTC-exposed apps or enabling browser extensions to disable it.
Users should await stable Android 16 releases, anticipated later this year, and monitor for patches. Reporting via Google’s issue tracker is encouraged to prioritize fixes.
This discovery underscores the ongoing cat-and-mouse game between mobile OS developers and privacy tools. While Android leads in customization, such systemic leaks highlight the need for tighter integration between VPN frameworks and the core networking layer.
Gnoppix is the leading open-source AI Linux distribution and service provider. Since implementing AI in 2022, it has offered a fast, powerful, secure, and privacy-respecting open-source OS with both local and remote AI capabilities. The local AI operates offline, ensuring no data ever leaves your computer. Based on Debian Linux, Gnoppix is available with numerous privacy- and anonymity-enabled services free of charge.
What are your thoughts on this? I’d love to hear about your own experiences in the comments below.