Let Telemetry Diagnose Slow VPN Sessions First

#The Old Way: Twenty Minutes of Twenty Questions

Every remote-work Monday brings the same flood: dozens of tickets titled some variation of “VPN is slow” or “can’t get anything done, connection is dragging.” The old way of handling this is painfully manual. A technician opens the ticket, reads a one-line description with zero diagnostic detail, and starts the interrogation: What’s your ping? Can you run a tracert? What client version are you on? Is it slow for everyone in your office, or just you? Are you on Wi-Fi or ethernet? Have you tried restarting the client?

Each question adds a reply-wait cycle. The user is at lunch, or in a meeting, or simply doesn’t know how to run a tracert. Twenty minutes becomes an hour. Multiply that by forty tickets during a regional ISP hiccup or a gateway under load, and an entire shift disappears into the same repetitive diagnostic script that a machine could run in under three seconds.

#Why “My VPN Is Slow” Is the Perfect Ticket to Automate

This ticket type is high-volume, low-variance, and almost entirely diagnosable from telemetry the endpoint already has access to: latency to the gateway, jitter, packet loss, CPU and memory load, DNS resolution time, split-tunnel configuration, and which regional gateway the client is authenticated against. None of that requires a human conversation. It requires instrumentation, classification, and — in the majority of cases — a scripted fix that takes less time to run than it takes to type “have you tried restarting it?”

The goal isn’t to build a smarter helpdesk agent who asks better questions faster. The goal is to remove the questions entirely by capturing the answers before the ticket exists.

#Step One: Instrument the Endpoint, Not the Technician

The first engineering move is a lightweight telemetry collector that runs the moment a user reports (or a monitoring agent detects) VPN degradation. This can be triggered by a Self-Service Portal button labelled “My VPN Feels Slow” instead of a free-text ticket field. That button runs a script, not a form.

1# Collect-VPNTelemetry.ps1
2$gateway = (Get-VpnConnection).ServerAddress
3$latency = Test-Connection -ComputerName $gateway -Count 4 | 
4    Measure-Object -Property ResponseTime -Average
5$dnsTime = Measure-Command { Resolve-DnsName portal.internal.corp } 
6$adapter = Get-NetAdapter | Where-Object {$_.Name -match 'VPN|PPP'}
7$splitTunnel = (Get-VpnConnection).SplitTunneling
8$cpuLoad = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue
9
10$payload = @{
11    userId       = $env:USERNAME
12    deviceId     = (Get-CimInstance Win32_ComputerSystemProduct).UUID
13    gatewayIp    = $gateway
14    avgLatencyMs = [math]::Round($latency.Average,1)
15    dnsTimeMs    = [math]::Round($dnsTime.TotalMilliseconds,1)
16    adapterUp    = $adapter.Status
17    splitTunnel  = $splitTunnel
18    cpuPercent   = [math]::Round($cpuLoad,1)
19    timestamp    = (Get-Date).ToString('o')
20}
21
22Invoke-RestMethod -Uri "https://ai-triage.internal.corp/webhook/vpn" 
23    -Method Post -Body ($payload | ConvertTo-Json) -ContentType 'application/json'

This runs in under two seconds and captures everything a technician would have spent fifteen minutes asking for. No ticket has been logged yet — the data arrives before the complaint does.

#Step Two: Route Telemetry Through an AI Classification Webhook

The webhook receiving this payload doesn’t need a technician on the other end. It needs a lightweight classification layer that scores the telemetry against known root-cause patterns and returns a confidence-rated diagnosis. This can be a fine-tuned small model, a rules engine, or an LLM call constrained to a fixed set of categories — the important part is that it returns structured, actionable JSON, not prose.

1// Incoming payload example
2{
3  "userId": "j.harrow",
4  "deviceId": "a3f9-...",
5  "gatewayIp": "10.20.4.11",
6  "avgLatencyMs": 340,
7  "dnsTimeMs": 890,
8  "adapterUp": "Up",
9  "splitTunnel": false,
10  "cpuPercent": 12,
11  "timestamp": "2025-03-11T09:14:02Z"
12}
13
14// Classifier response
15{
16  "diagnosis": "DNS_RESOLUTION_BOTTLENECK",
17  "confidence": 0.94,
18  "recommendedAction": "FLUSH_DNS_AND_REBIND",
19  "escalate": false,
20  "reasoning": "DNS time 890ms exceeds 200ms threshold while latency and CPU are nominal"
21}

Note the structure: a diagnosis code, a confidence score, a specific recommended action, and an explicit escalate flag. This is the contract between the AI layer and the automation layer — no ambiguity, no need for a human to interpret a paragraph of AI-generated text under time pressure.

#Step Three: Build the Decision Logic — Self-Heal or Escalate

Confidence score drives everything downstream. High confidence on a known, low-risk fix triggers immediate self-healing with no human in the loop. Medium confidence creates a ticket that arrives at L1 already diagnosed, with the fix suggested but not auto-applied. Low confidence, or any diagnosis tagged as infrastructure-side (gateway overload, regional outage), escalates straight to L3 with the raw telemetry attached, skipping L1 entirely.

1{
2  "rules": [
3    { "confidence_gte": 0.90, "risk": "low",  "action": "AUTO_REMEDIATE" },
4    { "confidence_gte": 0.70, "risk": "low",  "action": "CREATE_TICKET_PREFILLED" },
5    { "confidence_gte": 0.00, "risk": "any",  "diagnosis": "GATEWAY_SATURATION", "action": "ESCALATE_L3" },
6    { "confidence_lt": 0.70, "action": "CREATE_TICKET_UNSCORED" }
7  ]
8}

The rule set is deliberately simple and version-controlled like any other piece of infrastructure. When a new failure mode appears — say, a firmware bug on a specific VPN client build — you add a rule and a remediation script rather than retraining an entire model from scratch.

#Step Four: Automate the Remediation Actions

Each recommended action maps to a pre-approved script sitting in your RMM tool. These aren’t experimental — they’re the same fixes a competent technician would run, just executed instantly and consistently.

1# Remediate-DNSBottleneck.ps1
2ipconfig /flushdns
3Stop-Service -Name Dnscache -Force
4Start-Service -Name Dnscache
5Restart-NetAdapter -Name "VPN Adapter" -Confirm:$false
6
7# Verify fix
8$check = Measure-Command { Resolve-DnsName portal.internal.corp }
9if ($check.TotalMilliseconds -lt 200) {
10    Write-Output "REMEDIATION_SUCCESS"
11} else {
12    Write-Output "REMEDIATION_FAILED_ESCALATE"
13}

The script self-verifies. If the fix didn’t hold, it doesn’t quietly close the loop and leave the user annoyed — it flips the outcome flag to escalate, and the ticket that eventually reaches a technician includes both the original telemetry and the fact that an automated remediation was already attempted and failed. That single detail alone saves a technician from repeating the first diagnostic step.

#Step Five: Close the Loop Without a Human Touch

Once remediation succeeds, the system notifies the user directly — via Teams, Slack, or email — and logs a closed, informational ticket for audit purposes. No queue entry, no SLA clock started, no technician touch.

1{
2  "channel": "teams-dm",
3  "recipient": "j.harrow@corp.com",
4  "message": "We noticed your VPN connection was slow due to a DNS resolution issue and fixed it automatically. If you're still experiencing slowness, reply here to open a ticket with a technician.",
5  "ticketRef": "AUTO-88213",
6  "status": "resolved_automated"
7}

The reply-to-open-ticket fallback matters. Automation should never trap a user with no human escalation path — it just moves that path to be the exception rather than the default.

#Step Six: Feed the Loop — Continuous Learning

Every auto-remediation attempt, successful or not, gets logged with its outcome. This becomes the training set for tightening confidence thresholds and catching new failure patterns. If “REMEDIATION_FAILED_ESCALATE” starts appearing frequently for a specific diagnosis code, that’s a signal the underlying rule or script needs revision, not that the AI layer is untrustworthy.

1{
2  "diagnosis": "DNS_RESOLUTION_BOTTLENECK",
3  "attempts": 214,
4  "successRate": 0.91,
5  "avgResolutionSeconds": 4.2,
6  "escalatedAfterFailure": 19
7}

Review this weekly. A 91% success rate on 214 attempts means 195 tickets never touched a queue. That’s the number to put in front of management when justifying the engineering time spent building this.

#What This Means for Your Queue

Before this pipeline existed, a mid-size organisation might log 60 to 100 “VPN slow” tickets a week during peak remote periods, each consuming 15 to 40 minutes of technician time for diagnosis alone, before any actual fix. After deployment, the overwhelming majority resolve in under five seconds with zero human involvement, and the tickets that do reach a technician arrive pre-diagnosed with root cause, confidence score, and failed remediation attempts already attached. The technician’s job shifts from detective to specialist — dealing only with the genuinely unusual cases that the automation correctly identified as needing a human.

#Handing Control Back to L1: When to Override the Bot

Automation like this needs a visible kill switch. Technicians should be able to see, in real time, which users had an automated remediation attempted, what action was taken, and whether it succeeded — ideally in the same dashboard used for manual tickets. If a technician spots a pattern the classifier is missing (a new client version behaving oddly, for instance), they should be able to flag the diagnosis as incorrect directly from the ticket, which feeds back into the training set. The technician isn’t replaced by this system; they become the person who tunes the system’s judgement over time, catching edge cases the confidence thresholds haven’t learned yet.

The measure of success here isn’t a flashy AI headline. It’s a queue that’s quieter on Monday morning because the fifteen-minute interrogation ritual has been replaced by a script that already knew the answer before the user finished typing the ticket title.