Technical Tip: Behavioral change in user-agent matching for Microsoft Edge after upgrading to FortiProxy v7.4.x
| Description | This article describes a change in behavior after upgrading to FortiProxy version 7.4.x. Administrators may notice that traffic from Microsoft Edge browsers begins to bypass explicit proxy Authentication Rules, falling through to default or catching-traffic policies.
This happens because FortiProxy v7.4 introduces a stricter, more granular User-Agent (UA) parsing logic in the WAD engine compared to previous versions (like v7.0 and v7.2).
In older versions, Chromium-based Edge traffic (Edg) was grouped under the Chrome signature, or legacy Edge under the MS signature. In FortiProxy v7.4, the WAD engine now explicitly parses Edge as its own distinct signature category (edge). If the configuration previously relied on the chrome signature to catch Microsoft Edge traffic, the rule will fail to match after the upgrade. | |||||||||||||||
| Scope | FortiProxy v7.4+. | |||||||||||||||
| Solution | Behavioral Change Comparison Table. The following table illustrates how the signature matching logic has changed for Edge-related User-Agent strings:
Configuration example (Vulnerable to Bypass) If the firewall proxy-address object looks like the example below, Edge traffic will bypass the rule post-upgrade because edge is missing, and it will no longer piggyback on chrome: config firewall proxy-address edit "browser-user-agents" set type ua set ua chrome ms firefox safari next end Solution: To resolve this issue and ensure Microsoft Edge correctly matches authentication or inspection rules, explicitly add the edge signature to the Proxy Address object. Update the Proxy Address Object. Add edge to the allowed UA list via the CLI:
config firewall proxy-address |
