FortiGate SSL VPN — Web Mode and Tunnel Mode

The one-sentence mental model

SSL VPN turns TLS into a VPN transport. No IPsec, no UDP 500/4500, no NAT-T headaches. Runs on TCP 443 — the same port everything already lets out. That’s why it’s the road-warrior standard for corporate remote access.

Two modes, different use cases

Web mode (clientless)

• User points a browser at https://vpn.company.com.
• Authenticates → sees a portal page.
• Portal shows bookmarks: RDP, VNC, HTTP internal sites, SSH.
• FortiGate proxies each session — user never gets a real IP on the corporate LAN.

Pros: no client to install. Works from unmanaged devices (kiosk, contractor laptop). Fast to grant granular access.

Cons: only apps FortiGate can proxy. No thick-client (SAP, custom apps). Latency higher than tunnel mode.

Tunnel mode (full VPN client)

• User launches FortiClient (or the free FortiClient VPN-only build).
• Client authenticates, establishes TLS tunnel, receives an IP from the SSL-VPN pool.
• Traffic destined for corporate subnets (or all traffic, depending on split-tunnel config) is encapsulated over TLS.

Pros: full Layer 3 — anything IP-based works. Same experience as being on the LAN.

Cons: needs a client. IT owns the client lifecycle.

Design decision: split tunnel vs full tunnel

Full tunnel: every packet the user’s device sends goes through the FortiGate.

• Wins: full DPI on user traffic. DLP works. Web filtering enforces the corporate policy at home.
• Loses: doubles WAN traffic (user traffic + return). Streaming/Zoom quality drops.

Split tunnel: only traffic to corporate subnets goes over the VPN.

• Wins: user’s Netflix / Zoom / general internet goes direct. Great UX.
• Loses: security team has no visibility on that traffic. If the user’s home network is compromised, the endpoint is exposed.

Current best practice (2026): inverse split tunnel — full tunnel by default but exempt a small list of trusted high-bandwidth destinations (Microsoft 365, Zoom, WebEx). Best of both.

Configuring SSL VPN (tunnel mode)

Portal:

config vpn ssl web portal
  edit "full-access"
    set tunnel-mode enable
    set web-mode disable
    set ip-pools "SSLVPN-Pool"
    set split-tunneling disable      # or "enable" for split
  next
end

Settings:

config vpn ssl settings
  set servercert "Fortinet_CA_SSL"
  set port 443
  set source-interface "wan1"
  set tunnel-ip-pools "SSLVPN-Pool"
  set dns-server1 10.0.0.53
  config authentication-rule
    edit 1
      set groups "SSLVPN-Users"
      set portal "full-access"
    next
  end
end

Firewall policy — from the SSL VPN interface (ssl.root) into the LAN:

config firewall policy
  edit 90
    set srcintf "ssl.root"
    set dstintf "internal"
    set srcaddr "SSLVPN-Pool-Range"
    set dstaddr "corporate-lan"
    set service "ALL"
    set action accept
    set schedule always
    set groups "SSLVPN-Users"
  next
end

Notice groups on the policy — this is FortiOS enforcing group-based access post-authentication.

Authentication options

• Local users — quickest, doesn’t scale.
• LDAP — Active Directory. Most common. Group filter tells FortiGate which AD group can VPN.
• RADIUS — often used to chain into 2FA (FortiToken, Duo, Okta).
• SAML — modern SSO. FortiGate is the Service Provider; Azure AD / Okta / Ping is the IdP. Enables MFA / conditional access at the IdP.

Multi-factor is not optional for real deployments. Two paths: FortiToken (Fortinet’s own OTP) or an external MFA (Duo Push, Microsoft Authenticator via RADIUS or SAML).

Host checking

FortiOS can require the FortiClient endpoint to pass posture checks before completing the tunnel:

• OS version
• Antivirus running + up to date
• Disk encryption enabled
• Domain-joined

Fail = deny (or grant limited “remediation” access).

Diagnostics

diagnose vpn ssl statistics             # tunnels up, users connected
diagnose vpn ssl list                    # list of active sessions
execute vpn sslvpn del-tunnel <user>     # kick a specific user

FortiClient side: check the client’s VPN log for TLS handshake errors, cert warnings, DNS resolution issues.

Common exam / real-world mistakes

1. Wrong server certificate. The default Fortinet_CA_SSL cert triggers browser warnings. Use a public cert (Let’s Encrypt, DigiCert) for the SSL VPN interface.
2. Missing DNS server config in the portal. Users connect but can’t resolve intranet.company.local because the tunnel doesn’t push a DNS server.
3. Forgetting group-based policy enforcement. Everyone in AD becomes a VPN user. Restrict via groups on both the auth rule and the firewall policy.
4. Blindly enabling split tunnel. Answers UX complaints but blinds the security team. If you split-tunnel, at minimum push a DNS security service (Umbrella / FortiGuard DNS) client-side.
5. Not testing MFA fallback. If SAML IdP is down, VPN is down. Have a break-glass local-account path (audited).

Cheat strip

Web mode    clientless portal on HTTPS. FortiGate proxies apps.
            Bookmarks: RDP / VNC / HTTP / SSH.
Tunnel mode FortiClient builds L3 tunnel. Full IP.
Port        TCP 443 (default). Configurable.

Split       corporate subnets only over VPN. Better UX, less visibility.
Full        everything over VPN. Full inspection, more bandwidth.
Inverse     full tunnel except allow-listed SaaS. Current best practice.

Auth        Local | LDAP | RADIUS | SAML  (+ MFA)
Posture     OS ver | AV state | disk crypto | domain join

Debug       diagnose vpn ssl statistics
            diagnose vpn ssl list