Overview
On Exinda version 7.6.1, website/application blocking may be enforced in Mozilla Firefox but not in Microsoft Edge or Google Chrome (even for the same destinations and policies). This behavior is tied to a required DPI/signature engine update (ipoque library) that is included in Exinda 7.6.3.
<supportagent>
Agent Notes
Investigation Summary:
Reviewed customer-reported browser-specific blocking behavior on Exinda 7.6.1. Gathered reproduction evidence requirements (screen recording/video preferred when sysdump collection is sensitive) and escalated for Development/BU review due to a suspected DPI/signature (ipoque) dependency.
Findings:
- The behavior aligns with a DPI/signature-engine (ipoque library) dependency that required a vendor library update.
- Development/BU confirmed the needed ipoque update is included in Exinda 7.6.3; recommended remediation is to upgrade to 7.6.3 and re-test.
- “Edge Cache” not appearing in the UI was not identified as the root cause in this scenario; it may indicate the feature is not licensed/available in that environment.
- Where sysdumps contain sensitive data (e.g., AD user IDs/internal IPs), a reproduction video is an acceptable alternative for initial validation.
Escalation: Internal engineering/BU tracking references included:
- https://github.com/trilogy-group/eng-maintenance/issues/14064
- https://github.com/trilogy-group/eng-maintenance/issues/14238
- https://ignitetechpm.atlassian.net/browse/GFIEXINDA-157
- https://ignitetechpm.atlassian.net/browse/GFIEXINDA-60
- https://github.com/trilogy-group/gfi-kanban/issues/1898
Customer referenced a previous case (<prior_case_id>) and this issue instance was tracked as <case_id>. Customer confirmation that upgrading resolved the issue was not available in the provided excerpt.
</supportagent>
Solution
Problem
Blocking policies are not being enforced in Microsoft Edge and Google Chrome, while the same blocking works in Firefox.
Applies to
- Exinda appliance running 7.6.1 (reported), potentially other 7.6.x builds prior to 7.6.3
Resolution
This issue requires a vendor DPI/signature-engine update (ipoque library). The update is delivered in Exinda 7.6.3. To resolve the issue, upgrade the appliance to Exinda 7.6.3 and re-test blocking behavior in Edge/Chrome.
What to do
-
Confirm your current Exinda version/build.
Verify whether you are on 7.6.1 (or another 7.6.x build).
-
Upgrade to Exinda 7.6.3 using your standard Exinda upgrade procedure.
- Review the Exinda 7.6.3 release notes for prerequisites and the supported upgrade path (available in the Exinda support portal).
-
Re-test the original scenario.
- Use the same block rule/policy you expect to trigger.
- Test the same blocked destinations in Chrome, Edge, and Firefox.
- Confirm Chrome/Edge now match Firefox behavior (blocking enforced consistently).
If the issue still occurs after upgrading
Further analysis is needed to confirm whether it is the same underlying DPI/signature issue or a different cause. When requesting additional assistance, include:
- Your current version/build after the upgrade
- A brief description of the policy/rule used for blocking
- Timestamps of test attempts
- A screen recording showing the reproduction in Chrome/Edge vs Firefox (preferred when sysdumps/diagnostics contain sensitive user/IP data)
Frequently Asked Questions
- 1. How can I tell this is the same issue?
- You see browser-specific behavior where blocking fails in Chrome/Edge for all sites but works in Firefox under the same Exinda policies and network path.
- 2. I can’t find “Edge Cache” in the Exinda menu—does that matter?
- Not necessarily. If “Edge Cache” isn’t visible, it may not be licensed/available on your appliance. The browser-specific blocking issue in this case was handled via a DPI/signature (ipoque) update delivered in 7.6.3, not by enabling Edge Cache.
- 3. What version contains the fix recommended by Development/BU?
- Exinda 7.6.3 (ipoque library updated in that release). Upgrade to 7.6.3 and re-test.
- 4. What if upgrading to 7.6.3 does not fix it?
- Re-open/raise a support case and include a reproduction video and the post-upgrade version/build. If diagnostics like sysdumps contain sensitive data, request an alternative evidence method (screen recording/live session) so the behavior can be validated and routed to the appropriate team if needed.
Priyanka Bhotika
Comments