Load test endpoints with access restrictions using Azure Load Testing

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Often, we see that the endpoints under test are sitting behind a firewall, or they are only accessible from within a virtual network or a network boundary. Yes, we are talking about private endpoints. This is a common practice to meet security requirements. Our customers gave us feedback that they also want to use cloud-based load testing to test such private endpoints. Well, now you can! Azure Load Testing uses VNet injection to inject the load generating virtual machines into the same virtual network as your endpoint to enable this scenario.  

 

In this blog post we'll take you through the steps to load test a specific type of private endpoint: public endpoints with access restrictions. These are endpoints that have a public IP address and are accessible over the internet, but access to these endpoints is restricted to a set of IP addresses, virtual networks, etc. For example, a service running behind an Azure Application Gateway, a web application deployed behind a firewall, a web API getting called by a front-end web application etc.

 

To enable this scenario with Azure Load Testing, you'll route the test traffic through a NAT gateway and allow traffic coming from the gateway on your endpoint. Let’s see how to go about this.

 

Set up a sample public endpoint with access restrictions

Let’s use Azure App Service to deploy a simple node.js web application that keeps track of the number of web site visits. 

 Nagarjuna_V_17-1661520528689.png

Now, create a virtual network and add access restrictions such that the app will only be accessible from within the ‘default’ subnet of this virtual network. We can do this by adding a rule in the Networking section of the app service.

 Nagarjuna_V_18-1661520590912.png

With the access restriction in place, if we try to access the application from anywhere outside the subnet, we’ll get an HTTP 403 error. Here, we have imposed the restriction based on virtual network, but the restrictions can be an IP address-based rule, service tag-based rule etc.

  Nagarjuna_V_19-1661520636995.png

The next step is to run a load test against this endpoint. For this, we need to make sure that the test traffic can access the web application. Wondering how? You can do that in four simple steps

  1. Create an Azure Virtual Network.
  2. Create a NAT gateway.
  3. Add an access restriction rule to allow access.
  4. Create and run a load test.

Create a virtual network

Start by creating a virtual network. Ensure that the virtual network is in the same Azure region as your load testing resource (go create a load testing resource, if you don't have one already). For this example, the default subnet we get with a VNet is good enough and we don’t need additional subnets.

Once the VNet is created, make sure that you have the ‘Network Contributor’ role on the VNet.   

 Nagarjuna_V_20-1661520774555.png

Create a NAT gateway

The next step is to create a NAT gateway that will route all outbound traffic (the load test traffic) through a fixed set of public IP addresses. In the Outbound IP tab, create a “public IP prefix” so that you get a range of IP addresses for your load test engines instead of a single IP address. In the Subnet tab, select the virtual network and the subnet you created earlier.

 

 Nagarjuna_V_21-1661520871985.png

 Nagarjuna_V_22-1661520916315.png 

Add an access restriction rule to allow access

Let’s now allow list the NAT gateway traffic on our web app by adding an ‘Allow’ rule. This is similar to the ‘demoAllowRule’ rule we added while setting up the web app.

 Nagarjuna_V_23-1661521030158.png

After adding the ‘loadAllowRule’ rule, this is how the access restrictions of our web app should look like

 Nagarjuna_V_24-1661521061536.png

Create and run a load test

We can now go ahead and set up the load test for our web application using Azure Load Testing. There is no customization needed in setting up your JMeter script for this specific scenario. Set up your JMX script to point to the web app (simpledemoapp.azurewebsites.net) and follow the usual steps to create a load test.

The only difference though lies in configuring the load.

  • In the ‘Load’ tab of the test set up wizard, select ‘Private’ as your test traffic mode in the ‘Network’ section.
  • Select the ‘load_vnet’ virtual network and the ‘default’ subnet that you just created. This will ensure that the test traffic will be generated from this subnet. We have already configured our app to allow this traffic.

 Nagarjuna_V_25-1661521127295.png

 Nagarjuna_V_26-1661521157021.png

We can see that the test traffic was successfully sent to the web app, and we didn't experience any HTTP 403 errors. The load test was successfully run, and we can view and analyze how the app responded to the load by using the dashboard.

 

So, by using VNET injection with Azure Load Testing and routing the test traffic through a NAT gateway, we could allowlist the traffic on our web application and successfully perform a load test on our restricted public endpoint. In this blog post, we used Azure app service to host the endpoint, but this works just fine for all public endpoints with IP address allowlisting, regardless of where they're hosted.

 

What else are you waiting for? You can find the sample app and a sample JMX script here. Try it out and let the community know if you were able to load test your endpoint with access restrictions.

 

If you have any feedback on Azure Load Testing, let us know through our feedback forum.

Happy Load Testing…!

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.