Implementing Zscaler in No Default Route Environments

What is a no default route environment?

Many companies today have deployed an architecture that is known as a “no default route” environment in their network. In a network, the default route defines where a host will forward a packet when no specific route can be determined for a given destination address.  All packets for destinations not established in the routing table are sent via the default route. The default route usually points to a router, and eventually out to the Internet when the IP addresses for those packets are public IPs. However, in a no default route environment there is no default route known to most hosts that leads to the Internet, and thus this can be considered a closed network. Certain hosts in the network must be explicitly configured to reach resources on the Internet when there is no default route. With the advent of web proxies several years ago, many large enterprises have configured their legacy networks to use these proxies for security and other explicit control purposes.  In this architecture, web browser traffic is explicitly sent to a proxy through the use of a PAC file which is served via a local server, typically the proxy itself, and the proxy knows a valid path to the default route.

The no default route architecture when originally deployed many years ago was deemed to be a more secure approach, at a time when there was no direct access to the Internet except through the proxies and when very few Internet based threats existed. But in today’s world of cloud-based mission critical applications, mobile users, dynamic threats and targeted attacks, the usefulness of a no default route environment has been diminished. Regardless, Zscaler’s cloud service can be deployed in a no default route environment to provide a greater level of protection for end-users connecting to the Internet.

What are the challenges?

When deploying a cloud-based proxy service such as Zscaler into a “no default route” architecture, there are certain requirements to consider, including:

  • Fetching PAC files from the cloud
  • Forwarding traffic to cloud-hosted enforcement nodes
  • Protecting users when they are on or off the corporate network.

Managing the routes within an office and between offices in a no default route environment is also difficult. This makes it a necessary consideration when deploying a new solution where changes in a network configuration for each office are kept exactly the same between offices to simplify deployment. Also, some large distributed legacy enterprise networks may use Class A public IPs in an internal two-tier private network environment. This may make it more complex to add routes for public IPs in a customer network where overlap may exist with their private IPs.

Solution with Zscaler:

A no default route environment implies the use of either GRE or IPsec tunnels to deliver traffic to the Zscaler Enforcement Nodes (ZENs). With this in mind, the customer must choose whether to have separate internal and external PAC files (dual PAC), or just a single multi- purpose PAC file (single PAC). Dual PAC files will require an internal host plus the Zscaler external PAC server, while the other approach only requires the Zscaler PAC server.

Dual PAC - Customer Internal PAC Server + Zscaler External PAC Server:

  • Internal Users - Each browser must be configured with a PAC URL that points to a valid Zscaler-hosted PAC file. This URL must be spoofed on the internal network so that a browser can obtain the internal PAC file from an internal server. This requires using internal DNS to spoof Zscaler’s domain, or an intermediate device to rewrite the requested URL. The customer’s internal PAC server is configured to return a Zscaler Global ZEN IP (described below), and the user’s traffic needs to be explicitly routed though the network to the tunnel, which leads to the Global ZEN IP. This is typically accomplished via PBR (Policy Based Routing) policies on an internal router that is reachable by routes known to internal hosts.
  • For users outside the corporate network, the browser will obtain the external PAC file from Zscaler. A PAC file with the same name (so no changes to a user’s browser configuration required) is hosted on the Zscaler PAC server. When accessed, the PAC server returns the normal geo-localized IP, with the two nearest Zscaler public data centers, using ${GATEWAY} and ${SECONDARY_GATEWAY}, based on the fact that the PAC server detects that the user is not coming from a Zscaler IP. See Zscaler Best Practices for Writing PAC files.

Single PAC - Zscaler PAC Server for both Internal and External users:

  • Internal Users: When using only Zscaler’s PAC servers, the internal network requires a path as well as access to Zscaler’s external PAC file servers. Note that Zscaler hosts several PAC servers for redundancy so each of these IPs will need to be allowed. In this case, the user will be pulling the PAC over a GRE or IPsec tunnel. Therefore, appropriate routes and routing rules must be configured on internal routing devices to support access to this PAC host via the tunnel.
  • External Users: Browsers on PCs connected from external locations will obtain the PAC file directly from Zscaler with no special routing.
    The single PAC file requires additional logic to determine whether the user is on the internal or external network, and direct traffic accordingly. To aid the implementation of this logic, the Admin should check for reachability of an internal server. If the user is able to resolve this server, user should be located on the internal network and PAC should return the Global ZEN IP address. If the user is unable to resolve internal server, PAC should return ${GATEWAY} and ${SECONDARY_GATEWAY} returning the two closest ZEN IPs.

For no default route environments, Zscaler recommends that the single Zscaler PAC server be used, as this is an easier way to deploy without needing to maintain multiple PAC servers. The customer then needs to configure a route to these IPs and perform Destination NAT (preserving source IP) to send traffic through the tunnel to a Global ZEN IP. With this approach, a browser that uses the Zscaler PC while on the internal customer network will forward traffic to the Global ZEN IP, which will get routed through the GRE/IPsec tunnel and be properly received and process by the ZEN. A browser loading the same PAC from outside the corporate network will have a primary and secondary ZEN, based on the two closest ZENs.

In Zscaler’s architecture, a ZEN will process traffic that is destined for any ZEN in the cloud. This is called a Global ZEN. Zscaler has configured several Global ZENs across its clouds. Use the following IPs as Global ZEN IPs:

  • 185.46.212.88
  • 185.46.212.89
  • 185.46.212.90
  • 185.46.212.91
  • 185.46.212.92
  • 185.46.212.93
  • 185.46.212.97
  • 185.46.212.98

For example, in order to send packets to a Global ZEN (185.46.212.88), a user’s traffic with PAC configured will first resolve their PAC server address to http://pac.zscalertwo.net/your organization's domain/No-Default-Route. Because the user is coming from a Zscaler ZEN IP via a tunnel, the PAC server returns the Zscaler Global IP. See Figure 1 below.

The customer network must have a route for the Global ZEN IP through the internal network and be Destination NAT’d through the GRE or IPsec tunnel from the customer’s router to the Zscaler service. See Figure 2 below.

If the user is outside the corporate network coming from a non-Zscaler ZEN IP and non- customer public IP, then the PAC would use the "${GATEWAY}" variable instead. See Figure 3 below.

In the above described solution each of the customer location configurations will remain the same, providing a cookie cutter method of deploying configuration without differences between locations, minimizing any configuration and deployment complexity. In addition, both internal and external scenarios can be accommodated by a single PAC.

Customers can also detect whether the user is present on premise (by resolving an internal domain) and then return the Global ZEN IP. A sample PAC file is given below:

function FindProxyForURL(url, host) {

// If the user is able to resolve the internal domain, he is located on premise and the PAC file

// should return the Global ZEN IP address.

if (shExpMatch (host, "internal.sample_company.com"))

    return "PROXY 185.46.212.88:9400";

// Otherwise the user is external, send the user to the nearest Zscaler DC IP

return "PROXY ${GATEWAY}:9400; PROXY ${SECONDARY_GATEWAY}:9400; DIRECT";

}

Summary

The trends towards cloud-based services, Internet offloading, and protection for mobile users has led some companies towards transforming their networks. For those that choose to still embrace the “no default route” architecture, the Zscaler Global ZEN architecture can be leveraged for deployments.