Why Always On VPN Stops Triggering on the Office Network

The laptop joins the office Wi-Fi, and the Always On profile that connected from home stays down. Nothing in the event log calls it a failure, because from the client's point of view the network is trusted and the tunnel is unnecessary. Trusted network detection is the feature making that decision, and it compares specific values rather than recognising a familiar SSID. When the decision is wrong, you need to see which comparison passed.

What the trigger actually compares

Three things have to line up before the client treats a network as trusted. First, the connection-specific DNS suffix Windows records for the physical adapter must appear on the suffix list in the profile. Second, the connection profile Windows holds for that network has to be the one the policy expects, because the match is against that profile rather than against a name a user typed into a wireless dialog. Third, the network has to be classified the way the policy requires, which in practice means a domain or private network, or a device whose policy arrived through management. Drop any one and the trigger fires.

That is a narrower test than comparing the VPN's public exit address, and much narrower than trusting an SSID. An access point echoing the corporate name does not satisfy the suffix and profile comparisons on its own. It also means the feature says nothing about whether a network is safe; it says whether this device believes it is already home.

Read the current state before changing the profile

Start with what Windows currently believes. The connection profile cmdlet reports the network name, the interface and the category Windows assigned, which is the third comparison above. Then read the VPN profile and look for the trusted suffix list, using a full property dump instead of guessing at property names:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

If that dump does not expose the trusted suffix on your build, fall back to the profile XML, which is the authoritative copy when the property surface differs between versions. Read the XML from the management policy or from the all-user profile store, and compare its suffix entries against the adapter suffix reported above. Record both values before touching either one.

Test the boundary in both directions

Test on the intended corporate attachment and on one other approved network, and write down whether the tunnel came up. Then test the same device after leaving. A laptop that triggers at home and suppresses at the office is behaving as designed, while one that never triggers anywhere has a different fault. Check that resources behind the tunnel are reachable in the triggered case, because a started tunnel is not proof of a working path.

Do not add a broad suffix just to make a notification disappear. A suffix that appears on many networks teaches the client to suppress the tunnel almost everywhere, and the support load that follows is worse than the notification. Change the criteria through the profile owner, which on a managed fleet is the MDM administrator rather than the person at the laptop.

Keep both test networks in the record alongside the result. A boundary that was never tested is only a claim.

Separate suppression from blocking

A tunnel that was not started is not a blocked connection. Trusted network detection controls the automatic trigger, while traffic filtering and kill-switch behaviour are separate policy settings with their own failure modes. A device on a trusted network may legitimately send traffic outside the tunnel, and calling that a leak without reading the policy confuses two designs. Check the profile's traffic rules before blaming detection for a leak.

The same distinction explains the reverse complaint. Users who report that the VPN stopped randomly are usually describing a network change that satisfied the criteria, not a service failure. The matched suffix and the network category are the evidence to collect, and both appear in the output above.

Collect that evidence before changing policy. A toggle that hides the symptom also hides the cause.

Record what the decision was based on

Write the matched suffix, the connection profile name and the network category into the deployment notes for each site. When the tunnel does not come up, that record turns a mystery into a comparison: either one of the three values changed, or the policy did. It also gives the next engineer a way to confirm the design instead of disabling detection to close the ticket.

Review the suffix list when a site is renamed or a domain is consolidated, because a stale entry keeps suppressing the tunnel silently. Microsoft's trusted network detection reference lists the profile elements and the deployment prerequisites, and it is the document to quote when somebody proposes widening the list.