Application Control Engine False-Categorization Dropping Microsoft 365 & Teams
Following dynamic signature definition updates, the FortiOS ipsmonitor / app_id engine misclassifies legitimate Microsoft 365 and Teams WebSocket connections as unauthorized HTTP proxy tunnels, abruptly terminating calls, chats, and cloud synchronization.
Technical Root Cause Analysis
The FortiOS Application Control subsystem relies on the ipsmonitor process and dynamic signature packages (AppDB) to inspect packet headers and L7 framing. Microsoft 365 applications, specifically Microsoft Teams (calling, meeting video streams, and presence channels), initiate TLS 1.3 tunnels that upgrade to persistent bidirectional WebSockets over TCP 443 with proprietary framing tokens.
In Application Control database releases 24.810 through 24.825, pattern masks for the MS.Teams_Audio.Video and Microsoft.Portal signatures introduced an overly narrow regex evaluation boundary. When long-lived WebSocket sessions transitioned from JSON payload control to binary frame streaming, the parser encountered an unexpected header offset. Instead of preserving the authenticated Microsoft application ID, the classifier downgraded the session to Proxy.HTTP or Unknown.Application. In organizations enforcing corporate policy blocking circumvention tools and anonymous proxies, firewall policies actively reset active TCP sessions.
Affected Firmware & Blast Radius Matrix
| Component / Branch | Vulnerable Versions | Clean Build / Fix | Status & Workaround |
|---|---|---|---|
| AppDB Signature Engine | 24.810 – 24.825 | 24.830+ | Execute manual signature update |
| FortiOS 7.2 | 7.2.0 – 7.2.8 | AppDB 24.830+ | Create ISDB top-policy bypass |
| FortiOS 7.4 | 7.4.0 – 7.4.3 | AppDB 24.830+ | Exempt M365 from Proxy category filters |
| FortiOS 7.0 | 7.0.8 – 7.0.14 | AppDB 24.830+ | ISDB bypass or AppDB roll-forward |
Platform Impact: Mid-range and enterprise firewalls (FG-60F up to FG-600F) running deep SSL inspection or flow-based Application Control policies with strict proxy filtering profiles.
Step 01: Free Verification CLI (Safe Read-Only)
Run these diagnostic commands to determine the running Application Control database version and verify whether active Microsoft sessions are being miscategorized:
Diagnostic Commands
# 1. Inspect running IPS and Application Control daemon status
diagnose test application ipsmonitor 1
# 2. Check active 443 session count and identify drops
diagnose sys session stat | grep 443
# 3. Verify current dynamic signature and AppDB database versions
diagnose autoupdate versions
# 4. Filter active sessions targeting Microsoft Teams cloud endpoints
diagnose sys session filter dport 443
diagnose sys session list | grep -i "teams" -A 4 -B 2Remediation & Workaround Steps (Teaser Preview)
Eliminate Microsoft 365 and Teams application drops without disabling security inspection across the perimeter:
Frequently Asked Questions
Microsoft Teams uses persistent WebSocket connections and custom binary framing over HTTPS port 443. Vulnerable AppDB versions (24.810–24.825) contained an ambiguous token parser that misidentified this proprietary framing as an unknown obfuscated HTTP proxy tunnel, triggering proxy blocking rules.
Internet Service Database (ISDB) rules match on verified Microsoft ASN and IP prefixes at the network layer (L3/L4) before the deep payload signature engine (ipsmonitor/app_id) inspects the payload, preventing signature engine misclassifications from terminating business calls.
Fortinet released clean Application Control Database definitions in AppDB 24.830 and later. Updating definitions via 'execute update-now' permanently resolves the issue without requiring a full FortiOS reboot.