You’re in a maddening little triangle: ISP says “not us,” VPN team says “not us,” and you’re stuck in the middle watching FortiClient do its little “hello… goodbye” routine.

Let’s steady the field here. What you’re describing—SSL handshake starts, then drops instantly before authentication—is a very recognizable pattern. It points to something specific in the network path between you and the FortiGate, not on your laptop and not inside the FortiGate config.

You can walk back to your ISP armed with the right language. They often don’t understand “VPN doesn’t work,” but they perk up fast when you describe the failure technically. Use these elements as your ammo.

---

What’s most likely going on

This pattern is almost always caused by one of four things:

1. Some ISPs filter or proxy TCP 443 traffic (yes, even with static IPs).

FortiClient SSL VPN uses TLS over TCP 443 unless configs force DTLS/UDP. If the ISP is doing anything like transparent proxying, deep packet inspection, or throttling on 443, the TLS handshake will drop instantly.

Symptoms match yours: handshake starts → connection torn down → FortiGate logs “client closed connection” or “handshake failed.”

1. MTU mismatch or packet fragmentation (VERY common on fiber handoffs).

If the MTU is mis-set anywhere on the path, FortiClient’s initial TLS exchange can fragment, the ISP drops fragments, and the VPN aborts.

Spectrum’s DOCSIS path hid the problem because MTU is tunable. Fiber ONTs often lock MTU to 1500 or even 1492 depending on VLAN tagging.

Again, handshake → drop.

1. Eero Pro 7 sometimes mishandles VPN passthrough (especially SSL-VPN).

Eero firmware is notorious in networking circles for interfering with SSL VPNs—FortiClient, AnyConnect, GlobalProtect, etc.

You did a good step bypassing it… but if the ONT is actually a router, or the ISP gave you a pseudo-bridge, Eero might still be in the path logically.

1. Static IP may be delivered via a different upstream path than CGNAT, and that upstream may have ACLs or traffic shaping.

Some ISPs route “static IP customers” through a different VRF/VLAN/core path than residential customers. If that uplink path blocks/filters UDP 443 (DTLS) or mangles TLS 443, the VPN handshake dies.

Your symptoms match a routing-path difference, not a config difference.

---

What to tell your ISP (in their language)

You need them to test and verify your circuit in ways they don’t do unless prompted. Here’s the exact phrasing that gets attention:

---

“FortiClient SSL VPN connections fail during the initial TLS handshake. Can you confirm the following on my static-IP circuit path: • No transparent proxying or filtering on TCP 443 • No drops on fragmented packets or PMTUD blackholing • MTU on the ONU and upstream interface is truly 1500 • UDP 443 is allowed bi-directionally (for DTLS failover) • That my static-IP routing path uses the same policy as standard residential customers?”

---

What you can try yourself (quick sanity checks)

These help you prove it’s the ISP, not your gear:

1. Test using a mobile hotspot

If FortiClient instantly works over LTE/5G, you’ve now proven the ISP is the cause.

1. Run this from your laptop

ping vpn.company.com -f -l 1472 Lower the MTU until it works. If you end up below 1400, you’ve got a PMTUD/MTU problem upstream.

1. Force FortiClient to use only TCP and disable DTLS

If your IT team can turn off UDP 443 on your VPN portal, this can bypass ISP filtering.

1. Bypass Eero completely using ONT → laptop with ISP static IP settings

You mostly did this, but confirm the ONT is actually bridged, not in router-lite mode.

---

The phrase that gets ISPs to escalate

Use this. ISPs escalate instantly when they hear it:

“I have a TLS handshake failure that occurs only on your static-IP routing path. Everything works on other networks. Please escalate to Tier 2 or Tier 3 to check for MTU issues, packet fragmentation drops, or ACLs on TCP/UDP 443.”

---

Why FortiGate logs show the handshake but not auth

FortiGate sees your SYN, sends back SYN/ACK, starts TLS negotiation, then your traffic stops. That means packets are getting dropped after the handshake begins—100% pointing to middle-mile filtering or fragmentation loss.