Conditional forwarding or host file for zpa app

Hello I have a peculiar situation that I am racking my brain on how to do.

I have an app segment in which the apps are public websites that are anchored to public facing firewall NAT. The websites have public DNS but only allow whitelisted IP addresses to them. Our NAT is one of them…that is why I run these sites down the ZPA tunnels instead of going thru ZIA.

Some sites have been moved to cloud services and have no footprint to the public. The websites are 10.x.x.x ip addresses and no NAT. Our server enclave peers with the server enclave of the hosted websites. I can jump on a server and successfully browse to a website. Our clients on ZPA cannot. This is because our DNS doesn’t know about these sites and cannot go up the chain to find the sites (because they do not have public DNS). Is there a way to create a PAC or some other method that i can tell Zscaler “when a user goes to privatesite.domain.com that they go down the ZPA tunnel but do not use local DNS. they use a static/predefined method” …sort of like utilizing a host file?

Hey Nicholas,

as you already have ZPA: you could deploy a fwd proxy within your server enclave and route traffic for dedicated websites directly to that proxy via forward-PAC, e.g.:

/* Bypass for PRIVATESITE */
    if (localHostOrDomainIs(host, "privatesite.domain.com"))
    {
    return "PROXY PROXY.SERVERENCLAVE.COM:8888";
    }

Then configure your proxy to

  1. only accept requests from your ZPA-Connectors IPs (to make sure no one else use this fwd proxy for any other traffic) and
  2. route traffic via whitelist only for dedicated target URLs and discard any other requests

On the proxy host you would be able to use DNS settings of your choice and therefore “privatesite.domain.com” could be resolved to any IP of your liking (e.g. by local hosts file or local bind-dns).

We do some similar stuff for building our own IP anchoring solution. One could start with tinyproxy (https://tinyproxy.github.io/) or haproxy (https://www.haproxy.org/). The latter is officially “production-ready”, but also tinyproxy is quite stable & reliable.

I would start with tinyproxy (very easy to get up&running) and if you need a more sophisticated solution go with haproxy.

BR
Manuel

1 Like

thanks manuel. After a little research i found out we do have the routes to the private source anchored websites, just the app connectors aren’t seeing the sites.
I confirmed virtual machines on the same subnet can get to the site, hypervisors hosting the app connectors can get to it - just the app connectors cannot.

from the app connector i get “no route to host”
my route tables have 10.0.0.0/8 in them because we have quite a bit on the 10 network. just for troubleshooting I put the ip and /32 so basically a specific address and no luck. The error alludes to possible a route issue but I am at a loss. DNS appears to be working but the the traffic simply isn’t leaving the app connector

image

I ran into this situation at my client. They have several sections of their network enclaved off for PII/PHI segmentation, dev sandbox, etc., and have done the same in their AWS VPCs. Rather than fighting their network team about the funky routing and whatnot, I have simply added a minimum cluster of App Connectors in these subnets. They are able to reach out to ZPA just fine, and also of course can reach in for those “hidden” apps since they are now L2/L3 adjacent.

When I originally built their network out, I had two clusters of three at their two DCs and a cluster of four in AWS because those were the places they said they had servers. 18 months on I continually learn more about the actual environment, so now I have those original clusters plus three more clusters of two at the DCs and an addidional cluster of two in a PII-containing AWS VPC.

I’ve also started using the Dockerized App Connector because it is significantly quicker to deploy. It’s not technically listed as supporting zpagov.net, but I tried it for S&G’s, and it works masterfully.

1 Like