Tunnel 2.0 country variable


Can you please explain if it is possible to use country variables in pac file when tunnel 2.0 is used?

We have some plans to move from tunnel 1.0 to 2.0 but we are using country variable to keep some traffic inside specific countries, as for example we had some issues that users from Sweden were connected to Denmark etc.


Yes that works well. I use it time to time for demo.

Best Regards,

Jones Leung

1 Like

Hello Jones,

Thank you for information, that is good news. But I also have one additional concern, does in tunnel 2.0 is any possibility to steer traffic to specific urls? So for example my main node is Frankfurt but for google.com I would like to use Warsaw.


I imagine that is something you could do on an SD-WAN appliance where you could have a GRE or IPsec tunnel to Warsaw. You could then identify the traffic in the SD-WAN device that would need to go to Warsaw for instance. If these are remote-only clients not sure if this could be accomplished in a PAC file. Maybe someone else on the thread may know if this is possible in a PAC.


I am thinking about road warriors scenario. I know that this is not possibile in tunnel 2.0 directly, but I expected that if in fw pac I put statement
/* Updates are directly accessible */
if (dnsDomainIs(host, “google.com”))
this url will be bypassed from tunnel 2.0 to tunnel 1.0
and then in app pac I will do statement

/* Direct to specific node */
if (dnsDomainIs(host, “google.com”))
return “PROXY was1-2.sme.zscloud.net:443”;

Traffic for google will be directed to Washington node.



Hoping you can help me out with some issues I’m having with the country variable on tunnel 2.0. We’re having issues with users in China that are on Tunnel 2.0 because it’s sending their traffic to Tokyo. On our tunnel 1.0 profile we were using the country variable to force the China users to Shanghai.

We’ve tried doing the same thing on tunnel 2.0 but the traffic doesn’t seem to be matching the country variable, so it is going out via the default forwarding rule at the bottom of our pac file. I’ve been using a pac file tester on a machine located in China to validate this. Given I’m performing the pac file testing on a machine located in China, it should be matching the country variable and getting the rule to forward the traffic to Shanghai, instead I’m seeing the default rule as the result of the test.


Country variable is zscaler specific macros which requires pac file hosted on zscaler . If you are testing on different platform like online pac tester then it is not going to work.

Yeah, I think it is due fact that not all Zscaler nodes are capable to support tunnel 2.0. Unfortunatelly this information is not avaiable in documentation (at least I did not find it), and it was quite suprise for me when I find out about thatt. Hard to say if that will be aviable in China, as Zscaler have lot of other problems there.

1 Like

Did zscaler support tell you not all nodes can support tunnel 2.0?

Yes, and I understand that this way that not all Nodes have needed hardware to support tunnel 2.0

According to our TAM and to what is described on the config.zscaler.com Page, it needs to have the SVPN Virtual IP listed for the Datacenter your looking for, to confirm that it is capable and working. image

1 Like

Hi Katlyn,
Currently the Shanghai Node seems to have no SVPN Ip, so it wont be able to serve it.