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

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

The captive portal must be satisfied before the VPN can connect. Open a browser and complete the portal login, then let the VPN connect. If the always-on client blocks the portal page itself, use the client's captive-portal detection or temporarily allow portal bypass per policy.

The error

(Cannot connect to VPN on hotel/airport Wi-Fi; the portal page may or may not load.)

Steps

1. Open a browser and navigate to a plain HTTP site (not HTTPS). Expected: the captive portal login page appears. HTTPS sites fail silently behind portals; plain HTTP triggers the redirect.
2. Complete the portal login (room number, accept terms, etc.). Expected: portal confirms access. The VPN still cannot connect until this is done.
3. Let the VPN client retry; most detect portal completion automatically. Expected: tunnel connects within a minute.
4. If the always-on client blocks all traffic including the portal: check for a "captive portal detection" or "allow portal" setting in the client. Expected: found and enabled. Some clients pause the tunnel automatically for portals.
5. As a last resort per policy, temporarily disable always-on, satisfy the portal, reconnect VPN, then re-enable always-on. Expected: connected. Document the exception; do not leave always-on disabled.

When to use

• VPN fails specifically on hotel, airport, or conference Wi-Fi
• Portal page will not load with VPN trying to connect

When not to use

• VPN fails on all networks (general VPN issue)
• Home Wi-Fi without a portal

Compatibility

• Always-on VPN clients (GlobalProtect, AnyConnect, Zscaler); all OSes

Variants

Portal loads but VPN still fails after login

The portal may do MAC-based auth that expires, or require periodic re-auth. Re-check the portal.

Client has no portal handling

Older clients predate the feature; upgrade the client.

Why it happens

Always-on VPN tries to tunnel everything, but the portal needs untunneled HTTP to authenticate the device first. The two fight until the portal is satisfied, which requires a brief exception.

Edge cases

• Some portals block VPN protocols even after login; the user may need a different network.
• Warn traveling users about this before trips; it is the top travel VPN ticket.

Provenance

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

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

Thread query: always-on vpn fails on hotel wifi captive portal

TL;DR: The captive portal must be satisfied before the VPN can connect. Open a browser and complete the portal login, then let the VPN connect. If the always-on client blocks the portal page itself, use the client's captive-portal detection or temporarily allow portal bypass per policy.

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.