Work around for sites that are geofenced

Hello, I was thinking about a problem recently encountered with geofencing. There are web resources in countries that restrict access based on your IP addresses and drops the traffic if it is not within the country. Instead of trying to bypass every one of these things is there a way to write a statement in the PAC file that can identify wether or not a website is for fenced and then disable it if it is?

Do web servers have anything you can pull from a query that may identify it as being geo fenced? Looking to find a creative but not to difficult way around this. Any ideas are welcome.

Geo fencing is fun, aint it? :nauseated_face:

Say that you need to access some geo-fenced website in Canada but your users/locations are (mainly) outside of Canada, you just happen to have a small office somewhere in Canada…

In general there are multiple ways to solve such a problem, all have their own pros and cons:
a) Access these servers not directly from the client but via a Citrix server located in your office Canada
b) Change the US/wherever office locations GRE/IPSec endpoints at Zscaler side to be in Canada (Montreal, Toronto, Vancouver)
c) Access to these destinations needs to get tunneled through a ZS SIPA instance in your office in Canada (traffic would then be client->ZS cloud->SIPA Canada->internet)

A+C depend on infrastructure components which might not (yet) exist in your location in Canada; means would require to either a Citrix server or a SIPA connector being setup in our office in Canada first.
Both would work for users on premise and for user working from remote (C would even work without VPN, A would depend on an active VPN).

B might create more problems than it solves.
It could easily be that this measure then breaks connections to various US-based services for your users in US which work today but would not work when the access comes from Canada.
So maybe this then just replaces ‘meeeh’ with ‘dooh’… can’t be said for sure – no one knows which internet services today uses which kind of geofencing measures (and that can change pretty much any minute).

Great suggestions, unfortunatly I do not think they apply. I have users in Ukraine getting russian IP addresses being dropped from government sites. No zscaler edge there so an exception needs to be added for every site, and that’s just not something I want to do. Also have users in Ireland getting a London IP getting dropped from Irish servers. Again no edge in Ireland.

For suggestion A that would work if I had access to a jump server or the ability to stand one up but I do not.

Suggestion B won’t work because no edges in those countries. These are just 2 of the multiple countries that this is happening with.

What I think may work is using the pac file to detect and disable the ZCC for those sites. Just trying to figure out how to write code to determine if geofencing is enabled on the site.

As far as i’m aware there is no general way to reliably figure out whether or not a website is using geofencing mechanisms or not; always a try&error game.

Just wondering - do you have a location with GRE/IPSec tunnels towards ZScaler or do we talk about users working from home here?
If the former - change the locations configuration to NOT establish any tunnel with ZScaler CENR Moscow but some other CENR.
If the later - are you hosting your pac file at ZScaler? IF yes then you could step away from using ${GATEWAY} variable but instead use ${COUNTRY_GATEWAY}.
In a nutshell this behaves like the normal gateway with the exception that -if one is available- a CENR in the same country is choosen, if not then ZS uses the best one.

You can even get extra sure and only utilize that when the user is in UA, like adding this into your pac file:

var usercountry = "${COUNTRY}";
 if (shExpMatch(usercountry,"Ukraine")) { GW="PROXY ${COUNTRY_GATEWAY}; PROXY ${COUNTRY_SECONDARY_GATEWAY}"; }
 if (shExpMatch(usercountry,"Moldowia")) { GW="PROXY ${COUNTRY_GATEWAY}; PROXY ${COUNTRY_SECONDARY_GATEWAY}"; }

From what my TAM told me ZS has measures in place these days specifically for that UA<->RU issue and assures that ${COUNTRY_GATEWAY} will never resolve to their CENR in RU when the user is in UA, same for Moldawia.

Hope that helps.

1 Like

IMHO - Thomas has provided the best solution to solve your original problem and ensure the most secure transaction. SIPA is definitely the long-term solution if performance or the country variable doesn’t address some other geopolitical issue (e.g. you definitely don’t want to bypass ZS for traffic sourced from Russia, even if you could determine the destination is geo-fenced!), but it does come with a significant cost depending on if you are only using ZIA and the number of users you have subscribed.

That said, the COUNTRY variable in the PAC file is still the best option until geo-fencing goes away because people finally figure out it’s an ineffective “speed bump” with a better alternative (XFF Headers or better yet, SAML-based authentication so you put authentication before access instead of the other way around).

1 Like