SSL VPN Removed in FortiOS 7.6: A Migration Plan to IPsec and ZTNA

FortiGate SSL VPN removal happened in two steps: FortiOS 7.6.0 dropped both web and tunnel mode on entry-level models with 2 GB of RAM or less, and FortiOS 7.6.3, released in April 2025, replaced SSL VPN tunnel mode with IPsec VPN on every FortiGate model. Settings are not carried over on upgrade, so remote access has to move to IPsec IKEv2 or ZTNA before the firmware does.

What changed for SSL VPN in FortiOS 7.6?

The FortiOS 7.6 SSL VPN change spans three release notes: 7.6.0 removed web and tunnel mode on entry-level models, 7.6.1 refined the affected model list, and 7.6.3 replaced tunnel mode with IPsec VPN on every model while renaming web mode to "Agentless VPN". At no step are old settings carried into the new firmware.

This is a removal, not a deprecation notice. The special notice in Fortinet's FortiOS 7.6.3 release notes states that SSL VPN tunnel mode is no longer available in the GUI and CLI, that settings will not be upgraded from previous versions, and that this applies to all FortiGate models. The same notice asks customers to migrate their SSL VPN tunnel configuration to IPsec VPN before upgrading to 7.6.3 in order to keep remote access uninterrupted.

In our field experience the most common incident starts with a post-upgrade call that "the VPN portal disappeared": tunnel settings, the associated firewall policies and portal mappings are dropped during the upgrade, and the only way back is restoring the previous firmware and a configuration backup. Reading the change release by release is what makes correct timing possible.

The same release notes add that 2 GB RAM models also lose proxy-based features, Security Rating and Security Fabric topology in the 7.6 branch. On those devices the question is therefore not only about VPN but about the lifecycle of the whole 7.6 branch. From 7.6.4 onward (including FortiOS 8.0.0) the notice title was generalized to "some FortiGate series models", so always confirm the model list and dates against the current text in the Fortinet Document Library.

Which FortiGate models and organizations are affected?

Affected FortiGate models fall into two groups: on the 2 GB RAM 40F, 60F/61F, FGR-60F and on the 90G/91G, neither tunnel mode nor Agentless VPN remains; on every other model tunnel mode disappears with 7.6.3 while Agentless VPN continues. In practice, every FortiGate owner who provides remote access over SSL VPN is affected.

To confirm the memory class of your unit, run diagnose hardware sysinfo conserve in the CLI; if total RAM is below 2000 MB, the device falls under Fortinet's "2 GB class" definition. This matters most for models such as the FGR-60F that ship in several memory configurations. For a capacity view of the families, see our FortiGate 40F, 60F, 70G and 90G comparison; note that the 90G/91G appears on the Agentless VPN exclusion list while the 70G is not named there in the release notes.

By organization profile, three groups are affected:

• SMBs using SSL VPN tunnel mode with FortiClient: remote staff, accounting and ERP access, field technicians. This is the largest group and it is affected without exception in 7.6.3.
• Organizations using the web portal (bookmark-based access): those offering RDP/SSH/HTTP bookmarks to contractors or unmanaged devices. Mid-range and larger models can continue with Agentless VPN; entry-level models must move to IPsec or ZTNA.
• Managed service providers: teams that standardize firmware across dozens of customer devices at once. Bulk upgrading without a per-customer VPN inventory is the highest-risk scenario.

The FortiOS 7.4 branch still carries SSL VPN, and Fortinet has published a separate migration guide for 7.4 as well. Support for the 7.4 branch is time-limited, so verify its end-of-support dates on Fortinet's product lifecycle page. Staying on 7.4 buys time but is not a solution: relying on 7.4 for every security patch means missing new features and hardware support in the medium term. Deciding which device in your existing FortiGate estate fits which branch should be the first deliverable of the migration plan.

What are the alternatives to SSL VPN?

SSL VPN alternatives come in four flavors: IKEv2 dial-up IPsec VPN on the existing FortiGate, Agentless VPN for browser access on supported models, FortiGate ZTNA with FortiClient EMS for application-level access, and cloud-delivered FortiSASE. Most organizations move to IPsec first and then shift critical applications to ZTNA.

The choice is driven by your access model, not by which option is newest. Thick-client applications that need a network-layer tunnel (legacy ERP, file shares, print servers) are served fastest and with the least risk by IPsec. If you only need to expose web, RDP or SSH applications conditioned on device posture, ZTNA grants per-application access without opening a tunnel. If you would rather inspect branch and remote-user traffic in the cloud than backhaul it to a single concentrator, FortiSASE comes into play.

We explain how ZTNA works and how it differs from VPN in What is ZTNA? Zero-trust access replacing VPN; for the branch and remote-worker scenario, What is SASE? The FortiSASE approach for branches is the companion piece. On the product side, FortiClient combines VPN, ZTNA and endpoint protection in a single agent, while FortiSASE enforces the same access policies from the cloud.

How do you migrate to IPsec IKEv2 step by step?

Migrating from SSL VPN to IPsec IKEv2 follows the two-part approach in Fortinet's migration guide: first document the authentication methods and user groups in use, then build the IPsec dial-up tunnel alongside SSL VPN, add it to the FortiClient EMS profile, validate it with a pilot group and move the remaining users in waves.

Fortinet's SSL VPN to IPsec VPN migration guide stresses that no topology or port change is needed: users still connect to TCP 443 on the FortiGate WAN interface; the difference is IKEv2/ESP encapsulated in TCP instead of a TLS tunnel. The IPsec fundamentals in our existing FortiGate VPN configuration guide underpin these steps.

1. Take inventory. List SSL VPN portals, user groups and portal mappings, the authentication source (Local, LDAP, RADIUS, SAML), two-factor usage, split-tunnel and DNS suffix settings, address pools and every firewall policy bound to the SSL VPN interface.
2. Decide on the IKE version. IKEv2 is recommended: TCP 443 transport works only with IKEv2, SAML authentication is supported only on IKEv2, and FortiClient 7.4.4 and later no longer ship IKEv1.
3. Map authentication. The table below shows the IPsec equivalent of each current method. In IPsec a pre-shared key (PSK) or certificate is a mandatory field; user authentication is layered on top through EAP.
4. Build the tunnel on the FortiGate. The remote-access template in the VPN wizard generates the dial-up tunnel, address assignment (mode-cfg), user-group mapping and policies. Then switch the transport to TCP.
5. Resolve the admin-port conflict. If TCP 443 is used for IKE, administrative access on 443 on the same interface can be affected; change either the IKE port or the admin port.
6. Update the FortiClient EMS profile. Add the IPsec tunnel to the Remote Access profile; IKE version, mode and TCP transport must match the FortiGate exactly. Clients need 7.4.1 or later for TCP encapsulation and 7.4.6 or later if IPv6 is required.
7. Pilot and run in parallel. Open IPsec to a small group without disabling SSL VPN; validate MFA, split tunneling, DNS resolution and application access. Then move the groups, disable the SSL VPN policies and perform the firmware upgrade last.

The CLI change for TCP transport is short; adapt the tunnel name generated by the wizard to your environment:

config vpn ipsec phase1-interface
    edit "RemoteAccess-IKEv2"
        set ike-version 2
        set transport tcp
    next
end

config system settings
    set ike-tcp-port 443
end

Authentication mapping and policy clean-up always need an engineer's eye. In our projects, removing policies tied to SSL VPN that had not been used for years often delivers more security value than the migration itself.

When does moving straight to ZTNA make sense?

Moving to ZTNA makes sense for organizations that want remote access granted per application and conditioned on device posture rather than through a network tunnel. FortiGate has acted as a ZTNA application gateway since FortiOS 7.0, but FortiClient EMS, which holds identity and posture, is mandatory. For most SMBs, IPsec in the short term and ZTNA in the medium term is the most balanced sequence.

Fortinet's ZTNA architecture has three parts: the FortiClient ZTNA agent on the endpoint, FortiClient EMS holding identity and device posture (tags such as OS patch level, antivirus status or disk encryption), and the FortiGate enforcing the access decision. When a user requests an application, the FortiGate first checks the device's EMS tags and, if the conditions are met, opens access to that application only. Because no network tunnel is created, the room for lateral movement shrinks, a difference that becomes critical in ransomware scenarios.

ZTNA takes the lead in these situations:

• Most accessed applications are web, RDP or SSH: no tunnel is needed; the ZTNA access proxy is sufficient.
• Contractors, suppliers or BYOD devices are involved: opening a network tunnel without a posture condition is a risk we see repeatedly in audit findings.
• FortiClient EMS is already deployed: if EMS exists for endpoint management, ZTNA tags and policies can be enabled with modest additional work.

Conversely, legacy thick-client applications, print and file server access or site-to-site-like needs keep IPsec in place. That is why the model we recommend most often is hybrid: user groups that need a tunnel move to IPsec IKEv2 while web-based applications move to ZTNA. If you would rather inspect branch and remote-user traffic in the cloud than bring it to a central FortiGate, FortiSASE applies the same ZTNA policies from cloud PoPs; we cover that scenario in our FortiSASE article. For the conceptual framework of ZTNA, return to our ZTNA guide.

Pre-upgrade migration plan and checklist

The FortiOS 7.6.3 pre-upgrade checklist rests on one principle: no FortiGate that uses SSL VPN tunnel mode is upgraded to 7.6.3 or later until IPsec or ZTNA access has been validated in production. Fortinet's release notes explicitly ask for the migration to be completed before the upgrade.

Fortinet's guide leaves the decision of migrating before or after an upgrade to company policy and downtime tolerance; when a critical security patch is pending, upgrading first may be preferred. But because tunnel mode does not exist at all on 7.6.3 and later, the "upgrade first, migrate later" option effectively disappears at this threshold. The list below summarizes the order we follow in our projects.

These steps are also part of a broader firewall migration; for organizations moving to FortiGate from another vendor, our step-by-step migration plan applies the same discipline. If you prefer not to carry maintenance windows, monitoring and patch tracking with your own team, VPN migration and firmware management can be run together under a managed firewall service.

Frequently Asked Questions

I upgraded to FortiOS 7.6.3 and my SSL VPN users cannot connect; will the settings come back?

No. According to the release notes, tunnel mode settings are not upgraded from previous versions and cannot be recreated in the GUI or CLI. Your options are restoring the previous firmware from backup or building the IPsec IKEv2 dial-up tunnel and updating FortiClient profiles. Have the backup and rollback plan ready before upgrading to shorten any outage.

Are Agentless VPN and SSL VPN web mode the same thing?

Yes; the FortiOS 7.6.3 release notes refer to SSL VPN web mode as "Agentless VPN". Bookmark-based browser access continues, but the feature was removed from the GUI and CLI on the 40F, 60F/61F, FGR-60F (2 GB) and 90G/91G. It remains available on other models; confirm the current list in the Fortinet release notes.

Which FortiClient version is required for the IPsec migration?

According to Fortinet's migration guide, IPsec over TCP 443 requires FortiClient 7.4.1 or later; from FortiClient 7.4.4 onward IKEv1 is not supported, so IKEv2 must be used. FortiClient 7.4.4 does not support IPv6; if you need IPv6, use 7.4.6 or later. SAML authentication needs 7.2.4 or later.

Can I run IPsec VPN on TCP port 443 as well?

Yes. Set the transport of the IKEv2 tunnel to TCP; the FortiGate encapsulates IKE and ESP traffic over TCP 443 by default, and the port can be changed if needed. This keeps connections alive on hotel and carrier networks where UDP 500/4500 is blocked. If administrative access on the same interface also uses 443, change one of the two ports.

Do SAML and MFA work over IPsec?

They do. Fortinet's guide states that all SSL VPN authentication methods can be migrated to IPsec: SAML is supported only on IKEv2, LDAP uses EAP-TTLS on IKEv2, and FortiToken two-factor combines with Local, LDAP, RADIUS and SAML. Existing users and groups can be reused in the new IPsec configuration.

Can I stay on FortiOS 7.4 and keep using SSL VPN?

For now, yes; the 7.4 branch carries SSL VPN and Fortinet has published a migration guide for 7.4 as well. However, according to Fortinet's lifecycle bulletin, 7.4 support continues only for a limited period; verify the current dates on the support portal. Staying on 7.4 buys planning time but does not remove the need to migrate.

Does ZTNA require new hardware?

Usually not on the FortiGate side; FortiOS 7.0 and later include the ZTNA application gateway function. A FortiClient EMS server is mandatory for posture tags, however; verify its sizing in the current EMS documentation. For organizations that do not want branch hardware, FortiSASE enforces the same policies from the cloud.

Conclusion

FortiOS 7.6.3 removed SSL VPN tunnel mode on every FortiGate model, and entry-level 2 GB models lost Agentless VPN as well. Because settings are not carried over on upgrade, the right order is clear: inventory, build the IKEv2 IPsec dial-up tunnel on TCP 443 in parallel, update FortiClient EMS profiles, pilot and cut over in phases, and upgrade the firmware last. ZTNA for web applications and contractor access, and FortiSASE for distributed branches, are the next step.

At Sora Yazılım we can work through the impact analysis of your FortiGate estate, the IPsec or ZTNA migration plan and the upgrade calendar together with you. To review your current deployment, request a free discovery call or ask for a quote for the migration project.