The Zscaler Client Connector has an Application Bypass feature that allows you to automatically bypass specific applications from being tunneled through Zscaler Tunnel (Z-Tunnel) 2.0. You need to add the applications that you want to bypass in the Application Bypass field while configuring the App Profiles in the Zscaler Client Connector Portal. To learn more, see Configuring Zscaler Client Connector Profiles.

See image.

This application bypass is only applicable for Windows and macOS App Profiles and if you use Z-Tunnel 2.0 as your forwarding profile in Zscaler Client Connector. You can also view the details of the bypassed applications on the Application Bypass Info page.

Full visibility of the traffic bypassed by Zscaler Client Connector, such as bypassed session, bypassed session event time, and flow type is logged and displayed in the Web and Firewall Insights Logs in ZIA Admin Portal.

See sample Web Logs.

See sample Firewall Logs.

Application-Based Bypass in Android

Zscaler recommends bypassing Android application traffic. While configuring the Android App Profile, you can automatically bypass standard messaging applications on Android using the following steps:

1. Enable the Bypass Traffic for MMS Applications field to ensure that Android does not interfere with MMS, which also uses mobile data.

2. Add the app's identifier to the Bypass Traffic for Specific Applications field to bypass specific Android application traffic. You can find the app's identifier after the ID parameter in the URL of the app's Play Store details. For custom applications (i.e., applications not available in the Play Store), add the package name instead of the app’s identifier in the field.

   See image.

   

   Close

If you are not aware of the package name of the application, use PAC file-based exclusion to bypass specific hostnames and IP addresses. To do that, configure a custom PAC file on the ZIA Admin Portal to bypass the Google FQDNs, and add that PAC URL to the Custom PAC URL field while adding an Android App Profile.

See image.

The Zscaler exception list for SSL Inspection includes a few dozen known domains or destinations, such as Zscaler service IP addresses for Zscaler best practices, contactservice.zoom.us for UCaaS bypass, and self.events.data.microsoft.com for O365 bypass events, which cannot be SSL inspected for various reasons. These domains are not exposed as they are subject to change.

The predefined Zscaler Recommended Exemptions rule under the Policy > SSL Inspection Policy page, automatically exempts known destinations that cannot be SSL inspected when it is enabled. If you want to SSL inspect certain domains from the exempted list, create an inspection rule with higher rule order. Disable the predefined rule for SSL inspecting all domains. To learn more, see About SSL Inspection Policy.

You can find transactions that are not SSL inspected or blocked after an inspection under the SSL Policy Reason filter in the Web Insights Logs. The percentage of traffic automatically SSL bypassed is relatively small (less than 1%).

See sample Web Logs.

SSL inspection also does not work on applications that use certificate pinning because the client application is hardcoded to accept only one specific client certificate. They should be included in the list of URL categories for which SSL transactions are not decrypted. To manage the certificate pinning exempted applications, Zscaler recommends referring to the Certificate Pinning and SSL Inspection article.

The following are some of the Firewall Control policy rules applied to traffic that is bypassing the Zscaler cloud:

• Zscaler Bypass Traffic

  The Firewall Control policy has a predefined implicit Zscaler Bypass Traffic rule which applies only to self-traffic destined for the Zscaler cloud. This rule is logged and displayed under the Rule Name column in the Firewall Insights Logs and DNS Insights Logs.

  • Firewall Logs

    The Zscaler Bypass Traffic rule populates in the Firewall logs when:

    • The web module does not accept control for the traffic evaluation from the firewall module because the handshake abruptly terminates during flow establishment.
    • The traffic is forwarded from a firewall-enabled sublocation but not enabled to the parent location or another sublocation under the same parent location. This happens due to the latency in identifying these location differences, such as in the X-Forwarded-For (XFF) configuration.

    See sample Firewall Logs.

    

    Close

    Close
  • DNS Logs

    The Zscaler Bypass Traffic rule populates in the DNS logs when:

    • When the domain name in the DNS request query matches a Zscaler cloud domain.
    • When the DNS request query matches an Office 365 endpoint listed in the Office 365 One Click predefined firewall filtering rules if enabled.
    • When the DNS response does not contain a resolved IP or CNAME.
    • When the DNS response is not completely analyzed because of its resource record type. DNS Control performs a detailed analysis of responses for A, AAAA, CNAME, and PTR record types.

    See sample DNS Logs.

    

    Close

    Close

  Zscaler recommends keeping the predefined Zscaler Proxy Traffic rule enabled. When the recommended predefined rule is disabled, the Zscaler Bypass Traffic rule is triggered.

  Close
• Blocked by Web Proxy Policy

  This implicit rule is applied when a web policy blocks traffic while it is being evaluated by deep packet inspection to identify the network application to which the traffic belongs. You can view the transactions that match this rule in the Firewall Insights Logs.

  Close
• Other Implicit Rules for Traffic Bypasses

  The traffic flow from users might bypass Zscaler Firewall or DNS modules when the following scenarios occur:

  • When the ZIA Service Edge fails to establish a connection with the Zscaler Central Authority (CA), it results in the traffic flow passing through the Firewall or DNS without policy application. This might occur when traffic flow from a specific user or location arrives at the Service Edge for the first time and a connection to the CA is required to apply policies. Firewall logs this transaction, and you can view this in Firewall Logs by applying the Action > Bypassed due to missing config filter.

    See sample Firewall Logs.

    

    Close

  • If the Service Edge has established a connection with the CA but the requested configuration does not arrive from the CA within the expected time period (typically 5 seconds), it results in the traffic flow passing through the Firewall without policy application. This might occur when traffic flow from a specific user or location arrives at the Service Edge for the first time and a connection to the CA is established, but there is no response from the CA within the expected time frame. Firewall logs this transaction, and you can view this in Firewall Logs by applying the Action > Timed out while waiting for a config filter.

    See sample Firewall Logs.

    

    Close

  Close