Hosted PAC file retrieval trough IPsec tunnel

(Marco Mulder) #1

HI, When the user is located in the LAN and use the hosted PAC file with $gateway and $secondary_gateway, how is the GEO location working (whihc IP adress will it get) .I know evey zen proxy returned will work ofcourse if all traffic is sent into the tunnel. Just want to know hoe the geo locaiton will work.
Thank you

(David Creedy) #2


The PAC file uses ${GATEWAY} for the primary ZEN and ${SECONDARY_GATEWAY} for the secondary ZEN. The service uses the GeoIP coordinates of the source IP address to determine the nearest ZEN. Zscaler uses MaxMind databases to associate the longitude/latitude coordinates with the source IP address, and using that provides the closest data center to connect to.



(Marco Mulder) #3

So it uses the Source IP adress of the IPsec tunnel ? as normally private IP addresses are used within the tunnel.
Kind regards

(David Creedy) #4

Hi Marco,

It’s essentially what ever source IP hits the PAC server. If you are coming through a tunnel, it would probably be the egress IP of the tunnel as the source for the request.

However, if you are using an IPSEC tunnel to route the LAN traffic to the cloud, there should be no need to use PAC files pointing to ZENs. Generally you would leverage these PAC files with mobile users who aren’t sending traffic through an existing tunnel.



(Nick Morgan) #5

Hi @mmulder - If you PAC file request is being transparently included in the IPSec VPN tunnel that terminates on your closest Zscaler DC then the source IP of the request will be the Zscaler ZEN instance IP your request is proxied by.

The ZEN instance IP will be used by the Zscaler PAC file server to establish (maxmind lookup) the users closest Zscaler DC and replace the $gateway value with the VIP IP address of that Zscaler DC. It is likely to be the same DC that your tunnel terminates on…unless of course the DC is not included in the $gateway resolution (such as China nodes).

(Marco Mulder) #6

Thank you, for the explanation

(Yogi Chandiramani) #7

you also have the following macro variables: ${COUNTRY} and ${COUNTRY_GATEWAY} to stay in the same country.
For example, if you have a user between the dutch and german border but located in the Netherlands, you can use ${COUNTRY} to send them to the AMS node even though maxmind says they are closer to FRA node.

(Adrian Larsen) #8

One feature that I would like to request is a new variable called something like ${LOCATION} that can be used simplify deployments - for example:

PC (user) ----> Tunnel IPsec/GRE —> ZEN Node (*) ----> PAC file server

1 - The request for PAC file travel from inside the IPsec / GRE tunnel, reach the ZEN that terminates the tunnel and goes to the PAC file Server.
2 - At the ZEN Node (*) a http header with the Location ID is inserted.
3 - PAC files server will read the Location ID and will return it ${LOCATION} variable.

Finally, on your PAC logic you can create the rule that will select the ZEN nodes that you want according the ${LOCATION}

(Note, this is similar than current ${SOURCE_IP} with the difference that is able to determine the proper location more precisely and will work with sites with Dynamic IPs)

My two cents here. I will submit this as a request through Zscaler support

Best regards

Adrian Larsen
Maidenhead Bridge

(Marco Mulder) #9

Thanks, learned something :slight_smile:

(Marco Mulder) #10

Thank you Yogi, did not know this.

(Yogi Chandiramani) #11


Are you sure ${LOCATION} variable exists ?

(Nick Morgan) #12

@yogic The ${LOCATION} variable doesn’t exist. @Adrian_Larsen was proposing it as an enhancement request and has now submitted this via support

(Yogi Chandiramani) #13

ok got it now


(Adrian Larsen) #14

Hi Friends

Enhancement Request number is : ER -4272

Best regards

Adrian Larsen
Maidenhead Bridge