Why Does Little Snitch Still List the Browser Under a VPN?

You turn the VPN on, open Little Snitch, and the browser is right there with a connection to a site you thought was tunnelled. That entry is not evidence of a leak on its own. A local monitor reports which process opened a socket on this machine, and the browser did open it; the VPN client is a second process that picks those packets up afterwards. Both statements are true at the same time, and the display is showing you the first one.

What a local monitor can and cannot attribute

Attribution happens at the socket. The kernel knows which process owns a connection, so Little Snitch can label an entry with the application name with high confidence. What it does not see by default is the outer connection the VPN builds around that traffic, because that belongs to a different process.

Domain names are a weaker signal than they look. For an HTTPS connection the name may come from a DNS lookup, from the server name offered during the handshake, or from a reverse lookup of the address, depending on what the system observed. None of that requires decrypting the page, and none of it proves where the bytes went afterwards.

So the browser entry answers who, not where. Treat it as attribution data and get the where from a different view.

Step one: start from an empty window instead of scrolling history

Old entries cannot tell you what the current configuration does. Switch the time filter to From Now, or press Command-K, so the window shows only connections that appear after that moment.

Then do exactly one harmless thing in the application you are investigating, such as loading a page you are allowed to load. One action, one moment, so the entries that appear can be tied to it without guesswork. Wait a second or two after it completes, because a page load produces a burst of connections rather than a single one. Reading the list while it is still filling guarantees that you will misjudge the order.

Before you read the result, check whether a search field or a status filter is narrowing the list. A filter left over from an earlier session is the most common reason a connection appears to be missing when it is only hidden, and it is also why two people looking at the same machine disagree about what is happening.

Step two: include extension connections to see the tunnel itself

The VPN client on a current macOS release is usually a network extension rather than an ordinary app. Turn on Show Network Extensions in the Monitor and the connections that extension makes become visible alongside everything else.

Now the two layers can be read together. The browser is the origin of the request, and the extension is the transport that carries it. Seeing both is normal and expected; seeing only the extension usually means the view is filtered, while seeing only the application usually means the extension view is off.

Neither view alone inventories the whole path. Routing rules, DNS behaviour, and any per-app exceptions live outside the connection list, so a complete answer needs those checked separately.

Step three: tell a real direct connection from a display effect

If you suspect a specific destination is going out directly, name that destination and check it on its own. Look at the VPN client's own routing and blocking configuration for that host or app, and confirm whether it is supposed to be excluded.

What you should not do is block every visible browser entry in response. The browser still has to make its connections, and blocking them in the monitor does not redirect them into the tunnel; it only stops them. That turns a diagnostic question into an outage. If a rule seems necessary, scope it to the one destination you can justify, with a note about why it exists.

The same caution applies to the domain column. A name that surprises you may be a shared hostname, a content delivery endpoint, or a lookup that happened before the tunnel came up, and treating it as proof of a leak leads to rules that break working traffic.

Step four: keep the view and the rule separate

Every change in this exercise alters what the monitor displays. None of it alters what the firewall allows, and none of it moves traffic into or out of the tunnel.

When you are done, put the filters back to a state you can explain, so the next person opening the window is not reading a view you left behind. If the question was whether a destination is tunnelled, answer it from the routing and exclusion settings, then use the monitor to confirm the result rather than to guess at it.