Remote access finding · Edge

SSL VPN Tunnel Mode No Longer Supported: Migrate, Replace, or Document It

FortiOS 7.6.3 removed SSL VPN tunnel mode from every FortiGate. What breaks, how to move to IPsec or zero trust access, and how to document a hold.

What Fortinet said

SSL VPN tunnel mode no longer supportedSSL VPN tunnel mode is no longer available in the GUI and CLIMigration from SSL VPN tunnel mode to IPsec VPNAgentless VPN (formerly SSL VPN web mode)

Fortinet removed SSL VPN tunnel mode from FortiOS. From version 7.6.3, released in April 2025, it is gone from the GUI and CLI on every FortiGate model, virtual machines included, and tunnel-mode settings do not carry over on upgrade. Users whose FortiClient or built-in VPN client connects in SSL tunnel mode lose access the moment the firewall upgrades. Smaller models lost it sooner: FortiOS 7.6.0 dropped SSL VPN entirely on 2 GB models such as the 40F and 60F, and 7.4.8 dropped it on the 50G, 70G, and 90G. Browser-based web mode survives as Agentless VPN on larger models, turned off by default. Fortinet's direction is to move remote users to IPsec VPN before the upgrade.

Why it matters

The upgrade forces a choice. Upgrade to 7.6.3 and remote users on SSL tunnel mode lose access that day. Stay on FortiOS 7.4 and the clock still runs: Fortinet extended its dates in March 2026, so 7.4 now leaves engineering support on May 11, 2027 and reaches end of support on November 11, 2028. After the first date, Fortinet ships fixes only for critical issues and security advisories. Holding on 7.4 is a plan with an end date, and the migration has to happen before it.

SSL VPN is the most attacked service on the box. Four FortiOS SSL VPN flaws that let an attacker in without logging in are on CISA's Known Exploited Vulnerabilities list: CVE-2018-13379, CVE-2022-42475, CVE-2023-27997, and CVE-2024-21762. In April 2025, Fortinet reported attackers who had used those older flaws to leave a link behind in the SSL VPN's language files, which kept read-only access to device files, including configurations, after the device was patched. Shadowserver counted 16,620 internet-facing devices carrying it. Devices that never enabled SSL VPN were not affected. The migration is the natural time to turn the SSL VPN portal off completely and confirm nothing was left behind.

The remote access controls you answer for still apply after the move. NIST 800-53 AC-17 covers how remote access is authorized and monitored, SI-2 covers fixing known flaws on time, and PCI DSS 8.4.3 requires multi-factor authentication for remote access into the cardholder environment. For high- and medium-impact NERC CIP sites, interactive remote access also falls under CIP-005 R2. The new path has to meet the same requirements, with evidence that it does.

The fix

Check whether you're affected first: the FortiOS version, whether any firewall policies still carry SSL VPN tunnel users, and which client each user group connects with.

Then choose one of two paths, and finish the migration before upgrading to 7.6.3.

IPsec on the same FortiGate. This is Fortinet's documented path, and the fastest when users need full network access and the deadline is close. Build IPsec dial-up with IKEv2, keep multi-factor authentication (FortiToken, or SAML to your identity provider), move the user groups and policies across, and test with a pilot group. One trap: the setting that runs IPsec over TCP 443 applies to the whole firewall, not per tunnel, so changing it also changes every site-to-site tunnel to branches and partners. Plan it as a change for the whole firewall.

A zero trust gateway in your own tenant. This suits vendor and contractor access, many sites, or internal web apps. Every session is tied to a named identity, users reach only the apps they're granted instead of the whole network, and outbound-only tunnels mean the firewall stops answering remote access on the internet at all. We build this most often on the Cloudflare One™ platform, with hybrid post-quantum key exchange on the path. See Remote Access Hardening.

Close the old service. Once users have moved, remove the SSL VPN listener and its policies rather than leaving web mode (Agentless VPN) running. On any device that ever ran SSL VPN, follow Fortinet's April 2025 guidance: run a release that removes the leftover link, reset admin and local VPN passwords, end active sessions, and turn on multi-factor authentication. Then check advisory FG-IR-25-934 for the later bypass.

Verify. From outside your network, confirm the SSL VPN portal no longer answers, users connect through the new path with multi-factor authentication, and named sessions show in the logs. Keep the before-and-after results as evidence that the item is closed.

When you can't fix it

Sometimes the move can't happen before the upgrade: a vendor tool or older device that only speaks SSL VPN, a remote site with no maintenance window this quarter, or users scattered across clients you don't manage. Holding on FortiOS 7.4 is a defensible decision when it's written down, dated, and backed by controls.

Keep the hold narrow. Stay on the latest 7.4 release so security fixes keep arriving. Require multi-factor authentication for every SSL VPN user, with no local-only accounts. Limit the portal to named groups and, where you can, to known source addresses or countries. Turn off web mode if nobody uses it, and send VPN logs to wherever your team actually reviews them.

Know which models can't hold. On a 50G, 70G, or 90G, keeping SSL VPN means staying below 7.4.8 and missing every 7.4 fix after it. On a 40F or 60F, it means staying off 7.6. Those devices go first in the migration plan.

Document it. Record the decision as a risk acceptance: what stays on SSL VPN and why, the compensating controls, a named owner, and a date to revisit well before 7.4 leaves engineering support on May 11, 2027. Under NIST 800-53 that's an RA-7 risk response tracked on the POA&M. See compensating controls for legacy systems, or the Risk-Acceptance Memo on the published price list.

Where it lands in the Risk Register

Finding	Treatment	Owner	Evidence
SSL VPN tunnel mode in use on a named FortiGate, blocking the upgrade to FortiOS 7.6.3	Migrate (IPsec or a zero trust gateway), or accept a dated hold on 7.4	Named by you	Configuration and outside check before and after, the user cutover record, and MFA enforcement. Maps to NIST 800-53 AC-17 and SI-2, RA-7 for a hold, and PCI DSS 8.4.3 where it applies.

Common questions

Can we turn SSL VPN tunnel mode back on after upgrading to 7.6.3?

No. It's gone from the GUI and CLI on every FortiGate model, and the old settings don't carry over. To keep it for now, stay on 7.4 under a documented hold, and migrate before engineering support ends on May 11, 2027.

What happened to SSL VPN web mode?

It's now called Agentless VPN, and it's off by default after the upgrade. It isn't available on the 40F, 60F, and 90G series. If nobody relies on it, leave it off, since it keeps the web portal reachable from the internet.

Does FortiClient still work after the move to IPsec?

Yes. FortiClient connects to IPsec dial-up with IKEv2, so most users keep the same app with a new connection profile. Push the profile centrally, or test it with a pilot group before cutover.

Should we replace the VPN instead of moving to IPsec?

It depends on who connects and what they need to reach. Staff who need the whole network on a short deadline fit IPsec on the same firewall. Vendors, contractors, many sites, or internal web apps fit a zero trust gateway, which gives each person only the apps they are granted.