PoP Selection and Split Tunnel for a Global FortiSASE Pilot
A 2,400-employee manufacturer is deploying FortiSASE for secure internet access. Headquarters is in Chicago; data centers are in Frankfurt and Singapore. The user base is 800 in the Americas, 700 in EMEA, and 900 in APAC. Compliance requires internet-bound traffic from EMEA users to be inspected in the EU. During a 50-user Singapore pilot, users are automatically assigned to the default PoP in Northern Virginia and report 180 ms latency; Teams improves after a split-tunnel change, but SharePoint remains slow. FortiClient 7.4 is deployed through Entra ID SSO, and private applications use an existing FortiGate IPsec tunnel, not FortiSASE private access. Some pilot users stop the FortiClient service and browse directly. The project has six weeks, no new data centers, and a fixed FortiSASE user license.
1. Which PoP and client settings would you validate first, and what evidence would prove EMEA traffic remains compliant?
Read the worked answer
Start by separating tenant-level PoP availability from client-level selection. FortiSASE assigns users to a PoP based on the tenant region and the client's location, so confirm that the Singapore PoP is enabled for the tenant and that the FortiClient 7.4 profile is not pinned to the Northern Virginia gateway. Validate with client diagnostics, a traceroute to a known SaaS endpoint, and the egress IP seen in FortiSASE traffic logs. If Singapore is available, APAC users should resolve to it automatically; do not manually force EMEA users to APAC just to fix latency. Create or use separate client profiles per region if the tenant supports preferred PoP settings. To prove EMEA compliance, run a test from an EMEA user, capture the FortiSASE log's PoP and egress region, and confirm the traffic is inspected by an EU PoP. If the tenant license only covers one region, document that as the blocker; client tuning cannot satisfy the EU requirement.
2. Why did Teams improve after the split-tunnel change while SharePoint stayed slow, and what would you inspect next?
Read the worked answer
Split tunneling is destination-based, so improving Teams does not automatically fix SharePoint. Teams traffic may have matched the optimized Microsoft 365 endpoints added to the split-tunnel list, while SharePoint and OneDrive traffic still matched the default route and was sent to the distant PoP. Inspect the FortiClient split-tunnel include and exclude lists, the actual route table on an affected endpoint, and FortiSASE traffic logs for SharePoint destinations. Also compare latency to the SharePoint tenant with and without the client. Do not solve this by exempting all Microsoft 365; that can bypass web filtering. Instead, add only the required SharePoint and OneDrive endpoints if policy permits direct breakout, or keep inspection and move the user to a nearer PoP. If SSL inspection is adding delay, confirm that with timing tests before changing policy.
3. How would you stop users from browsing directly when they stop the FortiClient service?
Read the worked answer
FortiSASE cannot protect traffic that never reaches it, so enforcement must be at the endpoint and at the network edge. Configure FortiClient always-on or lockdown mode with a kill switch, tamper protection, and auto-reconnect. Use FortiClient EMS compliance to require the client and block or quarantine noncompliant endpoints. At the edge, deny direct internet egress for managed devices except to FortiSASE, and require conditional access through Entra ID. Provide a logged emergency bypass with a time limit rather than letting users stop the service. Test the policy on the pilot group, including reboot and sleep behavior, and review FortiSASE logs for gaps.