The notification area shows no internet, the private application keeps working, and someone wants to change the VPN profile until the icon behaves. Three different observations are being collapsed into one, and only one of them is about the tunnel. Separating them keeps an icon problem from turning into an unnecessary profile change.

Name the observation first, then decide whether anything actually needs repairing.

Three Observations, Three Questions

The Windows connectivity indicator answers what the system's detection process established for the current network profile. The VPN client's status answers whether that client reports an established peer session. A fresh application operation answers whether one specific request worked through the path it took. Each is a legitimate result and none of them substitutes for the others. Collapsing them produces a repair aimed at the wrong layer.

The classic confusion is treating the first as a summary of the other two. A machine can hold a healthy tunnel with working private resources and still be classified as having no internet, because the classification comes from a probe that never reached its service.

Get-NetConnectionProfile
Get-DnsClientServerAddress -AddressFamily IPv4
Test-NetConnection -ComputerName internal.example -Port 443

Write the three results down with a timestamp before touching anything. Most of these reports resolve at that step, because the disagreement becomes obvious once it is written out.

What the Classification Process Actually Does

Microsoft's NCSI overview describes active probing with HTTP requests to a configured probe service, combined with passive observation of network traffic. A failure to obtain the expected response can come from routing, a proxy or another environmental condition on that path. It is more specific than a general reachability test, and narrower than people assume. That narrowness is the whole reason the disagreement appears.

What it never audits is encryption, resolver privacy or whether an application is authorized. A positive classification does not prove that every application uses the tunnel, and a negative one does not prove the tunnel is down.

The reverse confusion is equally common. A tunnel can be established while the application it was built for has no usable route, no working resolver or no permission. The client indicator reports an earlier, narrower result than the one you need.

The Disagreement Itself Tells You What to Fix

Private access works and the system says there is no internet: the failing component is the probe path, not the tunnel. Record the interface and the time, then have the network owner look at how the probe reaches its service and whether policy blocks it. Replacing a working private-access profile with a broad internet route changes an icon and widens access you did not ask to widen.

The tunnel reports connected and fresh requests to required services fail: that is a real failure, and calling the icon a false alarm skips it. Compare the application error, the profile's intended scope, the resolver in use and the selected routes. A private-only tunnel is not designed to supply a public internet exit, and expecting one is a scope error rather than a defect.

Keep the Record, Change One Path

Use a fresh operation in the relevant application instead of a page that has been open since this morning. Keep required blocking active, and make any permitted direct comparison through the client's documented controls rather than by editing routes by hand.

If a managed proxy or firewall blocks the intended probe, correct that specific path with its owner. Microsoft's guidance cautions against disabling active probing as the remedy, and a hard-coded address exception or a registry edit is not an explanation of which component's answer is wrong.

After the change, keep all three results in the ticket: classification, session state and application outcome. If only the icon moved, you have learned that an indicator changed, not that the database or site works now.

Sɛbɛn minnu bɛ tali kɛ