Best Practices for Traffic Forwarding

This article provides best practices for traffic forwarding.

Zscaler recommends that organizations forward all Internet traffic (traffic for all protocols and destined for all ports) to the Zscaler service so it can secure your Internet traffic and apply policies accordingly.

For more information about the various traffic forwarding methods Zscaler supports, see Choosing Traffic Forwarding Methods.

NOTE: SLAs or performance may be impacted if you don't forward traffic using Zscaler's best practice recommendation.

See below for the traffic forwarding methods that Zscaler recommends.

Traffic Forwarding Methods

Following are the available traffic forwarding methods. You can use one or a combination of the following, depending on your environment. To learn more, see below:

Zscaler recommends that you enable the Surrogate IP feature. To learn more, see below:

Tunneling

Using tunnels is a traffic forwarding method for users within your fixed network locations. Tunneling makes it impossible for all users to bypass the Zscaler service.

Make sure that you have the appropriate software and hardware required to build, monitor, and failover the tunnels.

Zscaler recommends that you configure two tunnels from an internal router behind the firewall to the ZENs (Zscaler Enforcement Nodes); a primary tunnel from the router to a ZEN in one data center, and a secondary tunnel from the router to a ZEN in another data center. This type of deployment provides visibility into the internal IP addresses, which can be used for the Zscaler security policies and logging.

Zscaler recommends that you use GRE tunneling over IPsec tunneling. Compared to GRE tunnels, IPsec tunnels have additional processing overhead on your equipment. If your organization has an internal router or switch that supports GRE and its egress port has a static address, you can configure a GRE tunnel. To learn more about GRE tunneling, see About GRE.

If your router does not support GRE or if you use dynamic IP addresses, you can configure IPsec VPN tunnels. To learn more about IPsec tunneling, see About IPsec VPNs.

Zscaler recommends configuring two separate (GRE or IPsec) tunnels to two different ZENs for redundancy. If the primary tunnel or an intermediate connection does down, all traffic is then routed to the backup tunnel to the secondary ZEN. If you are using IPsec tunneling, note that there is a soft limit of 200 mbps per tunnel. Therefore, if your organization sends more than 200 mbps of traffic to Zscaler, you must create and manage multiple  tunnels and distribute load evenly between the tunnels.

PAC Files

A PAC file is a text file that directs the browser to forward traffic to a ZEN. To learn more about PAC files, see What is a PAC file?  

Zscaler recommends that you install a PAC file for each of your users to ensure coverage outside the corporate network.

If certain applications need to be excluded from the Zscaler service, it is easy to write an exclude statement in your PAC file to send traffic directly. Using PAC files allows you to set exceptions for forwarding your traffic, such as excluding intranet corporate sites from the Zscaler service.

Zscaler App

Zscaler recommends that you install Zscaler App on your users' devices to protect their web traffic when they are accessing the Internet from an unknown location (road warrior traffic). The application automatically detects when the user is no longer within the secure network, then automatically creates a connection to the Zscaler service from the unknown location.

To learn more about Zscaler App, see What is the Zscaler App?

Proxy Chaining

Proxy chaining involves forwarding traffic from one proxy server to another. It's a quick and easy way to forward traffic to the Zscaler service from an existing on-premise proxy. Though Zscaler supports proxy chaining, it is not recommended as a long-term solution in production environments. If you use proxy chaining, SLAs may be affected.

To learn how to configure proxy chaining, see Configuring Proxy Chaining.

Surrogate IP

Enabling Surrogate IP allows the Zscaler service to map a user to a private IP address and apply the user's policies, instead of the location's policies, to traffic that it cannot authenticate, such as transactions that use unknown user agents. To learn more about Surrogate IP, see What is Surrogate IP?

You must enable Surrogate IP for non-browser apps, such as Window Metro apps. With Surrogate IP, a user can authenticate to the service in one web browser, and will not have to authenticate again if the same user opens another web browser or use non-browser applications.

If you disable this feature, Zscaler loses its ability to tag all user traffic as authenticated once the user has authenticated successfully in at least one web browser. For example, if the user authenticates to the Zscaler service in Chrome and opens Firefox, that user will be prompted to authenticate again in Firefox.

Best Practice: Using Tunneling, PAC Files, Surrogate IP, and Zscaler App

Zscaler recommends that you use a combination of tunneling, using PAC files, enabling Surrogate IP, and installing Zscaler App on your users' devices, to forward traffic to the Zscaler service. Zscaler also recommends that organizations deploy mechanisms, such as IP SLA, to monitor tunnel health and enable tunnel failover.  

Note that if the tunnel's originating router is located after NAT traversal, Surrogate IP will not work.

Benefits:

  • You can leverage all of the features of the Zscaler platform, which includes Bandwidth Control, Cloud Firewall, and creating group and department policies.
  • Users cannot bypass the Zscaler service.
  • You can create sub-locations to implement different policies based on IP addresses. To learn more about sub-locations, see What is a sub-location?

If you cannot deploy this combination at all locations, you can choose any of the alternative traffic forwarding methods listed below for some locations.

Alternative Traffic Forwarding Methods

Using Tunneling, PAC Files, and Surrogate IP

See below for the benefits and limitations of using a combination of tunneling, using PAC files, and enabling Surrogate IP.

Benefits:

  • You can leverage all of the features of the Zscaler platform when the users' traffic is forwarded from known locations.
  • Users cannot bypass the Zscaler service.

Limitations:

  • When user traffic is forwarded from unknown locations with a PAC file, some features of the Zscaler platform are unavailable, such as Cloud Firewall, sub-locations, and Surrogate IP.
  • Not all applications support PAC files, therefore not all traffic will be secured by Zscaler.

Using Tunneling and PAC Files

See below for the benefits and limitations of using a combination of tunneling and PAC files.

Benefits:

  • You can leverage all of the features of the Zscaler platform when the users' traffic is forwarded from known locations.
  • Users cannot bypass the Zscaler service.

Limitations:

  • When user traffic is forwarded from unknown locations with a PAC file, some features of the Zscaler platform are unavailable, such as Cloud Firewall, sub-locations, and Surrogate IP.
  • Not all applications support PAC files, therefore not all traffic will be secured by Zscaler.
  • Without Surrogate IP, users will need to re-authenticate every time they use a new user agent, such as a new browser, because the Zscaler service will not be able to perform user to IP mapping.

Using Tunneling and Surrogate IP

See below for the benefits and limitations of using a combination of tunneling and enabling Surrogate IP.

Benefits:

  • You can leverage all of the features of the Zscaler platform when the users' traffic is forwarded from known locations.
  • Users cannot bypass the Zscaler service from a known location.

Limitations:

  • There is no protection for remote users outside of the office, because that traffic cannot be forwarded to the Zscaler service.
  • Managing applications that need to be excluded from the Zscaler service becomes difficult without PAC files.

Using Tunneling Only

See below for the benefits and limitations of using only tunneling to forward traffic to the Zscaler service.

Benefits:

  • You can leverage all of the features of the Zscaler platform when the users' traffic is forwarded from known locations.
  • Users cannot bypass the Zscaler service from a known location.

Limitations:

  • Without Surrogate IP, users will need to re-authenticate every time they use a new user agent, such as a new browser, because the Zscaler service will not be able to perform user to IP mapping.
  • Not all applications support PAC files, therefore not all traffic will be secured by Zscaler.
  • There is no protection for remote users outside of the office, because that traffic cannot be forwarded to the Zscaler service.
  • Managing applications that need to be excluded from the Zscaler service becomes difficult without PAC files.

Using PAC Files to Forward Traffic to a Dedicated Proxy Port

Your organization can subscribe to one or more ports, associate them with a location, and then forward your traffic to those ports. A dedicated proxy port is considered a known location. To learn more about dedicated proxy ports, see What is a dedicated proxy port?

Note that if you use this deployment, you must not specify specific ZENs by host name or IP addresses in the PAC file in order to prevent failover. In the PAC file, you must use the variables ${GATEWAY.<zscaler_cloud>} and ${SECONDARY_GATEWAY.<zscaler_cloud>} to send web traffic to ZEN closest to the user. Replace <zscaler_cloud> with your cloud name. To learn how to find your cloud name, see What is my cloud name?

See below for the benefits and limitations of subscribing to one or more dedicated proxy port and using PAC files to forward traffic to those ports.

Benefits:

  • The service can apply location, group, and user policies to the traffic.
  • If your router can attach X-Forwarded-For (XFF) headers and if it is enabled on your location, you can leverage the Surrogate IP feature.

Limitations:

  • You will not be able to leverage some of the features of the Zscaler platform, such as Bandwidth Control and Cloud Firewall, because you need tunneling to use them.
  • This method may not work when users connect to guest Wi-Fi (for example, at hotels and cafés) if that network only allows port 80/443 traffic and blocks the dedicated proxy port.
  • Not all applications support PAC files, therefore not all traffic will be secured by Zscaler.
  • End users may be able to bypass the Zscaler service by disabling PAC files.
  • Unless XFF headers are inserted, Zscaler will lost internal IP address visibility and you will not be able to leverage the sub-location feature.
  • SLAs and performance may be impacted if you don't implement GRE or IPsec tunnels.
  • Without Surrogate IP, users will need to re-authenticate every time they use a new user agent, such as a new browser, because the Zscaler service will not be able to perform user to IP mapping.

Using PAC Files to Forward Traffic

See below for the benefits and limitations of using only PAC files to forward traffic to the Zscaler service.

Benefits:

  • You can create locations if traffic is coming from a static public IP address.
  • If your router can use XFF headers and it is enabled on your location, you can leverage the Surrogate IP feature.  

Limitations:

  • You will not be able to leverage some of the features of the Zscaler platform, such as Bandwidth Control and Cloud Firewall, because you need tunneling to use them.
  • Not all applications support PAC files, therefore not all traffic will be secured by Zscaler.
  • End users may be able to bypass the Zscaler service by disabling PAC files.
  • Unless XFF headers are inserted, Zscaler will lose internal IP address visibility, and customers will not be able to leverage the sub-location feature.
  • SLAs and performance may be impacted if you don't implement GRE or IPsec tunnels.
  • The service can apply group and user policies, but not sub-location policies.
  • Without Surrogate IP, users will need to re-authenticate every time they use a new user agent, such as a new browser, because the Zscaler service will not be able to perform user to IP mapping.

Using Zscaler App Only

See below for the benefits and limitations of using only Zscaler App to forward traffic to the Zscaler service.

Benefits:

  • Zscaler App forwards all port 80/443 traffic to the Zscaler service for inspection from any location and ensures that your configured security and access policies will always be enforced.
  • Zscaler App can be configured to prevent your users from disabling, bypassing, or uninstalling it.
  • When traffic is forwarded to the Zscaler service, Zscaler provisions your organization's IP addresses, which can then be added as known locations in the admin portal.
  • You can deploy SSL inspection for Zscaler App users.

Limitations:

  • You cannot use Zscaler App to forward traffic for all ports and protocols to the Zscaler service.
  • You will not be able to configure location-based policies.
  • Your organization will not be able to leverage some features, such as Bandwidth Control, Cloud Firewall, sub-locations, and Surrogate IP.
  • Zscaler App may introduce performance impact.
  • A software application will need to be deployed, managed, and maintained on all end devices.

Using Proxy Chaining Only

See below for the benefits and limitations of using only proxy chaining to forward traffic to the Zscaler service.  

Benefits:

  • This method leverages your existing proxy servers, with no additional changes to the network.

Limitations:

  • You will not be able to leverage some of the features of the Zscaler platform, such as Bandwidth Control and Cloud Firewall, because you need tunneling to use them.
  • Multiple proxies add latency.
  • Proxy servers that support failover support only manual failover.
  • Unless XFF headers are inserted, Zscaler will lose internal IP address visibility and customers will not be able to leverage the sub-location feature.
  • Performance issues and troubleshooting issues are more difficult to solve.
  • It may be difficult to configure proxy chaining for all Internet traffic, which may result in Zscaler not providing complete Internet security.
  • SLAs and performance may be impacted if you don't implement GRE or IPsec tunnels.
  • Without Surrogate IP, users will need to re-authenticate every time they use a new user agent, such as a new browser, because the Zscaler service will not be able to perform user to IP mapping.