Introduction and Background
Here at Ferroque, we’re fans of ridiculous stock photos. Might as well have been “proxy server” painted on a cow’s buns. It’s so bad it’s great.
Ah network proxies.
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 Citrix ADC features into an environment with web proxies present is getting ADCs access to outbound Internet addresses. This is more often than not a rare occurrence as Citrix ADCs tend to deal with routing traffic toward the internal network and not outbound to the Internet.
And 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 Citrix ADC 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 Citrix ADC 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 Citrix ADC, 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.
There are a few pre-requisites to allow the Citrix ADC 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 Citrix ADC 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 Citrix ADC 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 Citrix ADC IP and the proxy server(s) and log the request in advance.
- Ensure the Citrix ADC 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 Citrix ADC 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 Citrix ADC were being received by the proxy and routed accordingly.
Michael Shuster is Ferroque Systems’ Chief Architect and noted Citrix authority. A passionate virtualization and digital workspaces advocate, he has designed, engineered, or otherwise advised clients on Citrix, VMware, and Microsoft technology platforms across the globe.