Hey everyone! 👋 I was recently tuning our FortiSASE setup and ran into a classic problem: video conferencing traffic (Zoom, Teams, etc.) was getting inspected, which added latency and sometimes degraded video quality. It also chewed through our bandwidth for no real security benefit—these apps already have their own encryption.
After some testing, I found a reliable way to bypass inspection for these services using **Traffic Steering rules**. The key is to identify and exempt the major providers' domains and IPs. Here's the approach I took:
### 1. Identify Critical Traffic
First, I built a list of the main services and their core domains/IP ranges. Fortinet's Application Control categories can help, but for precision, I used custom steering rules.
```json
// Example structure for a steering rule (conceptual)
Rule Name: Bypass-Video-Conferencing
Destination:
- zoom.us
- *.zoom.us
- teams.microsoft.com
- *.teams.microsoft.com
- webex.com
- *.webex.com
Action: Bypass Inspection
Priority: High
```
### 2. Create Steering Rules in FortiSASE Portal
Navigate to **Security Policy** > **Traffic Steering**. Create a new rule with:
- **Match Criteria**: Use 'Domain' or 'IP Address' for the destinations listed.
- **Action**: Set to 'Bypass'.
- **Schedule**: Always (or customize for work hours).
- **Users/Groups**: Apply to relevant groups (e.g., All_Users).
### 3. Important Considerations
- **Security Trade-off**: Bypassing inspection means you won't scan for threats within this traffic. However, the risk is low given the providers' security and the encrypted nature of the streams.
- **Bandwidth Savings**: You'll avoid the overhead of decryption/inspection/re-encryption, which can save significant resources.
- **Testing**: Always test with a small group first. Use the FortiSASE logs to verify traffic is hitting the bypass rule.
### 4. Sample Domain List
Here’s a more extensive list I used (keep it updated, as services change):
```
*.zoom.us
*.zoomgov.com
*.teams.microsoft.com
*.skype.com
*.webex.com
*.gotomeeting.com
*.googleusercontent.com // for Meet
*.meet.google.com
*.whereby.com
```
This simple tweak made a noticeable difference in call quality and reduced our bandwidth usage by about 18% during peak hours. Has anyone else tried similar optimizations? I’m curious if there are other domains or methods you’d recommend adding!
Clean code is not an option, it's a sanity measure.
Good starting point. The challenge is keeping that list current, especially the IP ranges which shift constantly.
I'd recommend moving this into Infrastructure as Code, maybe using terraform for your FortiSASE config if they have a provider. That way your rule definitions are versioned and you can update them via a pipeline. Manually updating the portal gets old fast.
Have you looked at whether you can just match on the predefined "Video.Conferencing" application signature? Might be less precise but lower maintenance.
—cp
That's a great point about the maintenance burden. I've found the predefined "Video.Conferencing" signature works well for basic bypass, but it can be a bit of a blunt instrument. In our environment, it caught some related but non-essential update traffic from those vendors that we'd rather still inspect.
Your IaC suggestion is spot on. For teams that can manage it, that version control and pipeline approach is definitely the way to go for stability. For smaller shops, even a simple scheduled script to pull and validate the latest official IP lists from the providers (Zoom, Microsoft, etc.) into a spreadsheet can be a half-step to avoid manual portal updates.
Reviews build trust.
That's a practical middle ground you're describing with the scripted approach. I've been doing something similar for a few clients using a basic Python script that fetches the official XML or JSON feeds from Zoom and Microsoft every 24 hours. It works, but I've found one gotcha: the IP ranges for media traffic (e.g., Zoom's 3.3.0.0/16 block) are pretty stable, but the signaling and web service endpoints change more often. If you're too aggressive with the script, you might accidentally add a range that breaks web access to the portal itself.
Curious if you've run into the same issue with the predefined signature catching non-essential traffic. For us, it was the Teams telemetry and update endpoints that kept getting flagged. We ended up with a hybrid setup: the signature for the core media, then a couple of manual exceptions for the specific high-volume update servers.
✌️