DNS traffic can leak outside the VPN tunnel on Android

Original Article ↗ Hacker News Discussion ↗

Mullvad’s reputation, goals, and technical approach

  • Many commenters praise Mullvad’s detailed write-up, transparency, open-source work (e.g., system transparency and hardware security projects), and non-affiliate marketing stance.
  • Mullvad’s diskless servers, signed software, and remote attestation efforts are seen as unusually strong for a VPN provider.
  • Some worry about future ownership changes or private‑equity buyouts despite Mullvad’s public “not for sale” stance.
  • Others raise the perennial “VPNs are honeypots” concern and note that, structurally, centralized VPNs always require high trust compared to systems like Tor.

Advertising and claims about tracking

  • Multiple people report seeing large Mullvad ad campaigns (billboards, buses, subway cars) in several cities.
  • Some find the campaigns refreshing compared to influencer ads; others find them jarring or “weird” for a privacy product.
  • A recurring criticism: certain subway ads allegedly imply Mullvad “stops online ad networks,” which commenters argue is misleading because VPN alone cannot stop cookie- or JS-based tracking.
  • Defenders note Mullvad offers DNS blocking, a privacy-focused browser, and clearly states on its site that VPN alone is insufficient.

Android DNS/VPN leak discussion

  • Thread assumes readers know Mullvad’s article: Android’s VPN API can leak DNS outside the tunnel under some conditions.
  • A GrapheneOS perspective says:
    • Built-in OS-level VPN profiles do not exhibit the described leaks.
    • Some leaks arise when VPN apps don’t fully configure DNS; Android allows VPNs that delegate DNS to the system, so behavior may be “by design” rather than a pure OS bug.
    • There is a likely OS bug where multicast packets can leak to the local network, again affecting VPN apps but not built‑in VPN profiles.
  • Overall: unclear boundary between OS design flaws and VPN-app bugs; Google has been notified.

Broader mobile OS security and permissions

  • Commenters criticize both Android and iOS for:
    • “Always-on VPN” that still leaks in corner cases.
    • System and OEM apps bypassing VPN and firewall rules.
    • Inability on stock Android to fully revoke Internet access per app; GrapheneOS is highlighted for adding a proper network permission toggle.
  • Concerns about baseband firmware, closed drivers, and cellular networks lead some to deem phones fundamentally untrustworthy for high‑sensitivity use.
  • Debate over root: some see lack of root/bootloader keys as inherently insecure; others (especially GrapheneOS positions) argue app‑accessible root severely weakens Android’s security model.

Workarounds, tools, and threat models

  • Suggested mitigations include:
    • Using external VPN gateways/hotspots (OpenWrt, MikroTik, “network slugs”) and only allowing traffic to VPN endpoints.
    • Local firewall/VPN apps (NetGuard, RethinkDNS) with caveats: they themselves may leak or be limited by OS behavior.
    • Disabling mobile data or using private DNS/DoT/DoH, while acknowledging these don’t fully solve OS‑level leaks.
  • Several note similar or worse VPN/DNS leakage and “special traffic” (e.g., APNS, MMS, VoLTE) bypassing VPN on iOS.

Skepticism and intelligence-agency angle

  • Some speculate that at least some big VPNs are or will be intelligence honeypots, citing historical examples of compromised crypto vendors.
  • Others argue that even if state intelligence can deanonymize VPN users, this is mainly relevant for high‑end threat models (terrorism, serious crime), not casual privacy from ISPs, advertisers, or copyright trolls.

Miscellaneous related topics

  • Mullvad’s removal of port forwarding (due to abuse, blacklisting, and law‑enforcement pressure) disappoints some BitTorrent users.
  • Several report long‑standing problems with Android’s DNS handling (esp. IPv6 and internal DNS), and frustration with both Android and iOS “helpful” network fallbacks that undermine strict routing and privacy.