FortiGate SSL VPN Migration Checklist: What to Audit Before You Touch Anything (FortiOS 7.6)

The Problem This Post Addresses

Fortinet is removing SSL VPN. Not deprecating it in the "we'll support it forever but please don't use it" sense — actually removing the binaries from certain models and FortiOS builds. The pressure behind this is a documented string of high-severity CVEs — FG-IR-22-398, FG-IR-23-097, FG-IR-24-015, and others — that made the SSL VPN portal Fortinet's most-exploited attack surface over a two-year span. Fortinet's answer is to kill the portal and push customers toward IPsec dialup or ZTNA.

This post is not a step-by-step migration guide. It is the pre-flight checklist you run before you recommend or scope the migration to anyone. It is written for the engineer who knows the change is coming and needs to understand what they are walking into before they open a change ticket.

Environment: FortiOS 7.4.x and 7.6.x. Most of this checklist applies regardless of version, but the removal timelines reference the 7.4.x and 7.6.3 lines specifically where noted.

Important caveat before you read further: Fortinet has been updating the SSL VPN removal scope across point releases. The exact list of affected models and the exact features removed in each FortiOS build — tunnel mode vs. web mode vs. the portal entirely — changes. Before you scope anything, verify the current state against the Fortinet PSIRT advisories and the release notes for the target FortiOS version. Do not rely on secondhand summaries, including this one, as the definitive model-version matrix.

Bucket 1: License, Firmware, and Model Inventory

Start with what is on the box, not what the customer thinks is on the box.

Confirm the Current FortiOS Build

get system status

Note the exact build number, not just the major version. A FortiGate running 7.4.4 build 2662 and one running 7.4.7 build 2860 are in meaningfully different positions regarding SSL VPN support. The build number is what matters when you cross-reference against release notes.

Confirm Whether SSL VPN Is Actually in Use

show vpn ssl settings
show vpn ssl web portal
get vpn ssl monitor

show vpn ssl settings tells you how it is configured. get vpn ssl monitor tells you who is actually using it right now. Run the monitor output at several points during a business week, not just once at 2 PM on a Tuesday. Customers consistently have configured SSL VPN for users who have not connected in 18 months. Your actual migration scope is the active user population, not the provisioned one.

Web Mode vs. Tunnel Mode — This Changes Everything

Determine whether the environment uses:

Tunnel mode only — FortiClient connects, gets an IP, pushes routes. This is the straightforward path to IPsec dialup. The replacement is direct.
Web mode only — Users open a browser, authenticate to the portal, and access RDP/SSH/HTTPS bookmarks without a client. IPsec dialup does not replace this. The web mode workload moves to ZTNA or a reverse proxy. If the customer is using web mode, the migration scope is significantly larger.
Both — Scope both paths. They may need different migration targets and different timelines.

Model Compatibility and the Target Version Decision

Entry-level desktop FortiGate models (the 40F, 60F, 80F class) lost SSL VPN tunnel mode earlier in the 7.4.x line than mid-range and higher models. FortiOS 7.6.3 extends the removal further. Verify the exact cutoff for the specific hardware on the table against current Fortinet documentation before you commit to a firmware target.

Your version decision tree:

Stay on 7.4.x — SSL VPN still present on most models, still supported. Buys time but does not solve the problem.
Move to 7.6.x and migrate in the same window — Clean but requires the migration to be fully scoped and tested before the upgrade.
Coexistence window on current version, then upgrade — Run SSL VPN and IPsec dialup in parallel, migrate users in waves, then upgrade. This is almost always the right answer when the model still supports SSL VPN on the current firmware.

Licensing

FortiCare must be active to download firmware. Confirm the contract expiry before you plan a firmware upgrade that requires a download.
ZTNA requires FortiClient EMS. If the customer does not have EMS, ZTNA is off the table. Fortinet's licensing for ZTNA has changed across recent contract cycles — verify the current bundling against the customer's active contract before recommending it.
IPsec dialup does not require an additional license for the tunnel itself. It is part of the base FortiGate firmware. However, per-model limits on concurrent dialup tunnels exist. Verify the maximum for the specific model against the expected concurrent user count.

Bucket 2: Endpoint Inventory

The firewall config takes a few hours to rebuild. The endpoint situation is what bites you at 8 AM the morning after cutover.

FortiClient Version Inventory

IPsec dialup with EAP-based authentication requires a reasonably current FortiClient build. Older 6.x clients and early 7.0.x builds have known issues with EAP-MSCHAPv2 and IKEv2 fragmentation. Before you finalize a migration plan, verify the minimum FortiClient version that handles IPsec dialup cleanly with the target FortiOS version against current Fortinet documentation. Assume you will need to push a FortiClient update to at least a portion of the endpoint fleet before cutover.

Endpoint OS Mix

Windows managed endpoints — Straightforward. FortiClient for Windows handles IPsec dialup cleanly on current builds.
macOS — FortiClient on macOS has historically been less consistent for IPsec dialup than for SSL VPN. Test this early. Do not assume parity.
iOS and Android — Native OS IKEv2 VPN profiles work. FortiClient Mobile is smoother if the customer is licensed for it. Document how many mobile users exist and whether they are managed.
Linux — If anyone is using SSL VPN from Linux, document it now. Native IKEv2 options exist but vary by distro and need explicit testing.

BYOD vs. Managed

On managed endpoints, you push a FortiClient profile via EMS or Intune. On BYOD, you are emailing users a config file and a one-page instruction sheet. Estimate the BYOD population and budget help-desk capacity accordingly. The help-desk load from a BYOD migration is real and consistently underestimated.

Non-FortiClient Users

Some users may be connecting with the native OS VPN client rather than FortiClient — Windows built-in IKEv2, macOS built-in, Cisco Secure Client, strongSwan on Linux. get vpn ssl monitor will show them, but it will not label them by client type. Find them before cutover. They need a separate IKEv2 configuration profile that matches whatever you build on the FortiGate.

Geographic and Network Spread

Document where endpoints connect from. Endpoints on mobile carrier networks, hotel WiFi, and airport networks are where IKEv2 fragmentation and UDP blocking surface first. These users should be part of your pilot group, not discovered after go-live.

Bucket 3: Auth Chain and Identity Dependencies

This is where migrations fail silently. The tunnel comes up but authentication breaks for a subset of users, and it takes an hour to figure out why.

Map Every Auth Dependency

show user ldap
show user radius
show user saml
show user group
show vpn ssl settings | grep auth

Document the auth source (local, LDAP/AD, RADIUS, SAML), the MFA layer on top of it, and which user group hits which portal mapping. The auth source itself usually carries over fine. The binding — which group hits which portal with which MFA requirement — has to be re-expressed in IPsec terms, and the model is different enough to require explicit redesign.

MFA Chain — The Most Common Silent Failure

FortiToken TOTP / FortiToken Mobile push: Both work with IPsec dialup, but the user experience flow differs from the SSL VPN portal. Push-based MFA over IPsec requires the auth method to support challenge-response — typically via RADIUS or EAP. Verify current FortiToken Mobile push compatibility with IPsec dialup on the specific FortiOS target version before you commit to this path.

SAML via Entra ID or Okta: SSL VPN has had clean SAML support at the portal for a long time. SAML authentication over IPsec dialup is a more recent capability and has more rough edges depending on the FortiOS build. Verify the current support state before scoping a SAML-to-IPsec migration.

Duo via RADIUS proxy: Works for both SSL VPN and IPsec dialup, but the proxy timeout values typically need adjustment. IPsec dialup authentication flows can behave differently than SSL VPN under a RADIUS challenge-response. Test end-to-end MFA with Duo before you migrate the production population.

Conditional Access Policies in Entra ID

Audit every Conditional Access rule that touches the VPN authentication path:

CA rules keyed on the SSL VPN client application ID
Named locations matched to the SSL VPN public IP address
Device compliance state passed through SAML
Session controls that rely on the SSL VPN SAML claim set

Every one of these needs review before cutover. A CA policy that was tuned for the SSL VPN portal will not automatically apply correctly to a new IPsec dialup SAML flow.

Multiple Portal Mappings

If the customer has more than two SSL VPN portal mappings (different split-tunnel policies, different resource access for different groups), scope this carefully. In SSL VPN, you express this with portal mappings. In IPsec dialup, you express it with multiple phase1-interface dialup tunnel configurations and per-group firewall policies. The architecture is different, not harder — but it is a redesign, not a direct copy. Four or more portal mappings means explicit re-architecture work that needs to go in the project scope.

Service Accounts and Exceptions

Find the printer that connects via VPN. Find the legacy application that hits a hardcoded portal URL. Find the monitoring system that authenticates with a local service account. These exist in almost every environment and never appear in the user inventory. Ask the customer explicitly. Check firewall session logs for persistent low-traffic connections to the SSL VPN tunnel interface.

Bucket 4: Network and Reachability Dependencies

Public IP and DNS

SSL VPN typically runs on TCP/443 of a WAN IP — often the same IP used for FortiGate management or other published services. IPsec dialup uses UDP/500 and UDP/4500 for IKE negotiation, plus either ESP (IP protocol 50) or UDP/4500 encapsulation for the data plane with NAT-T. The DNS record pointing to vpn.customer.com can stay pointed at the same IP. The protocol underneath it changes.

Document every firewall rule and port forward on the upstream ISP router or carrier device that currently permits inbound TCP/443 for SSL VPN. You will need new rules for UDP/500 and UDP/4500. Confirm whether upstream NAT-T passthrough is needed.

The Silent Killer: Upstream UDP Filtering

This is the issue that derails more IPsec migrations than anything else. TCP/443 gets through almost everywhere because the internet is built around it. UDP/500 and UDP/4500 do not get through everywhere:

Hotel and airport WiFi — commonly filtered or rate-limited
Mobile carrier networks — varies by carrier and country, but strict filtering is common
Corporate guest networks — often whitelisted for TCP/80 and TCP/443 only
SASE platforms and cloud security proxies — may intercept or block IKE traffic

Test IPsec dialup connectivity from representative endpoint locations before the cutover window, not after. Testing from the office LAN or a home cable connection will pass. Testing from a mobile hotspot or hotel WiFi may not. The most important test sites are the ones where your users are most likely to be when they need VPN to work at 7 AM.

If upstream filtering is a known issue for a significant portion of your user base, evaluate whether IKEv2 over TCP (if supported in your FortiOS target version — verify in your environment) or ZTNA is a better fit than standard UDP IPsec dialup.

Split-Tunnel Configuration

show vpn ssl settings | grep split
show firewall address

Document the current split-tunnel posture — full tunnel, specific subnet inclusion, or cloud-app exclusions — before the migration. Then make a deliberate decision: replicate the current posture exactly in the IPsec config, or use the migration as an opportunity to change it. The strong recommendation is to replicate first and change later. Changing split-tunnel policy simultaneously with changing VPN technology doubles the number of variables you are debugging at 2 AM.

DNS, DNS Suffix, and Internal Name Resolution

SSL VPN portal config pushes DNS server addresses and DNS suffix to the client. IPsec dialup pushes the same information via mode-config. The capability exists on both sides — but document the current SSL VPN settings explicitly and plan to mirror them. A missed DNS suffix push is one of the most common post-migration complaints ("I can't reach the file server by name") that takes 10 minutes to diagnose and 2 minutes to fix, but only if you already know to look there.

Interface References in Firewall Policy and Routing

The SSL VPN tunnel interface is typically named ssl.root. The IPsec dialup interface will have whatever name you assign it — something like dialup-vpn. Every object in the FortiGate config that references ssl.root needs to be identified and updated:

Firewall policies (source and destination interface)
Static routes with ssl.root as outgoing interface
SD-WAN rules that reference the SSL VPN interface
Traffic shaping policies
SIEM-side correlation rules that key on interface name in log fields

show firewall policy | grep ssl.root
show router static | grep ssl.root

Do this audit before you build anything new. Knowing the scope of policy changes required is part of scoping the change window.

SIEM and Logging

Any SIEM correlation rule or dashboard keyed on SSL VPN-specific log fields (type=vpn subtype=ssl, specific event IDs, interface names) will go quiet after migration. This is not just a visibility gap — if your security team has detections built on SSL VPN log patterns, those detections stop working silently. Inventory the detection content that depends on SSL VPN telemetry and plan updates as part of the migration project, not as a follow-up.

Bucket 5: Change Planning, Communications, and Rollback

Change Window Sizing

A small environment — under 50 concurrent users, single auth source, single portal mapping, managed endpoints only — is realistically a 2-to-4-hour change window for the FortiGate side. Add time for:

Endpoint FortiClient updates (can be pre-staged the week before)
BYOD user configuration assistance
Post-change validation
Buffer for unexpected auth issues

Larger environments, multiple auth sources, BYOD populations, or multiple portal mappings should be scoped as phased migrations across multiple change windows by user group, not a single cutover.

Coexistence: Run Both in Parallel

If the FortiGate model and current FortiOS version still support SSL VPN, run SSL VPN and IPsec dialup in parallel during the migration period. Build the IPsec dialup configuration, test it with a pilot group of 5-10 users, validate auth and split-tunnel behavior, then migrate user groups in waves over 1-2 weeks. Disable SSL VPN only after the last user is confirmed off it.

This approach is almost always better than a simultaneous firmware-upgrade-and-cutover. The only reason not to do it is if the model has already lost SSL VPN in the current firmware version, in which case coexistence is not an option.

Backups — More Than You Think You Need

Full config backup before any change. Store it off-box. Not on the FortiGate flash.
Export show vpn ssl settings and show vpn ssl web portal to a text file and save it separately. Once SSL VPN is gone from the config, this is your only reference for what was there.
Full config backup after the IPsec config is built but before SSL VPN is disabled.
Full config backup after SSL VPN is disabled.

Screenshots of the GUI portal config are acceptable as supplementary documentation but are not a substitute for the CLI output. CLI output can be diffed and searched.

Rollback Decision Thresholds

This is the part of the change ticket that almost never gets written explicitly:

Before firmware upgrade: Config restore is cheap. Rollback is fast.

After firmware upgrade, on a version that still has SSL VPN binaries: Config restore still works. SSL VPN comes back. Still a manageable rollback.

After upgrade to a FortiOS build where SSL VPN binaries are removed (e.g., the 7.6.3 line on affected models): Rolling back means a firmware downgrade. Firmware downgrades on FortiGate are possible but carry their own risk — config compatibility issues, boot complications on some models. At this point, rollback is no longer cheap. This threshold needs to be documented in the change ticket and explicitly acknowledged by whoever approves the change window.

Define your rollback decision point before the window opens: "If X users cannot connect 90 minutes after IPsec cutover, we initiate rollback. The rollback procedure is Y." Write it down.

User Communications — Three Touchpoints

T-7 days: Email to all affected users. State what is changing, what is not changing (the VPN address, the apps they can reach), and what action they need to take before the cutover (update FortiClient to version X, expect a new connection profile). Keep it short. One paragraph, one action item.

T-1 day: Reminder. Cutover window date and time. Help-desk contact for issues.

T-0: Confirmation that migration is complete, with the exact new connection profile details and a single-page PDF or linked page with step-by-step instructions for connecting with the new config. The instructions should assume the user has never configured a VPN client before.

Post-Migration Validation — Next Morning, Not Next Week

The morning after cutover:

Pull get vpn ipsec tunnel summary or equivalent — concurrent connected users should match expected active population
Manual test from each major endpoint type: Windows managed, macOS, iOS or Android, any non-FortiClient clients
Manual test from at least one "hard" network — mobile hotspot, not office LAN
Check SIEM for expected log volume from the new IPsec tunnel
Check help-desk ticket count — a spike means a quiet majority is failing and not calling
Confirm DNS resolution is working correctly from a connected IPsec client (internal hostnames, not just IP)

Troubleshooting: Common Pre-Migration Discovery Issues

1. `get vpn ssl monitor` Shows Zero Users but SSL VPN Is Configured

SSL VPN is configured but not in active use. Before you treat this as a simple cleanup job, check whether the configuration is referenced by firewall policies or automation objects. A configured-but-unused SSL VPN setup sometimes has policy or NAT entries that reference ssl.root that still need to be cleaned up post-migration. Confirm with show firewall policy | grep ssl.

2. FortiCare Contract Expired — Cannot Download Target Firmware

Firmware download requires an active FortiCare contract. If the contract is expired, the migration is blocked at the firmware step until renewal. Identify this in pre-migration inventory, not in the change window. Renewal processing time varies by partner and reseller — build it into the project timeline.

3. Multiple SSL VPN Portals with Overlapping Group Memberships

A user in two groups that map to different portals is handled by SSL VPN portal mapping priority order. In IPsec dialup, the equivalent model is per-group phase1-interface configuration with matching firewall policies. If the current portal mapping order is not documented, the migration may inadvertently change access scope for users in multiple groups. Document the portal mapping order explicitly with show vpn ssl settings before any changes.

4. SAML Auth Breaks After IPsec Migration (Entra ID)

If the FortiGate SSL VPN was registered as an enterprise application in Entra ID with a specific reply URL and entity ID, the IPsec dialup SAML flow requires its own service provider configuration — it does not inherit the SSL VPN SAML registration automatically. If you are migrating to SAML-over-IPsec, treat it as a new IdP application registration, not a modification of the existing one. Verify current SAML-over-IPsec support state for the target FortiOS version before committing to this path.

5. Upstream ISP or Carrier Firewall Blocking UDP/500 and UDP/4500

IPsec dialup connections fail from outside the office but succeed from inside the office network. The firewall policy on the FortiGate is correct. The problem is upstream. Confirm by running a packet capture on the WAN interface:

diagnose sniffer packet <wan-interface> 'udp port 500 or udp port 4500' 4 0

If IKE negotiation packets are arriving, the upstream path is open. If no packets arrive during a connection attempt from an external endpoint, the upstream device or ISP is dropping them. Resolution: work with the ISP or upstream device owner, or evaluate alternative transport for IPsec (verify IKEv2-over-TCP availability in your environment).

FAQ

Is FortiGate SSL VPN really being removed, or just deprecated?

It is being actively removed from specific model and firmware combinations — not just marked as end-of-life while remaining functional. Entry-level FortiGate models had SSL VPN tunnel mode removed in the 7.4.x line. FortiOS 7.6.3 extends the scope of removal. On models and builds where removal has occurred, the SSL VPN binaries are not present. This is not a soft deprecation. That said, the exact scope — which features, which models, which FortiOS builds — has been updated across point releases. Verify the current state against Fortinet PSIRT advisories and release notes for the specific model and target version before making any planning decisions.

Which FortiGate models still support SSL VPN in FortiOS 7.6?

This is the question with the most risk of a wrong answer in a blog post, because Fortinet has updated the affected model list across builds. Mid-range and high-end FortiGate models have generally retained SSL VPN support longer than entry-level desktop models. The definitive answer for any specific model is in the FortiOS 7.6.x release notes and the Fortinet PSIRT advisory referenced for SSL VPN removal. Check those documents for the model you are working with before drawing any conclusions.

What replaces FortiGate SSL VPN — IPsec or ZTNA?

Depends on what the SSL VPN was doing. If it was running in tunnel mode — FortiClient connecting, getting an IP, accessing internal resources — the direct replacement is IPsec dialup with IKEv2. Same access model, different protocol, no extra license required. If it was running in web mode — users accessing a browser portal with RDP, SSH, or HTTPS bookmarks without a client — IPsec dialup does not replace that. Web mode access moves to ZTNA (which requires FortiClient EMS) or a separate reverse proxy. Many environments need to decide which path applies to which user population, because the answer is sometimes both.

Can SSL VPN and IPsec dialup run on the same FortiGate at the same time?

Yes, on FortiOS versions that still include SSL VPN binaries on the specific hardware. This is the recommended migration approach: build and validate the IPsec dialup configuration while SSL VPN remains active, pilot with a small user group, migrate in waves, then disable SSL VPN once all users are confirmed on the new tunnel. This only works on models and firmware versions where SSL VPN has not yet been removed. If the upgrade to a FortiOS build that removes SSL VPN and the user migration happen simultaneously, coexistence is not an option.

Do I need a separate license to migrate from SSL VPN to IPsec dialup?

For IPsec dialup itself — no. The tunnel capability is part of the base FortiGate firmware. You need a valid FortiCare contract to download the target firmware if a firmware upgrade is part of the migration, but no separate feature license for IPsec. If the migration target is ZTNA instead of IPsec dialup, that does require FortiClient EMS licensing, and the specific bundling depends on the customer's current contract. Verify the ZTNA licensing requirement against current Fortinet terms before scoping it as an option.

Will my existing FortiClient version work after the migration?

Possibly, but do not assume it. Older 6.x and early 7.0.x FortiClient builds have known issues with EAP-MSCHAPv2 and IKEv2 fragmentation in IPsec dialup configurations. The minimum supported FortiClient version for clean IPsec dialup operation with the target FortiOS version should be verified against current Fortinet documentation. Budget a FortiClient update push for the endpoint fleet as part of migration pre-work, staged before the cutover window.

How do I roll back if the SSL VPN to IPsec migration fails?

The rollback options depend on how far through the migration you are. If you have not upgraded the firmware, restore the config backup and SSL VPN is back. If you have upgraded to a FortiOS version that still includes SSL VPN on the hardware, restore the config backup and SSL VPN is back. If you have upgraded to a FortiOS version where SSL VPN binaries have been removed, rollback requires a firmware downgrade, which carries its own risk and complexity. This threshold is the most important thing to identify and document in the change ticket before the window opens. Define explicitly which point in the process represents the last cheap rollback, and make that the decision gate for the change approver.

What is the difference between IPsec dialup and ZTNA for remote access?

IPsec dialup gives the endpoint a routable IP on the internal network and pushes routes, giving the client access to internal resources the way a physical LAN connection would. It is a network-layer VPN — the security model is "trusted endpoint on trusted network." ZTNA operates per-application rather than per-network. The endpoint does not get a routable internal IP. Instead, access is brokered through a ZTNA gateway (the FortiGate or FortiSASE) for specific application destinations, with the access decision made based on device posture, user identity, and policy at the time of each connection. ZTNA requires FortiClient EMS for the endpoint posture checks that make the access decision meaningful. IPsec dialup requires no extra infrastructure. For most SMB environments without EMS today, IPsec dialup is the realistic migration target. For environments that already have EMS and want to move toward posture-based access control, ZTNA is the longer-term direction Fortinet is pushing toward.

Conclusion

The SSL VPN removal is not a hypothetical. The CVE history made it inevitable, and Fortinet is executing the removal in stages across model lines and FortiOS builds. The question for most environments is not whether to migrate but when and how.

This checklist covers the five audit areas that determine how hard the migration will actually be: what is on the box and what licenses it has, what is on the endpoints and whether they are managed, what the auth chain looks like and where it will break, what the network around the box will do to IPsec dialup, and whether the change plan has a real rollback strategy.

The engineers who have a bad migration experience are almost always the ones who skipped one of these buckets. The ones who have a clean cutover did the audit first.

Suggested next reads: The closest existing reference for the IPsec build itself — phase1-interface, phase2-interface, traffic-selector alignment, and the failure modes during Phase 2 negotiation — is the FortiGate IPsec Site-to-Site VPN to Cisco ASA on FortiOS 7.4 post. It covers site-to-site rather than dialup, but the IKEv2 negotiation, encryption-domain matching, and PFS configuration translate directly. For environments where the new IPsec dialup will live in a dedicated VDOM (a common ask when consolidating remote access onto an existing corporate FortiGate), the multi-VDOM groundwork is in How to Configure FortiGate VDOM (FortiOS 7.4). The full FortiGate path on this site is curated in the FortiGate Field Guide.