Traffic Forwarded to un-authorized DC

Hello,

We have used below statement in our PAC File.

var country = “${COUNTRY}”;
if (shExpMatch(country,“India”)) {
return “PROXY ${COUNTRY_GATEWAY_FX}:80; PROXY ${COUNTRY_SECONDARY_GATEWAY_FX}:80; DIRECT”;
}

Even though we specified above, we still see that some traffic is routed to another Data Centers rather than India DCs.

Is this expected behavior ? This is something concerning us.

Generally also, we do see random traffic is being routed to another DCs (Los Angeles, Singapore Etc.,)

Below is the return statement we are using for our default PAC File.

return “PROXY ${GATEWAY_FX}:443; PROXY ${SECONDARY_GATEWAY_FX}:443; DIRECT”;

Thanks,
Rahul V

Guess you already doublechecked (by downloading that pac file from such a ‘misguided’ user) that country variable is correctly set to ‘India’?
Does the same happen when you remove the ‘; DIRECT’ fallback option from the return statement?

Could easily be that the IP geolocation DB ZScaler uses does not have 100% accurate information.

Just going to ping a few people in the community that have answered these types in the past. @Andreas, @JonasBoehm can you assist?

Otherwise, if everything is configured properly, I would reach out to support :slight_smile:

Sources:

Hi,

yes, sometimes the gateway / country gateway do not show the expected results. (geo locations wrong, Zscaler has removed a ZEN temporarily from gateway variable…)

I guess, that the variables are set based on a service like this, just change the IPs in the URL to query your URL.
pac.zscloud.net/getGatewayEndpoints?srcip=27.110.149.238

I would suggest to not use the $gateway variable together with ${COUNTRY} but hardcode the ZEN nodes.

var country = “${COUNTRY}”;
if (shExpMatch(country,“India”)) {
return “PROXY maa2.sme.zscloud.net:80; PROXY del1.sme.zscloud.net):80; DIRECT”;
}

Instead of “${COUNTRY}” and depending on your architecture you could also try to use “${SRCIP}”; But this would work only for locations with static IPs but no GRE/IPsec tunnel.

However, you would either need different PACs / profiles if your users are based in different regions of India. Users travelling around in India would sometimes get “not so close” ZEN nodes - but always ZENs in India, if Country-Variable is set correctly.

What is your traffic forwarding? It is tagged as Client connector. In that case I would not use DIRECT at all in the app profile pac.

Best regards
Andreas

1 Like

We have an on-going ticket with Zscaler due to clients randomly not being able to parse or download the PAC file. This causes them not to use our sub-cloud or country variable and use the default proxy variable.

This is AMAZING. Never seen it before.

there are some more of these ‘hidden gems’
never seen that one so far either but another one (sorry, forgot what exactly but was also very helpful)

One i do remember is this one:
http://127.0.0.1:9000/?ztest?q=@<your domain, like acme.com>

Would really be great to have an offiical KB article listing all these nice little gems.

1 Like

[quote=“GordonWright, post:5, topic:17683, full:true”]
We have an on-going ticket with Zscaler due to clients randomly not being able to parse or download the PAC file.[/quote]
Does the pac file come back green when verifying it in the GUI?
Unless you’re doing some really odd things (wrong charset, hidden characters or alike) in the pac that verification is pretty solid (syntax, logic flaws is a different topic)

I think we found the PAC verified correctly in 6.1 but failed in 6.2.
Something to do with a variable we where declaring.

hmm, still on 6.1 so can’t say much here
But would be interesting to know what exactly the issue was/is - we use quite some ‘pac voodoo’ as well (but no subcloud).