How to avoid to connect Russia Zen Node

🆕 Connectors Client Connector
#1

Hi Friends,

I want to share this example with the community because this is a common request these days.

Below is a PAC file to apply to your Win/Mac ZCC profile if you want to prevent your users from connecting to the Russia ZEN node.

The example below is for “zscalertwo” cloud with Russian ZEN node IP: 165.225.90.24 . To use this PAC file, you need to use your “cloudname” and obtain your Russian ZEN node IP.

How it works: the PAC compares if the variables ${GATEWAY} or ${SECONDARY_GATEWAY} are equal to the Russian ZEN node IP. If yes, the variable “tozscaler” is changed to “PROXY fra4.sme.zscalertwo.net:80; PROXY muc1.sme.zscalertwo.net:80”; (you can put here the ZEN nodes you want. In this case, are Frankfurt and Munich)

Here the PAC:

function FindProxyForURL(url, host) {
// =========================================================
// Section 1: Zscaler standard PAC values

var privateIP = /^(0|10|127|192\.168|172\.1[6789]|172\.2[0-9]|172\.3[01]|169\.254|192\.88\.99)\.[0-9.]+$/;
var resolved_ip = dnsResolve(host);

/* Don't send non-FQDN or private IP auths to us */
if (isPlainHostName(host) || isInNet(resolved_ip, "192.0.2.0", "255.255.255.0") || privateIP.test(resolved_ip))
    return "DIRECT";

/* FTP goes directly */
if (url.substring(0, 4) == "ftp:")
    return "DIRECT";

/* test with ZPA */
if (isInNet(resolved_ip, "100.64.0.0", "255.255.0.0"))
    return "DIRECT";

// =========================================================
// Traffic to Zscaler Two - Restrict Russia ZEN node  -  165.225.90.24

// Direct to Internet
var tozscaler = "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";

// Get $GATEWAY address       
var gatewayZenIP = "165.225.90.24:80";
var gatewayReturned = "${GATEWAY}";
var SecondaryGatewayReturned = "${SECONDARY_GATEWAY}";

// Changing values to "tozscaler" if the user gets Russia ZEN Nodes. 
if ((gatewayZenIP == gatewayReturned) || (gatewayZenIP == SecondaryGatewayReturned)) {
    var tozscaler = "PROXY fra4.sme.zscalertwo.net:80; PROXY muc1.sme.zscalertwo.net:80";
}

// =========================================================
// Section 4: Default Traffic
/* Default Traffic Forwarding. Forwarding to Zen on port 80, but you can use port 9400 also */
return tozscaler;

}

Finally, you need to configure the PAC URL on the ZCC Win/MAc profile, section PAC Configuration → Custom PAC URL.

image
image711×555 36.7 KB

Thanks to @Trace_Woodbury for the testing done.

Best regards
Adrian Larsen
Maidenhead Bridge
Cloud Security Connectors for Zscaler.

7 Likes
How to temporarily bypass specific DCs for Road Warriors running ZCC
#2

Great post Adrian! Thanks for sharing with the community :slight_smile:

1 Like
#3

Thanks for sharing, Adrian. While it will solve most use cases, I see a few issues to watch out for, which I wanted to add to this thread.

  • You are changing the default return statement and forcing that traffic to the Frankfurt or Munich-based nodes. It might not be diserable for users close to Moscow but further from Europe as it will increase latency and decrease performance.
  • When used directly in the browser configuration, we have seen cases where PAC file processing is not optimal, causing the PAC file to be misinterpreted by the browser. Hence, Zscaler recommends to keep the PAC file as simple as possible.
  • Lastly, the PAC file uses the exact IP address of the Russia node, which might change in the future. This will effectively render the PAC file useless.

With that said, the better approach is to use a subcloud, i.e. a subset of Zscaler nodes you can adjust to your needs. In this scenario, your subcloud will contain all public Zscaler nodes except the one in Russia.
The only change admins will have to make is the default return statement in the default PAC file. No specific PAC file logic is required. Speak to your Zscaler representative about getting a subcloud up.

3 Likes
#4

We use a sub-cloud which excludes Moscow and other Service Edge locations we don’t want users connecting to. It works well the majority of the time.

One problem we do see is that if there is some kind of error it defaults back to the normal cloud config gateway..net which does include Moscow. So occasionally users do hit the Moscow Service Edge.