In the networking world, there is a widely known adage: “It’s always the network”. This phrase refers to the tendency of users to blame network connectivity whenever access to a resource fails, even if the true reason lies elsewhere—such as being blocked by a corporate security policy.The Need for Better User CommunicationWhen end-users receive no clear notification of why access to an application or network has been denied or other action taken, it is natural for them to assume the failure stems from a “networking issue.” Left in the dark, users often retry accessing the resource, wasting valuable time and, eventually, filing help desk tickets.This pattern creates multiple challenges:Increased workload for IT support teams, draining resources that could be allocated elsewhere.Frustration across the business, as employees feel hindered by network inefficiencies.Potential security risks, as users may attempt to bypass corporate security restrictions by leveraging unsanctioned third-party solutions.In most instances, employees adopting workarounds are driven by necessity, not malice—they simply want to complete tasks without engaging with technical barriers they don’t fully understand.The solution? Providing clear, timely end-user notifications (EUNs) that inform users when access to a specific resource is blocked, along with the reason for the restriction. Such transparency not only reduces the volume of unnecessary tickets but also cultivates better-informed, security-aware employees. Over time, this strengthens the organization’s overall security posture.A Unique Challenge: Non-Web Traffic EUNsFor web traffic, user notifications are relatively straightforward: organizations can display a web-based End-User Notification (EUN) page explaining the block. This page might include customized corporate branding, a message specific to the policy violation, and instructions for contacting IT support if needed.But not all traffic is web-based. What happens, for example, when a user tries to access a resource via SSH in a public cloud, only to have the attempt blocked by a security policy? Since there’s no browser-based interaction, traditional EUN pages can’t be displayed in such cases. This can leave users confused, wasting time trying to troubleshoot what they perceive as “networking” or application-related issues.Enter Zscaler Client Connector EUN NotificationsThis is where Zscaler Client Connector EUN Notifications step in to fill the gap. Starting with Zscaler Client Connector version 4.8 (used in conjunction with Z-Tunnel 2.0), notifications can now be surfaced directly to the user for ZIA policies, clearly explaining that access to a site or resource has been blocked by a corporate security policy.Expanded Policy SupportPreviously, ZCC-based notifications were available for policies such as Inline Web Data Loss Prevention (DLP), Endpoint DLP, and Cloud App Control. Recently, Zscaler has enhanced these capabilities to include:Firewall FilteringDNS ControlIntrusion Prevention System (IPS) ControlThis expanded support is particularly valuable for non-web traffic, where no web-based EUN page can be presented.Key Use Cases for EUN NotificationsHere are some common scenarios in which Zscaler Client Connector EUN Notifications offer clarity:DNS Control Actions:When a DNS request is blocked due to a classification (e.g., a domain falls under a restricted category).When DNS Control redirects a request (e.g., A-record response redirected to a specified IP), but no subsequent web flow occurs, leaving the user without context for the block.Firewall or IPS Control Actions:When attempts to use protocols such as SSH are blocked.When an IPS signature match triggers a block, users are left wondering why their application or connection isn’t functioning as expected.EUN notifications eliminate this ambiguity by clearly communicating the reason behind the restriction, for example, by communicating:Block actions on non-web traffic to the user.Warnings to the user when they go to a suspicious domain or use a protocol or application that is not banned but dangerous.Remediation steps to the user (opening a ticket, not running an app etc.).
[#item_full_content] In the networking world, there is a widely known adage: “It’s always the network”. This phrase refers to the tendency of users to blame network connectivity whenever access to a resource fails, even if the true reason lies elsewhere—such as being blocked by a corporate security policy.The Need for Better User CommunicationWhen end-users receive no clear notification of why access to an application or network has been denied or other action taken, it is natural for them to assume the failure stems from a “networking issue.” Left in the dark, users often retry accessing the resource, wasting valuable time and, eventually, filing help desk tickets.This pattern creates multiple challenges:Increased workload for IT support teams, draining resources that could be allocated elsewhere.Frustration across the business, as employees feel hindered by network inefficiencies.Potential security risks, as users may attempt to bypass corporate security restrictions by leveraging unsanctioned third-party solutions.In most instances, employees adopting workarounds are driven by necessity, not malice—they simply want to complete tasks without engaging with technical barriers they don’t fully understand.The solution? Providing clear, timely end-user notifications (EUNs) that inform users when access to a specific resource is blocked, along with the reason for the restriction. Such transparency not only reduces the volume of unnecessary tickets but also cultivates better-informed, security-aware employees. Over time, this strengthens the organization’s overall security posture.A Unique Challenge: Non-Web Traffic EUNsFor web traffic, user notifications are relatively straightforward: organizations can display a web-based End-User Notification (EUN) page explaining the block. This page might include customized corporate branding, a message specific to the policy violation, and instructions for contacting IT support if needed.But not all traffic is web-based. What happens, for example, when a user tries to access a resource via SSH in a public cloud, only to have the attempt blocked by a security policy? Since there’s no browser-based interaction, traditional EUN pages can’t be displayed in such cases. This can leave users confused, wasting time trying to troubleshoot what they perceive as “networking” or application-related issues.Enter Zscaler Client Connector EUN NotificationsThis is where Zscaler Client Connector EUN Notifications step in to fill the gap. Starting with Zscaler Client Connector version 4.8 (used in conjunction with Z-Tunnel 2.0), notifications can now be surfaced directly to the user for ZIA policies, clearly explaining that access to a site or resource has been blocked by a corporate security policy.Expanded Policy SupportPreviously, ZCC-based notifications were available for policies such as Inline Web Data Loss Prevention (DLP), Endpoint DLP, and Cloud App Control. Recently, Zscaler has enhanced these capabilities to include:Firewall FilteringDNS ControlIntrusion Prevention System (IPS) ControlThis expanded support is particularly valuable for non-web traffic, where no web-based EUN page can be presented.Key Use Cases for EUN NotificationsHere are some common scenarios in which Zscaler Client Connector EUN Notifications offer clarity:DNS Control Actions:When a DNS request is blocked due to a classification (e.g., a domain falls under a restricted category).When DNS Control redirects a request (e.g., A-record response redirected to a specified IP), but no subsequent web flow occurs, leaving the user without context for the block.Firewall or IPS Control Actions:When attempts to use protocols such as SSH are blocked.When an IPS signature match triggers a block, users are left wondering why their application or connection isn’t functioning as expected.EUN notifications eliminate this ambiguity by clearly communicating the reason behind the restriction, for example, by communicating:Block actions on non-web traffic to the user.Warnings to the user when they go to a suspicious domain or use a protocol or application that is not banned but dangerous.Remediation steps to the user (opening a ticket, not running an app etc.).
