FortiGate remote-access design changed materially in the FortiOS 7.6 train. Starting with FortiOS 7.6.3, SSL VPN tunnel mode is no longer available and Fortinet directs tunnel-mode deployments toward IPsec VPN. SSL VPN web mode was renamed Agentless VPN. That makes an article framed as a simple \u201cSSL VPN versus IPsec\u201d comparison misleading for current 7.6 administration: engineers now need to understand both the legacy SSL VPN architecture and the migration path to current IPsec remote access.<\/p>\n
This transition is especially important for candidates working from older labs or internal documentation. A configuration that was valid on 7.6.2 or an earlier release may not survive an upgrade to 7.6.3 as an operational tunnel-mode service. The current NSE 4 FortiOS Administrator<\/a> context therefore rewards version awareness: identify which VPN method is supported on the target FortiOS release before designing authentication, routing, policy, and user rollout.<\/p>\n Fortinet removed SSL VPN tunnel mode from the GUI and CLI beginning in FortiOS 7.6.3. Existing SSL VPN tunnel settings are not simply converted into an equivalent IPsec configuration during upgrade, so administrators must plan a manual migration. This is a release-specific architectural change, not a recommendation that administrators can ignore while keeping the old tunnel model indefinitely.<\/p>\n The change also affects terminology. SSL VPN web mode continues as Agentless VPN, which provides browser-oriented access without becoming a general replacement for client tunnel connectivity. That distinction matters because an organization may have used \u201cSSL VPN\u201d to describe two very different experiences: a full tunnel for FortiClient users and a portal for selected web applications.<\/p>\n Before any upgrade, inventory the existing remote-access population. Identify tunnel-mode users, portal-only users, authentication sources, MFA, address pools, split-tunnel routes, DNS behavior, bookmarks, host checks, and policies. The migration requirement is easier to manage when each dependency is documented rather than discovered after the old tunnel service disappears.<\/p>\n IPsec provides encrypted network-layer connectivity and is the current Fortinet direction for remote-access tunnel use on FortiOS 7.6.3 and later. The underlying IPsec architecture<\/a> uses IKE to negotiate security associations and IPsec to protect data traffic. For administrators, the important design choices include authentication, proposals, client addressing, route distribution, policy scope, and how users reach internal resources after the tunnel forms.<\/p>\n FortiClient-based dialup IPsec can give roaming users a familiar tunnel experience while aligning with current platform support. FortiOS 7.6 can also support IPsec transport over TCP 443 in relevant remote-access scenarios, which is useful where UDP-based IPsec traffic has difficulty traversing restrictive networks. That does not eliminate the need to test hotels, guest Wi-Fi, mobile networks, proxies, and other real user paths.<\/p>\n Do not treat \u201cthe tunnel is up\u201d as the success criterion. A useful validation confirms address assignment, DNS resolution, routing to approved internal networks, firewall policy, security inspection, return routing, and access to each representative application. Remote access is an end-to-end path built on the VPN, not the VPN negotiation alone.<\/p>\n Full-tunnel remote access sends a broad set of client traffic through the enterprise VPN, giving the organization more centralized control and inspection but consuming WAN bandwidth and potentially adding latency to internet-bound applications. Split tunneling sends only selected destinations through the VPN, while other traffic exits locally from the client.<\/p>\n The split-tunneling trade-off<\/a> is a security and architecture decision, not merely a performance setting. Split routing can reduce backhaul and improve cloud application performance, but the endpoint may communicate with the public internet and internal resources at the same time. The organization should evaluate endpoint controls, DNS, SaaS architecture, and data paths before deciding what should bypass the tunnel.<\/p>\n Route definitions should be as intentional as firewall rules. If the client receives an overly broad internal prefix, it can send unnecessary traffic into the tunnel and create conflicts with home or partner networks. If a required application subnet is missing, the tunnel can be healthy while the application fails. Keep a documented mapping between remote-access services and the routes clients need.<\/p>\n A remote-access VPN must establish both a secure tunnel and a trustworthy user or device identity. Authentication may use local or directory-backed accounts, RADIUS, SAML or other supported identity integrations depending on the design. Multifactor authentication raises assurance by requiring another factor beyond a password.<\/p>\n Administrators should distinguish tunnel cryptography from user authentication. Strong IPsec proposals do not compensate for weak account controls, and MFA does not compensate for an unnecessarily broad firewall policy once the user connects. Each layer addresses a different threat: channel protection, account compromise, and authorization should be designed independently and then tested together.<\/p>\n Identity-provider dependencies also need failure planning. If authentication depends on an external IdP, determine how remote users reach it, what certificates and redirect URIs are involved, and what an outage looks like. The general principles behind multifactor authentication<\/a> remain important, but implementation details must match the FortiGate and client flow.<\/p>\n After authentication, remote users should receive only the access their role requires. Separate administrative access, employee application access, third-party support, and other use cases rather than placing every remote user in one broad group. Firewall policy should define which VPN population can reach which internal destinations and services.<\/p>\n Source addresses assigned to remote clients can assist policy and logging, but group or identity context is often more meaningful than the pool alone. A pool shows where the session came from technically; the authenticated group shows why the user should have access. Use both where they add clarity.<\/p>\n Security profiles can be applied to remote-user traffic where appropriate, particularly when the traffic crosses into internet or application zones that already have inspection requirements. Avoid assuming that traffic is safe merely because it arrived through an encrypted tunnel. The tunnel proves a protected path and an authentication event; it does not prove the endpoint or payload is benign.<\/p>\n Remote-access migrations frequently fail at DNS rather than encryption. Users may depend on internal suffixes, private resolvers, split DNS, or names that resolve differently inside and outside the network. When moving from SSL VPN tunnel mode to IPsec, reproduce the necessary resolver and domain behavior and test it before pilot users are moved.<\/p>\n Applications may also bind sessions to addresses or react badly to changed MTU, fragmentation, or path length. File transfer, voice, database, and legacy thick-client applications deserve real tests over the new tunnel. Browser access alone is not representative of every remote workload.<\/p>\n Where overlapping private networks are common\u2014for example, employees whose home LAN uses the same RFC1918 range as the office\u2014consider the routing conflict explicitly. A client cannot reliably route the same prefix to both the local LAN and VPN without more specific design. Address planning, route specificity, and in some cases translation can be necessary.<\/p>\n Agentless VPN, the name used for the former SSL VPN web mode in current FortiOS releases, is useful when users need browser-mediated access to selected resources without a general network tunnel. It can reduce client requirements and narrow the exposed surface, but it is not interchangeable with IPsec for every application.<\/p>\nUnderstand what changed in FortiOS 7.6.3<\/h3>\n
Use IPsec as the current tunnel-mode foundation<\/h3>\n
Decide between full tunnel and split tunnel deliberately<\/h3>\n
Design authentication and MFA as separate controls<\/h3>\n
Map VPN users to narrow firewall policies<\/h3>\n
Preserve DNS and application behavior during migration<\/h3>\n
Use Agentless VPN for the use cases it actually fits<\/h3>\n