Mac VPN Connected but Internet or DNS Fails
A VPN can report 'connected' while websites, internal applications or local network devices still fail. The connection status confirms that the VPN client established its own session; it does not guarantee that all destinations are reachable through the configured routes and DNS policy.
Identify exactly what stopped working
Test three destinations separately: an ordinary public website, a resource that should be reachable through the VPN, and a device on your local network if local access is permitted by policy. Repeat the tests after disconnecting the VPN, where permitted. Write down which combination works; that pattern is more useful than the generic message 'VPN broken.'
Understand split tunnel versus full tunnel
A full-tunnel configuration normally sends general traffic through the VPN, subject to policy and implementation. A split tunnel sends only selected destinations through the VPN and leaves other traffic on the usual connection. Either design can be correct. If public websites work but the internal service fails, examine the routes, internal DNS and access rules for that resource. If internal services work but public websites fail, examine whether the VPN is intended to carry public traffic and whether its DNS, gateway and security rules permit it. Do not presume that every VPN should provide internet breakout.
DNS can fail even when the tunnel is up
Private service names may require DNS servers or search domains available only inside the VPN. A lookup failure is different from a route or firewall failure. Review DNS servers and search domains under System Settings > Network > [network service] > Details > DNS, but remember that VPN applications and management profiles can dynamically influence DNS. Public DNS is not automatically a replacement for a private resolver.
Check software and policy
Some VPN and endpoint-security products install network extensions or filters. If failures started after an update or profile change, record the product, version and time of the change. On a managed Mac, ask the administrator to check VPN DNS, split-tunnel routes, firewall policies and the configured network extensions. Do not remove an organization's security profile or disable a filter simply to make a page load.
Read-only Terminal checks
These commands inspect the local state. They do not change the VPN configuration. The outputs can contain local network information; review them before sharing.
scutil --dnsroute -n get defaultnetworksetup -listallnetworkservicesscutil --dns: shows resolver configuration visible to the system; interpretation can be more complex than one global resolver.route -n get default: inspects the IPv4 default route, but does NOT prove all VPN routes or policy-routing behavior; a split-tunnel VPN can add more-specific routes.networksetup -listallnetworkservices: enumerates network services; it does not enumerate every VPN client's actual dynamic routing state.
What the symptoms suggest
| Symptom | Area to investigate | Next check |
|---|---|---|
| Public sites fail, internal works | Full-tunnel egress/policy or DNS issue | Check intended design and gateway |
| Internal site fails by name only | Internal DNS/search domains | Check VPN DNS profile |
| One internal subnet fails, others work | Missing route or access policy | Check precise subnet and policy |
| Local printers stop working | Split-tunnel/local-access policy | Confirm whether local LAN access is allowed |
| All connections fail only with VPN | VPN/filter interference | Compare connection with permitted VPN-off test |
What not to change first
Avoid switching off the macOS firewall, deleting system files, blindly replacing DNS with 8.8.8.8 or forcing all traffic outside the tunnel. These steps can conceal the fault or violate an organization’s access policy. Start with the intended VPN design and the actual failed destinations.