To deploy Zscaler Client Connector in a no-default route environment, see Implementing Zscaler Client Connector in No-Default Route Environments.

Some organizations use a no-default route architecture in their network, which means that although an individual client machine might have a default route configured, the edge router does not automatically forward all traffic upstream through the default route. Instead, it allows only specific devices to access the internet through static routes. In this architecture, web browser traffic is explicitly sent to a proxy using a PAC file that is served through a local web server, through the proxy itself, or through the use of Microsoft's Web Proxy Auto-Discovery (WPAD) protocol.

The advent of application proxy software and appliances enabled no-default route architecture, where application proxies can provide deep visibility and control for protocols such as HTTP and HTTPS, and firewall rules can be kept simple. In addition, many other protocols that require access to the internet can also be proxied similarly, including Simple Mail Transfer Protocol (SMTP), DNS, and FTP.

Organizations often consider the no-default route architecture a more secure option. However, it developed when cloud services did not exist, network traffic typically backhauled to a few egress points, users weren't mobile, and threats were more easily understood. Using this legacy architecture now leads to compromises.

Companies are moving away from Multiprotocol Label Switching (MPLS) and toward low-cost local access for internet offloading. In this context, maintaining a no-default route architecture requires a considerable cost to replicate appliances at each location. Additionally, mobile users must enforce an always-on virtual private network (VPN), which adds to latency and poor user experience, and allows users to access the internet unprotected when they are outside the organization's network. This is where Zscaler can provide additional value when used with no-default architecture.

Challenges: Using Zscaler in No-Default Route Environments

When using a cloud-based secure web gateway such as Zscaler in combination with a no-default route architecture, there are certain requirements to consider for fetching PAC files from the cloud, forwarding traffic to cloud-hosted Zscaler Internet Access (ZIA) Public Service Edges, and protecting users when they are on and off the corporate network.

A no-default route architecture relies on explicit proxy web traffic, either through the use of a PAC file or by hard-coding the proxy to use. A web browser fetches PAC files over port 80, and Zscaler publishes the PAC IP addresses for a cloud as part of the Zscaler Hub IP address range. You can use the IP address range to define static routes and firewall rules to allow access to the PAC files, including the proxy port. To learn more about Zscaler IP address ranges, go to (config.zscaler.com/<Zscaler Cloud Name>/hubs).

You can serve PAC files locally, but additional configurations are needed to provide dynamic failover and protect users outside the corporate network. Browsers fetch PAC files from Zscaler PAC file servers using special variables for proxy IP addresses, and Zscaler substitutes the user's source IP addresses with the nearest data center virtual IP addresses (VIPs).

If serving PAC files locally, verify that the Zscaler data centers used are available. To protect users outside the corporate network, ensure that the PAC file path resolves to the internal PAC file when inside the network, and to the Zscaler PAC file server when outside the network (which is highly recommended).

The following sections describe your options when using Zscaler in a no-default route environment:

Use Cases

• Servers that cannot use PAC files can use special DNS names such as gateway.zscalertwo.net and secondary.gateway.zscalertwo.net. Using these names provides some level of high availability because they resolve to available data centers based on the source IP address of the DNS resolver. You should also define static routes to allow access to the Zscaler data center ranges.

The Zscaler SLA does not apply in this scenario because there are known issues with Microsoft caching the DNS responses in violation of the Time to Live (TTL) returned. However, the Zscaler SLA can be acceptable for server traffic.

• Other protocols, such as SOCKS, which have traditionally been used in no-default route architectures to send non-proxy-aware protocols via a proxy, should be handled differently. In many cases, those protocols can be sent directly to the internet or configured to use a standard proxy.

The trend toward cloud-based services, internet offloading, and protection for mobile users has led some companies toward network transformation. For organizations that choose to still embrace the no-default route architecture, it is still possible to use Zscaler with some minor adjustments, either as a long-term solution or an intermediate one before network transformation.