## TL;DR
"Connection reset by peer" on FortiClient SSL VPN usually means something between the client and the FortiGate is killing the TLS handshake: a TLS version mismatch, a middlebox doing TLS inspection, or DTLS being blocked. Force TLS 1.2 in FortiClient settings, try with DTLS disabled, and test from a different network. If it works elsewhere, the user's network or ISP is the problem.

## The error
```text
Connection reset by peer
```
FortiClient log: "ssl vpn connection terminated by peer"

## Steps
1. Confirm the basics: the FortiGate is reachable (try the web portal URL in a browser), credentials are correct, and the user's account is not locked. Expected: the portal page loads. If the portal does not load either, the problem is reachability, not the client.
2. In FortiClient > Settings, set the TLS version explicitly (try TLS 1.2) and disable DTLS temporarily. Expected: the connection attempt proceeds further or connects. DTLS uses UDP and is the first thing broken networks kill.
3. Try connecting from a different network, like a phone hotspot. Expected: if the hotspot works, the home or office network or ISP is resetting the connection; a middlebox doing TLS inspection is the usual suspect.
4. Check the FortiGate side with your network admin: SSL VPN settings > TLS versions allowed, and the SSL VPN event logs during the attempt. Expected: the logs show where the handshake died (a rejected client hello means a TLS mismatch).
5. If it fails on every network: fully uninstall FortiClient, delete its leftover config, and reinstall the version your org supports. Expected: a clean config connects. Corrupt profiles survive upgrades and cause exactly this error.
6. Re-enable DTLS after the fix for better performance. Expected: the VPN connects with DTLS on; if it breaks again, leave DTLS off and document it.

## Use this when
- FortiClient shows "connection reset by peer" during SSL VPN connect
- The VPN starts connecting then drops mid-handshake
- SSL VPN fails but the web portal works

## Not for this skill when
- The error is wrong username or password, or a 2FA failure (a credential problem)
- Using FortiClient IPsec dial-up instead of SSL VPN (a different stack)
- The FortiGate itself is down (nothing client-side to fix)

## Compatibility
- FortiClient 7.x on Windows and macOS; FortiGate / FortiOS 7.x SSL VPN

## Variants
### Works on Wi-Fi but not on hotel or cafe networks
Captive portals and aggressive firewalls reset long-lived TLS. Complete the captive portal login first, or use the hotspot workaround.
### Every user fails at once
The FortiGate side changed: check for a recent FortiOS upgrade, an expired SSL VPN server certificate, or a TLS setting change. That is a server incident, not 50 client incidents.

## Why it happens
SSL VPN is TLS with extra steps. "Reset by peer" means the TCP connection was torn down mid-handshake, which TLS never does on its own; something in the path (a firewall, proxy, or ISP middlebox) or a version mismatch between client and server killed it. The steps isolate whether the killer is the client, the network, or the server.

## Edge cases
- Antivirus with TLS inspection can reset the handshake; test with web filtering paused.
- Old FortiClient versions default to TLS 1.0/1.1, which modern FortiOS rejects; updating the client fixes it.
- Split-tunnel vs full-tunnel does not affect this error; it happens before the tunnel is even built.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rm64t1ZeXKEi-esE6SEyfw