VPN Down for Remote Workers: A Diagnostic Checklist

The remote team can't connect. The VPN client throws an error, or worse, connects but routes nothing. The office is fine; the remote workers are stranded. The MD wants to know how long.

VPN failures look identical from the user's side regardless of cause, but the root issues fall into a small number of categories — internet, certificate, authentication, routing, licence. Walk them in order and you'll find it inside 30 minutes. This guide gives the systematic checklist a senior engineer would run, with vendor-specific notes for the four common business VPN platforms in the UK SMB market: Fortinet FortiGate, Cisco Meraki, SonicWall, WatchGuard, plus Microsoft Always-On VPN.

If your remote team is offline now and you need this resolved today, call 01923 372471 — senior engineer answers directly and we respond quickly.

Step 1: Define the failure precisely

The user said "the VPN doesn't work". Translate that into one of these:

The "what changed" question is the highest-yield. VPN doesn't usually break by itself.

Step 2: Quick checks before deep diving

Before opening the firewall logs:

[ ] Is the firewall reachable from the public internet on the VPN's port?
    Test: from a phone on mobile data, https://<public-ip>:<port> or
    nc -vz <public-ip> <port>
[ ] Is the firewall's ISP up?  Check the public IP from a different network.
[ ] Is the firewall's certificate still valid?  Browse to the SSL VPN portal
    URL — browser cert warning means the cert has expired or doesn't match
    the hostname users are connecting to.
[ ] Has the firewall recently been updated, or had a config change?
    Most VPN failures correlate to a change within the last 48 hours.
[ ] Does the VPN client itself need an update?  Some vendors bump minimum
    client versions silently — old clients then fail on next reconnect.
[ ] Is licensing in date?  SSL VPN, Mobile/Client VPN, or User-based licences
    expire and stop working without warning unless monitored.

Two of these — certificate expiry and licence expiry — account for a disproportionate share of "the VPN died overnight" calls. Check them first.

Step 3: SSL VPN — Fortinet FortiGate

By far the most common SMB business VPN in the UK.

Common errors

• Error 7200 / 7211 / 7203 — TLS / certificate handshake failure on the client. Almost always a server-side certificate issue, an unsupported client version, or TLS version mismatch. FortiGate dropping support for TLS 1.0/1.1 by default in recent FortiOS versions broke a lot of legacy clients overnight.
• Error 1503 (license/user limit) — Maximum SSL VPN user reached. SSL VPN has a per-model concurrent user limit. Check diagnose vpn ssl statistics on the firewall.
• Stuck at 40% / "Connecting" — usually port unreachable, firewall rule, or the SSL VPN service is bound to the wrong interface.

Diagnostics on the firewall (CLI)

diagnose vpn ssl list                  # Active sessions
diagnose vpn ssl statistics            # User count, peak, errors
diagnose debug enable
diagnose debug application sslvpn -1
# attempt connection from client; observe; then:
diagnose debug disable

Read the debug output for the specific error. The FortiGate is verbose; the answer is in the log if you let it run long enough.

CVE warning

FortiGate SSL VPN has had a string of high-severity CVEs over the past few years. If your FortiGate is running a FortiOS version more than a few months old and exposes SSL VPN to the public internet, assume it is being actively scanned and probe-attacked. Patch to a supported version; rotate any local-firewall account passwords; check Log & Report > Forward Traffic for unusual outbound connections; review User & Authentication > User Definition for accounts you don't recognise.

Step 3 (continued): Meraki Client VPN

Meraki's Client VPN uses L2TP/IPsec by default — a protocol that's been in slow decline industry-wide.

Common errors

• Error 789 / 809 (Windows L2TP) — IPsec couldn't negotiate. Check the pre-shared key on the client matches the MX, check that UDP 500 and 4500 (and IP protocol 50 — ESP) are open inbound at the ISP/upstream, and that the client isn't behind a NAT that mangles IPsec.
• Authentication fails despite correct credentials — Meraki Client VPN supports Active Directory, RADIUS, or Meraki cloud auth. AD auth in particular has a chequered history; users with & in their UPN, expired passwords with cached creds, and certain UPN formats fail intermittently.
• MX has reset; client connects but no traffic — split-tunnel config, or the LAN subnet on the MX overlaps with the client's home network.

Where to look in the dashboard

Security & SD-WAN > Monitor > VPN status shows current connections. Security & SD-WAN > Monitor > Event log for connection attempts and errors. Network-wide > Configure > General for the time zone (Meraki logs everything in network-local time).

Modernisation note

Meraki has been promoting AnyConnect VPN as the replacement for L2TP/IPsec Client VPN. AnyConnect is a paid add-on (per-user licence) but is materially more reliable, supports SAML auth, and works on platforms (modern macOS, mobile) where L2TP has been deprecated. If you're rebuilding a Meraki VPN, AnyConnect is the path forward.

Step 3 (continued): SonicWall NetExtender / Mobile Connect

SonicWall has two clients — NetExtender (Windows, full SSL VPN) and Mobile Connect (mobile, lighter).

Common errors

• "The connection to the SonicWall is broken" — usually port closed, certificate, or service stopped. Check the SSL VPN service is running on the SonicWall (System > Services or SSL VPN > Server Settings).
• NetExtender connects but doesn't route — split-tunnel routes not pushed. Check SSL VPN > Client Routes — the LAN subnet must be there.
• Recent firmware update broke the client — SonicWall has occasionally shipped firmware updates that broke older NetExtender clients without an obvious version bump on the client side. Update the client.

CVE warning

SonicWall has had several severe SSL VPN CVEs (CVE-2024-40766, others). If the SonicWall hasn't been patched recently, patch immediately. Keep the management interface off the public internet.

Step 3 (continued): WatchGuard SSL VPN / Mobile VPN with SSL

Common errors

• Could not download configuration / 4002 — the SSL VPN configuration profile didn't download. Usually a TLS version mismatch (newer Fireware enforces TLS 1.2+), or the client is being intercepted by a TLS-decrypting upstream (corporate proxy or some hotel Wi-Fi captive portals).
• Client downloads config, fails to authenticate — RADIUS / AD auth issue, or the user is not in the SSL VPN group on the WatchGuard.
• Connects but shows different inside IP than expected — check the address pool isn't exhausted (a small /24 pool runs out fast as connection counts grow).

Diagnostics

WatchGuard's web UI is fine for reviewing connections (System Status > Mobile VPN); the CLI is where the proper logs live (logfile show -f -t /var/log/sslvpnd.log from a system-management SSH session).

Step 4: Always-On VPN (Microsoft AOVPN)

The Windows-native option. More moving parts than vendor SSL VPN clients, more places to break.

Components in play

1. Client side: the VPN profile (deployed via Intune, GPO, or PowerShell), the device certificate (machine tunnel) or user certificate (user tunnel), and Windows' RasMan service.
2. Server side: RRAS or VPN Gateway (Azure VPN Gateway, third-party VPN concentrator), NPS for RADIUS auth, AD CS for certificate issuance.
3. Network: UDP 500/4500 (IPsec) or TCP 443 (SSTP), inbound to the VPN concentrator's public IP.

Common errors

• 0x80092013 — the certificate has expired or has been revoked. Check the device cert on the client, the RRAS server cert, and the issuing CA's CRL.
• 0x80072746 / 0x800704D4 — connection forcibly closed. Network reachability or NPS auth failure.
• 0x800B0109 — root CA chain not trusted. The device doesn't trust the VPN server's certificate, often because the Enterprise Root cert isn't pushed to non-domain devices.
• Profile won't apply via Intune — common cause is the EAP XML being malformed (every escaped quote and ampersand matters), or the certificate issuance not having completed before the profile applies.

Server-side diagnostics

# On the RRAS server:
Get-RemoteAccess
Get-VpnConnection
Get-NetIPInterface | Where-Object InterfaceAlias -like "*VPN*"
Get-Service RemoteAccess, RaMgmtSvc

# Logs:
Get-EventLog -LogName "Application" -Source "Routing and Remote Access" -Newest 50

# NPS auth events:
Get-EventLog -LogName "Security" | Where-Object {$_.EventID -in 6272,6273,6274,6278} | Select-Object -First 20

NPS Event 6273 (Network Policy Server denied access) gives the explicit reason in the event detail — wrong network policy match, certificate issue, account state. Read the reason; don't guess.

Client-side diagnostics

# Check the profile is present and configured
Get-VpnConnection -AllUserConnection
Get-VpnConnection -AllUserConnection | Get-VpnConnectionTrigger

# Check the certificate is present and valid
Get-ChildItem Cert:\LocalMachine\My  # for machine tunnel
Get-ChildItem Cert:\CurrentUser\My   # for user tunnel

# Real-time diagnostic
Set-VpnConnection -Name "<Profile>" -Force -Verbose
rasdial "<Profile>"   # Tries to connect, gives error

The Windows event log under Microsoft-Windows-NetworkProfile and RasClient has the granular failure detail.

RDP Shortpath note

If you're running AVD or RDS over Always-On VPN and getting poor performance, RDP Shortpath needs UDP 3390 reachable end-to-end with proper QoS. Misconfigured AD Sites and Services topology — a remote subnet not associated with the right site, or no site at all — is a leading cause of slow AVD over VPN even when the tunnel itself is healthy.

Step 5: Routing and DNS once connected

Connection succeeds, but the user can't reach anything internal. Diagnose:

# On the connected client:
ipconfig /all                       # confirm VPN adapter, IP, DNS, suffix
route print                         # what subnets is the VPN routing?
Test-NetConnection -ComputerName <internal-server> -Port 445
Test-NetConnection -ComputerName <internal-server> -InformationLevel Detailed
nslookup <internal-server>          # is DNS resolving internally?

Common findings:

• VPN adapter has no DNS suffix → user can't resolve server but can resolve server.corp.local. Fix on the firewall / VPN profile to push the search domain.
• VPN routes only the public subnet, not the internal subnet → split-tunnel config wrong.
• Client subnet overlaps with the LAN subnet → home network is 192.168.1.0/24, office LAN is 192.168.1.0/24, no traffic flows. Common with small offices using default ranges. Fix: change the office (or VPN client) subnet to something less generic — 10.x.y.0/24 or 172.20.x.0/24.
• MTU issues → ping -f -l 1300 <internal-server> to test. If small pings work and large ones don't, MTU is the issue. Lower MTU on the VPN adapter (1380 is a safe starting point for IPsec).

Step 6: When all users are affected

Treat as an outage of the VPN service itself, not user-side issues.

1. Check the firewall is up and reachable on its public IP.
2. Check the firewall hasn't received an automatic firmware update overnight that broke things.
3. Check the certificate isn't expired (browse to the SSL VPN portal URL).
4. Check the licence isn't expired (vendor admin portal).
5. Check the public IP hasn't changed (ISP changes are surprisingly common; DNS still points at the old IP).
6. Check authentication backend — RADIUS server up, AD reachable, NPS service running.

A surprisingly high portion of "VPN totally down for everyone" calls are actually "AD is down" or "the certificate expired this morning" — fix those and the VPN comes back without further work.

What NOT to do

• Don't reset every user's password to "fix" VPN auth. Almost never the cause.
• Don't reinstall the VPN client on every endpoint as a first response. The 1% it fixes don't justify the 99% you've burnt time on.
• Don't disable MFA to "test" — you've now removed a security control and you'll forget to put it back.
• Don't open the VPN management interface to the public internet as a "temporary" remediation. This is how the next breach starts.

Prevention

• Monitor certificate expiry. A certificate expiry calendar review every 90 days. Or better, automated monitoring (Uptime Kuma, PRTG, Nagios) with alerts at 30 / 14 / 7 days out.
• Monitor licence expiry. Same approach.
• Document the recovery procedure with the steps specific to your VPN vendor, in a place that doesn't depend on the VPN being up to read it.
• Patch firewalls on a scheduled cadence. Firewall vendors ship security fixes; SSL VPN appliances are routinely on the public internet and routinely targeted.
• Audit accounts quarterly. Local firewall admin accounts, VPN-only user accounts, RADIUS/NPS access policies. Disable what isn't being used.
• Move from L2TP/PPTP to SSL VPN or AnyConnect-style modern protocols. L2TP is increasingly fragile on modern OSs, increasingly blocked by carrier-grade NAT, and lacks the logging visibility to diagnose properly.
• Test failover. If you have HA firewalls, fail them over once a quarter — at a planned time, not when the primary dies for real.

When to call us

Call us if:

• Your VPN is down and you've exhausted vendor documentation.
• A firewall update has broken connectivity and rolling back isn't trivial.
• You're seeing intermittent VPN failures that don't correlate with user behaviour.
• You suspect the firewall has been targeted (failed login bursts, unusual destinations in egress logs).
• You need a VPN architecture review — moving from L2TP to AnyConnect-class, designing AOVPN, or sizing a new VPN concentrator.

Engineerdirect.co.uk has senior engineers across Fortinet, Meraki, SonicWall, WatchGuard, Cisco IOS and Microsoft RRAS / AOVPN. On-site response across London and the South East within 2 hours.

Call 01923 372471 — senior engineer answers directly, no call queues.

FAQ

My VPN connects but my home and office are on the same subnet — what do I do? Change the office subnet to something less common. 192.168.1.0/24 and 192.168.0.0/24 are the most-used home network subnets in the UK; if your office uses one of these, every staff member with a BT/Sky/Virgin router has the conflict. 10.10.10.0/24 or 172.20.5.0/24 avoid the collision.

Why is my VPN slow even on a fast connection? Three common causes: MTU issues (large packets fragmented or dropped), full-tunnel config sending all traffic to the office (saturating its WAN), or the VPN appliance is encryption-bottlenecked (older boxes max out at 50–100 Mbps regardless of internet speed). Test with iPerf inside and outside the tunnel.

Should I move from VPN to ZTNA / Zero Trust? For most SMBs, eventually yes. The main candidates: Cloudflare Access, Microsoft Entra Private Access, Cisco Duo Network Gateway, Tailscale. ZTNA replaces the "trust everyone on the VPN" model with per-application access. Migration is a project, not a quick switch — but the result is materially better security and usually better performance.

A user reports their VPN drops every 8 hours. Is that normal? Possibly — many VPNs default to a session lifetime of 8 hours (or 1 hour for IKEv2 IPsec child SAs). If reauth is automatic and seamless, fine. If users have to enter credentials again, look at session-persistence config and refresh-token handling.

Can I run my SSL VPN on a non-standard port to "hide" it? You can run on a non-standard port; you can't hide it. Port-scanning the public IPv4 space is cheap. What matters is patching, MFA, account hygiene, and limiting authentication attempts. Custom ports add user friction without adding security.

My firewall says SSL VPN concurrent user limit hit, but we don't have that many users. Stale sessions. Disconnected clients sometimes leave sessions open until session timeout. Reduce idle timeout (SSL VPN > Settings), and on FortiGate diagnose vpn ssl list and clear specific stale sessions if needed. If the count is genuinely high, check the model's licensed user count — concurrent SSL VPN users is a per-model limit.

If your remote workforce is offline and you need it fixed today, that is what our emergency network & VPN support covers.

Part of a series of disaster-recovery references. If your remote workforce is offline right now: 01923 372471.

References

Vendor documentation and security guidance behind this guide:

• Fortinet Document Library
• Cisco Meraki Documentation
• SonicWall Support
• NCSC — Virtual Private Networks (VPNs)