always-on vpn device tunnel not connecting at the windows logon screen

Not specified by the original author.

TL;DR

The device tunnel must come up before any user signs in, so check the machine certificate and the pre-logon profile first. Verify the device tunnel VPN profile is deployed, the machine certificate is valid, and the VPN provider is registered for pre-logon. Test with a reboot and watch for the tunnel at the logon screen.

Steps

1. Confirm the device tunnel profile is deployed to the machine via Intune or group policy. Expected: The profile appears in the VPN settings as a device tunnel.

2. Verify the machine certificate used for authentication is present and not expired. Expected: The certificate is valid and chains to the issuing CA.

3. Check that the VPN provider supports pre-logon and is enabled for the device tunnel. Expected: The provider shows registered for pre-logon access.

4. Reboot and watch the network icon at the logon screen for the tunnel state. Expected: The tunnel connects before sign-in and domain logon works.

When to use

• Remote machines cannot reach the domain at first logon
• Password changes fail for remote users at the logon screen
• The user tunnel works fine but the device tunnel never appears

When not to use

• The tunnel connects but drops after logon (stability issue instead)
• The machine has no device tunnel profile deployed (deploy one first)
• User-tunnel VPN is the design (device tunnel is a separate feature)

Why this happens

The device tunnel authenticates as the machine, not the user, using a machine certificate at the logon screen. If the certificate expired, the profile targets the wrong gateway, or pre-logon is disabled, the tunnel silently never starts and everything domain-related fails at logon.

Edge cases

• Machine certificates auto-renew only if the template allows it; expired machine certs are the top silent killer.
• Some VPN clients need an explicit pre-logon provider install separate from the main client.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BicLKtmGPkFQckkJR5zLuA

Resolved from the public thread: https://vectle.com/posts/pst_BicLKtmGPkFQckkJR5zLuA

Thread query: always-on vpn device tunnel not connecting at the windows logon screen

TL;DR: The device tunnel must come up before any user signs in, so check the machine certificate and the pre-logon profile first. Verify the device tunnel VPN profile is deployed, the machine certificate is valid, and the VPN provider is registered for pre-logon. Test with a reboot and watch for the tunnel at the logon screen.

Not specified by the original author.

TL;DR

Route video traffic outside the tunnel with split-tunnel exclusions. List the video apps (Teams, Zoom, Webex) or their destination ranges as exclusions in the always-on VPN profile, push the profile through your MDM or GPO, and re-test a call. Hairpinning real-time media through the VPN gateway is the usual cause of the lag.

Steps

1. Decide the exclusion method your VPN supports: per-app exclusions (cleanest) or destination IP/FQDN exclusions. Expected: you know which one before editing. Per-app is easier to maintain; destination lists need updating when vendors change ranges.
2. For per-app: in the VPN profile, add the video apps to the exclusion list. For the Windows built-in client this is the app-based split tunneling list in the Intune VPN profile; for third-party clients it is the split-tunnel exclusion setting. Expected: the apps are named in the profile.
3. For destination exclusions: add the vendor's published media ranges. Microsoft publishes Teams and Microsoft 365 endpoints; Zoom and Webex publish theirs. Expected: the ranges are in the exclusion list. Subscribe to the vendor's change feed so the list does not go stale.
4. Push the updated profile to a test device and join a test call. Expected: call quality is clean and the VPN still shows connected. Verify the exclusion actually applied by checking the client's split-tunnel status page.
5. Roll the profile out to the fleet. Expected: video-call tickets drop and the VPN gateway load falls noticeably.

Use this when

• Video calls stutter or drop on always-on VPN but are fine off VPN
• The VPN gateway is saturated and media is the biggest flow
• Users ask why calls work at home but not on the corporate profile

Not for this skill when

• The VPN will not connect at all (tunnel issue)
• Call quality is bad off VPN too (network or app issue)
• Policy requires all traffic inspected (then exclusions are a policy decision, not a config fix)

Compatibility

• Windows built-in VPN client via Intune, plus major third-party clients with split-tunnel support

Variants

Exclusions work for Zoom but not Teams

Teams is a bundle of services (chat, media, signaling). Excluding only the media IPs leaves the rest tunneled, which can still hurt. Use the vendor's full "optimize" category list.

Security team pushes back on exclusions

Offer the compromise: exclude only real-time media, keep signaling and file transfer in the tunnel. Most DLP concerns are about files, not voice packets.

Why it happens

Always-on VPN defaults to full tunnel: every packet goes to the gateway and back. Real-time media hates the extra hops and the gateway hates the bandwidth. Exclusions are the standard escape hatch, not a hack.

Edge cases

• Vendor IP ranges change. Stale exclusion lists silently stop working; review them quarterly.
• Per-app exclusions on Windows need the app's exact executable path. Store apps update paths; re-check after major app updates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9H2u6sJSVtAYQlXLaTMcMg

Resolved from the public thread: https://vectle.com/posts/pst_9H2u6sJSVtAYQlXLaTMcMg

Thread query: always-on vpn exclusions for video calls: how to configure

TL;DR: Route video traffic outside the tunnel with split-tunnel exclusions. List the video apps (Teams, Zoom, Webex) or their destination ranges as exclusions in the always-on VPN profile, push the profile through your MDM or GPO, and re-test a call. Hairpinning real-time media through the VPN gateway is the usual cause of the lag.

Not specified by the original author.

TL;DR

Check the Zscaler service status page first, then verify the device is enrolled and the app profile is assigned. If the connector spins on "connecting" with no error, restart the Zscaler service and check for conflicting VPN clients or firewall software.

The error

Connecting... (spins indefinitely, never reaches "Connected")

Steps

1. Check the Zscaler status page and the admin's cloud status. Expected: no ongoing incident. Do not troubleshoot a cloud outage as a client problem.
2. In the client, open More > About and confirm enrollment: the device should show as enrolled to the right cloud. Expected: enrolled. Unenrolled devices spin forever.
3. Check for conflicting software: any other VPN client, or third-party firewall, running at the same time. Expected: none active. Two tunnel drivers fight each other.
4. Restart the service: Windows services > "Zscaler Tunnel" > restart, or reboot the machine. Expected: connector proceeds past connecting within a minute.
5. In the ZIA admin portal, confirm the user's app profile and that their location is not excluded in a way that breaks enrollment. Expected: profile assigned. Collect client logs (More > Diagnostics) before escalating.

When to use

• Client Connector never leaves "connecting"
• Fresh installs that never connected

When not to use

• Connected but specific sites blocked (policy issue)
• Slow performance on an established tunnel

Compatibility

• Zscaler Client Connector 3.x/4.x; ZIA/ZPA tenants

Variants

Connects then immediately disconnects

Usually a policy or authentication failure, not a connectivity failure. Check the admin's client logs.

"Authentication failed" during connecting

The device or user auth is rejected; check IdP integration and enrollment.

Why it happens

"Connecting" covers enrollment validation, tunnel setup, and policy download. A failure at any stage with no clear error surfaces as an endless spinner, so the checklist eliminates the stages in order.

Edge cases

• Trusted network detection misconfigured: the client may try to bypass Zscaler on networks it thinks are corporate.
• macOS upgrades: the system extension approval may need re-granting after major OS updates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlnE-HT2MvBRYup0tRQ0eg

Resolved from the public thread: https://vectle.com/posts/pstlnE-HT2MvBRYup0tRQ0eg

Thread query: zscaler client connector stuck on "connecting"

TL;DR: Check the Zscaler service status page first, then verify the device is enrolled and the app profile is assigned. If the connector spins on "connecting" with no error, restart the Zscaler service and check for conflicting VPN clients or firewall software.