FortiSASE administration and onboarding

Why Harbourline's remote access VPN stopped scaling

Harbourline Retail, the fictional company of this course, protects its 80 office staff with FGT1. Another 120 people work from home or travel, and they connect with a full-tunnel remote access VPN to FGT1's port1 (203.0.113.2). Every web page, video call and SaaS session they open goes to headquarters first, through FGT1's security profiles, and then back out to the internet.

It worked for 15 users. With 120, the HQ internet link is saturated in the morning, calls to a SaaS provider in another country take a detour through the office, and some sales staff simply disconnect the VPN to get work done, which leaves their laptops with no web filtering at all. Contractors on their own laptops had no VPN access, so nobody inspected their browsing. A pop-up shop opening for three months needs secure Wi-Fi for its tills and staff, with no IT person on site.

These are the usual remote-work problems:

• Backhauling. Sending traffic to a central firewall adds latency and loads the HQ link, even for traffic with no reason to go there.
• Gaps in coverage. Users off the VPN, or on devices without a client, are outside every policy.
• SaaS and cloud. Most traffic now goes to the internet, not to the data centre.
• Inconsistent policy. Office, home and branch users get different protection and produce logs in different places.

What a SASE architecture changes

SASE moves the security stack to the cloud, near the users. Each user or site connects to the nearest security PoP, the PoP applies the policy, and traffic continues from there. FortiSASE builds this from parts that a FortiGate administrator already knows:

The security features are the ones from the security profiles module: antivirus, application control, data loss prevention, DNS filter, IPS, file filter, web filter and SSL inspection. They are configured in the FortiSASE portal with settings that look familiar from FortiOS, and FortiSASE is licensed per user.

The three FortiSASE use cases

By default all remote-user traffic is tunnelled to FortiSASE, so the three use cases share the same path. ZTNA is the exception: there FortiClient connects straight to the FortiGate access proxy that protects the application.

Choosing how each user group joins

Onboarding is the exam's focus, and the choice depends on the device, not the person. Fortinet's architecture guide compares the internet-access methods like this:

For Harbourline: company laptops get FortiClient, contractors use the proxy, and the pop-up shop gets a FortiAP. In practice, most organisations put managed devices on the agent first, because it covers every protocol and carries endpoint information for ZTNA, and keep the proxy for the devices they don't control.

Onboarding remote users in the FortiSASE portal

Step 1: decide where users come from

Users are defined under Access & authentication. FortiSASE can hold local users or use remote sources:

DC1 sits on 10.0.1.5, a private address. FortiSASE can use an internal LDAP or RADIUS server only when the server's Access Type is set to Private and the server is reachable behind an SPA hub (step 4 below). Without that, the directory has to be reachable on a public address.

Step 2: onboard managed laptops with FortiClient

Open the Onboard Users slide-in from Access & authentication › Access › Users and groups (or from the Remote users widget under Monitoring › Dashboards › Status). Its Managed Endpoint Users part offers two deliveries:

• Download installer. The Windows and macOS installers come preconfigured with the instance's default invitation code, ready for an MDM or UEM tool. Android, iOS and Linux installers are the public ones, so those users type the invitation code themselves.
• Send link to installer. Enter users' email addresses and FortiSASE sends each one links to installers for the main operating systems.

Once installed, FortiClient registers with the Endpoint Management Service, activates the FortiSASE licence and brings up a persistent tunnel to the nearest PoP. From then on the user does nothing special; the policy follows the laptop.

An invitation code on its own is enough to register an endpoint. Authenticated onboarding, a select-availability feature enabled through FortiCare, adds a SAML sign-in to that step so only authenticated users can register.

Step 3: onboard unmanaged browsers with the proxy

• Network › Proxy configuration shows the proxy server name, port and the hosted PAC file. The default PAC file points browsers at the instance's global proxy address and port, which directs users to the closest PoP.
• Exceptions (for example an identity provider's sign-in pages that must not be proxied) go into a custom PAC file, created under Hosted PAC files in the same menu or edited offline and hosted elsewhere.
• If deep inspection is used, the FortiSASE CA certificate must be installed on each device; on Windows domain machines, Group Policy can push both the certificate and the PAC file URL.
• The user signs in with FortiSASE credentials when the browser prompts.

Step 4: connect sites and private applications

Edge devices live under Operations › Connectivity › Edge devices. A FortiAP or FortiExtender becomes a micro-branch: the device connects to FortiSASE, an administrator authorises it, and FortiSASE assigns the client subnet from its IP address management pools. A FortiGate can join as a secure edge (LAN extension) over a VXLAN-over-IPsec tunnel, which needs its own FortiSASE licensing and a supported model; check the FortiSASE guide before planning it. Any other IPsec device can use a Branch On-ramp PoP instead.

For private access, FGT1 becomes the SPA hub. In Operations › Connectivity › Secure private access you add the hub with its remote gateway (203.0.113.2), the authentication method (for example a pre-shared key), the hub's BGP peer IP and an overlay ID; the BGP routing design (BGP per overlay by default) is set under Network › BGP. Each PoP then acts as an IPsec spoke of FGT1, with BGP carrying the routes to 10.0.1.0/24. FortiSASE supports up to 12 hubs.

Learn more: Site-to-Site IPsec VPN · SD-WAN Basics

Step 5: tighten the default policy

A new instance has two agent policies: Allow-All, which lets remote agents reach every service and applies the enabled security features, and Implicit Deny at the bottom. Allow-All can be edited or deleted, and it should be replaced with policies for real user groups and services before go-live, exactly as an "all to all" rule would be on a FortiGate.

Proving the onboarding worked

• Operations › Connectivity › Connected users lists authenticated users with their groups. Add the FortiSASE agent session column to see a user's public source IP and their FortiSASE tunnel IP.
• The FortiSASE logs show which policy and security features handled a user's sessions.
• From a connected laptop, ping 10.0.1.5 tests private access to DC1 through the SPA hub (ICMP must be allowed by the policies on both FortiSASE and FGT1).

On FGT1, the hub side, the tunnels from each PoP should be up and passing traffic:

FGT1 # get vpn ipsec tunnel summary
'ToSpokes_0' 198.51.100.40:64916  selectors(total,up): 1/1  rx(pkt,err): 2689/0  tx(pkt,err): 1043/0
'ToSpokes_1' 198.51.100.41:52270  selectors(total,up): 1/1  rx(pkt,err): 2710/0  tx(pkt,err): 1102/0

Where FortiSASE onboarding goes wrong

A contractor's browser shows certificate errors on every HTTPS site

Pages load through the proxy, but each one warns that the certificate is not trusted.

SSO users of the proxy can't sign in after a PAC file change

A custom PAC file was published, and now the SAML sign-in page loops or fails.

Remote users reach the internet but not DC1

FortiClient is connected and browsing works, but ping 10.0.1.5 times out.

Test yourself on FortiSASE