FortiGate SSL VPN Tunnel Mode Is Gone: Move to IPsec, ZTNA or SASE

Summary: FortiOS 7.6.3 removed FortiGate SSL VPN tunnel mode on every model, and the upgrade deletes the old settings instead of converting them. Build the replacement first, then upgrade.

‍

The default path for most teams is an IKEv2 dial-up IPsec VPN with managed FortiClient. ZTNA and SASE fit best as a second phase, or as the main path when your users need a short list of apps.

FortiOS 7.6.3 shipped on April 16, 2025, and it removed SSL VPN tunnel mode from every FortiGate model. The feature is gone from the GUI and the CLI. If your remote users connect with FortiClient over FortiGate SSL VPN today, the next 7.6 upgrade ends that.

The part that hurts is what happens to your configuration. The upgrade deletes your tunnel settings, together with the firewall policies that use the SSL VPN interface. Nothing carries over.

So the risk sits in the order of your work. Upgrade first and your remote access stops on the same night. Build IPsec first, run it next to SSL VPN, move your users, and the upgrade becomes a non-event.

‍

Safe FortiGate SSL VPN to IPsec cutover order: back up, build IPsec beside SSL VPN, pilot, upgrade to FortiOS 7.6.3, then retire SSL VPN

I have run VPN cutovers where the tunnel was the easy part. The work that took time was the inventory: which groups had which access, which apps used which ports, and which contractor still had an old client installed.

This guide covers what changed by model and version, how long FortiOS 7.4 can carry you, and how to pick between IPsec, ZTNA and SASE. It also lists the failures that show up after the cutover, with the fix for each one.

IT Leaders Report 2026

What are your IT peers investing in 2026?

We spoke to about 1,300 IT leaders from various organisations to understand what they're evaluating. Most of it is the kind of thing you'd only hear from a peer you know well enough to ask, so we've put it in one place.

Read the report

‍

What Changed With FortiGate SSL VPN in FortiOS 7.6.3

In FortiOS 7.6.3 and later, SSL VPN tunnel mode is removed on all FortiGate models. Fortinet replaced it with IPsec VPN, which can run over TCP port 443. Tunnel settings and their firewall policies are deleted during the upgrade. SSL VPN web mode stays on supported models under a new name, Agentless VPN.

The removal did not happen in one release. It came in three waves, and the wave that hit you depends on your hardware. The explainer below shows each wave, the models it touched and what was left after it.

‍

What Still Works: Agentless VPN and Its Limits

Agentless VPN is the old SSL VPN web portal with a new name. Users sign in from a browser and open bookmarks. The portal proxies HTTP and HTTPS, RDP, VNC, SSH, Telnet, FTP, SFTP and SMB.

It does not give the device a network tunnel. Each user reaches only what a bookmark exposes. Fortinet hides the Agentless VPN menus by default, so you must turn them on in System > Feature Visibility or in the CLI.

Treat it as a fallback for a few web or RDP resources. RDP and VNC sessions can have limits, such as shortcut keys that do not work. It is also absent on the 40F, 50G, 60F, 61F and the 2 GB FGR-60F.

One more thing to keep in mind: Agentless VPN still runs on the SSL VPN web stack. If you keep it, add MFA, restrict the source addresses and patch fast.

How to Check What Your FortiGate Still Offers

Run get system status on each firewall. Write down the model and the FortiOS build. Those two values tell you which wave applies to you.

If the SSL VPN or Agentless VPN menus are missing, look at System > Feature Visibility first. If you enable the feature and the menu is still missing, your model and build no longer support it.

‍

Which FortiGate Models Lost SSL VPN, and in Which FortiOS Version

Every FortiGate model lost SSL VPN tunnel mode in FortiOS 7.6.3. Models with 2 GB of RAM or less lost all SSL VPN in 7.6.0. Entry-level G-series models lost it in 7.4.8, and the 90G and 91G also lost it in 7.2.12 and 7.6.1. Larger F-series models and FortiGate-VM keep Agentless VPN.

Use the matrix to find your row. The column for your planned firmware shows what you will have after the upgrade. If your box is missing, check Fortinet's model-by-model support list.

‍

Two details save you a support ticket:

• 2 GB models on 7.4.8. Web mode on these boxes has a known Access Denied issue. The only documented workaround is a downgrade to 7.4.7.
• Patch releases count. The G-series removals landed in maintenance builds such as 7.2.12 and 7.4.8. Read the special notices for every patch you install, because an auto-upgrade can remove a feature you still use.

If you own a 40F, 60F, 61F, 50G, 70G or 90G, you have no browser-portal fallback on 7.6. Dial-up IPsec is your supported path, and it should be your first project.

‍

Can You Stay on FortiOS 7.4 to Keep SSL VPN?

Yes, as a bridge. FortiOS 7.4 still includes SSL VPN tunnel mode on models that support it. After a one-year extension, 7.4 reaches End of Engineering Support on May 11, 2027, and End of Support on November 11, 2028. Use that time to build the replacement, and do not plan around it.

The chart below puts the 7.4 and 7.6 support windows on one line, with today marked. The gap between the marker and the end of the green bar is the time you have for full fixes.

‍

The extended support dates give you about six months of full engineering fixes from today. After May 11, 2027, the 7.4 branch gets must-fix support only, which means critical issues and security vulnerabilities.

Why the 7.4 Bridge Has a Security Cost

Staying on 7.4 means keeping an SSL VPN listener on the internet. That listener has a record.

• In April 2025, CISA described a post-exploitation file that attackers left on FortiGates after they exploited some vulnerabilites. The file could give read-only access to files on the device, including configurations. It works only when SSL VPN is enabled.
• On July 27, 2026, CVE-2025-68686 joined the Known Exploited Vulnerabilities catalog. It lets an attacker bypass the fix for that same persistence file, after they compromise the device another way.
• CVE-2022-42475 and CVE-2023-27997 both carry a Known flag for ransomware use in the KEV catalog.

if you bridge on 7.4, treat the SSL VPN listener as a temporary exception with an end date. Patch to the latest 7.4 build, require MFA, restrict source countries or addresses where you can, and reset credentials if you ran a vulnerable build in 2024 or 2025.

‍

What Maps to What When You Leave SSL VPN Tunnel Mode

Every part of your SSL VPN tunnel setup has an IPsec dial-up equivalent on the same FortiGate. The portal becomes a phase 1 interface, the ssl.root policies point at the tunnel interface, and the FortiClient profile changes to IPsec. Authentication carries over, with new EAP and client version rules.

Use this table as your inventory sheet. Fill in the left column from your current config before you build anything.

‍

The one row with no clean replacement is web mode on small boxes. If your users need browser-only access on a 40F or 60F, plan for ZTNA or a cloud service instead.

‍

Choose Your Path: IPsec, ZTNA or SASE

Rebuild on IPsec if your next FortiOS upgrade is close, users need full network access, or devices are unmanaged. Move to ZTNA if users reach a known list of apps from managed devices. Move to SASE if remote access, web filtering and branch connectivity are all up for a decision this year.

In practice, you will probably do two of these. IPsec goes in first because it keeps people working. ZTNA or SASE follows, app by app, once the deadline pressure is gone.

‍

Try the path picker below. Answer five quick questions about your upgrade date, your users and your devices. It gives you a recommended path, the reason it fits and your first three steps. It does not name or recommend vendors.

‍

The table below compares the four options on the five things your leadership will ask about.

‍

‍

Path 1: Migrating FortiGate SSL VPN to IPsec Dial-Up VPN

Build an IKEv2 dial-up IPsec tunnel on the same FortiGate, with FortiClient as the client and SAML or RADIUS for MFA. Run it next to SSL VPN, push the new profile from EMS, move your users, and upgrade to 7.6.3 only after the cutover. This is the fastest path, and your team already knows the box.

Fortinet's SSL VPN to IPsec migration procedure runs in this order:

1. Inventory. Record portals and group mappings, the IP pool, split-tunnel subnets, DNS, and every ssl.root policy with its groups and authentication method.
2. Convert. Use the GUI wizard, the CLI or FortiConverter. Set the incoming interface to the same listen interface as your SSL VPN.
3. Run both. Keep SSL VPN on while IPsec goes live, and build the IPsec profile in FortiClient EMS.
4. Verify. Check the connections with diagnose vpn ike gateway list.
5. Enforce. Remove the SSL VPN tunnel settings from the EMS profile.
6. Upgrade. Move to 7.6.3 or later, then test again.

Build on IKEv2 only. FortiClient 7.4.4 and later cannot connect to an IKEv1 tunnel, so an IKEv1 build breaks on the next client update. Check the IKE version the wizard gives you before you push any profile.

FortiClient VPN-Only vs EMS-Managed FortiClient for IPsec

The free FortiClient VPN-only client supports IPsec. It is fine for a small office with a handful of users. For a managed fleet, it creates work you do not need.

‍

If you go with the free client, document the XML edit. Somebody will rebuild a laptop in a year and forget it.

MFA and SAML on FortiGate IPsec VPN

MFA works over IPsec. It comes from one of three places: FortiToken on FortiGate users, the MFA on your RADIUS server, or your identity provider through SAML.

SAML for dial-up IPsec needs IKEv2, FortiOS 7.4 or later and FortiClient 7.2.4 or later. With Entra ID or Okta, users get the same sign-in page they use for everything else, which cuts help desk calls.

Watch the port rules. In FortiOS 7.6.1 and later, SAML sign-in can run over the IKE TCP port itself, and FortiOS then ignores auth-ike-saml-port. Do not set ike-tcp-port and auth-ike-saml-port to the same number. If you do, the IKE process misses TCP IPsec traffic.

Networks That Block IPsec: UDP 500 and 4500, and IPsec Over TCP

Hotel, airport and guest networks often block UDP 500 and 4500. FortiGate can carry IKEv2 over TCP to get through them. Set the transport to Auto so clients try UDP first and fall back to TCP.

On new FortiOS 7.6.1 and later deployments, the default IKE TCP port is 443. The old default of TCP 4500 was often blocked by ISPs. Port 443 is open on most networks, but it brings two traps:

• Admin GUI conflict. If the HTTPS admin port on the same interface is also 443, IKE takes the port and you lose GUI access there. Move the admin port, or pick another IKE TCP port. Keep console or SSH access ready before you change it.
• Tunnel flush. Changing ike-tcp-port drops every IPsec tunnel on that VDOM. Do it in a change window.

In 7.6.5, the GUI offers only Auto or UDP for the transport. Set TCP in the CLI. Here is an example. Change the names and ports to match your design.

# Example only. Match names and ports to your design.config system global    set admin-sport 8443endconfig system settings    set ike-tcp-port 443endconfig vpn ipsec phase1-interface    edit dialup-ikev2        set ike-version 2        set transport auto    nextend# Then confirm connected clients:diagnose vpn ike gateway list

‍

What FortiConverter Does, and the Defaults to Change

FortiConverter turns each SSL VPN web portal into a phase 1 interface. It creates a default phase 2 and points your ssl.root policies at the new tunnel interfaces. That saves hours on a busy config.

Check its output before you load it. The FortiConverter Service sets the pre-shared key to 123456789. Its default phase 2 uses AES with SHA-1 and Diffie-Hellman group 5. Replace the key, and move to SHA-256 or stronger with a modern DH group before any user connects.

IPsec Cutover Checklist

Use the interactive checklist below to track your cutover. Each step names an owner. Tick a step when it is done, and the progress bar shows how far you are from a safe upgrade. Your ticks reset when you leave the page, so copy the list into your change ticket if you need a record.

‍

Why FortiClient VPN Is Not Connecting After the IPsec Cutover

Most failures after an SSL VPN to IPsec move come from three areas: the transport and ports, the sign-in setup, and client versions. Each one has a known cause and a known fix. Check the table before you open a ticket.

I keep this list next to the help desk queue for the first two weeks after a cutover. The same five or six tickets come in every time.

‍

The last row is the expensive one. It is also the only one you can fully prevent, with a config backup and an upgrade freeze.

‍

Path 2: Replacing FortiGate VPN With ZTNA

ZTNA gives each user access to named apps, after a check of identity and device posture, so users never land on the network. On FortiGate, ZTNA needs FortiClient EMS for device tags, an access proxy on the firewall, and proxy policies that match those tags. It suits web, RDP, SSH and file share access from managed devices.

I have the same advice here that I gave in our guide to replacing Cisco AnyConnect with ZTNA: start with the app list. ZTNA projects stall on the apps nobody wrote down, and the network part is the quick part.

ZTNA vs VPN for FortiGate Users: What Changes for Users and Admins

The biggest change is scope. A VPN puts the device on a network segment. ZTNA puts the user in front of one app per rule.

‍

Fortinet ZTNA vs a Third-Party ZTNA Service

Fortinet's ZTNA setup has four parts. You connect FortiGate to EMS, create an access-proxy VIP, define the services (HTTPS, TCP forwarding or SAML), and write proxy policies that match EMS tags with ztna-ems-tag. If you already run FortiGate and EMS, you add licenses and design work on hardware you already own.

Third-party services such as Zscaler Private Access, Cloudflare Access, Netskope Private Access and Palo Alto Prisma Access take a different approach. A connector inside your network dials out to the vendor's cloud, so you expose no inbound listener. The FortiGate stays as your site firewall.

Before you compare Fortinet with Zscaler or anyone else, ask each vendor two questions. Does it support UDP? Does it support traffic that the server starts, such as VoIP or active FTP? Several vendors put those behind a higher tier or an add-on. Our ZTNA tools compared guide covers the trade-offs in depth.

Apps That Make ZTNA Harder

Some apps do not fit per-app access well. Keep IPsec for them while the rest moves:

• UDP and voice apps. FortiGate ZTNA forwards UDP only from FortiClient 7.4.1 and EMS 7.4.1, over QUIC, with HTTP/3 support turned on. Test call quality before you move a softphone.
• Thick clients that open many ports. Each port or range needs a rule. Map them with the app owner first.
• OT and vendor access. A vendor who needs a whole subnet for maintenance is a VPN user. Give that vendor a separate, time-limited tunnel.

Move apps in phases. Disable the VPN policy for each app as soon as ZTNA covers it, so you never run two open doors to the same app. One more practical point: FortiOS 7.6.7 caches ZTNA tags if EMS goes offline, so a short EMS outage does not lock everyone out.

‍

Path 3: Moving FortiGate Remote Access Into SASE

SASE moves remote access, web security and often branch connectivity into one cloud service. Remote users connect to the nearest point of presence, and the cloud reaches your private apps through IPsec tunnels to a hub, which can be your existing FortiGate. Pick this path when those three contracts come up for a decision in the same year.

SASE is the largest change of the three paths. It is also the only one that removes the remote-user listener from your own firewall. Plan it in phases: remote users first, then web security, then branches.

What Is FortiSASE?

FortiSASE is Fortinet's cloud-delivered SASE service. It covers a secure web gateway, universal ZTNA and CASB, for managed devices with an agent and unmanaged devices without one. Licensing is per user.

For private apps, FortiSASE builds IPsec tunnels from its points of presence to a FortiGate. That FortiGate can be an SD-WAN hub you already run, or a firewall you convert into a standalone secure private access hub. This setup carries both TCP and UDP apps. A few planning details matter:

• Hub licensing. The secure private access license is needed at the hub locations only.
• Hub sizing. For SD-WAN hubs, a FortiGate-100F or larger is the recommended size.
• Unmanaged devices. Agentless access to private apps works over HTTPS only. It needs the Advanced, Professional or Comprehensive license tier.

In practice, FortiSASE lets you keep the FortiGates you own and stop terminating remote users on them. For a Fortinet shop, that is the least disruptive way into SASE.

FortiSASE vs Zscaler, Netskope, Palo Alto and Cato

If you are open to leaving Fortinet for remote access, the other SASE platforms work the same way at a high level. Your FortiGates stay as site firewalls and connect to the vendor cloud over IPsec. The differences show up in UDP support, server-initiated traffic, agentless options and how each one prices private access.

We compared these platforms side by side in our SASE platforms compared guide. If branch links are part of the decision, read our SD-WAN options, Fortinet included guide as well. For background on the wider portfolio, see what Fortinet does.

‍

A 30-Day Plan Before Your Next FortiOS Upgrade

Thirty days can be enough to move a typical FortiGate SSL VPN user base to IPsec, if you start with the inventory and freeze upgrades on day one. Spend week one on inventory, week two on the build, week three on the pilot and week four on the cutover and the upgrade. ZTNA or SASE follows as phase two.

The visual below lays out the four weeks and the two tracks that start after the upgrade.

‍

Definition of Done for the SSL VPN Retirement

Do not call the project finished until every gate below is green:

• Every remote user connects over IPsec, ZTNA or SASE, and nobody has an SSL VPN profile left in EMS.
• Every firewall runs FortiOS 7.6.3 or later, or carries a dated exception with an owner.
• No firewall policy references ssl.root, and no SSL VPN or Agentless VPN listener faces the internet without a named reason.
• The help desk has the failure table above and a tested answer for each row.
• Credentials from any device that ran a vulnerable SSL VPN build have been reset.

‍

Treat FortiOS 7.6.3 as a Remote Access Decision

The tunnel mode removal forces a choice you would have made anyway. The teams that come out of it well do three things in order. They freeze upgrades, they rebuild remote access on IPsec next to SSL VPN, and they use the calm after the cutover to move apps to ZTNA or SASE.

The teams that struggle upgrade first and plan second. A config backup and a one-line upgrade freeze are the difference between a planned project and a night of rebuilding VPN policies from memory.

If you are designing the end state, our guide to building a Zero Trust architecture shows where ZTNA and identity fit.