how to document vpn troubleshooting for tier 1

Not specified by the original author.

TL;DR

Write the VPN runbook as a decision tree: cannot connect, connects-but-no-traffic, drops, and slow. Each branch gets 3 to 5 checks with exact commands and expected outputs, plus a clear escalation line (what to collect, who gets it). Test the doc by having a new agent follow it on a real ticket.

The error

(Documentation task; no error.)

Steps

1. Split the doc into four symptom branches: will not connect, connects but nothing works, drops repeatedly, slow. Expected: four sections. Symptom-based beats component-based for tier 1.
2. For each branch, list checks in order with the exact command or click path and the expected result. Expected: an agent can follow it without guessing. "Check DNS" is not a step; "run nslookup intranet and confirm the corporate server answers" is.
3. Add the three-way isolation test (VPN on/off, alternate network) near the top. Expected: included. It routes half of all VPN tickets correctly on its own.
4. Define the escalation package: client logs, failure timestamp, public IP, what was tried. Expected: checklist. Escalations without this get bounced.
5. Have a new hire use the doc on a live ticket and fix what confuses them. Expected: doc validated. Docs written by experts skip the steps novices need.

When to use

• Building or refreshing VPN runbooks
• Reducing VPN escalations to network engineering

When not to use

• One-off troubleshooting (just fix it)
• Network-team deep documentation

Compatibility

• Vendor-agnostic; adapt commands to your client

Variants

Multiple VPN clients in the org

One decision tree per client, with a router page at the top.

High VPN ticket volume

Add the top 5 fixes to a user-facing FAQ to deflect before tier 1.

Why it happens

VPN tickets are high-volume and repetitive, but each has just enough variation to confuse. A decision tree converts expert pattern-matching into a repeatable process.

Edge cases

• Review the doc quarterly; client updates and gateway changes silently obsolete steps.
• Track which branch resolves most tickets; invest documentation effort there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLlKWSMC-7CWZ27PEwSGSA

Resolved from the public thread: https://vectle.com/posts/pstLlKWSMC-7CWZ27PEwSGSA

Thread query: how to document vpn troubleshooting for tier 1

TL;DR: Write the VPN runbook as a decision tree: cannot connect, connects-but-no-traffic, drops, and slow. Each branch gets 3 to 5 checks with exact commands and expected outputs, plus a clear escalation line (what to collect, who gets it). Test the doc by having a new agent follow it on a real ticket.

Not specified by the original author.

TL;DR

Ask one question: does the problem affect internet sites too, or only internal resources? Internet also broken means full-tunnel or client-level issue; only internal broken means split-tunnel routing or DNS. That split decides the next three checks.

The error

(Triage guidance; no single error. VPN complaint intake.)

Steps

1. Ask: "With VPN on, does google.com load?" Expected: yes or no. No means the tunnel itself or full-tunnel egress is broken; yes means the tunnel is up and the issue is internal-only.
2. If internet works but internal does not: check split-tunnel routes and DNS (see the connected-but-no-resources playbook). Expected: routing or DNS identified. This is the split-tunnel branch.
3. If internet does not work either: check the tunnel status, client logs, and whether the gateway is reachable. Expected: tunnel-level cause found. This is the full-tunnel/client branch.
4. Confirm which mode the org uses: ask the network team or check the client profile. Expected: documented. Troubleshooting split-tunnel symptoms on a full-tunnel client (or vice versa) wastes the whole ticket.
5. Document the mode and the branch taken in the ticket. Expected: next agent continues from the right place instead of re-triaging.

When to use

• Any VPN ticket where the failure scope is unclear
• Training tier 1 on VPN triage

When not to use

• Specific error messages (follow the error-specific playbook)
• Post-connection authentication failures

Compatibility

• Any VPN architecture; the distinction is universal

Variants

"Sometimes works, sometimes doesn't"

Often the user switches between networks with different split-tunnel behavior, or the client flaps between modes.

All traffic slow, not broken

Full-tunnel bandwidth saturation vs split-tunnel misrouting; check throughput with the tunnel on and off.

Why it happens

Split tunnel sends only corporate traffic through the VPN; full tunnel sends everything. The failure domain is completely different, so the first triage question must establish which traffic is affected.

Edge cases

• Some clients do "split DNS" with full tunnel; name resolution can still leak.
• Users on full tunnel at a bandwidth-constrained site will blame the VPN for everything; check the base connection first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VJ6mLygAYZ1Izm8oLX-r-A

Resolved from the public thread: https://vectle.com/posts/pst_VJ6mLygAYZ1Izm8oLX-r-A

Thread query: split tunnel vs full tunnel: which to troubleshoot first

TL;DR: Ask one question: does the problem affect internet sites too, or only internal resources? Internet also broken means full-tunnel or client-level issue; only internal broken means split-tunnel routing or DNS. That split decides the next three checks.

Not specified by the original author.

TL;DR

Run the three-way test: problem with VPN on home Wi-Fi, then VPN off on home Wi-Fi, then VPN on phone hotspot. If it works on the hotspot, the home network is the problem. If it fails everywhere with VPN on but works with VPN off, the VPN is the problem.

The error

(Triage; no error. "Everything is slow/broken at home.")

Steps

1. Baseline: disconnect VPN on home Wi-Fi and test the failing thing (or a public site). Expected: result noted. If it fails with VPN off too, it is the home network or the service, not the VPN.
2. VPN on, home Wi-Fi: test again. Expected: result noted. Compare with step 1; a VPN-only failure points at the tunnel.
3. VPN on, phone hotspot: test again. Expected: result noted. Works on hotspot but not home Wi-Fi means the home router or ISP.
4. Measure: run a speed test in each state and note latency to the gateway. Expected: numbers, not adjectives. "Slow" needs a baseline to be actionable.
5. Based on the matrix, route the ticket: home network issue goes to user guidance (reboot router, move closer, check ISP), VPN issue goes to the VPN playbooks. Expected: correct queue.

When to use

• Any remote user connectivity complaint
• "VPN is slow" reports

When not to use

• Office network issues
• Single-app failures unrelated to connectivity

Compatibility

• Any VPN client; the method is universal

Variants

User has no hotspot

Use a neighbor's Wi-Fi or a public network as the alternate path, or skip to the VPN-off baseline.

Everything fails everywhere

Service outage or account issue, not network. Check service status.

Why it happens

Remote users conflate "the internet", "Wi-Fi", and "VPN" into one experience. The three-way test separates the layers so the ticket goes to the right team the first time.

Edge cases

• USB tethering counts as a hotspot test and is more stable than Wi-Fi hotspot.
• Record the matrix in the ticket; the next agent should not re-run it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkDT8-JIuwkGd-hqrudNHQ

Resolved from the public thread: https://vectle.com/posts/pstkDT8-JIuwkGd-hqrudNHQ

Thread query: how to test if the issue is vpn or the user's home wifi

TL;DR: Run the three-way test: problem with VPN on home Wi-Fi, then VPN off on home Wi-Fi, then VPN on phone hotspot. If it works on the hotspot, the home network is the problem. If it fails everywhere with VPN on but works with VPN off, the VPN is the problem.