Another round of critical NetScaler vulnerabilities, another night of emergency patching. they all have one thing in common. Network access to the Gateway was enough, no login required. I am considering a simple hardening layer: a small reverse proxy from a different vendor in front of NetScaler, doing just one job: enforcing a device certificate (mTLS). No certificate, and the traffic never reaches NetScaler. The key word is small. Candidates are HAProxy, Caddy or Envoy on hardened Linux. Not FortiGate, Palo Alto, F5 or Ivanti, as these are equally complex all-in-one appliances with their own track record of critical vulnerabilities. Putting one of them in front of NetScaler only moves the problem. It will not remove bugs from the code, but it changes "anyone on the Internet within hours" into "someone who first has to compromise a managed device". And that buys time to patch calmly. Does anyone run a setup like this in production? What do you think: a sensible layer of defense, or extra complexity with no real gain?

Let us know how it goes. I’m pretty sure it’ll crap up at least ICA/HDX stuff and perhaps other GW functionalities…

If you can put a cert on all devices that connect in, why use a 3rd party tool? Why not just enforce mTLS cert on the gateway itself? That should prevent any connections and thus threat actors that dont have the certificate wouldnt it?

Interesting discussion. I’ve been working on a related approach for quite some time, using hardware-backed YubiKey PIV certificates for mandatory mTLS directly on NetScaler Gateway, followed by Entra ID / Okta OIDC authentication with phishing-resistant FIDO2. I’ve automated the NetScaler configuration through NITRO, including certificate and CRL integration, and built a Docker-based Linux CA implementation to make the setup reproducible. I also have an established Microsoft AD CS variant. This doesn’t provide the same independent isolation boundary as an external HAProxy/Caddy layer, but it might be an interesting alternative for environments wanting native Gateway integration without additional reverse proxy infrastructure. I’m preparing the complete mTLS reference implementation for GitHub. The underlying NITRO automation is already available here: https://github.com/bensplittgerber/netscaler-nitro Happy to exchange experiences with anyone working on similar designs.

@langsbr With mTLS on the gateway, the NetScaler still accepts every connection from the internet and has to process it before it can reject it. Most NetScaler CVEs are exploited at exactly that point, before authentication. The third-party solution checks users and devices in front of the NetScaler, so untrusted traffic never reaches it at all.

I can't pretend to be an IP, Netscaler, or mTLS expert, but doesn't the mTLS cert block the connection at the TLS layer, preventing the vast majority of the netscaler RCE and authentication bypass attacks that happen at layer 7. It wouldnt be 100% protective, but would it not reduce the attack surface dramatically?

Yes, you're right that mTLS cuts the attack surface a lot. Most of the known NetScaler RCE and auth bypass bugs sit at layer 7, and without a valid certificate an attacker never gets there. But the NetScaler is still the one doing the certificate check. So it still accepts every connection from the internet, and its TLS stack still processes untrusted traffic. It also stays visible to scanners, and it can still be hit by DoS or by a bug in the TLS handshake itself. On top of that, a client certificate can be stolen from an endpoint, and then the attacker is back at layer 7 with full access. So mTLS is a good step, but the goal is for untrusted traffic never to reach the NetScaler at all. Only a separate layer in front of it can do that.

Makes sense. Ive seen all kinds of potential solutions for this thrown about lately but wouldn't any edge device be in scope for being a massive target?

Yes, any edge device is a target, the gate included. That's why it should do one small job with very little code, and come from a different vendor than NetScaler. To get in, an attacker would need two zero-days at the same time, for two different products from two different vendors, which is very unlikely.