Ending VPN Split-Tunnel Break Fixes With Auto-Profile Repair

#The Old Way vs The New Way

The old way of handling broken split-tunnel VPN profiles looks like this: a remote worker cannot reach an internal file share, the technician remotes in, opens the VPN client, deletes the profile, re-imports a golden XML config from a shared drive, restarts the adapter, and prays the routing table rebuilds correctly. Multiply that by every laptop that drifted after a Windows update reset an adapter metric or a conflicting local VPN client injected its own routes. It is thirty minutes of manual routing table archaeology per incident, and it recurs weekly across a large fleet.

The new way treats a broken split-tunnel profile as a state-drift problem, not a support ticket. A scheduled remediation script compares the live routing table and VPN client configuration against a known-good baseline, rewrites the profile automatically, and reports back through your RMM or Intune proactive remediation channel before the user notices anything is wrong.

#Prerequisites and Permissions

• Endpoints enrolled in Microsoft Intune (or equivalent MDM/RMM with script deployment) with Proactive Remediations enabled.
• VPN client supports command-line profile export/import (this example uses the native Windows VPN client via PowerShell; adapt cmdlets for Cisco AnyConnect or GlobalProtect using their CLI utilities).
• A signed, version-controlled baseline profile XML stored in an access-controlled repository (Azure Blob with SAS token or an internal package share).
• Minimum role: Intune Endpoint Security Administrator or equivalent RMM script-deployment role. No local admin rights should be granted to end users.
• Test scope: pilot on a device collection of 15 to 25 machines from a single region before fleet-wide deployment.

#Implementation Steps

1. Action: Export the current known-good VPN profile as the baseline. Run Get-VpnConnection -Name "CorpVPN" | Export-Clixml -Path "C:\Baseline\CorpVPN.xml" on a healthy reference machine.
   Expected result: A clean XML file containing split-tunnel routes, DNS suffixes and authentication settings.
   Evidence: File hash recorded in your configuration repository changelog.
2. Action: Write the detection script that compares live route count and DNS suffix list against baseline values, exiting with code 1 if drift is detected.
   Expected result: Script correctly flags a deliberately broken test profile.
   Evidence: Intune Proactive Remediation detection log showing non-compliant status.
3. Action: Write the remediation script (below) and package both as an Intune Proactive Remediation pair.
   Expected result: Non-compliant devices auto-repair on the next scheduled run (default every hour).
   Evidence: Remediation output log entry VPN profile repaired: routes restored to 4, DNS suffix corrected.
4. Action: Deploy to the pilot group and monitor for 5 business days.
   Expected result: Zero new VPN routing tickets from pilot devices.
   Evidence: Ticket volume report filtered by device collection tag.
5. Action: Roll out to the full fleet in rings of 20 percent per day.
   Expected result: Steady decline in split-tunnel related tickets across each ring.
   Evidence: Weekly ticket category trend chart.

#

Detection Script (PowerShell)

1$baseline = Import-Clixml -Path "C:\Baseline\CorpVPN.xml"
2$current = Get-VpnConnection -Name "CorpVPN" -ErrorAction SilentlyContinue
3if (-not $current) { Write-Output "VPN profile missing"; exit 1 }
4$routeCount = (Get-VpnConnectionRoute -ConnectionName "CorpVPN").Count
5if ($routeCount -ne $baseline.RouteCount -or $current.DnsSuffix -ne $baseline.DnsSuffix) {
6    Write-Output "Drift detected: routes=$routeCount expected=$($baseline.RouteCount)"
7    exit 1
8} else {
9    Write-Output "VPN profile healthy"
10    exit 0
11}

#

Remediation Script (PowerShell)

1Remove-VpnConnection -Name "CorpVPN" -Force -ErrorAction SilentlyContinue
2$baseline = Import-Clixml -Path "C:\Baseline\CorpVPN.xml"
3Add-VpnConnection -Name "CorpVPN" -ServerAddress $baseline.ServerAddress -TunnelType $baseline.TunnelType -SplitTunneling -AuthenticationMethod $baseline.AuthenticationMethod -Force
4foreach ($route in $baseline.Routes) {
5    Add-VpnConnectionRoute -ConnectionName "CorpVPN" -DestinationPrefix $route -PassThru
6}
7Write-Output "VPN profile repaired: routes restored to $($baseline.Routes.Count), DNS suffix corrected"
8exit 0

#Verification and Expected Evidence

#Rollback

If the remediation script causes unintended connectivity loss, disable the Proactive Remediation assignment immediately, then push a targeted script to run Remove-VpnConnection -Name "CorpVPN" -Force followed by manual re-import of the last known-good XML from the pre-automation era. Blast radius is limited to the assigned device collection, never the full tenant, because rings are staged.

#Failure and Escalation Conditions

Wake a human technician when the same device fails remediation three consecutive cycles, when detection scripts report a missing baseline file (indicating repository access failure), or when remediation success is logged but users still report connectivity loss, which suggests a firewall or conditional access policy change unrelated to the VPN profile itself. Monitor via the Intune remediation success-rate dashboard; a drop below 90 percent success across a ring should pause further rollout.

#Measuring Ticket Deflection

Track before-and-after ticket counts tagged “VPN routing” or “split-tunnel” over a rolling four-week window. A well-tuned baseline and hourly detection cycle typically removes 70 to 85 percent of this ticket category within the first month, since most drift is caused by predictable events like Windows updates or conflicting client installs rather than genuine network faults.

Full reference material for building and testing these remediation pairs is available in Microsoft’s Intune Proactive Remediations documentation and the underlying cmdlets are documented in the VpnClient PowerShell module reference. Once this pipeline is running, split-tunnel VPN routing becomes a self-healing baseline problem rather than a recurring interrupt for the desktop team, freeing technician time for issues that genuinely need a human.