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.

#Why Drift Happens in the First Place

Before building the remediation pipeline it is worth understanding what actually corrupts a split-tunnel profile, because the detection logic is only as good as the failure modes it anticipates. The four most common causes observed across managed fleets are Windows feature updates that reset network adapter bindings and metrics, third-party VPN or SD-WAN clients that install their own routing table entries with a lower metric and silently win the route, group policy

#Implementation Steps

1. Action: Export the current known-good VPN profile as the baseline. Run Get-VpnConnection -Name "CorpVPN" | Export-Clixml -Path "C:BaselineCorpVPN.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.
6. Action: Configure the baseline repository access policy so the SAS token or share credential used by the remediation script is scoped to read-only and rotated on the same cadence as other automation secrets.
   Expected result: Script continues functioning after rotation with no manual intervention beyond updating the stored credential reference.
   Evidence: Credential rotation log entry cross-referenced against successful remediation runs in the following cycle.
7. Action: Add a lightweight local log write (for example to C:ProgramDataVpnRemediationhistory.log) each time the remediation script runs, independent of the Intune reporting channel.
   Expected result: A local audit trail exists even if Intune reporting is delayed or unavailable.
   Evidence: Log file showing timestamped entries for each detection and remediation cycle on a sample device.

#

Detection Script (PowerShell)

1$baseline = Import-Clixml -Path "C:BaselineCorpVPN.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:BaselineCorpVPN.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. Before re-enabling the assignment, isolate the root cause by comparing the baseline XML hash against the version recorded at pilot sign-off; a silent baseline edit is the most common cause of a rollback event, since anyone with write access to the repository share can inadvertently push a stale or malformed profile that the remediation script then propagates fleet-wide on its next cycle. Treat the baseline file with the same change-control discipline as a production configuration file, including mandatory peer review before any update.

#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. Escalation should also trigger automatically if the local audit log on a device shows a gap exceeding three scheduled cycles, since this typically indicates the Intune management agent itself has stopped checking in rather than a VPN-specific fault, and no amount of profile repair will resolve an agent communication failure. In that scenario the ticket should be routed to endpoint management rather than the network team, and the routing rule should be documented in the runbook so first-line triage does not misclassify the incident.

#Change Control and Governance

Every update to the baseline XML, the detection script, or the remediation script should go through the same change advisory process as any other production automation: a named owner, a documented reason for change, a dated pilot re-run on the 15 to 25 machine test collection, and a rollback plan captured before the change is approved. Version the baseline file using a naming convention that embeds the date and a short description, for example CorpVPN_2026-03-14_split-tunnel-v3.xml, and retain at least the previous three versions in the repository so a regression can be traced to the exact change that introduced it. Assign a quarterly review of the detection thresholds themselves; route counts and DNS suffixes that were correct at initial deployment can become stale as the corporate network topology evolves, and a detection script comparing against an outdated baseline will generate false positives that erode trust in the automation and increase ticket volume rather than reducing it.

#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. Beyond raw ticket counts, track mean time to resolution for the residual tickets that do reach a technician; because the automation absorbs routine drift, the tickets that remain are disproportionately the genuinely complex cases, so resolution time per ticket may rise even as total volume falls, and reporting both figures together prevents a misleading impression that service quality has declined. It is also worth recording the proportion of remediation runs that detect drift at all; a healthy fleet on a mature baseline should see drift rates settle below 5 percent of scheduled runs once the initial wave of legacy misconfiguration has been cleared, and a sustained rise above that figure across multiple rings is itself a leading indicator worth investigating, often pointing to a newly deployed application or a Windows update ring that is systematically breaking the adapter configuration.

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. The broader lesson for any operations team maintaining this kind of automation is that the value comes not from the cleverness of the scripts themselves but from treating the baseline configuration as a governed artefact with the same rigour applied to source code, because a remediation pipeline is only trustworthy for as long as the thing it repairs towards is known to be correct.