Troubleshooting
Mac VPN Causing Issues? Here's How to Diagnose and Fix
VPN on Mac breaking your internet, slowing connections, or refusing to disconnect cleanly? Here's how to diagnose and fix it on Sonoma and Sequoia.
You connect to your VPN, suddenly Slack can’t load, Spotify cuts out, and websites take 20 seconds to open. Or you disconnected the VPN an hour ago, but DNS is still routing through some old configuration. Or the VPN client crashed and left your Mac with no internet at all until you rebooted.
VPN issues on Mac are a special category because they touch the lowest layers of the network stack — system extensions, packet filters, DNS resolvers, and routing tables. When something goes wrong, the visible symptom is rarely the actual cause.
Here’s how to diagnose and fix the common cases on macOS Sonoma 14 and Sequoia 15.
Step 1: Identify which VPN is misbehaving
If you have multiple VPNs installed (work, personal, a free one you tried last year), they fight. List what’s loaded:
systemextensionsctl list
You’ll see entries for every system extension installed, including network filters from VPNs. Each has a team identifier, a bundle ID, and an “activated” or “user-level” status.
Check what configurations exist:
scutil --nc list
This shows network configurations (VPN, VLAN, etc.) by name. You’ll see your active VPN connections.
Also check System Settings → VPN. Disable any you’re not actively using.
Step 2: Test internet without VPN
Disconnect the VPN. Open Terminal:
ping 1.1.1.1
ping cloudflare.com
Both should work. If they don’t, the issue isn’t the VPN itself — it’s stuck routing/DNS state from when the VPN was connected. That’s common after an uncleanly-disconnected VPN.
Fix the routing:
sudo route -n flush
Reboot if that doesn’t help.
Step 3: Check the routing table
netstat -rn | head -30
Look for the “default” gateway. After a clean VPN disconnect, the default route should point to your local router (192.168.x.x typically). If it’s pointing to a 10.x.x.x address from your VPN, the VPN didn’t unhook cleanly.
Some VPN clients install routing rules they fail to remove on disconnect. Force removal:
sudo route delete default
sudo route -n flush
Or, more cleanly, toggle the network connection: Wi-Fi off → on. macOS rebuilds the routing table.
Step 4: Check DNS post-VPN
After VPN disconnect, DNS sometimes stays pointed at the VPN’s resolver, which is now unreachable. Symptoms: hostname lookups fail, but ping 1.1.1.1 works.
scutil --dns | head
Look at the first resolver’s nameservers. If they’re a 10.x.x.x or VPN-tunnel address, that’s the problem.
System Settings → Network → Wi-Fi → Details → DNS. Manually add 1.1.1.1 and 8.8.8.8 if no entries are there. Apply.
Also flush:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Step 5: Disconnect and reconnect cleanly
Most VPN clients have a clean disconnect option. Use it instead of force-quitting:
- NordVPN, ExpressVPN, Mullvad: click Disconnect in the app.
- Cisco AnyConnect: status icon → Disconnect.
- Built-in macOS VPN: System Settings → Network → click VPN → Disconnect.
If the client crashed and the VPN session is “stuck connected” in the OS but the client thinks it’s disconnected:
sudo scutil --nc stop "VPN Service Name"
This force-stops a VPN at the macOS level even if the client is unresponsive.
Step 6: Disable kill switch features temporarily
Most modern VPNs have a “kill switch” that blocks all traffic if the VPN drops, to prevent leaks. If the kill switch malfunctions, you have no internet until you toggle it off in the VPN client’s settings.
If the VPN client itself is unresponsive but the kill switch is active, the cleanest path is to fully quit the VPN client:
killall <VPN-app-name>
Then disable the kill switch in settings before reconnecting.
Step 7: Check for leftover system extensions
This is the most common source of “phantom VPN issues.” A VPN you uninstalled months ago left its network extension loaded. Even with no VPN client running, the extension intercepts traffic and slows or breaks connections.
systemextensionsctl list
Look for extensions whose parent app is no longer installed.
Removing them properly requires systemextensionsctl uninstall with the right team and bundle IDs:
systemextensionsctl uninstall <team-id> <bundle-id>
In practice, this is finicky. The cleaner approach is to use a thorough uninstaller that handles system extensions, configuration profiles, keychain entries, and launch agents in one pass. Sweep’s app uninstaller does this — it’s specifically useful for VPN cleanup, where drag-to-trash leaves the most cruft.
Step 8: Check for orphaned configurations
System Settings → VPN. If you see configurations for VPNs whose apps are gone, they’re orphans. Click each → minus button → remove.
Also check System Settings → Privacy & Security → Profiles. Configuration profiles can install VPN settings that survive app removal. Remove any that came from VPNs you no longer use.
Step 9: Check the keychain
VPN credentials live in Keychain. After uninstall, leftover keychain items occasionally cause new VPNs to fail on connect because they conflict with the old auth.
Open Keychain Access → search for the old VPN’s name → delete entries.
Step 10: Diagnose VPN slowness
If your VPN is connected but slow:
- Wrong server: try a closer geographic location. Most VPN clients let you choose.
- Protocol mismatch: WireGuard is fastest, OpenVPN UDP next, OpenVPN TCP slowest. If your client lets you pick, go WireGuard.
- Server load: switch to a less-busy server.
- MTU issues: VPNs sometimes default to MTU 1500 when 1420 is needed. Most clients have an MTU setting.
Run a speed test with VPN off, then on. If VPN-off is 200 Mbps and VPN-on is 12 Mbps, you have a serious tunnel issue. Most VPNs should incur 10-30% overhead, not 90%.
Step 11: Check for split tunneling
Some VPNs let you exempt specific apps or destinations from the tunnel. If split tunneling is configured oddly, certain apps appear broken because they’re going through the VPN unexpectedly, or vice versa.
VPN client → Settings → Split Tunneling. Confirm it’s set how you expect.
Step 12: Check for DNS leak
Even with the VPN connected, if your DNS queries go through your ISP, your privacy is compromised. Test:
Visit dnsleaktest.com while connected. If you see your ISP’s DNS servers, you have a leak.
Fix:
- VPN client settings → “Block DNS outside the tunnel.”
- Or manually set DNS to the VPN provider’s resolver in System Settings → Network → Wi-Fi → Details → DNS.
Step 13: Check the firewall
System Settings → Network → Firewall. If “Block all incoming connections” is on, some VPN protocols (especially split-tunnel and reconnect logic) fail.
If you use Little Snitch or LuLu, look for rules that block your VPN client’s processes. Allow them.
Step 14: Test with a different VPN client
If a specific VPN provider always misbehaves, test with the built-in macOS VPN:
System Settings → Network → click “VPN” header → Add VPN Configuration → enter the provider’s IKEv2 details (most providers publish them).
If the built-in client works but the third-party client doesn’t, the third-party client is the issue. If both fail, the VPN provider is the issue.
Step 15: When you’ve truly tried everything
Last-resort steps:
- Sign out of any VPN that uses cloud sync (NordVPN, ExpressVPN, Surfshark).
- Uninstall the VPN client completely (use Sweep for the leftover cleanup).
- Restart the Mac.
- Reinstall the VPN fresh.
- Reconfigure.
This is the cleanest reset. Any leftover state from past installs is gone, and you’re starting from a known-good baseline.
Why VPNs are so hard to fully remove
Compared to most apps, VPNs install:
- A system extension (network filter or VPN provider).
- A configuration profile.
- Keychain entries for credentials.
- Launch agents (
~/Library/LaunchAgents/) for auto-launch. - Login items.
- DNS configuration changes.
- Routing table entries.
- Sometimes kernel extensions on Intel Macs.
Drag-to-trash uninstalls remove only the .app bundle. The other six artifacts stick around indefinitely.
The most common “VPN issues on Mac” complaint I see is from people whose problem is a leftover from a VPN they uninstalled six months ago, not the VPN they’re using today. Cleaning the cruft from old VPNs typically fixes new VPNs that “won’t behave.”