NSE4 Part 7: SSL VPN

25 April 2026 FortinetNSE4FortiGateVPNSSL VPNSecurityCertification

NSE4 Part 7: SSL VPN

Part 7 of the NSE4 series. This post covers Lesson 12 of the official curriculum — SSL VPN, the most-used remote access option on FortiGate.

SSL VPN modes

A FortiGate offers three SSL VPN modes; an exam question often shows a portal definition and asks which mode is configured.

Mode	Client	Use case
Web-only	Browser	Bookmark-driven access to internal web apps; no client install
Tunnel	FortiClient (or third-party SSL VPN client)	Full layer-3 tunnel, IP from VPN pool
Full	Browser or FortiClient	Web portal that can also launch a tunnel session

Per-portal:

config vpn ssl web portal
    edit "tunnel-only"
        set tunnel-mode enable
        set web-mode disable
        set ip-pools "ssl-vpn-pool"
        set split-tunneling enable
        set split-tunneling-routing-address "corporate-net"
    next
end

The settings block

Top-level SSL VPN configuration:

config vpn ssl settings
    set servercert "wildcard.example.com"
    set tunnel-ip-pools "ssl-vpn-pool"
    set source-interface "wan1"
    set source-address "all"
    set default-portal "tunnel-only"
    set port 10443
end

Notes the exam targets:

servercert must be a cert the client trusts. Self-signed will work but produces a warning. Real deployments use a public CA cert with the SSL VPN hostname in the SAN.
port 10443 is the typical choice — port 443 collides with the admin GUI if https is in allowaccess on the same interface.
source-interface + source-address lock down where the SSL VPN listens. Geo-block by setting source-address to a country object.

Realms

A realm lets multiple portals share the same listener under different URL paths. A realm partners becomes:

https://vpn.example.com:10443/partners

Used to give different user groups different portals (with different bookmark sets, IP pools, split tunnel scope) on the same FortiGate. Configured under config vpn ssl web realm.

Authentication and MFA

User authentication walks the standard chain (covered in Part 4) — local, LDAP, RADIUS. The mapping happens in the firewall policy that uses the SSL VPN tunnel interface as ingress:

config firewall policy
    edit 100
        set srcintf "ssl.root"
        set dstintf "port1"
        set srcaddr "ssl-vpn-pool"
        set dstaddr "internal-net"
        set users "alice"
        set groups "ssl-vpn-users"
        set service "ALL"
        set action accept
        set schedule "always"
    next
end

Two-factor auth options on the user side are unchanged: FortiToken, email, SMS, or RADIUS-relayed (Duo, RSA, etc.). For RADIUS-based MFA, the client sees a challenge prompt during connect — important to know that some older SSL VPN clients can’t handle multi-prompt RADIUS conversations gracefully.

Split tunnelling

Decides whether all client traffic goes through the FortiGate or only traffic destined to specific subnets:

Setting	Behaviour
Disabled	All client traffic via VPN (default route pushed)
Enabled	Only routes to listed subnets via VPN; rest goes direct
Enabled (based on policy and routing)	FortiGate pushes routes derived from firewall policy destinations

Performance-wise, split tunnelling is the right default for most remote workers — pushing all consumer streaming and video calls back through the FortiGate eats licence and bandwidth for no security benefit. Block local LAN access (prefer-dtls-tunnel, dns-server-override) and force corporate DNS if you need to maintain visibility.

Web portal bookmarks

Web-mode portals expose internal apps as bookmarks. Supported types include HTTP/HTTPS, RDP, SSH, VNC, SMB. The FortiGate proxies the connection — clients never get layer-3 network access, only application-level reach.

config vpn ssl web portal
    edit "web-only"
        set tunnel-mode disable
        set web-mode enable
        config bookmark-group
            edit "Apps"
                config bookmarks
                    edit "wiki"
                        set apptype web
                        set url "http://wiki.corp.local"
                    next
                end
            next
        end
    next
end

Diagnostics

Three commands solve most SSL VPN tickets:

diagnose vpn ssl list
diagnose vpn ssl statistics
diagnose vpn ssl info

They show connected sessions, allocated IPs, cipher suites in use, and current connection counts. For deeper trace:

diagnose debug application sslvpn -1
diagnose debug enable

(Remember to diagnose debug disable afterwards — left running, it’s noisy.)

Common exam scenarios and their resolutions:

Connects but no traffic flows → no firewall policy from ssl.root to internal interface, or pool IPs not in policy srcaddr.
Connection times out at handshake → source-interface or source-address blocking; or admin GUI on the same port.
Routes pushed but DNS broken → dns-server not set on portal; clients use their own DNS and can’t resolve internal names.
Cert warnings on every connect → using built-in self-signed cert; replace with public CA cert or deploy internal CA to clients.

Part 8 covers IPsec VPN — IKEv1/v2, route-based vs policy-based, dial-up, and the diagnostic commands that distinguish a phase 1 problem from a phase 2 problem.