Guest Segmentation and Inspection Exemptions with SD-WAN
Meridian Credit Union has 12 branches and a data center. Each branch FortiGate 80F runs two VDOMs, CORP and GUEST. In CORP, an SD-WAN zone named wan contains MPLS and DIA; GUEST has only DIA. Core banking must go to the data center over MPLS. Microsoft 365 should break out directly over DIA. Guest traffic must use DIA and must never reach CORP. Security requires SSL inspection for corporate web traffic except a treasury application that uses certificate pinning and a partner portal that breaks when re-signed. A pilot Microsoft 365 rule is configured with an internet service entry, but users report sign-in loops and the FortiGate shows the traffic matching the default SD-WAN rule, not the Microsoft 365 rule. The Microsoft 365 rule sits below a broad all rule in the same SD-WAN zone.
1. Why does Microsoft 365 match the default rule, and how do you fix it without breaking GUEST?
Read the worked answer
SD-WAN service rules are first-match, top-down. The broad all rule is evaluated before the Microsoft 365 internet-service rule, so Microsoft 365 never gets a chance to match. Move the Microsoft 365 rule above the catch-all; the catch-all should be last. Keep the rules inside the CORP VDOM and keep the wan zone only in CORP. GUEST should have its own firewall policy using the DIA interface or a GUEST-only SD-WAN zone; do not add GUEST interfaces to the CORP zone. Verify with diagnose sys sdwan service after generating traffic, and check the policy hit count and FortiAnalyzer logs. The sign-in loops may also be caused by inspection of Microsoft 365 endpoints, so test with the inspection exemption in place.
2. Design the SSL inspection exemptions and show where they sit in the policy order.
Read the worked answer
Use a dedicated SSL/SSH profile with inspection enabled for the corporate web policy, and an exemption policy or profile with no inspection for the treasury application and partner portal. Match by destination address, internet service, or application control signature, not by user group alone. Place the exemption above the inspection policy in the firewall policy list; the first matching policy applies. Keep GUEST on a no-inspection profile. Log the exempted sessions so you can audit them. If the treasury application uses certificate pinning, re-signing will cause a hard failure; do not inspect it. For Microsoft 365, test the specific endpoints; if breakage continues, add the Microsoft internet-service entries to the exemption rather than disabling inspection globally.
3. How do you prove that GUEST cannot reach CORP, including after the next FortiManager install?
Read the worked answer
Check that there is no inter-VDOM link between GUEST and CORP and no firewall policy with GUEST as source and a CORP interface as destination. Use diagnose sys session list filtered by the guest subnet, FortiAnalyzer traffic logs, and a policy lookup. Run a traceroute from a guest client to a CORP server and confirm it dies at the GUEST default route. Also confirm the GUEST SD-WAN zone or interface has no route to the CORP RFC1918 range; if the branch has a corporate route, add a blackhole route or a deny policy in GUEST. Audit the FortiManager policy package to ensure a later template install does not add a permit, and compare the installed revision after each change.