FortiOS 7.6.3 Removed SSL VPN Tunnel Mode: Your Migration Options Step by Step

If you upgrade a FortiGate to FortiOS 7.6.3 without preparing first, your remote workers lose access the moment it reboots.

Fortinet removed SSL VPN tunnel mode in that release. The tunnel mode configuration does not carry over during the upgrade, and you cannot rebuild it afterwards because the feature is gone from both the GUI and the CLI.

You have four viable replacement paths. Before you pick one, it is worth getting the facts straight, because most write-ups on this change are describing it incorrectly.

What Fortinet removed, and what it quietly kept

There are three separate changes here, not one, and they landed in different releases.

Here is the part almost every article gets wrong. SSL VPN web mode was not removed in 7.6.3. Fortinet renamed it Agentless VPN, and existing web mode configurations persist through the upgrade rather than being wiped.

Only tunnel mode is destroyed. Web mode carries on under a new label.

That changes your options considerably. If a group of your users only needs browser access to internal web applications, you may not have to migrate them at all. One caveat: Agentless VPN is not available on the FortiGate 40F, 60F and 90G series, so those models remain a special case.

Will your FortiGate lose remote access? Two checks

Check the RAM. From the CLI:

diagnose hardware sysinfo conserve

If total RAM reads below 2000 MB, SSL VPN was already removed for your model back in FortiOS 7.6.0. You cannot move to any 7.6.x release without replacing it first.

Check which mode you actually run. Open your SSL VPN portal configuration. Tunnel mode users launch FortiClient and get a full network connection. Web mode users log into a browser portal. Plenty of organisations run both without realising, and the two have entirely different outcomes on upgrade.

Those two answers determine everything below.

Four ways to replace SSL VPN tunnel mode

IPsec VPN, the direct swap

Fortinet's intended replacement, and what their migration tooling is built around. IPsec is standards-based rather than proprietary, and it can run over TCP port 443, which solves the usual worry about users on hotel wifi, mobile data or restrictive guest networks where UDP 500 and 4500 are blocked.

Choose it when you want the closest functional match to what you have and you need this closed out quickly.

One thing to check first: the IPsec port setting is global, not per tunnel. Switching it to TCP 443 affects every IPsec tunnel on that firewall, including site-to-site links to branches and partners.

Agentless VPN, if browser access is enough

Formerly SSL VPN web mode, still present, still requires nothing installed on the endpoint. Good for contractors, auditors and anyone on a device you do not manage.

The limit is scope. It is an HTTPS reverse proxy to internal web applications. No mapped drives, no RDP, no thick clients. And it is unavailable on 40F, 60F and 90G series hardware.

Fortinet Universal ZTNA, if you want off VPN entirely

This changes the model rather than swapping one tunnel for another. Users connect to specific applications instead of to your network, with device posture verified on every session.

The commercial argument is straightforward: ZTNA capability ships with FortiOS and is delivered through the FortiClient agent, so for most organisations already running FortiGate there is no new product to buy. It also applies the same policy whether someone is at their desk or at home.

It does need FortiClient EMS for agent management, and it needs proper policy design rather than a like-for-like config translation. Allow more planning time than an IPsec migration.

FortiSASE, if remote access is not your only problem

The cloud-delivered route, sensible if branch connectivity, web filtering or multi-site security are also on your list this year. Choosing it purely to replace SSL VPN is a large tool for a small job.

Picking the right path for your setup

Most organisations end up running two of these. IPsec for staff who need full network access, plus Agentless VPN or ZTNA for third parties, is a common and sensible outcome.

Not sure which applies? Send us your current SSL VPN portal configuration and we will tell you which paths are open to you on your specific hardware and firmware, at no cost. Request a FortiGate configuration review.

The migration sequence that avoids downtime

1. Inventory before you touch anything. Every portal, which mode it uses, which user groups map to it, and what each group actually reaches. Teams skip this and then overrun. You cannot write equivalent policy for access nobody documented.

2. Confirm your FortiClient position. IPsec settings must match on both the FortiGate and the client, so the FortiClient EMS profile migrates in parallel, not afterwards. Check versions too: from FortiClient 7.4.4 onward IKEv1 is no longer supported.

3. Build the new path alongside the old one. Do not modify the working SSL VPN configuration. Stand up IPsec, ZTNA or Agentless access in parallel on the same firewall so you can roll back by simply telling people to use the old method. Fortinet supports GUI and CLI migration, and FortiConverter handles bulk translation for larger configs. The command-level walkthrough sits in our companion article, How to Migrate FortiGate SSL VPN to IPsec VPN.

4. Pilot with ten to twenty users. Mix device types and network conditions. Include someone on a mobile hotspot and someone on a home broadband connection, because that is where transport problems surface. Test the applications people actually use, not just whether the tunnel establishes.

5. Migrate in waves. Move user groups in batches a few days apart, updating the FortiClient EMS profile per wave rather than pushing one change to everybody. Keep the old path live throughout.

6. Upgrade the firmware last. This is the whole point. Move to 7.6.3 or later only once every user is validated on the new path. After that, tunnel mode is gone and reverting is not a configuration change.

Where these migrations go wrong

The config is not recoverable. Tunnel mode settings are lost on upgrade and cannot be recreated. There is no hidden CLI flag.

The IPsec port change is global. Check what else runs over IPsec on that box before switching to TCP 443.

FortiClient EMS is half the job. Teams migrate the FortiGate, test from a manually configured laptop, then discover on rollout day that hundreds of managed endpoints are still pushing the old profile.

Two changes may stack. A 2GB model on an older release is dealing with the 7.6.0 removal and the 7.6.3 one together. Your options are narrower than the general guidance suggests.

Audit logging can change shape. If CERT-In's 180-day retention applies to you, confirm the new access method produces equivalent records before decommissioning the old one.

What we would do in your position

Treat this as two decisions rather than one.

Short term, keep remote access working. If the upgrade window is close, migrate to IPsec VPN over TCP 443. It is the nearest equivalent, the tooling supports it, and your users will barely notice.

Longer term, ask whether you want to keep running a VPN at all. You are doing a migration project either way. Since ZTNA capability is already included with FortiOS and FortiClient EMS, going once toward application-level access usually beats going twice toward another tunnel. We covered the wider reasoning in VPN Limitations in Hybrid Workforce Environments, and if you want to see how Fortinet's approach stacks up against the alternatives, that is in Top 10 ZTNA Solutions in India.

For multi-site organisations, this decision often folds into a bigger one. When we replaced the network and access layer across 22 locations for Shahi Exports, the remote access question was solved as part of the SD-WAN and zero trust rollout rather than separately. Worth considering if you are already reviewing branch connectivity.

Whichever path you take, the sequence matters more than the destination. Inventory, build in parallel, pilot, migrate in waves, upgrade last.

Running out of runway before your upgrade window? NetNXT is a Fortinet partner and handles these migrations end to end for organisations across India, including the FortiClient EMS side that catches most teams out. Book a migration scoping call and we will map your portals, users and hardware into a dated plan. If the longer-term question is what you are really weighing, start with a zero trust assessment instead.

FAQs

1) Is SSL VPN completely gone in FortiOS 7.6.3?

No. Tunnel mode was removed. Web mode was renamed Agentless VPN and existing configurations survive the upgrade. The exception is the 40F, 60F and 90G series, where Agentless VPN is unavailable, and 2GB RAM models which lost SSL VPN entirely in FortiOS 7.6.0.

2) Can I just stay on an older FortiOS version?

Temporarily. But you are choosing to stop patching a remote access service that attackers actively target, which is a worse risk than the migration itself.

3) Will IPsec work for users behind restrictive firewalls?

Yes. IPsec can be configured over TCP port 443, which handles most networks blocking UDP 500 and 4500. Test on a mobile hotspot before you roll out.

4) How long does the migration take?

Two to four weeks for a single firewall with a few hundred users and a clean inventory, including pilot and phased rollout. Multiple sites or mixed firmware versions extend that.

5) Should I move straight to ZTNA instead of IPsec?

If you were already planning to leave VPN behind, yes. You are running a migration project regardless, and doing it once toward the model you actually want beats doing it twice. If your upgrade window is two weeks away, IPsec is the pragmatic call.