Virtually Private Networks

VPN Effectiveness in Hostile WiFi: How Secure Are Enterprise VPNs Against Captive Portals and Compromised Networks?

**Overview**

Charlton Avela and Vickers Ross, researchers at Orange Cyber Defence (the cybersecurity division of Orange Mobile) in South Africa, present research examining whether VPN technologies actually deliver the protection they claim in real-world hostile WiFi scenarios. Rather than analyzing specific VPN vulnerabilities, the researchers examine a fundamental question: do enterprise VPNs provide "network and security equivalency" between hostile WiFi networks and trusted corporate networks? Drawing from travel experiences and common WiFi scenarios (airport terminals, hotels, coffee shops with captive portals), the research tests whether VPNs actually protect against six specific technical threat classes: traffic sniffing, DNS manipulation, DNS leakage, DHCP manipulation, default route manipulation, and other network-layer attacks. The findings reveal surprising gaps between VPN marketing claims and actual security delivery, particularly when VPNs are used with split tunneling (where non-corporate traffic bypasses the VPN), home routers, and captive portals. The researchers demonstrate that even enterprise-grade VPNs fail to protect users in scenarios the security community considers normal and expected, and that defenders' assumptions about VPN effectiveness may be dangerously optimistic.

**Technical Details**

Threat Model: Hostile WiFi Environments:

1. **Captive Portal Scenario**: - WiFi access point (airport, hotel, café) provides free WiFi via captive portal - Users must authenticate, accept terms, or provide information to access internet - Captive portal acts as "man-in-the-middle": intercepts HTTP traffic, redirects to portal login page - User device is in "captured" state: connected to WiFi LAN but not internet - Malicious actors can position same attack infrastructure without legitimate purpose

2. **Home Router Compromise**: - Theoretically identical threat to captive portal when home router is compromised - Compromised routers (Mirai botnet, firmware vulnerabilities) can reconfigure DHCP, DNS, routing - No practical difference between intentional captive portal and compromised router attacking same way - Home networks increasingly targeted; Mirai botnet example shows real-world exploitation

3. **Common Assumptions**: - Working from home via WiFi is common (COVID-19 accelerated adoption) - WiFi access points with captive portals encountered daily during travel - Home router technology stacks expected to be insecure or poorly configured - Corporate VPN deployments commonly use split tunneling (non-corporate traffic bypasses VPN)

The "Captured" State:

4. **DHCP Configuration Under Attack**: - Attacker-controlled WiFi AP can inject DHCP options during WiFi connection establishment - Standard DHCP options included: IP address, subnet mask, default gateway, DNS servers - Malicious option: DHCP domain search suffix (option 15) specifying attacker-controlled domain - Attack: Non-fully-qualified DNS requests (e.g., "printer") get suffix appended, resolving to attacker addresses - Example: Corporate printer accessed as "printer" becomes "printer.attacker.local", resolves to attacker IP

5. **SSL Certificate Spoofing During Capture**: - Captive portal intercepts HTTPS traffic, presents incorrect SSL certificates - System applications and browsers detect certificate mismatch, display warnings - Users pressured to accept invalid certificates via "Connect" buttons (often large, prominent) - Problem: Some applications (Zoom, corporate VPN clients) prominently offer "Remember this setting" - Consequence: User may permanently trust attacker's certificates, future connections automate abuse

6. **Windows Captive Portal Detection**: - Windows performs network connectivity checks: tries to resolve/access known domains - Captive portal intercepts ALL traffic, redirects to login page - Multiple Windows dialogs and system notifications trigger, each seeing wrong SSL certificates - Creates chaos on user's system: hundreds of certificate warnings appearing simultaneously - Pressure to accept invalid certificates accumulates across multiple applications

VPN Threat Model and Expected Protection:

7. **Network and Security Equivalency**: - VPN establishes encrypted, authenticated tunnel from client to corporate network - Expected benefit: user on WiFi experiences same network conditions as on-site employee - Three components of equivalency: confidentiality (encryption), integrity (authentication), access control (corporate policies) - Confidentiality: traffic encrypted between client and VPN gateway; eavesdropping prevented - Integrity: VPN cryptography ensures traffic not modified in transit - Access control: corporate firewall, ACLs apply to VPN traffic

8. **Six Threat Classes VPNs Should Prevent**: - **Traffic Sniffing**: Attacker captures unencrypted traffic from WiFi; VPN prevents by encrypting all traffic - **DNS Spoofing/Meddling**: Attacker modifies DNS responses; VPN should encrypt and authenticate DNS - **DNS Leakage**: DNS requests sent to attacker's DNS server instead of corporate DNS; VPN should force corporate DNS - **DHCP Manipulation**: Attacker injects malicious DHCP options (routes, search domains, servers); VPN should override - **Default Route Hijacking**: Attacker provides malicious default gateway; VPN should enforce routing policy - **Domain Search Suffix Injection**: Attacker-provided search suffixes cause unqualified names to resolve unexpectedly

9. **Split Tunneling Complication**: - Split tunneling: VPN encrypts corporate traffic; non-corporate traffic uses local WiFi directly - Common in corporate deployments: improves bandwidth efficiency, enables local services - Problem: Non-corporate traffic (web browsing, cloud services) remains vulnerable to WiFi attacks - Problem: DNS, DHCP, routing attacks can affect BOTH VPN and non-VPN traffic - Example: Attacker-injected search domain suffix applies to all DNS requests, not just corporate

Testing Methodology:

10. **Scenario Construction**: - Simulated hostile WiFi: controlled test environment with malicious DHCP, DNS, routing - Captive portal simulation: ability to intercept and redirect traffic - VPN client testing: major commercial VPN products tested against scenarios - Metrics: traffic capture, DNS leakage, route leakage, certificate acceptance

11. **Threat Execution**: - Attacker controls WiFi AP: configures DHCP to inject malicious options - Attacker provides DNS services: responds to DNS queries with attacker IPs - Attacker provides default gateway: intercepts traffic intended for external networks - User runs normal tasks: email, web browsing, VPN connection, file access - Monitor for information leakage: what data reaches attacker vs. corporate network

**Defense & Takeaways**

Improving WiFi security and VPN effectiveness for remote workers: (1) Understand VPN limitations—VPNs are not silver bullets; they don't protect split-tunnel non-corporate traffic; they don't override DHCP settings by default; they may not force DNS through corporate servers; (2) Disable split tunneling in corporate VPN policies—all traffic should route through VPN when connected to untrusted networks; sacrifices bandwidth efficiency but improves security; (3) Force corporate DNS—VPN should override DHCP-provided DNS servers; corporate DNS should be only DNS resolver available when VPN connected; (4) Override DHCP options—VPN client should replace DHCP-provided search domains, default gateways, routes with corporate policy; don't trust WiFi AP configuration; (5) Implement DNS-over-HTTPS (DoH)—encrypt DNS queries end-to-end; prevents WiFi AP or VPN provider from seeing what sites users visit; (6) Educate users on certificate warnings—users should NEVER accept invalid SSL certificates, even when pressured by application UI; train users to disconnect and report rather than accept; (7) Deploy endpoint security monitoring—detect when applications accept invalid certificates; flag abnormal network behavior; monitor for suspicious DNS resolutions; (8) Use certificate pinning where possible—applications should pin expected corporate certificates; prevents MITM attacks even if user accepts wrong certificate; (9) Implement network segmentation—corporate networks should restrict what VPN clients can access; even compromised clients shouldn't access sensitive systems; (10) Monitor and log WiFi behavior—when connecting to WiFi, log DHCP options, DNS servers received, routes configured; compare against expected values; alert on anomalies; (11) Use static IP configuration when possible—avoid DHCP in high-security scenarios; manually configure DNS, routes, search domains; (12) Deploy mobile device management (MDM)—force corporate DNS, disable certificate acceptance dialogs, enforce VPN usage, monitor compliance; (13) VPN provider selection—verify VPN actually implements promised features; test for DNS leakage; verify routes actually enforced; don't assume compliance without verification; (14) Captive portal detection/bypass—implement safe captive portal handling; warn users before accepting invalid certificates; provide manual verification mechanisms; (15) Assume wireless is hostile—treat all wireless networks (home WiFi, corporate WiFi, public WiFi) as potentially compromised; never trust network-provided configuration without verification. The critical insight: VPNs are sold as magic solutions for remote work security. Marketing suggests connecting to VPN on untrusted networks creates security equivalency with being in the office. Research shows this assumption is dangerously wrong. Even enterprise-grade VPNs frequently leak traffic, accept attacker-provided DNS settings, fail to override malicious DHCP options, and permit certificate spoofing attacks. The problem is not VPN technology itself but rather how VPNs are deployed, configured, and assumed to work. Organizations implementing VPN assume users are safe on WiFi; users assume VPN provides complete protection; attackers exploit these assumptions. Real security requires understanding what VPNs actually protect (confidentiality of corporate traffic) versus what they don't (non-VPN traffic, network-layer attacks, certificate validation), and implementing additional controls to close those gaps. Remote work security must be defense-in-depth: not relying solely on VPNs but combining them with DNS enforcement, DHCP verification, certificate pinning, network monitoring, and user training.