VPN, Wi-Fi & Branch Connectivity
Remote access and edge reality
Open interactive version (quiz + challenge)Real-world analogy
A VPN is a private tunnel through a public road. Wi-Fi is the parking lot attached to your building. Branch connectivity is the regional highway linking offices. If any one fails, everything inside looks broken — even though the servers are fine.
What is it?
Edge connectivity covers how users and branches reach corporate resources securely. VPN, Wi-Fi, and branch WANs together form the ‘last mile’ — and most outages users feel start here.
Real-world relevance
Hybrid users at home complain the CRM is ‘down.’ Junior checks VPN logs: authentication OK, tunnel up. ipconfig shows split tunneling left DNS pointing at the home ISP. Internal hostnames don’t resolve. Pushes DNS config correctly via group-policy/VPN client config — fixed.
Key points
- Remote-access VPN vs site-to-site VPN — Remote access: individual user device tunnels in (SSL VPN, IKEv2, WireGuard). Site-to-site: two offices connect via a permanent encrypted tunnel between routers/firewalls.
- Split tunneling — With split tunneling, only corporate traffic goes through the VPN; the rest goes direct. Saves bandwidth; raises security tradeoffs. Many regulated shops force full tunneling to enforce inspection and policy.
- Common VPN failure patterns — (1) Authentication/MFA failure, (2) blocked UDP ports, (3) route/DNS pushed incorrectly, (4) certificate expired, (5) MTU/MSS mismatch breaking large transfers, (6) client version outdated.
- Wi-Fi fundamentals — Wi-Fi failures often look like ‘everything is slow.’ Real causes: channel interference, dense devices, weak signal, captive portals, DHCP starvation, wrong PSK/802.1X, roaming issues between APs.
- Authentication on Wi-Fi — PSK (shared key) for small/home networks. 802.1X (user/device certificate or RADIUS auth) for enterprise. Enterprise networks increasingly use certificates so users aren’t typing passwords repeatedly.
- Branch connectivity — MPLS, SD-WAN, internet — MPLS: carrier-grade private circuits (reliable, expensive). SD-WAN: software-defined WAN using multiple internet links intelligently. Many enterprises now run hybrid: primary MPLS + internet failover, or pure SD-WAN.
- DNS and DHCP at the branch — Branches typically receive DNS/DHCP from a local server or hub. If WAN to HQ fails, local services should continue (split-DNS, cached AD, branch DC). Know whether your branch design is resilient or HQ-dependent.
- The golden rule of VPN support — Reproduce the issue yourself if possible. If you can’t, gather: client version, OS, connect logs, ipconfig/all after connect, nslookup of a target, ping gateway, ping internal name, ping internal IP. That evidence is half the ticket.
Code example
// VPN/Wi-Fi support triage
--- VPN troubleshooting order ---
1) Auth/MFA OK? (check client + SSO/IdP logs)
2) Tunnel up? (client status, ports 443/UDP 500/4500/WireGuard 51820)
3) Routes/DNS pushed? (ipconfig /all after connect)
4) Can ping internal IP? (L3)
5) Can resolve internal name? (DNS / split tunnel)
6) Can reach service? (L4 port check)
--- Wi-Fi triage ---
- signal strength, channel, standard (2.4/5/6 GHz)
- SSID, security (PSK or 802.1X), roaming behavior
- DHCP scope exhausted? valid lease?
- captive portal forcing re-auth?
--- Branch WAN ---
- Primary link (MPLS/ISP-A) up?
- Failover (ISP-B / SD-WAN) kicked in?
- Latency/jitter from branch to HQ DC/DNS?Line-by-line walkthrough
- 1. Edge support triage block
- 2. VPN header
- 3. Auth/MFA check
- 4. Tunnel up check
- 5. Routes/DNS pushed
- 6. Ping internal IP
- 7. Resolve internal name
- 8. Reach the service
- 9. Blank separator
- 10. Wi-Fi triage header
- 11. Signal/channel/band
- 12. Security mode
- 13. DHCP health
- 14. Captive portal
- 15. Blank separator
- 16. Branch WAN header
- 17. Primary link status
- 18. Failover status
- 19. Latency/jitter to HQ
Spot the bug
User reports: ‘VPN connects but nothing works.’
Junior reinstalls the VPN client 3 times.Need a hint?
Which ipconfig/ping/nslookup checks would reveal the real issue faster?
Show answer
After tunnel up: ipconfig /all (check DNS and default route), ping internal IP (L3), nslookup internal.host (split-tunnel DNS), Test-NetConnection internal.host -Port 443 (L4). Reinstalling without evidence wastes time; most ‘nothing works’ is DNS or routes not pushed correctly.
Explain like I'm 5
A VPN is a secret tunnel from your house to the office. Wi-Fi is how your chair connects to your own house. If either is bad, you feel like the office is broken — but the office is fine.
Fun fact
Many ‘the VPN is slow’ tickets turn out to be user Wi-Fi congestion from neighbors. A 30-second iperf test often shows the home network topping out well before the VPN ever becomes the bottleneck.
Hands-on challenge
On your own machine, connect to any VPN (corporate, personal, or a free test VPN). Before and after, run ipconfig /all and nslookup. Note DNS, default route, and assigned IP. Explain the difference.
More resources
- Windows VPN client (Microsoft Learn)
- SD-WAN overview (Cloudflare Learning)
- 802.1X for enterprise Wi-Fi (Practical Networking)