Does the built-in web filter actually work for modern SaaS apps like Slack and Teams?

You've hit the nail on the head. That persistent WebSocket connection is the killer. Once it's up, it's just a tunnel, and the appliance can't see inside to re-classify the traffic.

I gave up trying to do it purely at the network layer for that exact reason. You can maybe catch the initial handshake, but it's a constant cat-and-mouse game with their CDN IPs.

For SaaS apps like those, you really need an agent on the endpoint doing the blocking, or a proper cloud proxy that sits in front of the service. The firewall can be a backup, but it's not the primary control point for this anymore, sadly. Been there, fought that battle.

Ugh, the "tune it" response is so frustrating, right? I've seen this exact issue from the other side when HR tries to block apps for policy reasons, but IT's tools can't actually deliver.

You're right about the core functionality being broken for this use case. The web filter might work for casual browsing, but modern SaaS apps are built to bypass those controls. We had the same fight with a learning platform that used similar persistent connections. Management wanted it blocked after hours, but the firewall rule just... didn't.

Have you looked into a dedicated SaaS security posture tool? I know it's adding another layer, but we found that's what actually worked for controlling access, not the network filter. Just a thought from someone who's been in those "why is this still working?!" meetings.

Totally agree about the dedicated SaaS tool being the real answer here. That "tune it" advice drives me nuts, because it usually means weeks of chasing IP lists and still losing.

One caveat from our rollout: those posture tools are great for *access* control, but if you also need to filter *content* within the app, you hit the same wall. We could block our support team from opening Slack at all, but we couldn't stop the sales team from posting sensitive data *in* their active Slack. That's a whole other layer.

So yeah, a cloud proxy or agent works for the "is it on?" problem, but the old web filter dream of inspecting and controlling the actual content? Still dead for these modern persistent apps.

You're describing the classic mismatch between marketing slides and reality. That persistent WebSocket connection is exactly why the "block Slack category" checkbox fails. It's not that the feature is fundamentally broken, it's that it was built for a different model of web traffic, like blocking Facebook.com, not a stateful application tunnel.

I managed to get it "working" at one point by treating it like a constant DDoS on my own time. It involved deep packet inspection with a very aggressive certificate, combined with IP/domain lists that changed daily, and killing all long-lived TCP sessions every few minutes. The performance hit was massive, and user complaints were endless. It's technically possible to make the river stop, but you do it by poisoning the well, not with a better screen door.

Have you checked if your FortiGate has the specific "Slack Calling" or "Microsoft 365" application signatures turned on? Sometimes the main app category is stale, but sub-features are updated more frequently. It might catch *some* traffic, but as you and others have said, it won't be reliable for your actual goal.

You've identified the exact technical limitation. The firewall's application signature database is built to recognize the initial HTTPS handshake and maybe the first few packets of a *transaction*. But as you said, once that WebSocket tunnel is established, all it sees is an encrypted pipe to a generic AWS or Azure IP. The category filter can't re-evaluate.

I forced it to work once by writing a script that polled our DNS logs for Slack's ever-changing hostnames and dynamically updated a firewall address group, then set a session-ttl policy to kill connections every 90 seconds. It created so much overhead and support noise it wasn't worth it. The "tune it" advice ignores the operational cost of treating a core business app like an active threat.

That "screen door" feeling is exactly what we ran into trying to control access to Asana and Notion. The built-in filter would catch the initial login page load, but the moment the app hydrated in the browser and established that persistent connection, it was game over.

From a marketing automation standpoint, it's like trying to block a drip campaign by filtering the initial opt-in email; the subsequent automated flow just finds another path.

I'm curious, when management pushed for this, was the goal to block the app entirely during certain hours, or was it more about preventing specific data exfiltration within the app? Your point about the core functionality being broken for this use case makes me wonder if they're even asking for the right thing.

Yeah, you've found the main weakness. The category filters work by matching signatures against the initial HTTPS transaction. Once that WebSocket upgrades and establishes its long-lived tunnel, you're done. The traffic is just encrypted bytes to a cloud IP.

You can sometimes catch the initial app load, but blocking "Slack" after it's already running in the browser is nearly impossible. The "tune it" advice usually means maintaining a massive, dynamic list of CDN hostnames and IPs, which is a full-time job for a single app.

The real answer is that you can't effectively block a core SaaS app at the network layer anymore without breaking it completely. You need an agent or a cloud access proxy for reliable on/off control. The built-in web filter is a checkbox feature for this specific use case.