No Internet After VPN Connect: Step-by-Step Fix Guide (2026)

The VPN connects, the status bar says “Connected” — and then everything stops working. No websites load, Teams disconnects, and you’re stuck choosing between the internet and your corporate resources. I’ve seen this misconfiguration in everything from 5-person startups to 5,000-employee enterprises, and it almost always comes down to one of three things: full-tunnel routing without internet breakout, a DNS server that only knows internal names, or an MTU mismatch that silently drops packets.

This guide walks through every root cause and fix systematically — from a quick DNS test that solves 60-70% of cases in under 2 minutes, to routing table fixes, split tunneling setup, and MTU adjustments. For help with initial Azure VPN Gateway setup or VPN tunnel connection failures, see our related guides.

Written by Naveed Alam — Network & Cloud Engineer with 8+ years of experience in enterprise networking, Azure infrastructure, Cisco routing & switching, and VPN deployments.

Table of Contents

1. What This Error Means
2. Common Symptoms
3. Root Causes
4. Prerequisites & Tools
5. Step-by-Step Troubleshooting
6. Advanced Diagnostics
7. Real-World Scenario
8. Prevention & Best Practices
9. FAQ

What This Error Means

When a VPN connects, it installs routes that redirect traffic through the encrypted tunnel. In “full tunnel” mode, 100% of traffic — including general internet requests — goes through the corporate network. If the corporate infrastructure doesn’t provide internet breakout, or if its DNS only resolves internal names, you lose internet access entirely. For VPN protocol details, see IETF RFC 4301.

Affected platforms: Windows 10/11, macOS, Linux, and mobile devices — across Cisco AnyConnect, FortiClient, Pulse Secure, GlobalProtect, OpenVPN, WireGuard, and Azure Point-to-Site VPN. See Microsoft Azure VPN Gateway documentation for Azure-specific details.

Common Symptoms

• “No internet access” notification in Windows system tray immediately after VPN connects
• Browsers show DNS_PROBE_FINISHED_NO_INTERNET or ERR_NETWORK_CHANGED
• Ping to 8.8.8.8 fails with “Request timed out”
• Internal corporate resources remain accessible
• Internet instantly resumes when VPN disconnects
• Windows Network Troubleshooter reports “Default gateway is not available”

Root Causes

Full Tunnel Without Internet Breakout

100% of traffic routes through the corporate network, but the company doesn’t have infrastructure to handle external requests. The most common enterprise misconfiguration.

DNS Pushed by VPN Only Resolves Internal Names

VPN pushes internal DNS servers (10.0.0.10, 192.168.1.5) that are configured only for corporate Active Directory zones. They can’t resolve google.com, so all websites appear broken.

Routing Table Conflicts

VPN adds routes that conflict with local network routes (e.g., home network on 192.168.1.0/24 vs. VPN route for 192.168.0.0/16), creating ambiguous path selection that blackholes traffic.

Adapter Metric / Priority Issues

Windows gives the VPN adapter a lower metric (higher priority) than your physical adapter, so even with split tunneling configured, all traffic goes to the VPN.

MTU Mismatch

VPN encapsulation adds 50-100 bytes of overhead. If MTU isn’t adjusted, large packets get silently dropped, making internet appear broken while small requests work intermittently.

Corporate Proxy Required

Company requires all internet traffic through an authenticated proxy only reachable via VPN. Without proxy config in browsers, internet looks completely broken.

Prerequisites & Tools

Access needed: Local administrator rights, ability to connect/disconnect VPN, access to Command Prompt or PowerShell.

Tools: ipconfig/ifconfig, nslookup/dig, ping, tracert/traceroute, route print (Windows) / netstat -rn (macOS/Linux), Event Viewer, Wireshark (optional).

Step-by-Step Troubleshooting

Step 1: Verify VPN Connection Status

# Check active network adapters
Get-NetAdapter | Where-Object {$_.Status -eq "Up"} | Select-Object Name, InterfaceDescription, Status

You should see both physical and VPN adapters showing “Up.” If VPN shows connected but internet fails, the issue is routing or configuration — not the tunnel itself.

Step 2: Test Connectivity to External IPs (Do This First)

# Test Google DNS
ping 8.8.8.8 -n 4

# Test Cloudflare DNS
ping 1.1.1.1 -n 4

If ping succeeds → problem is DNS only (go to Step 7). If ping fails → routing or firewall issue (continue to Step 4).

Step 3: Check DNS Resolution

# Test resolving google.com
nslookup google.com

# Test with Cloudflare DNS directly
nslookup google.com 1.1.1.1

# Check current DNS servers
ipconfig /all | findstr /i "DNS Server"

Step 4: Examine Routing Table

# View routing table (Windows)
route print -4

# macOS/Linux
netstat -rn

Look for the default route (0.0.0.0). A VPN route with metric 1 vs. local internet at metric 25 means all traffic goes through VPN.

Step 5: Check Adapter Metric Values

# Check current metrics
Get-NetIPInterface | Select-Object InterfaceAlias, AddressFamily, InterfaceMetric | Sort-Object InterfaceMetric

# Increase VPN adapter metric to give physical adapter priority
Set-NetIPInterface -InterfaceAlias "Cisco AnyConnect VPN Adapter" -InterfaceMetric 50

Step 6: Configure Split Tunneling (If Allowed)

# For Windows built-in VPN: route only corporate network through VPN
Add-VpnConnectionRoute -ConnectionName "YourVPNName" -DestinationPrefix "10.0.0.0/8" -PassThru

Step 7: Manually Set DNS Servers

Go to Network Connections (ncpa.cpl) → right-click physical adapter → Properties → IPv4 → set DNS to 1.1.1.1 (primary) and 8.8.8.8 (alternate). Or via PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","8.8.8.8")
ipconfig /flushdns

Step 8: Disable IPv6 on VPN Adapter

Disable-NetAdapterBinding -Name "Cisco AnyConnect VPN Adapter" -ComponentID ms_tcpip6

Step 9: Check for Corporate Proxy Requirements

netsh winhttp show proxy

# Set proxy if required
netsh winhttp set proxy proxy.company.com:8080

Step 10: Fix MTU Size

# Test current MTU (should succeed at 1472)
ping 8.8.8.8 -f -l 1472

# If it fails, reduce MTU on VPN adapter
netsh interface ipv4 set subinterface "Cisco AnyConnect VPN Adapter" mtu=1400 store=persistent

Step 11: Check Firewall (Temporary Test)

# Temporarily disable — re-enable immediately after testing!
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
ping 8.8.8.8
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

Step 12: Reset Network Stack (Last Resort)

# Run as Administrator
netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew
shutdown /r /t 0

Advanced Diagnostics

Wireshark capture: Select physical adapter → filter ip.dst == 8.8.8.8 → start capture → ping 8.8.8.8. Look for: no packets (routing issue), TCP RST packets (connection reset), ICMP Destination Unreachable.

VPN logs: Cisco AnyConnect logs at C:ProgramDataCiscoCisco AnyConnect Secure Mobility ClientLogs. Windows VPN: Event Viewer → Windows Logs → System, filter by “RasClient” or “RemoteAccess.”

Real-World Scenario

Situation: A 200-person financial services firm deployed a new Cisco AnyConnect configuration in full tunnel mode. All remote users immediately lost internet access — they could reach internal resources but not Office 365, Salesforce, or any external websites.

Root Cause: Full tunnel was enabled without configuring internet breakout on the corporate firewall. Internal DNS servers had no forwarders for external domains.

Immediate workaround: Users manually set Cloudflare DNS (1.1.1.1) on their physical adapters and increased VPN adapter metric to 50.

Permanent fix: Re-enabled split tunneling (only 10.0.0.0/8 and 172.16.0.0/12 through VPN), configured DNS forwarders to 1.1.1.1, deployed settings via Group Policy.

Result: All 200 users back online within 2 hours. Zero VPN internet complaints in the following 90 days.

Prevention & Best Practices

For network administrators: Use split tunneling to route only corporate subnets through VPN. Configure internal DNS with forwarders to 1.1.1.1 or 8.8.8.8 for unknown domains. If full tunnel is required, ensure the corporate firewall provides internet breakout with sufficient bandwidth. Monitor VPN connection success rates and DNS failure rates.

For end users: Run ping 8.8.8.8 first to determine if it’s DNS or routing. Restart the computer (not just VPN) before calling IT. Keep VPN client software updated.

Frequently Asked Questions

Why does internet stop working only when VPN connects?

The VPN client modifies your routing table to send all traffic through the tunnel. If the VPN server doesn’t provide internet breakout or if its DNS can’t resolve external names, all internet requests fail. This is the standard behavior of full-tunnel VPN without proper infrastructure.

Can split tunneling fix this?

Yes — split tunneling routes only corporate traffic through the VPN while internet traffic goes directly through your local connection. It’s the cleanest solution, though many organizations disable it for compliance reasons.

How do I tell if it’s DNS or routing?

Ping 8.8.8.8 (an IP address, not a hostname). If it succeeds, your routing works but DNS is broken — fix DNS. If it fails with “Request timed out,” you have a routing problem.

Will changing the VPN adapter metric break my VPN?

No. The tunnel stays connected and functional. Changing the metric only affects which adapter handles which traffic. Some VPN clients reset the metric on reconnection — you may need to reapply the setting.

Conclusion

Start with the two-minute test: ping 8.8.8.8. If it succeeds, set public DNS on your physical adapter. If it fails, check routing and adapter metrics, then configure split tunneling or raise the issue with your IT team as a network architecture problem. Full-tunnel VPN without internet breakout is an infrastructure issue that no amount of client-side fixes can permanently solve.

For related challenges, see our guides on Azure VPN Gateway troubleshooting and RDP connectivity issues.

Professional Consulting Services

Need help diagnosing or redesigning your VPN architecture? I provide enterprise VPN troubleshooting, split tunneling configuration, and network optimization services worldwide.

Contact: itexpert@navedalam.com | WhatsApp: +92 311 935 8005 | Free 30-minute consultation

About the Author

Naveed Alam is a Network & Cloud Engineer with 8+ years of experience in enterprise networking, VPN infrastructure (Cisco, Fortinet, Azure), and Windows Server administration. CCNA, AZ-900, and CompTIA A+ certified.

Connect on LinkedIn