Remote SAP Latency After a FortiSASE Pilot
Northwind Components runs 18 manufacturing plants, a headquarters in Singapore, and 3,200 remote users, including 400 contractors. Each plant has a FortiGate 200F; HQ has a 600E. Inter-site traffic follows a hub-and-spoke MPLS design into Singapore, with broadband used only for guest and cloud. A FortiSASE pilot covers 500 remote users. Pilot users in Europe report 210–240 ms to the Singapore SAP plant, versus 60–70 ms on the old VPN. Meanwhile, plant-to-plant SAP traffic still traverses MPLS to HQ and back, and firewall policy differs between the pilot and branch edges. The team has FortiManager but no global policy standard. Leadership wants a unified SASE design within two quarters without replacing the FortiGates. Security insists private SAP traffic must not break out to the public internet, while cloud SaaS should go direct. The network team worries that steering all remote traffic through a single FortiSASE region will worsen latency.
1. Classify the traffic flows and decide what should use FortiSASE, what should use regional private access, and what should stay on MPLS. Justify the latency and security trade-offs.
Read the worked answer
Start by separating flows by destination and risk, not by user location. SaaS such as Microsoft 365 should go from the user to the nearest FortiSASE PoP for SWG, CASB, and DLP, then to the SaaS provider. That avoids backhauling to Singapore. Private SAP should not egress to the public internet; use FortiSASE private access from a European PoP to the Singapore FortiGate, or ZTNA direct-to-application through a FortiGate ZTNA proxy if the app can be published that way. The key latency test is user-to-PoP plus PoP-to-Singapore, not user-to-Singapore. Plant-to-plant SAP is better handled by SD-WAN over MPLS and broadband with ADVPN shortcuts, because sending it through FortiSASE adds an unnecessary cloud hop. Guest traffic should break out locally. Do not force all remote traffic through one region; select PoPs by user geography and measure SAP response time before and after. Security policy should follow the flow: private apps require identity-aware access and no internet exposure; SaaS requires inline inspection; plant-to-plant requires segmentation and encrypted transit.
2. How would you make policy consistent across FortiSASE and 18 FortiGates without replacing the existing edge devices?
Read the worked answer
Use FortiManager as the source of truth for FortiGate policy and object definitions, with metadata tags and templates rather than per-device rules. Build policy around user groups, device posture, application categories, and destination zones so the same intent can be expressed at both edges. For FortiSASE, use the supported integration or API to mirror the same group and application objects, then validate that group membership and application signatures resolve identically. Avoid duplicating raw IP addresses, because overlapping RFC1918 space and dynamic SaaS addresses will drift. Define a small number of policy intents: contractor access to SAP, employee access to SaaS, guest internet-only, and plant-to-plant restricted traffic. Test each intent in the pilot and compare logs from FortiSASE and FortiGate. Where native synchronization is limited, document a controlled change process and a weekly drift check. The judgement call is to standardize intent and identity first; device-by-device rule matching is fragile and will fail the two-quarter timeline.
3. What migration sequence would you recommend, and what evidence would cause you to pause the rollout?
Read the worked answer
Sequence by risk and measurability. First, fix the pilot region selection and add private access for SAP, then measure latency, policy hits, and user complaints for the 500 pilot users. Second, migrate one European plant’s remote users and one plant-to-plant pair to SD-WAN with ADVPN, keeping the VPN as fallback. Third, expand by region, not by user count, so PoP and private-access paths are proven before load increases. Fourth, retire the old VPN only after two weeks of stable authentication, latency within agreed thresholds, and no unresolved DLP or CASB exceptions. Pause if SAP latency remains above the business threshold after PoP correction, if private traffic appears in internet egress logs, if policy drift appears between FortiSASE and FortiGate, or if contractor access cannot be tied to identity and posture. The reasoning is that unified SASE changes both path and policy; rolling out globally before proving the private-access path would turn a latency problem into a security exception.