Zscaler cloud proxy and obvious logical flaw in default PAC file template

 Here is the default PAC file template from Zscaler cloud security solution:

function FindProxyForURL(url, host) {
    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(host)) {
        return "DIRECT";
    }

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

    /* Updates are directly accessible */
    if (((localHostOrDomainIs(host, "trust.zscaler.com")) ||
        (localHostOrDomainIs(host, "trust.zscaler.net")) ||
        (localHostOrDomainIs(host, "trust.zscalerone.net")) ||
        (localHostOrDomainIs(host, "trust.zscalertwo.net")) ||
        (localHostOrDomainIs(host, "trust.zscloud.net")) ) &&
        (url.substring(0,5) == "http:" || url.substring(0,6) == "https:")){
        return "DIRECT";
    }

    /* Default Traffic Forwarding. Forwarding to Zen on port 80, but you can use port 9400 also */
    return "PROXY ${GATEWAY}:80; PROXY ${SECONDARY_GATEWAY}:80; DIRECT";
}

 I don't know how, but quiet obvious error crept here, highlighted with bold:

    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(host)) {

And here is the screenshot for sake of proof:

The point being here is that privateIP.test should check resolved_ip variable against regexp instead of host. That's it. So the correct variant is here:

    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)) {

Strictly speaking, this is not only Zscaler's default PAC template error, but somehow this code snippet was spread widely across the Internet.

For example, the same error migrated here:

http://itzecurity.blogspot.ru/2016/05/pac-file-recommendation-warnings-and.html

and here:

http://findproxyforurl.com/pac-code-snippets-examples/

 and even here:

https://support.google.com/chrome/a/answer/3504945?hl=en

Certainly, at the time you will check it, error may be fixed. But this is good sign that means my blog post was notified.

Hope this helps somebody.

Quick note: How to check http server reachability if you can't resolve DNS name

Note: How to check http server reachability if you can't resolve DNS name:

Variant number one:

$ telnet 127.0.0.1 80
GET / HTTP/1.1
host: www.example.com

Variant number two with curl:

$ curl --resolve www.example.com:80:127.0.0.1 http://www.example.com/ 

Better varian for older curl:

curl -k --verbose --header 'Host: www.example.com' 'https://127.0.0.1:443/' 

Even shorter:

curl -kvH 'Host: www.example.com' 'https://127.0.0.1:443/'  

Tricks: Maximum Recursive Route Lookups IOS vs IOS XR

Just small note, primarily for myself because long time ago I was absolutely sure that maximum recursive route lookup was limited to 3rd level depth (Maybe it was changed?), actually, for IOS 15.4(2)T1 tested that 9th lookup is too many:

Check it your own if you want ;)

192.168.0.0/24 - connected network in my example:

ip route 1.1.1.1 255.255.255.255 1.1.1.2
ip route 1.1.1.2 255.255.255.255 1.1.1.3
ip route 1.1.1.3 255.255.255.255 1.1.1.4
ip route 1.1.1.4 255.255.255.255 1.1.1.5
ip route 1.1.1.5 255.255.255.255 1.1.1.6
ip route 1.1.1.6 255.255.255.255 1.1.1.7
ip route 1.1.1.7 255.255.255.255 192.168.0.2


1.1.1.1/32, epoch 0
  recursive via 1.1.1.2
    recursive via 1.1.1.3
      recursive via 1.1.1.4
        recursive via 1.1.1.5
          recursive via 1.1.1.6
            recursive via 1.1.1.7
              recursive via 192.168.0.2
                recursive via 192.168.0.0/24
                  Too many (9) levels of IP recursion truncating
1.1.1.2/32, epoch 0
  1 RR source [no flags]
  recursive via 1.1.1.3
    recursive via 1.1.1.4
      recursive via 1.1.1.5
        recursive via 1.1.1.6
          recursive via 1.1.1.7
            recursive via 192.168.0.2
              recursive via 192.168.0.0/24
                attached to GigabitEthernet0/0
  
And for IOS XR according to the documentation it limited to 128 and can be configured with recursion-depth-max command in the range of 5 to 16.