by Saadallah Chebaro, CTA, UAE CUGC Leader

Introduction:

Just when I thought I had it all figured out, Citrix NetScaler on Microsoft Azure gives me a reality check–proving to be a worthy adversary and a true nemesis. Having spent so much time on the HA part of NS on Azure, now is the time to dive into real-world scenarios involving advanced features, that being WAF “Web Application Firewall” use-cases on Azure with PaaS offerings aka. Web Apps.

Citrix NetScaler platinum offers WAF capabilities that can be applied to published virtual servers on the appliance itself, which works the same as on-premises or on-Azure, since IaaS machines can be simply added as a LB virtual server on the appliance in the same manner that on-premises VMs/Servers are added.

On Microsoft Azure cloud though, the Web App “Platform as a Service” offering allows organizations to host web applications directly on the cloud, utilizing a pre-built infrastructure environment that is maintained by Azure. This relieves you of the burden of having to build, configure, support, scale, and maintain backend infrastructure to host your web applications.

That sounded great, until my colleague Shejoor, received a requirement to configure WAF for Azure Web Apps using Citrix NetScaler, which clearly states on its Azure Marketplace that the service is fully supported on the cloud. Needless to say, documentation did not exist for this specific requirement, so after a week of work into it, here is how to get this working the right way.

Microsoft Azure has two approaches when it comes to creating App Services, each serves a different requirement:

• Web Apps

Directly create a web app service, upload your website content, and publish the same. Custom domains and custom SSL certs can be added to this service. A content delivery network can also be added to this web app and, most importantly, restrictions can be applied for accessibility to this service IP-based.

Downside here is that Web Apps are deployed with an Azure-provided public IP only and thus are created toward external access with no internal network functionality, which is a major show-stopper when it comes to our scenario: WAF with NetScaler for Web App Service. Unfortunately, our customer had this exact same scenario and I will detail how to make this work. But, it is not the optimal configuration, nor the recommended one.

https://docs.microsoft.com/en-us/azure/app-service/app-service-web-overview

In order to configure this with a direct Web App deployment, the following has to be done to overcome the challenges that an out-of-the-box approach would present:

• Add and Verify a custom domain to the Web App Service.
• Assign a custom SSL certificate to the Web App Service.
• Assign a Public IP to the Subnet IP SNIP of the NetScaler.
• Create an LB server with WAF policy applied and point to Web App Service.
• Delete CName record that was used to verify custom Web App domain and create an A record with same custom domain pointing to NetScaler VIP for that service.
• Disable HTTP on Web App Service and only allow HTTPS.
• Apply restriction on Web App and only allow access to NetScaler SNIP IP (All NS SNIPs if in HA mode).

The downside of this approach is that all traffic will be going from the SNIP public IP to reach the Web App (since the Web App only has a public IP, thus we had to add a public IP to the NetScaler SNIP) and not communicate internally using Azure backend network which would be considered as outbound traffic, and Azure will charge you for all that traffic. Also, this approach requires HTTPS with custom domain and SSL cert, as HTTP will not work between NetScaler and Web App. This approach is not recommended for high traffic Web Apps.

• App Service Environment

ASE creates a fully isolated and dedicated environment for securely running App Service apps at high scale. Create an App Service Environment and, inside that, create a Web App exactly as the first approach but one that would be hosted under the ASE. ASE can be configured with an external public VIP or an internal VIP connected to an Azure vNET. Because Internal ASE can have an internal IP (utilizes Azure Internal Load Balancer) that is hosted on a vNET, which, in turn can communicate internally with other Azure IaaS services, thus making it the recommended way to go.

NetScaler on Azure is an IaaS VM and is thus connected to a vNET which, in turn, has IPs that can be configured to communicate with an Internal App Service Environment that has a Web App configured. This would allow us to apply restrictions on the Web App to only allow traffic from NetScaler to force users to use the LB virtual server that has WAF applied to connect to the Web App. That is not possible with standard direct Web App deployment.

https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase

In order to configure this with an Internal App Service deployment, the following has to be done to overcome the challenges that an out-of-the-box approach would present:

• Build the ASE with an internal VIP on a vNET that is peered with NetScaler vNET in the same region.
• Add and Verify a custom domain to the Web App Service under ASE.
• Assign a custom SSL certificate to the Web App Service under ASE.
• Create an LB server with WAF policy applied and point to Internal ASE ALB IP.
• Delete CName record that was used to verify custom Web App domain and create an A record with same custom domain pointing to NetScaler VIP for that service.
• Disable HTTP on Web App Service and only allow HTTPS.
• On the NSG applied to the vNET of the Internal ASE, apply an allow rule from the NetScaler Subnet IP and block all other traffic. That is why we built the ASE on a seperate vNET because the NSG has to be applied to the whole vNET subnet not on the ASE directly.

The upside with this approach is that no public IP is required on NetScaler and communication is using Azure backbone internally, so no additional charges and no foreseen bandwidth limitations or performance issues since its on the same network logically. This is the recommended approach and the right way to do it.

Now, ASE is not cheap, and I could not add a service on my subscription, so cannot document this in my lab and with no customer consent, I won’t be able to show this (although I will show the first type deployment which has some similar steps and required more out-of-the-box thinking to get it working).

Configuration:

1- Create a Web App Service and a static HTTP site for testing (click to enlarge images):

Accessing the Azure-hosted URL on HTTP and HTTPs shows the following out of the box page.

Make sure that the service plan is not Dev/Test, so that a custom domain and SSL cert can be added for the Web App.

I have deleted the above and created one using Cloud Shell with a static HTTP site ( Deleted the above to have the same name “netscaler”).

2- Add a custom domain, SSL certificate, and apply HTTPS Only to Web App:

The reason I am showing this configuration is that because out-of-the-box, when using a custom domain, the A record with custom domain, cert, and IP SSL binding, is that the records must point to Azure-hosted public IP of Web App. So, how can NetScaler LB be configured with WAF applied in this scenario? If a NetScaler LB server is created and a subdomain mapped to it, without that subdomain being verified under Azure Web App although pointing to the Azure provided URL through the NS VIP, it won’t work. The trick here is that Azure only uses these records for verification, and after that has been done, they can be changed to point to the NetScaler LB server, which would then work only when using custom domain with IP SSL binding (took me a week to figure this out).

After Applying an IP-Based SSL binding, the public IP changes for the Web App so that in normal conditions, one would change this in the public DNS for the custom URL to work. But for us, no change as of now, since our subdomain is verified and in the near future after NS is configured, we will point this subdomain to the public IP of the NS VIP used to load balance this Web App and apply WAF policies on that virtual server.

Delete all related records to that subdomain, as later on, we will add only an A record for our custom subdomain pointing to the NS VIP public IP that is hosting that service.

3- Configure a load balancing virtual server on NetScaler for this Web App and apply WAF policy and Web App IP Restriction:

Remember to add a public IP to the Subnet IP:

Server must point to the Azure-provided URL, not custom URL:

Apply WAF policy on this virtual server:

Create an A record for the custom domain previously added to Web App that points to the public IP assigned to the NS virtual LB server that has WAF enabled:

Test access to custom domain (which now is going through NS):

IP restrictions will be added to only allow SNIP public IP to access this Web App Service (this would prevent users from accessing the Azure-provided URL and bypassing the NS LB URL which has WAF enabled):

Access to the Azure-provided URL is now blocked from ALL IPs except NetScaler SNIP public IP:

Conclusion:

Internal ASE is the recommended way to go forward when wanting to deploy WAF the right way for a Web App, yet the direct configuration does work with the listed “before considerations and short comings.” If I get access to an ASE environment, I will document the same though for the most part, the difference would be an Internal ASE would have an internal IP rather than a web URL to load balance, and restrictions would apply to allow SNIP internal IP rather than having to assign a public IP for the same in a standard Web App NS WAF approach. Let me know your thoughts.

Zero To Hero Blog