A key component of the Zscaler cloud, Zscaler Enforcement Nodes (ZENs) are full-featured secure Internet gateways that provide integrated Internet security. They inspect all web traffic bi-directionally for malware, and enforce security, compliance and next generation firewall (NGFW) policies.

ZENs are deployed in Zscaler data centers around the globe. So no matter where your users are, at headquarters or at a branch office, in a coffee shop or at the airport, they can access the Internet from any device and the ZENs will protect their traffic and apply your corporate policies.

ZENs have significant fault tolerance capabilities. They are deployed in active-active mode all over the world, to ensure availability and redundancy. Zscaler monitors and maintains its ZENs worldwide to ensure 24/7 availability. They are located in Zscaler data centers, which provide the highest level of data privacy and network security.

Zscaler always recommends that organizations forward traffic to the ZENs in the Zscaler cloud. However, some organizations may have certain requirements, such as those listed below, that may make forwarding their traffic to the ZENs in the Zscaler cloud less than ideal:

  • Locations with certain geopolitical requirements and regulations
  • Locations that experience high latency when connecting to public ZENs
  • Applications that require an organization's IP address as the source IP address
  • Users who need to see localized content

If your organization has similar requirements, then with Zscaler's approval, you can extend the Zscaler patented cloud architecture to your organization’s premise by licensing and deploying virtual ZENs (VZENs). A VZEN uses a virtual machine (VM) to function as a full-featured ZEN dedicated to your organization’s traffic. VZENs perform the same service as the public ZENs in the Zscaler cloud, including support for features, such as the Firewall, Sandbox, and DLP.

Integrated with Zscaler Cloud

VZENs are part of the Zscaler cloud. They communicate with the Zscaler cloud for user authentication and policy updates, and for logging and reporting. Thus, admins define policies only once, through the admin portal. Additionally, after users are signed in and authenticated to the Zscaler service, the service will always apply their policies, whether they connect to an on-premise VZEN or to a public ZEN anywhere in the world. Logs are transmitted to and stored on the Zscaler cloud as a central repository for integrated analytics. So you can view and monitor Internet traffic activity on the admin portal dashboard and make full use of the real-time logging and interactive reporting capabilities of the service.

Easy, Fault-Tolerant Deployment

  • VZENs are easy to deploy and require minimal administration. Your organization has full access to the VZENs for monitoring and configuration. Zscaler does not require access to the VZENs.
  • VZENs are horizontally scalable so you can easily add more VZENs as your traffic increases.
  • VZENs are deployed in a cluster, which features built-in load balancers to ensure availability and redundancy.

Limitations

VZENs currently do not support the following:

  • Traffic forwarding through IPsec VPN tunnels
  • Kerberos authentication
  • Supports VMware ESX/ESXi only

About VZEN Clusters

VZENs are deployed in a cluster, which requires at least two VZENs for active-active redundancy and load balancing. As shown in the diagram below, each VZEN has a load balancer bundled in. The load balancer is specifically designed to distribute user traffic evenly across the VZENs.

NOTE: Zscaler does not recommend using external load balancers.

To ensure high availability, the Zscaler load balancers use Common Address Redundancy Protocol (CARP) for active-passive fault tolerance. As shown in the diagram, all VZEN instances in the cluster are active, and one load balancer instance is active at a time. The active load balancer receives ingress traffic through the cluster IP address and directs the traffic to the appropriate VZEN. If the active load balancer instance fails, then the passive load balancer instance automatically takes over, ensuring no disruption in service.

About VZEN Clusters

NOTE: For evaluation purposes with test traffic, you can configure a VZEN in standalone mode, which does not support failover. Zscaler does not support standalone VZENs for production environments with live user traffic.

Each VZEN in a cluster requires a separate VZEN subscription. Zscaler offers three VZEN subscription types, based on the amount of traffic that they process. If you have a subscription to the Zscaler Next Generation firewall and you are sending all your Internet traffic (both port 80/443 and non-port 80/443 traffic) to the VZEN, consider the total traffic volume when determining the VZEN type for your organization. The available VZEN types are as follows:

  • Small: The VZEN instance can process up to 30 Mbps of full duplex throughput.
  • Medium: The VZEN instance can process up to 100 Mbps of full duplex throughput.
  • Large: The VZEN instance can process up to 600 Mbps of full duplex throughput.

You can change the subscription type of the VZEN instances in a cluster if your traffic requirements change. Note though that all the subscription types in a cluster must be the same. Therefore, if you change one subscription in a cluster, you will need to change all the other subscriptions to match.

Forwarding Traffic to VZENs

VZENs are hosted within an organization’s premise. Zscaler recommends that you deploy VZENs behind your firewall, though you can deploy it in the DMZ as well. The following sections describe the different ways that your organization can forward traffic to a VZEN cluster.

GRE Tunnels

Zscaler recommends that you configure a GRE tunnel from your internal router to the VZEN cluster IP address. Because you are using internal IP addresses for the tunnel, you will not need to contact Zscaler to register the tunnel IP addresses. Though a VZEN cluster provides failover and redundancy, you can also configure a backup GRE tunnel between the internal router and a public ZEN.

GRE tunnels configured on VZENs are dynamically established with no internal IP addresses, similarly to unnumbered GRE tunnels. This requires VZENs to be configured as locations. Zscaler uses any internal IP address configured on the router side of GRE tunnels for routing purposes only. Note that proxy settings or ICMP ping on those internal ranges is not supported. You must use GRE keepalives and ICMP pings to the VZEN VIP for tunnel monitoring.

Forwarding Traffic to VZENs

PAC Files

You can configure your users’ devices to use a PAC file to forward their traffic to the internal VZEN. You can edit the Zscaler default PAC file and add the VZEN Cluster IP as the proxy, as shown in the following example

return "PROXY 10.84.0.188:80; DIRECT";

You can configure a failover to the Zscaler public ZENs too, as shown in the following example:

Return "PROXY 10.84.0.188:80; PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80;DIRECT";

If you want a user to browse through the VZEN while in the office and automatically switch over to a public ZEN when the user is out of the office, add the variable ${SRCIP} to direct the browser to send traffic to the VZEN. The following is a sample argument:

var egressip = "${SRCIP}";
If (shExpMatch(egressip,"203.0.113.10")) {
		/* User is in the office */
		return "PROXY 10.84.0.188:80;DIRECT";
}

L3 Redirect

If your router or switch is in the same subnet as the VZEN cluster IP address, then you can configure your router or switch to use L3 forwarding to redirect packets to the VZEN.