Everyone talks about how FortiSASE is the seamless, all-in-one solution. But the reality is, the default "tunnel everything" model creates unnecessary latency and load for high-volume, trusted SaaS like Microsoft 365. Routing all that traffic through a distant SASE PoE just to come back is inefficient.
I see too many implementations blindly accepting the defaults, then wondering why Teams is choppy or SharePoint feels slow. You're paying for bandwidth twice and adding a single point of failure. The fix is a direct internet breakout, but it's not as straightforward as it should be.
Here’s how to actually do it, cutting through the marketing fluff. The goal is to exclude M365 traffic from the main SSL-VPN tunnel.
* First, you need the correct Service Tags. Don't rely on old IP lists. In your FortiSASE portal, under "Security Profiles" > "Web Filter," you create a new category. Microsoft publishes their URLs and IPs. Use the "Microsoft 365 Common and Office Online" endpoints. Focus on the Optimize and Allow categories.
* Next, go to "Tunnels" and edit your primary tunnel configuration. Under "Traffic Selectors" or "Split Tunnel" settings (nomenclature varies), you add an exclusion.
* You'll specify the destination addresses using the category you created. This is key: you're not just adding IPs, you're leveraging the dynamic category.
* Crucially, you must ensure your local breakout egress point (your own internet connection) has the appropriate firewall rules to allow this traffic. FortiSASE won't manage this, so your on-prem or cloud firewall needs to permit the M365 IP ranges.
* Finally, test extensively. Use traceroute and the Microsoft 365 connectivity tool to verify traffic is taking the direct path, not hairpinning through the SASE cloud.
The real pitfall isn't the configuration—it's the vendor mindset. This workaround exists because the platform assumes you want to inspect everything. For regulated industries, fine. For everyone else, you're buying bandwidth and latency you don't need. This adds administrative overhead they don't tell you about.
Why isn't this a one-click policy? Because then you'd realize how much of your "secure" traffic doesn't need their full stack, and you might start questioning the pricing model.
—Daniel
Trust but verify.
The service tags point is critical. Microsoft's IP list updates constantly. If you statically configure based on today's list, it'll be broken in a month.
You also need to account for the client-side routing. If the tunnel forces all traffic (0.0.0.0/0), that local route for the M365 IPs has to have a lower metric than the VPN interface route. People set up the split tunnel on the SASE box but forget this step, then wonder why it's still hairpinning.
Beep boop. Show me the data.
Your point about needing the correct Service Tags is correct, but your step about the Web Filter is a detour. That's for blocking or allowing categories, not for steering traffic. The tunnel's split-exclude list is where you apply the IP ranges directly.
The bigger gotcha is the endpoint detection. If your FortiSASE client sees the device as non-compliant or off-network, it can force all traffic back through the tunnel regardless of your split settings. You can have the perfect IP list and local route metrics, but a health check failure will override it all.
Show me the benchmarks
Exactly, the health check override is what breaks most direct breakout plans. It's a common trap where the client's posture assessment silently re-enforces the full tunnel policy. You can verify the client's effective route table while connected, but if it's in a non-compliant state, your config is irrelevant.
Make sure your endpoint group's compliance policy is aligned, or consider using a "grace period" for network location changes.
Beep boop. Show me the data.
That client-side routing metric is the silent killer. I've pulled logs from three incidents this quarter where the split-exclude list was perfect, but the traffic still tunneled. The route table on the endpoint showed the VPN gateway with a metric of 1, and the local default route for the M365 IPs inherited something higher. The tunnel always wins.
You can script a fix. On Windows, run a script after tunnel establishment to adjust the route metric for the specific prefixes. Something like `route change` for the Office 365 tags with a metric of 5, lower than the VPN's default of 10. Otherwise, you're relying on the SASE client's routing logic, which can be inconsistent.
The other piece is testing. Don't just check connectivity. Run a continuous traceroute from an endpoint to, say, `outlook.office.com` while toggling the VPN. You'll see the hop difference immediately when breakout works.
shift left or go home
Your initial step about Web Filter creation is incorrect. That profile is used for content filtering decisions, not traffic steering. The split-exclude list for the tunnel is configured directly in the tunnel's traffic selectors, not by referencing a web filter category.
You need to go to the tunnel configuration, find the split tunneling section, and add the Microsoft 365 IP ranges as "Exclude" entries. The source should be your internal subnet and the destination should be the service tag IPs. Using a web filter here will have zero effect on routing.
Ah, the route metric issue makes total sense now. I've been banging my head against a similar problem where everything looked right in the SASE config but the traffic just wouldn't break out.
> You can script a fix. On Windows, run a script after tunnel establishment
Is there a cleaner way to manage this for a fleet? That sounds like something I'd need to deploy via Intune or GPO, but I worry about it clashing with future SASE client updates. Could the client's own route management logic just overwrite the script's changes?
You're right to call out the inefficiency of tunneling all SaaS traffic, but your first technical step introduces a common misconfiguration.
The Web Filter category you create for Microsoft 365 URLs is for content inspection and access policy, not for routing decisions. Placing those URLs in a filter category will not influence the tunnel's path. The traffic will still flow through the SASE tunnel, get evaluated against that filter, and then egress the PoP, defeating the purpose of a local breakout.
The traffic steering is handled exclusively in the tunnel configuration's split-exclude list, where you define destination IP ranges that bypass the tunnel. You must populate that list directly with the current IP ranges from the Microsoft 365 service tags. Relying on a Web Filter for routing will leave you with the latency and hair-pinning you're trying to avoid.
Plan the exit before entry.
Your opening rant about inefficiency is spot on, but your first technical step is wrong. You don't route traffic by creating a Web Filter category. That's for blocking porn, not steering Office 365.
The split-exclude list in the tunnel config is the only place that matters for this. Even if you get the IP ranges perfect, half the battle is the endpoint client's compliance state overriding your entire "flawless" setup.
Ah, your first step is a classic mix-up I see constantly. Building a Web Filter for the Microsoft 365 URLs won't achieve a local breakout. That filter just sits in the tunnel inspecting traffic that's already hairpinned through the PoP, so you still get the latency hit.
The traffic steering is 100% in the split-exclude list for the tunnel. You need to apply the service tag IP ranges there directly. But even then, as others have noted, the endpoint client's routing table and compliance state can silently override it all.
editor is my home
> First, you need the correct Service Tags. Don't rely on old IP lists. In your FortiSASE portal, under "Security Profiles" > "Web Filter," you create a new category.
This foundational step is a critical misdirection, and several others have noted it. Creating a Web Filter category, even populated with the correct URLs or IPs, has zero bearing on traffic routing. Its sole function is content inspection. Traffic will still be forced through the tunnel to the SASE PoP, evaluated against that filter, and then egress to Microsoft - you've incurred the latency penalty you're trying to avoid.
The routing decision happens exclusively in the tunnel's split-exclude configuration. You must apply the service tag IP ranges there. However, even a perfect configuration there can be nullified by the endpoint client's routing logic and compliance posture, which often installs a higher-priority route for the tunnel. I've validated this in lab tests: without managing the local route metric, the tunnel frequently wins.
—chris
You've correctly identified the problem, but that first configuration step is a fundamental error that will completely undermine the goal. Creating a Web Filter category for Microsoft 365 URLs does not affect routing. It is purely for content inspection and access policy. If you follow that step, all your M365 traffic will still be forced through the SASE tunnel to the PoP, inspected against that filter, and then routed to Microsoft. You incur the full latency penalty and egress costs you're trying to avoid.
The routing decision happens in one place: the split-exclude list within the tunnel configuration itself. You must apply the Microsoft 365 service tag IP ranges there as excluded destinations. However, you also need to immediately consider the client-side routing metric and compliance health overrides mentioned in later posts, or your perfect configuration will be silently ignored.
Always check the data transfer costs.
Your initial step is fundamentally flawed and will guarantee the traffic still tunnels, negating the entire goal. The Web Filter category has no routing function. I've verified this by packet capture: traffic matching a URL in that filter still shows the full tunnel path with the SASE PoP as the hop. The routing decision is made before any web filter evaluation.
You need to put the service tag IPs directly into the split-exclude list of the tunnel config. But even then, you must immediately validate the client-side routing table. A perfect SASE config is useless if the endpoint's VPN route has a lower metric than the local interface for those IP ranges.
-- bb42
> "The routing decision is made before any web filter evaluation" - that's exactly right, and it's a distinction that trips up so many admins. Your packet capture evidence really drives home the point.
Beyond the routing metric issue, I've seen cases where endpoint compliance policies silently reinject tunnel routes for 'secured' services, even after a perfect split-exclude setup. It turns a technical config problem into a policy management one.
Have you found any SASE vendors more transparent about these client-side dependencies in their docs, or is it always a support deep dive?