Move your remote users to IPsec IKEv2 before upgrading a FortiGate that still serves SSL VPN tunnel-mode clients. In FortiOS 7.6.3 and later, SSL VPN tunnel mode is unavailable and its configuration does not carry forward. SSL VPN web mode is a separate feature, called Agentless VPN in FortiOS 7.6.3. Inventory browser-only workflows separately if your organization uses them.
FortiOS 7.6.3 release notes · Fortinet Agentless VPN documentation
1. Inventory what SSL VPN delivers today
Take an approved configuration backup and record the current FortiOS build, model, VDOM, WAN interface, public DNS name, client OS versions, and FortiClient builds. On a build that still supports SSL VPN tunnel mode, these commands show the existing settings and portals:
get system status
show vpn ssl settings
show vpn ssl web portal
Use the firewall policy list and traffic logs to identify the rules that reference the SSL VPN interface, typically ssl.root in the root VDOM. Record the resources, ports, and user groups those rules permit. Some organizations discover during a pilot that a portal also supplied an internal DNS server or a route to a subnet absent from the documented application inventory.
| Existing setting | IPsec migration check |
|---|---|
| Portal and group mapping | Identify which users can connect and which resources each group can reach. |
| Client address pool | Allocate a non-overlapping pilot pool and confirm the internal return path. |
| Split tunnel routes | Recreate the approved networks and verify client routing after connection. |
| Internal DNS | Verify resolver addresses, reachable DNS services, and the client’s handling of internal names. |
| MFA and device requirements | Check support for the exact authentication method, FortiClient platform, and management mode. |
| Firewall rules | Create policies for the new IPsec interface with the intended destinations and services. |
2. Build an IKEv2 pilot alongside SSL VPN
Use the Fortinet migration guide for your starting FortiOS version to create a route-based dial-up IPsec tunnel. Configure IKEv2, an approved authentication method, and compatible Phase 1 and Phase 2 proposals. Use mode config to assign a client address and distribute the applicable DNS settings and split routes. Keep pilot membership small and document the mapping from the old portal to the new IPsec profile.
Create VPN-to-LAN policies on the IPsec tunnel interface. Start with the applications and services your pilot users need. Confirm that LAN gateways route replies for the new pool back through the FortiGate. Check how the firewall rules apply identity for your selected VPN design, then test two accounts with different access requirements. For a full-tunnel design, verify the separate internet egress policy and its NAT behavior.
Fortinet SSL VPN tunnel mode to IPsec VPN migration
3. Choose a transport the pilot can actually reach
For a UDP pilot, verify UDP 500 for IKE and UDP 4500 for NAT traversal. Test from at least one network outside the office and one network behind NAT. If a required client network restricts UDP, check whether the FortiOS and FortiClient builds support the intended IPsec over TCP configuration.
TCP 443 requires a listener review before you deploy it. Check what already uses that port on the same IP and interface, including administrative HTTPS and the existing SSL VPN listener. Fortinet documents an administrative HTTPS conflict for interfaces bound to an IPsec tunnel using that port. Check the effective IKE-TCP port on upgraded appliances as defaults for new configurations may differ from existing settings. Use a pilot transport or listener that lets you keep a working management path.
Fortinet migration transport guidance · Fortinet IKE-TCP port conflict notes
4. Validate the tunnel and application access
Connect a pilot user and run the following from the relevant VDOM. Replace the placeholder with your configured Phase 1 name.
diagnose vpn ike gateway list name <phase1-name>
diagnose vpn tunnel list name <phase1-name>
Use the gateway output to verify that IKE negotiated. Use the tunnel output to inspect the IPsec security association and compare packet counters before and after a controlled application request.
| Pilot result | Next check |
|---|---|
| No IKE gateway appears | Check public DNS, listener reachability, client transport and port, and WAN interface selection. |
| IKE negotiation starts but fails | Compare IKE versions, proposals, identities, authentication logs, and client compatibility. |
| IKE establishes but no usable IPsec association appears | Check Phase 2 proposals and traffic selectors. |
| Tunnel connects but applications time out | Check client routes, policy hits, and the return route for the VPN pool. |
| An application works by IP but fails by name | Check the DNS server assigned to the client, the route to it, and DNS policy. |
| A user can reach a resource outside their role | Review group matching and policy scope before expanding the rollout. |
For example, a pilot user gets an address from the new pool and can open the application by IP. The hostname fails to resolve. Check which resolver the client uses and whether its address is routed through the tunnel. Use a query against that resolver to distinguish DNS reachability from a missing record or an incorrect DNS suffix.
Fortinet IPsec diagnostic commands
5. Roll out in waves before the firmware upgrade
Start with IT, then include users across operating systems, access networks, and authentication groups. Test MFA, reconnect after a network change, internal DNS, access to critical applications, and denial for out-of-scope resources. Confirm that help desk staff can identify the profile and distinguish a negotiation failure from an application access issue.
Publish the new FortiClient profile through your normal endpoint management process and track who has successfully connected. While the current firmware still supports SSL VPN tunnel mode, retain the tested legacy access path during the pilot if your migration plan permits it. Once users rely on IPsec, retire the legacy configuration through your change process and proceed with the firmware upgrade. After upgrading, rollback requires the approved firmware and configuration recovery plan if the old access path must be restored.