FortiSASE policy web, private, then path

Lessons · FortiSASE · SWG, ZTNA, SD-WAN policy

Hero · one user, three exits

Why internet working is not private access

The day-one ticket is always the same: “SASE is up, so the private app should work.” Wrong. SWG succeeding only proves the endpoint reached a FortiSASE PoP and hit an internet policy. RFC1918 never uses that list.

Three silent-zero states look identical from the laptop (timeout to 10.20.20.80):

• SWG/SIA policy is accept; there is no ZTNA application object and no SPA To-hubs policy for 10.20.20.80.
• ZTNA app exists for TCP/443, but the user asked for SMB/UDP or a whole subnet — ZTNA access proxy does not carry that.
• SPA hub IPsec is up, BGP has 10.20.20.0/24, and the To-hubs catch-all is still below a deny, or the endpoint is missing tag SASE-Compliant.

SWG, ZTNA, SD-WAN — three engines

Fortinet’s SASE split is SSE + networking. In the product that is FortiSASE (cloud SWG, ZTNA, FWaaS, CASB) joined to FortiGate Secure SD-WAN as the SPA hub. You still configure three policy families in the FortiSASE portal.

Path · web, then private, then path

Web, private, then path

Do not start at the hub. Classify the destination. Internet stays on SWG. Private TCP with an access proxy stays on ZTNA. Everything that needs a routed overlay — subnet, UDP, spoke-to-hub — takes SD-WAN SPA, then a To-hubs accept.

Which engine for this ticket

Pick by destination and protocol, not by license SKU. Mixing engines is the usual “internet is fine” ticket.

Runbook Side A / B / C

Side A is identity and steering. Side B is the three policy families. Side C is logs plus hub health. Do not start at C.

Side A — who is on the wire

1. Identity and posture

   SAML / LDAP / RADIUS group remote-users. Security posture tagging rule set that emits SASE-Compliant / SASE-Non-Compliant for agent-based users. Source: FortiSASE Administration Guide — Configuring security posture tagging rule sets; Supporting external IdP users.

2. Steering

   Agent-based: FortiClient connected to the FortiSASE instance. Agentless SWG: PAC from System › SWG Configuration, corporate prefixes returned DIRECT so 10.20.20.0/24 is not hairpinned into the proxy. Source: FortiSASE — Downloading and customizing the PAC file.

function FindProxyForURL(url, host) {
  if (isInNet(host, "10.20.20.0", "255.255.255.0") ||
      isInNet(host, "127.0.0.0", "255.0.0.0")) {
    return "DIRECT";
  }
  return "PROXY <fortisase-swg-host>:10447; DIRECT";
}

Side B — one policy family per destination

1. SWG / SIA

   Security › Traffic › Policies (internet / SWG / proxy). Accept for remote-users, dest internet, attach a profile group (web filter, DNS, AV, SSL). Log all sessions. Source: FortiSASE — Security profiles; Configuring a SWG policy.

2. ZTNA application

   SPA using ZTNA: FortiGate access proxy publishes web-int = 10.20.20.80:443. Agentless: Configuration › Agentless ZTNA — private application, application policy, bookmark portal. Still TCP. Source: FortiSASE Architecture Guide — SPA using ZTNA; Administration Guide — Agentless ZTNA.

1. SD-WAN SPA hub, then To-hubs

   Service connection: FortiSASE PoPs as spokes of hub 10.20.20.1 / WAN 192.0.2.1. BGP advertises 10.20.20.0/24. Then the To-hubs policy above. If the hub initiates to users, add From hubs. Source: FortiSASE — Configuring a new service connection; Viewing health and VPN tunnel status.

Side C — prove the engine that fired

1. SWG proof

   From the laptop, HTTPS to 203.0.113.80. FortiView / Analytics traffic log: policy Allow-Web-HTTPS (or Allow-All), dest is internet, action accept. Empty private-access log is expected.

2. ZTNA proof

   HTTPS to web-int. Log shows the application policy, user, tag SASE-Compliant. Access-proxy health on the FortiGate is up. A SWG hit for that FQDN means you steered it to the internet engine — wrong class.

3. SPA proof

   Operations › SPA hub monitoring: IPsec up, BGP has 10.20.20.0/24. Traffic log on Secure private access, policy Allow-SASE-Compliant. On the hub: IPsec and BGP as in FortiSASE — Verifying IPsec tunnels on the FortiGate hub; Verifying BGP routing.

One flow after go-live

Laptop SYN to 203.0.113.80:443. FortiClient steers to PoP. Identity remote-users. Dest is internet → SWG policy accept + profile group. Session logged on SIA. Private prefixes in PAC stay DIRECT / off this path.

Same laptop SYN to 10.20.20.80:443 as ZTNA app web-int. Dest class = named TCP app → access proxy, posture SASE-Compliant, application policy accept. No BGP required for that one host if ZTNA is the design.

Same laptop SMB to 10.20.20.10. Dest class = routed subnet / UDP-capable → SPA overlay. PoP IPsec to hub 192.0.2.1, BGP next-hop 10.20.20.1, To-hubs Allow-SASE-Compliant. Hub FortiGate still needs its own LAN policy. SWG never sees this flow.

Proof · three log rows, not one dashboard tile

Traps + proof

Sources

• FortiSASE Administration Guide — SWG Policies / Configuring a SWG policy; Agentless ZTNA; Security profile groups; SSL Inspection
• FortiSASE Administration Guide — Configuring a private access policy for client-to-server traffic (To hubs)
• FortiSASE — Dynamic private access policies using security posture tags (Allow-SASE-Compliant above Allow-All; Location = Private Access Hub)
• FortiSASE Architecture Guide — SIA vs SPA using ZTNA (TCP, access proxy) vs SD-WAN private access (all protocols, FortiGate hub)
• FortiSASE Unified SASE for MSSP Architecture Guide — Security policies (SIA, SPA To Hub, SPA From Hub; proxy policies and posture tags)
• FortiSASE — System › SWG Configuration / PAC customization; Viewing health and VPN tunnel status; Verifying IPsec / BGP on the FortiGate hub
• Fortinet Cyberglossary — SASE = SSE (SWG, ZTNA, CASB, FWaaS) + SD-WAN

Related: FortiClient steering and private access · FortiGate ZTNA tags · FortiGate zone, policy, NAT