Device tunnel or user tunnel in Windows Always On VPN?

A laptop that needs to reach a management server from the sign-in screen and a laptop that needs to reach file shares after the user authenticates are two different problems. Windows solves them with two different tunnels, and the difference is not which one appears in the profile list. The device tunnel runs as the machine, before anyone signs in. The user tunnel runs as the person, after the platform has an identity to work with. Choosing between them starts with the moment the traffic must flow, not with the resources it must reach.

Two identities, two moments

The device tunnel establishes in machine context, which is why it can carry the traffic needed to authenticate a user or to let management agents check in before logon. The user tunnel establishes in user context, after sign-in, with the user's credentials and the policy that applies to that account.

That timing difference is the whole design. Everything else follows from it, including which authentication methods are available and which resources make sense.

If the requirement is a line-of-business application used by a signed-in person, the user tunnel answers it. If the requirement is a domain controller, a certificate authority or a management service reachable from the logon screen, only the device tunnel is early enough.

The phone book is not the distinction

Saving a native profile into the all-user phone book does not create a device tunnel. The profile becomes available to every user on the machine, which is a storage scope question, and it still connects in user context.

A real device tunnel is configured as one, with the platform, protocol and certificate requirements that Microsoft documents for it. Those requirements include an edition that supports it, a domain-joined device, IKEv2 and machine certificate authentication. A profile named device, copied from a user tunnel and renamed, satisfies none of that.

Microsoft's device tunnel documentation is the reference for the profile shape, and it is worth reading before assuming a working user profile can be reused.

Keep each path narrow

The device tunnel should reach only what the machine needs before logon: the directory, the certificate authority, the management endpoint and the DNS records that resolve them. Its routes and firewall rules should reflect that short list rather than the full corporate range.

The user tunnel carries the person's access and can be scoped by group, application or destination as the deployment requires. Mixing the two scopes is how a pre-logon tunnel ends up with file-share access that no machine account should ever have.

Both tunnels can be deployed together, and in most Always On designs they are. The device tunnel comes up first and stays narrow. The user tunnel comes up at sign-in and carries the working traffic. If you deploy only one, decide which failure you can live with. A logon screen with no network and a user tunnel carrying management traffic are both bad, but only one of them is usually acceptable in your environment.

Test the stage, not the browser

A working browser request after logon proves the user tunnel and says nothing about the device tunnel. Test the stages separately: cold start to the logon screen, logon itself, the user connection, and recovery after sleep or a network change.

At the logon screen, the check is whether the machine can reach the management endpoint with no user signed in. That is the only moment the device tunnel exists on its own, and it is the stage people skip because testing it requires a reboot.

After sign-in, check the user tunnel separately, including the case where the device tunnel is up but the user tunnel failed. Two tunnels with two states produce four combinations, and only one of them looks healthy.

When it fails, name the tunnel first

Machine certificate renewal and user account recovery are different tasks with different owners. A device tunnel that fails after a certificate expires will not be fixed by resetting the user's credentials, and a user tunnel that fails after a password change will not be fixed by reissuing the machine certificate.

Record which tunnel was active, which identity it used and which stage failed, then compare that with the documented requirements for the edition and management environment in use. Copying an old generic VPN wizard is how deployments end up with a device tunnel that only works for administrators.

Order of work: name the moment traffic must flow, choose the tunnel that exists at that moment, narrow its routes, test each lifecycle stage separately, and keep the two identities' recovery procedures apart.