Shore Up
A locked office building with a glowing secure tunnel stretching out to a laptop at a kitchen table, a guard checking an ID badge where the tunnel meets the wall
FirewallsSecurity

Set Up SSL VPN Remote Access for Staff on a FortiGate

Ketan Aagja8 min read
No ratings yet

This walks through a standard tunnel-mode SSL VPN on a FortiGate running FortiOS 7.4, the kind you hand to remote staff with FortiClient. I'll do it in the GUI (the normal path on a FortiGate) and give the equivalent CLI so you can review or script it. Web-mode (clientless) portals are being wound down by Fortinet, so this guide is tunnel mode only.

Before you run this

What this does: It stands up an SSL VPN listener on your WAN interface, assigns connecting users an IP from a pool, and adds a firewall policy that lets an authenticated user group reach the internal network. This is an inbound-from-the-internet service — treat every step as production-impacting.

Privileges: You need an admin account with write access to VPN, firewall policy, and user configuration — in practice a super_admin profile, or a custom profile that covers all three. Access the GUI over HTTPS or the CLI over SSH.

Before you touch anything:

  • Keep a second way in. Have an out-of-band path open — the physical console port, or a management connection on a different interface than the one you're changing. A wrong firewall policy or a port collision can lock you out of management and cut production traffic at the same time.
  • Back up the running config first. System > Configuration > Backup in the GUI, or execute backup config from the CLI (see the FortiOS Administration Guide for the exact destination arguments for TFTP/USB). If anything goes sideways, restore it from System > Configuration > Restore. That restore is your rollback.
  • Do this in a maintenance window and test with one throwaway user before you tell staff it's live. Everything below is reversible by deleting the objects you create — I show that at the end — but a live SSL VPN exposed with a bad policy is a real risk, so verify scope before you announce it.
  • Port collision warning: if your admin GUI uses HTTPS on 443, do not put SSL VPN on 443 too. This guide uses 10443.

I assume you have a working WAN interface named wan1, an internal LAN interface named lan, and you're serving local users (not yet LDAP/RADIUS). Substitute your real interface names.

Step 1 — Create a user and a user group

Local users first. Replace staffuser1 and the password with your own.

User & Authentication > User DefinitionCreate New → Local User, set username and password.

Then User & Authentication > User GroupsCreate New, name it SSLVPN_Users, add the user.

CLI equivalent:

config user local
    edit "staffuser1"
        set type password
        set passwd "ReplaceWithAStrongPassword"
    next
end

config user group
    edit "SSLVPN_Users"
        set member "staffuser1"
    next
end

When you move to LDAP/RADIUS later, you add the server as a remote-server object and reference it as a member of this group instead. That's the other common path; I'm not walking through it here.

Step 2 — Confirm the tunnel IP pool

FortiOS ships a built-in address object SSLVPN_TUNNEL_ADDR1 (a small private range) that clients draw from. That's fine to start. If you'd rather use your own range, create a firewall address of type IP Range under Policy & Objects > Addresses first, and pick a range that does not overlap your LAN. I'll reference the built-in object below.

Step 3 — Configure the SSL VPN portal

The portal defines what a connected client gets — tunnel mode on, which pool, and whether to split-tunnel. FortiOS includes a built-in full-access portal. I'll set it explicitly so you can see what's in it.

VPN > SSL-VPN Portals → edit full-access:

  • Enable Tunnel Mode.
  • Under Source IP Pools, select SSLVPN_TUNNEL_ADDR1.
  • For Split Tunneling: leave it disabled to send all client traffic through the FortiGate (simplest, safest to reason about), or enable it and specify only your internal subnets. If you're unsure, start disabled.

CLI equivalent (split tunnelling off):

config vpn ssl web portal
    edit "full-access"
        set tunnel-mode enable
        set ip-pools "SSLVPN_TUNNEL_ADDR1"
        set split-tunneling disable
    next
end

If you enable split tunnelling, the routing address is set with split-tunneling-routing-address pointing at a firewall address for your internal subnet. Check the exact keyword and behaviour in the FortiOS Administration Guide before you rely on it in production.

Step 4 — Turn on the SSL VPN listener

VPN > SSL-VPN Settings:

  • Listen on Interface(s): wan1
  • Listen on Port: 10443
  • Server Certificate: the factory self-signed cert (Fortinet_Factory) works for testing, but replace it with a publicly trusted certificate before go-live so clients don't get certificate warnings. Import that under System > Certificates and select it here.
  • Authentication/Portal Mapping: add a rule mapping the group SSLVPN_Users to the full-access portal.

CLI equivalent:

config vpn ssl settings
    set servercert "Fortinet_Factory"        # replace with your real cert
    set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
    set source-interface "wan1"
    set source-address "all"
    set default-portal "full-access"
    set port 10443
    config authentication-rule
        edit 1
            set groups "SSLVPN_Users"
            set portal "full-access"
        next
    end
end

If VPN > SSL-VPN Settings isn't in your menu, check System > Feature Visibility and confirm SSL-VPN is enabled.

Step 5 — Add the firewall policy

Nothing works until a policy permits the tunnel interface (ssl.root) to reach your LAN, scoped to the group. This is the step most likely to over-expose you, so keep the destination tight — don't leave it wider than the group actually needs.

Policy & Objects > Firewall PolicyCreate New:

  • Incoming Interface: SSL-VPN tunnel interface (ssl.root)
  • Outgoing Interface: lan
  • Source: address SSLVPN_TUNNEL_ADDR1 and user group SSLVPN_Users
  • Destination: an internal address object (a specific subnet is better than all)
  • Service: only what staff need, or ALL if you're deliberately allowing everything
  • NAT: enable if your internal hosts have no route back to the tunnel pool

CLI equivalent (destination shown as all — narrow it):

config firewall policy
    edit 0
        set name "SSLVPN_to_LAN"
        set srcintf "ssl.root"
        set dstintf "lan"
        set action accept
        set srcaddr "SSLVPN_TUNNEL_ADDR1"
        set dstaddr "all"
        set groups "SSLVPN_Users"
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end

Verify it worked

From an external network (tether a phone — don't test from inside), connect with the FortiClient VPN client: gateway = your WAN IP, port 10443, the test username and password.

On the FortiGate, confirm the session:

get vpn ssl monitor

That lists connected users and their assigned tunnel IPs. In the GUI, the same appears under Dashboard > Network > SSL-VPN (or the SSL-VPN monitor widget). Once connected, have the client ping an internal host that the policy permits.

If the client connects but can't reach anything, the fault is almost always the Step 5 policy (wrong destination, wrong group, or NAT needed). If it won't connect at all, check the listener port and certificate, and confirm your upstream device isn't blocking TCP 10443 to the WAN IP.

How to undo it

Reverse order of creation. In the GUI delete the firewall policy, then clear the authentication rule and settings under VPN > SSL-VPN Settings, then the portal changes, group, and user. Or from the CLI:

config firewall policy
    delete <policy-id>            # the id shown by: show firewall policy
end

config vpn ssl settings
    unset source-interface
    config authentication-rule
        delete 1
    end
end

config user group
    delete "SSLVPN_Users"
end

config user local
    delete "staffuser1"
end

If you'd rather revert wholesale, restore the pre-change backup from Step 0 via System > Configuration > Restore — that puts the box back exactly as it was before you started.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.