HowTo: Route NetScaler Outbound Internet Requests Through Proxy

Introduction and Background

For better or for worse, proxy solutions are a mainstay in the modern corporation’s network security arsenal. They provide highly extensible controls for outbound Internet traffic from the corporate network to restrict access to websites for a multitude of reasons.

As a consultant, they frustrate me to no end. I have yet to work with a customer who happened to have ZScaler deployed for example and have it not create a nightmare in some form or another for me. This isn’t a bash at ZScaler or other proxy services, it’s just the nature of the beast and comes with the territory.

Back on point… one challenge one might encounter when integrating NetScaler features into an environment with web proxies present is getting NetScalers access to outbound Internet addresses. This is more often than not a rare occurrence as NetScalers tend to deal with routing traffic toward the internal network and not outbound to the Internet.

At the network level, there are seldom workarounds to bypass this as most organizations who implement proxy solutions fully restrict their network so outbound communication can only occur through the proxy.

An example of a scenario that would require this, would be the NetScaler needing to access a public CRL or OCSP server out on the Internet. Working with a customer recently, this was a hard requirement as part of their device certificate checks which used an enterprise PKI platform whose OCSP responder was publically hosted. Without Internet connectivity, our OCSP server was inaccessible, and this compromised the security of their client certificate model as a result as the customer would need to omit the OCSP responder in order for users to continue logging in.

I am sure others have run into other scenarios where outbound calls from NetScaler to the Internet were necessary, but we’ll focus on this use case for the purposes of this article.

After attempting numerous methods in vain including PBRs, host A records, and virtual server configurations either alone or in combination with each other, an esteemed colleague provided a surprisingly simple and effective solution using merely a host A record on the NetScaler, and a modification to the URL out on the Internet. it is so simple in fact, it will take a fraction of the time to read it, as you have spent reading this introduction.

Pre-Requisites

There are a few pre-requisites to allow the NetScaler to use a proxy service for an outbound request. They are as follows:

• Know the IPs of the proxy server(s) in your network and the port they’re configured to listen on.
• Acquire an exception (if necessary) for the NetScaler IPs (in case of an OCSP responder check, the SNIP is the source) to access the proxy server WITHOUT needing authentication. Good proxy solutions should have this ability, and most security admins are aware this is a necessary evil on an exception basis. In our case, a network appliance that in niche configurations, needs to call out to specific addresses on the Internet. Although it is likely possible to get a NetScaler to authenticate against a proxy server, this is not a native capability, and would likely be so complicated (and questionably supportable) as to significantly diminish the value of attempting to accommodate this.
• Determine if a firewall rule is required between the NetScaler IP and the proxy server(s) and log the request in advance.
• Ensure the NetScaler IP can route to the proxy server(s). This may seem obvious but in some network architectures, it may intentional by default to not permit certain networks to access the proxy service.
• [Optional – For OCSP Responders] Ensure the OCSP responder policies are configured and bound to the CA certificate, and the CA certificates are bound to the vServer with “OSCP Mandatory” set.

Step 1 – Create Host A Records

A straightforward and common task, navigate on the NetScaler to Traffic Management > DNS > Records > Address Records.

Create a new record with the FQDN of the OCSP server. In this case “ocsp.internalhostnames.com” and specify the IP (or IPs if there are several) of the proxy server. This will have the effect of routing the appliance’s HTTP request for the URL using that hostname, through the proxy.

Step 2 – Modify the Object Calling the URL

In this case, the Internet URL was specified within the OCSP responder policy. Simply append the FQDN to include the port of the proxy. In this example, http://ocsp.internalhostnames.com became http://ocsp.internalhostnames.com:8080.

Step 3 – Test!

In the reference scenario, we successfully confirmed the OCSP responder policy now worked when bound to the CA certificates. The customer security engineer confirmed requests from the NetScaler were being received by the proxy and routed accordingly.