FortiGate SSL VPN Web Mode: Configuration Guide

FortiGate SSL VPN gives remote users secure access without a full tunnel client: in web mode, users log into a portal in their browser and reach internal applications through bookmarks - for example an RDP session to a Windows server - while in tunnel mode the FortiGate pushes a full virtual adapter and routes all traffic. Web mode is the quickest to deploy and the least invasive on endpoints. This guide follows the official Fortinet cookbook workflow: interface and addresses, local users and groups, the web portal, the SSL-VPN settings on the WAN interface, and the firewall policy that ties it together, with the matching CLI snippet.

It is worth being explicit about where web mode fits, because the two modes solve different problems and the same FortiGate can serve both at once. Web mode is a reverse-proxy-style portal: the FortiGate terminates the HTTPS session, then originates a new connection to the internal application on the user's behalf. Nothing is installed on the client, no route table entries are created and no client-side split-tunnel decision has to be made. Tunnel mode, by contrast, extends the corporate network to the endpoint and is required for protocols the portal does not proxy and for applications that open their own secondary connections.

Prerequisites and Design Decisions

Before starting, settle these four questions — each one changes the configuration you will write:

• Which internal applications must be reachable? Web mode works best for HTTP/HTTPS, RDP, SSH, Telnet, VNC and SMB through the portal's built-in proxies. Anything outside that list needs tunnel mode or a different remote-access design.
• Which interface will terminate the SSL-VPN? Using a non-standard port such as TCP 10443 avoids conflict with the admin GUI on 443 and reduces the volume of automated scanning noise.
• Which certificate will users see? The self-signed Fortinet_Factory certificate is fine for a lab but generates browser warnings in production; use a CA-issued certificate whose SAN matches the hostname users type.
• How will users authenticate? Local users are the simplest to demonstrate; most deployments ultimately use LDAP/AD, RADIUS, SAML or client certificates. The portal and policy structure is identical either way — only the user object changes.

Step 1: Interfaces and Addresses

Give the WAN interface its public IP and the internal interface its LAN IP (172.20.120.123/24 WAN, 192.168.1.99/24 LAN in Fortinet's example), then create an address object for the protected internal subnet 192.168.1.0/24.

config system interface
    edit "wan1"
        set mode static
        set ip 172.20.120.123 255.255.255.0
        set allowaccess ping https ssh
    next
    edit "port1"
        set mode static
        set ip 192.168.1.99 255.255.255.0
        set allowaccess ping https ssh
    next
end

config firewall address
    edit "LAN_192.168.1.0"
        set subnet 192.168.1.0 255.255.255.0
    next
end

Naming the address object descriptively pays off later: the same object will be referenced from the SSL-VPN portal bookmarks, from the destination of the firewall policy, and from any log filter you build, so an object called LAN_192.168.1.0 is self-documenting in a way that addr-1 never is.

Step 2: Local User and Group

Under User and Device, create a local user sslvpnuser1 with a password, then a user group sslvpngroup containing that user.

config user local
    edit "sslvpnuser1"
        set type password
        set passwd "<strong-password>"
    next
end

config user group
    edit "sslvpngroup"
        set member "sslvpnuser1"
    next
end

Always attach users to a group rather than to the portal and policy directly. Groups are the unit that the SSL-VPN authentication rule and the firewall policy both reference, so adding a second user is a one-line change to the group membership instead of an edit in two places. For anything beyond a lab, replace the local user with an LDAP or RADIUS reference at this point so that offboarding happens in the directory rather than on the firewall.

Step 3: SSL VPN Web Portal

Under VPN > SSL-VPN Portals, create a web-mode-only portal and add a predefined bookmark that launches an RDP session to the Windows server:

config vpn ssl web portal
    edit "my-web-portal"
        set web-mode enable
        config bookmark-group
            edit "bookmarks"
                config bookmark
                    edit "RDP-WINSRV"
                        set type rdp
                        set hostname 192.168.1.100
                    next
                end
            next
        end
    next
end

Leaving set tunnel-mode enable absent is deliberate — it makes this portal web-mode only, so the group mapped to it can never obtain a tunnel even if a user tries. Bookmarks are the entire user experience in web mode: each entry is a service the portal will proxy, and the type field determines which proxy is used (rdp, vnc, ssh, telnet, http, https, smb, ftp). For an HTTP bookmark you can also set a URL path and pass form-field prefill values, which is how single-sign-on style launching into an internal web app is done without any client software.

Step 4: SSL-VPN Settings on the WAN Interface

Under VPN > SSL-VPN Settings, listen on the wan1 interface, set the port (10443 in the example), pick the server certificate, and map the group to the web portal:

config vpn ssl settings
    set servercert "Fortinet_Factory"
    set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
    set source-interface "wan1"
    set source-address "all"
    set default-portal "web-access"
    config authentication-rule
        edit 1
            set groups "sslvpngroup"
            set portal "my-web-portal"
        next
    end
end

Two fields in this block are commonly misunderstood. source-address "all" restricts which source IPs are permitted to reach the SSL-VPN listener at all; restricting it to a vendor or branch range is a meaningful hardening step, but if you set it to a narrow object and then change your remote-access addressing, users are locked out with no obvious error. set default-portal is the fallback portal presented to users who do not match any authentication rule — set it to a restrictive portal rather than to the full-access one.

To move the listener to TCP 10443, add the port to the interface configuration:

config vpn ssl settings
    set port 10443
end

show vpn ssl settings
get vpn ssl monitor

The authentication rule is what binds group → portal. Multiple rules can coexist, which is how one FortiGate serves both a full-tunnel group and a web-mode-only group: each group is mapped to a portal that enables exactly the access that group is entitled to. Users matching no rule receive the default portal.

Step 5: Firewall Policy for SSL-VPN Traffic

Create an IPv4 policy whose incoming interface is the SSL-VPN tunnel interface (ssl.root), outgoing interface is the internal port1, source is the sslvpngroup, destination is the protected subnet 192.168.1.0/24, service ALL, action ACCEPT.

config firewall policy
    edit 0
        set name "sslvpn-web-access"
        set srcintf "ssl.root"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "LAN_192.168.1.0"
        set action accept
        set schedule "always"
        set service "ALL"
        set groups "sslvpngroup"
        set nat disable
    next
end

Three things about this policy are worth stating plainly, because getting any of them wrong produces a portal that authenticates successfully and then fails to open anything:

• The source interface must be ssl.root, the shared SSL-VPN virtual interface, regardless of whether the session is web mode or tunnel mode. A policy written against wan1 will never match.
• The source address is typically all because the portal originates connections from the FortiGate itself; the group field is what actually restricts access. If you set an SSL-VPN tunnel IP pool object as the source while using web mode only, the policy will not match, because web-mode portal traffic does not source from the tunnel pool.
• Destination should be the specific protected subnet, and the service should be narrowed to the protocols the bookmarks actually use. "ALL services to 192.168.1.0/24" is convenient for a first deployment and should be tightened before handover — particularly because web mode can proxy SMB, which turns an open policy into a lateral-movement path.

Verifying the SSL-VPN Service

Log into https://<wan-ip>:10443 in a browser with the local user's credentials, launch the RDP bookmark, then confirm sessions under VPN > Monitor > SSL-VPN Monitor and inspect forward traffic logs for the SSL-VPN entries.

From the CLI the same evidence is available without the GUI:

# Current sessions: user, source IP, assigned tunnel IP, duration, bytes
get vpn ssl monitor

# Live diagnostics for one user's session
diagnose vpn ssl list
diagnose vpn ssl statistics

# Is the listener actually up on the expected port?
diagnose sys TCPSock | grep 10443

# Did the policy match? Filter the forward traffic log
execute log filter category 1
execute log filter field srcintf ssl.root
execute log display

The forward traffic log is the decisive test. A log entry showing the session accepted on ssl.root with a sane byte count proves the whole chain works — listener, authentication rule, portal, policy. No log entry at all means the traffic never reached the policy, which points back at the listener or the authentication rule; a log entry that shows the policy denying the traffic points at the group membership or the destination object.

Common Problems and Fixes

• Portal loads but bookmarks fail to open. Almost always the firewall policy: wrong source interface, or a source address object that excludes web-mode portal traffic.
• Browser certificate warning. Replace Fortinet_Factory with a CA-signed certificate and make sure the CN/SAN matches the hostname users type.
• Users get the wrong portal. The authentication rule did not match — check the group name spelling and that the user is actually a member of the referenced group.
• RDP bookmark opens a blank screen. The portal's RDP proxy needs to reach the target on 3389; verify the target host is reachable from the FortiGate with an explicit source of the portal, and that the internal host's firewall permits it.
• Nothing at all on port 10443. Confirm the port is set under SSL-VPN settings and that the interface allows HTTPS-style access on that port; some upstream firewall or ISP CPE may also block non-standard ports.
• Locked out after tightening. Changing source-address to a narrow object with no admin session open is a self-inflicted outage. Keep the management GUI reachable on the internal interface while making changes.

Security Notes for Web Mode

Web mode is convenient, and convenience is the risk. Apply the standard controls from the start rather than retrofitting them:

• Enable two-factor authentication for the SSL-VPN group; the portal is internet-facing and password-only access on it is a standing invitation.
• Restrict source-address to known regions or corporate ranges if the user population is not globally distributed.
• Narrow the destination address and service on the policy to the applications that are actually published, rather than the whole internal subnet.
• Turn off any bookmark type the organisation does not use, and keep the portal free of administrative interfaces.
• Monitor failed logins and watch for credential-stuffing patterns; the SSL-VPN log is the place where attempts on the portal will show up first.

Related articles: FortiGate IPsec site-to-site VPN and Juniper SRX route-based IPsec VPN. For remote-access alternatives on other platforms see Palo Alto site-to-site IPsec VPN, and for troubleshooting tunnel negotiation more broadly, IPsec IKEv2 debugs: SA_INIT and IKE_AUTH.

原文链接：https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/579694/ssl-vpn-web-mode-for-remote-user