Why a VPN Can Look Connected While Nothing Works

Your client reports connected while the interface sits up and the browser times out, and none of those three statements is false. Connected describes a layer that has nothing to do with the page you asked for. Deciding which layer is reporting takes one fresh request and one look at the counter that would prove traffic moved. A restart throws that evidence away and rebuilds the conditions you were trying to observe.

Three Different Things Called Connected

At the bottom, connected can mean a client process is running and holding a socket toward a peer. Above that it can mean an interface exists with an address, which a persistent device or a recovery routine can create with no live session behind it. At the control level it can mean an association was negotiated, which says nothing about whether a single packet has crossed under it. Each of those survives failures the others do not, and a client usually displays the strongest one it can claim.

A green icon and a dead tunnel are therefore compatible rather than contradictory; they report on different objects. That is the whole reason this failure keeps getting misdiagnosed as a client bug.

Send one harmless request to a destination you actually need before touching the daemon, and keep the required direct-traffic block in place while you work. A restart erases the ordering of events and then recreates them closely enough to hide the cause, which is why the same ticket returns a week later with nothing new in it. One request, one counter reading and the trigger that produced the failure are the minimum evidence.

Which Counter Proves the Packets Moved

In IPsec the IKE association and the CHILD association are separate objects, and only the child carries the counters that answer this question. List the child, watch whether packets increase in both directions, and compare that with what the application is trying to do. An installed association at zero is a different finding from one incrementing while the application still fails; the first means traffic is not being selected, the second means it is moving and the fault is further along. Read the counters twice, a few seconds apart, because one sample cannot show a trend.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Zero counters point at selection: routing, policy, a namespace the packet left from, or an interface the client never bound. Growing counters point away from the tunnel, so continue with forwarding at the far end, name resolution, the return path and the destination service, in that order. A protocol without a separate child object exposes the same evidence in its own terms, so use whatever it reports for peer state and packet counts rather than borrowing the IPsec vocabulary. The shape of the reading matters more than the tool that produced it.

Where the Fault Sits After the Counters Move

A gateway answering on its own management address proves the gateway runs, not that anything behind it serves your request, so test the far side rather than the box in the middle. Name resolution hides failures best, because a resolver that cannot be reached through the tunnel times out in a way that looks identical to a dead connection. Two lookups separate those cases, and both are cheap. Ask the resolver the tunnel pushes first, then ask a public resolver for the same name.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

A name that resolves through the public resolver but not through the tunnel resolver means the DNS path is broken, while a name that resolves through both and still times out in the browser points at the return path or at the service. If the ping by address succeeds and the application still refuses, the network delivered the request and the service rejected it, which is a later stage entirely.

Record the Trigger, Then Change One Thing

Record what preceded the failure: a stretch of idleness, a network change, a key renewal, a resumed laptop, or a restored system. Those produce different mechanisms, and only the restored system usually repairs itself, which is exactly the case that teaches you nothing. A restart removes the ordering of events and then recreates conditions close enough to hide the cause. Write the trigger down while it is still reproducible.

Then make one supported correction and repeat the original request together with the trigger that produced the failure. Idleness is the easiest trigger to reproduce, so it is the fastest confirmation that the fix addressed the mechanism rather than the symptom.

What you want to report is proof that the traffic you meant to send reached the service you meant to reach. An icon that turns green, a cached page that loads, and a counter that moves all prove less than one completed request against the intended destination. Keep the request, the counter reading and the trigger together, so the next person can tell a fix from a coincidence.