ZPA in no default route environments

nodefaultroute
(Nathan Howe) #1

Often we find ourselves with customer who want to use our services, but are unable to do so due to lack of default routes to the Internet on their internal landscape. Naturally the lack of a DFR means that for a prospect or customer to consumer our services, there needs to be either:

  • static route defined from within the network to Zscaler, or

  • proxy with whitelisting for the Zscaler domains, IPs, etc.

  • PAC files to direct traffic to the necessary location

So if you do have a ZPA customer/prospect that has setup specific policies to allow the clients to speak to the ZPA cloud via one of the above options, then we can use ZPA to steer this traffic.

Consider the large European company that is a ZPA only customer - for M&A. E.g. ZPA policy was defined to enable the mother company users to access the Childe company apps and vice versa. Thus the ZPA name and IP space (ips.zscaler.net/zpa) has been whitelisted.

The customer then hit a snag as Z-App needed to update from 1.4 to 1.5, but they never whitelisted the Z-App update domains and ips (ips.zscaler.net/zscaler_app) & to get this done through security and change approval would take weeks if not months. Z-App, for the package update process, is not pac aware, thus even if the OS had a pac set, Z-App is not going on recognise that.

So the only way for the customer to get updates was to have users go “off network”.

BUT then this hit another snag, the customers security team mandates that all traffic MUST route through a full tunnel VPN (except the ZPA broker bound traffic).

This is where the power of ZPA comes in. The resolution here, albeit a work around, was to define the normally not-accessible apps as applications within the ZPA policy. Thus all traffic to these non-DFR & non-pac traffic can then pass through ZPA. Thus in the case of Z-App traffic, the customer defined the Z-App update domains and ips (ips.zscaler.net/zpa) as an app & steered this through a specific connector group.

This can be used for other non-pac or non-dfr traffic which means that you and your customers can steer that private traffic using the ZPA policy. Remember though, ZPA does not do inspection, so this is simply steering of traffic and nothing more.

One major caveat: while this super powerful, be aware that customers can only do this for private applications & must be done within the bounds of our (EUSA), which states Zscaler products cannot be used to bypass laws or regulation.

(Scott Bullock) #2

Nate, does the user have to go off-network for the update to work, or was the need to go off-network mooted once the Z-App updates domains were defined in Private Access?

(Nathan Howe) #3

Hey Scott,
So actually this work around alleviates the need to have the users go off net for the z-app update :slight_smile: