Always On VPN Is Not LAN Access: A Resource Checklist

Always On is a connection lifecycle: the profile connects at sign-in or before it, and reconnects without the user pressing anything. It is not a statement that every private destination, protocol and user is allowed. The practical question is which resources the deployed profile actually delivers, and that answer needs a per-resource check rather than a look at the Connected badge.

Step 1: Write the resource down before testing it

Start with one small record per application. The record is a planning note, not profile XML, and the values must come from the real environment: name, destination prefix, service and port, tunnel role, identity group and resolver path.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

The record forces four separate questions. A route decides where the address goes. DNS policy decides how the client learns the address. A traffic filter decides whether that traffic may use the connection. The destination's own firewall and application permissions decide whether the request is accepted. None of the four is implied by a connected tunnel.

Step 2: Establish which tunnel should carry it

Windows Always On VPN has a device tunnel and a user tunnel, and they are configured as separate profiles with separate certificates and separate scopes. A device tunnel usually provides only the infrastructure needed before anyone signs in, such as management and domain services. Broad employee application access normally belongs to the user tunnel.

Traffic filters are a device-tunnel feature, which is why Microsoft's device-tunnel example uses them for management traffic. Copying that example into a general resource-access profile gives you a tunnel that connects but carries the wrong set. Confirm which connection is active in Get-VpnConnection, and test the resource under that connection rather than under whichever one happens to be up.

Step 3: Verify the route for the real address

Resolve the application name once, then check the route for that address: Find-NetRoute -RemoteIPAddress 10.20.5.10 reports the chosen interface, next hop and source address. If the interface is the physical adapter, the prefix is not in the tunnel's route set, or the client excluded it through split tunnelling. Compare with the profile definition instead of adding a local route in front of it.

A local route add can make the test pass and disappear at the next policy refresh, which is why the change belongs in the managed profile. Check both the user and device profile definitions for the prefix, and check the split-tunnel setting: a full-tunnel profile should not need a per-prefix route, and a split-tunnel profile needs one for every private prefix it must carry.

Step 4: Test private name resolution separately

Private names are a policy path of their own. The profile can deliver NRPT rules and a DNS suffix search list, and those rules apply while the tunnel is connected. Read what the client actually received with Get-DnsClientNrptPolicy, then test a name and an address in the same session. Names that fail while addresses work point at the resolver path; both failing points at the route.

A name can also resolve to an address that is outside the tunnel's routes, which produces a confusing mix of success and timeout. Compare the returned address with the prefix in your record. If they differ, the private zone is answering with a public or alternate address, and the route that matched is not the one you designed.

Step 5: Check filters, identity and the application's own gate

Traffic filters restrict which protocols and ports may use the device tunnel, and an empty or narrow filter set can block a resource that the route would otherwise carry. On the identity side, the profile assigns the connection to a group, and the resource has its own authorization. A user who can connect is not automatically a user the file server accepts.

Change the managed profile through its owner, whether that is Intune, a ProfileXML deployment or a script the operations team maintains. Then retest after a normal reconnect and after a reboot, because the failure mode you are checking is often a stale local route or a profile that only applied once. Keep the profile version next to the test result; that pair is what makes the next change safer.