How to check a Mac's IPv6 state after the VPN disconnects

Reach a site over IPv4 after the tunnel drops, and you have proved nothing about IPv6. macOS configures the two families separately, per network service, and a VPN client can change one without touching the other. Work the three layers in order: address configuration, route selection, then whatever policy the client installs while disconnected. Keep the access network unchanged meanwhile, or you will be comparing two different problems.

Start with the family that actually broke

A page that loads over IPv4 tells you the physical network is alive. It says nothing about whether the service has a global IPv6 address, whether the prefix is still advertised, or whether something is filtering the family. Confirm what failed before choosing a tool, because a name that resolves to an unreachable address looks identical to a name that does not resolve at all. Ask which layer answered wrongly, and write the answer down. Without that, every later step is guesswork dressed as procedure.

Keep the same Wi-Fi network and access point for the whole comparison. A café network that offered IPv6 yesterday says nothing about the one you are on now.

Read the address before the route

In System Settings, the active service's TCP/IP pane shows whether IPv6 is automatic, manual or link-local only. Compare that with what you expect, remembering that an organisation may have chosen manual configuration deliberately. Then run ifconfig and read the interface in question. A fe80:: address on its own means the interface can talk to its neighbours and nothing more, so link-local presence is not evidence of a usable path.

Also look for utun interfaces the client left behind. A stale tunnel device can hold an address and a route long after the client stopped using it. If one is there, that is a lifecycle finding for the client's owner rather than something to delete on the spot.

Read the route table for the failing destination

Ask the kernel about the destination that failed, not about the default route. route -n get 2001:db8::25 prints the interface and gateway selected for that address, and netstat -rn -f inet6 shows the whole table for comparison. A default route tells you a default exists; it does not tell you this destination uses it.

Keep DNS in its own compartment. A resolver reachable over IPv4 can still return AAAA records, so a lookup failure and a routing failure produce the same symptom in the browser.

Separate the client's block policy from a leftover

Some clients are designed to block traffic while disconnected, including the other address family, and that behaviour is a feature rather than a fault.

Find out which behaviour your client documents before treating a block as damage. scutil --dns shows the resolvers in effect per service, which is where a client-installed resolver or a scoped DNS setting becomes visible. Then check whether packet filter rules were installed and left behind. An expected block and a leftover rule need opposite responses, and only the owner's documentation separates them.

Capture evidence, then change one thing

Record the client version, the macOS version, the network service, the intended disconnected policy, and the address and route output on both sides of one connect-disconnect cycle. That record is what turns a complaint into a lifecycle problem someone can investigate. Then make a single change and measure again.

Resist the reset. Deleting virtual interfaces, flushing the route table and disabling IPv6 across the machine all destroy the state you needed to capture, and they can take unrelated configuration with them. If the client has a supported pause, repair or uninstall flow, use it, and follow the administrator's procedure where the network is managed. A machine that has already been reset gives the owner nothing to work with, and it usually reproduces the fault on the next connection.