FortiGate remote access changed materially in FortiOS 7.6.3: SSL VPN tunnel mode was replaced by IPsec VPN, and existing tunnel-mode settings are not automatically carried forward during upgrade. That makes remote access a migration and control-design problem, not a matter of finding the old SSL VPN menu in a new interface.
For administrators following the NSE 4 FortiOS 7.6 path, the durable lesson is to separate the user-access objective from the transport technology. Users still need authenticated, authorized, observable access to private resources. What changed is the preferred tunnel mechanism and the operational work required to migrate safely.
The correct question is therefore not “how do I turn SSL VPN back on?” It is “what remote-access behaviors did the old design provide, and how do we reproduce only the justified ones with current IPsec, identity, endpoint, routing, and policy controls?” That framing avoids cloning years of accumulated exceptions into a new design.
Inventory the old remote-access behavior before changing technology
Legacy SSL VPN deployments often contain more logic than the main tunnel configuration reveals. Portal assignments, user groups, split-tunnel routes, bookmarks, per-group policies, certificate requirements, DNS behavior, address pools, and endpoint expectations may all differ between populations. If migration begins with only the headline configuration, important behavior is discovered after users lose access.
Build an inventory around user journeys instead. Which user groups connect? From which device types? To which applications? Through which authentication factors? What name resolution and routes are required? Which exceptions were temporary but became permanent? This turns migration into a controlled redesign rather than a syntax translation exercise.
IPsec over TCP 443 solves reachability constraints, not trust design
FortiOS 7.6.3 allows IPsec remote access to use TCP port 443, which helps in environments where traditional IPsec transport is blocked or difficult. That feature can preserve connectivity characteristics users associated with SSL VPN, but it does not automatically reproduce authorization, endpoint posture, or segmentation decisions.
The transport should therefore be treated as one layer. Authentication proves who is connecting, endpoint controls help establish what is connecting, policy defines which resources are reachable, and logs provide evidence about what happened. A migration is successful only when those layers still express the intended trust boundary.
Split tunneling should be justified per traffic class
Sending only private application traffic through the tunnel reduces bandwidth consumption and can improve user experience, but it means internet traffic leaves through the user’s local network rather than the enterprise security stack. Full tunneling centralizes inspection but increases dependency on gateway capacity, egress architecture, and latency. The role of the gateway itself is clearer when read alongside VPN headend architecture.
There is no universally correct choice. The decision should consider data sensitivity, SaaS usage, endpoint protection, regional performance, logging requirements, and incident-response needs. A useful companion is the broader explanation of split tunneling in VPNs, but the FortiGate design still needs to map that trade-off to actual user groups and applications.
Remote-access policy should assume credentials can be stolen
Username and password alone are a weak trust boundary for internet-facing access. Multifactor authentication, certificate-backed device identity, constrained user groups, and least-privilege policy reduce the value of a stolen password. The design should also consider how inactive accounts, contractors, and emergency access are removed or reviewed.
This is where remote access intersects with a broader zero-trust security model. The useful idea is not the label itself but continuous skepticism about identity, device, and session context. A successful login should open only the specific access that the role and current context justify.
Address assignment and DNS behavior can break applications after migration
Users may authenticate and establish a tunnel yet still report that “nothing works” because address pools overlap with local networks, internal DNS is not reachable, split-DNS behavior changed, or routes do not include a required service. These are not secondary details; they determine whether the client can locate and reach protected resources.
Migration testing should therefore use real application names and workflows, not only ping tests. Resolve internal names, access representative web and client/server applications, test long-lived sessions, and verify return routes from server networks back to the remote-access pool. A tunnel indicator cannot substitute for end-to-end validation.
Policy segmentation is more valuable than recreating a broad remote network
Older VPNs often placed remote clients into a network where policy was permissive because the original assumption was “connected means trusted.” Rebuilding that model with a new tunnel technology preserves the most dangerous part of the old architecture. Migration is an opportunity to separate administrators, employees, vendors, and specialized application users into distinct policy relationships.
Segmentation also improves incident response. If one credential or endpoint is compromised, the reachable resource set is smaller and easier to reason about. Logging becomes more meaningful because policy identity maps more closely to business purpose rather than a single rule that permits every remote user to reach a large internal range.
Endpoint failures should be separated from gateway failures
Remote access spans software and policy on both sides. Client version, certificates, local firewall behavior, device clock, DNS cache, network changes, and operating-system security settings can all break a connection that the FortiGate is ready to accept. Treating every failure as a gateway problem encourages unnecessary firewall changes.
A useful support model records where the process stopped: client initiation, network reachability, IKE exchange, authentication, address assignment, route installation, policy, or application. That staged view is similar to the broader discussion of VPN failure analysis, but the evidence must come from the actual FortiGate, client, and application path.
Migration needs a rollback plan because old tunnel settings are not preserved automatically
The FortiOS 7.6.3 change is unusually consequential because SSL VPN tunnel-mode configuration is not simply upgraded into an equivalent IPsec configuration. Teams should therefore build and test the new access path before the production upgrade, document user-impact windows, and define what happens if a required application behaves differently after cutover.
Rollback planning should include configuration backups, version compatibility, client distribution, communication, and an explicit decision point for aborting the change. The safest migration is one in which the team can identify failure early and restore known service without improvising under outage pressure.
A migration pilot should deliberately include awkward users rather than only IT staff on managed laptops. Test users behind restrictive hotel Wi-Fi, home routers with unusual NAT behavior, mobile hotspots, overlapping local subnets, and long-lived applications. Include users whose access is narrower than the default employee policy. These scenarios are where a new remote-access design reveals assumptions that a clean office test never exercises. The approved article on remote-work VPN and home-network challenges is relevant because endpoint networks are part of the production path even when the enterprise does not control them.
Support readiness should be treated as part of the cutover. Help-desk staff need a small set of observable checkpoints: can the client reach the gateway, does IKE start, does authentication complete, is an address assigned, are expected routes installed, and does policy allow the target resource? A migration that changes technology without updating support diagnostics creates a hidden operational regression even if the security design is better.
Remote access should also be tested during identity disruption. If the primary identity provider, MFA service, certificate validation path, or directory group lookup is unavailable, the team should know whether users fail closed, which emergency access exists, and who can authorize it. Resilience that bypasses the intended trust boundary is not resilience; it is an undocumented alternate security model.
Emergency access deserves its own design rather than an undocumented bypass. If remote employees cannot authenticate during a major identity outage, the organization may need a tightly constrained break-glass path for a small operations group. That path should use separate credentials or certificates, narrow destinations, strong monitoring, and explicit activation procedures. The purpose is to restore critical administration without converting an identity outage into a period of unrestricted network access.
The migration should also leave behind a simpler documentation set. Record the current Fortinet remote-access method, supported client versions, authentication dependencies, address pools, DNS behavior, policy destinations, and the evidence support staff should collect. Pair that documentation with the broader concept of split-tunnel behavior so design choices remain understandable after the original migration team has moved on.
The new remote-access model should be easier to explain than the old one
A successful redesign produces a simple narrative: which users may connect, how they authenticate, what endpoint requirements apply, which resources they can reach, how traffic is routed, what is inspected, and which logs prove the control is working. If the new design requires tribal knowledge to explain exceptions, the migration has reproduced technical debt instead of removing it.
Current FortiGate administration is therefore less about preserving SSL VPN terminology and more about preserving justified access outcomes. IPsec is the transport Fortinet now emphasizes for tunnel-mode remote access; the security quality still depends on identity, segmentation, endpoint trust, routing, policy, and evidence around that transport.
