This post is the first step of breaking out of your Web App hosted in Azure App Services into the outside world. It involves connecting it to a virtual network (VNET) running in Azure. To make this real we’ll have it connecting to a Web Service running on a Virtual machine connected to the VNET. In doing so we will have proven that a network connection can be initiated from the Web App, traffic routes onto the virtual network and is directed to an endpoint connected to the VNET.
I have updated the diagram from the overview to include the network address ranges we’ll be using. For this part of the walk through you can ignore the on premise network and the Site to Site VPN connection. We’ll be dealing with that and the virtual appliance alternative option in a future post.
The point to site VPN feature in Azure is designed to let individuals connect their PCs and laptops to a network hosted in Azure in a similar way to how you might use VPN software to connect from home to your corporate network. Connecting App Services to an Azure VNET piggy-backs on this technology so the official Azure Point – Site VPN documentation makes no mention of App Services. Instead this article provides better coverage of what needs to be achieved when using Point to Site VPN with App Services. The article describes allowing Azure to create the VNET and the VPN gateway and then hooking it up to the App Service application. Instead in this walk through the components will be built up from scratch to aid understanding their roles.
Follow along with the steps below to configure a Point to Site VPN connection.
- Create a resource group that will contain all of the network components. Keeping the networking and the resources that connect to the network separated in resource groups allows them to have different lifecycles.
- Create a Virtual Network in the resource group created in step 1). Give it an address space of 10.160.0.0/16. You will also have to create a subnet at this point. Call it “backend” and give it the subnet address range of 10.160.2.0/24. If you are not using this you can always remove it later. I have not created the GatewaySubnet at this point as this is treated as a special subnet by Azure and is created automatically when you create the Virtual Network Gateway in the next step.
- Create a Virtual Network Gateway in the resource group created in step 1). Select Gateway Type: VPN, VPN Type: Route Based & SKU: Basic. Select the Virtual Network created in step 2) and enter a subnet range of 10.160.1.0/24. This is the address range for the GatewaySubnet. The gateway needs a public IP address so you can create one at this stage. It can take up to 45mins for Azure to provision the Virtual Network Gateway.
- The next step is to configure the Point to Site VPN. This is achieved by selecting the Virtual Network Gateway you created in step 3) and selecting the “Point-to-Site configuration” option. The screen that appears can seem confusing. There is mention of an Address Pool and Root Certificates. However most of this can be ignored. All you need to configure is the range of IP addresses that will be allocated to clients as they connect over the VPN. This is the address pool mentioned on this screen and you define a range of IP addresses using CIDR notation. These addresses must exist outside of your VNET address space and must not clash with any other connected networks. In this example, the range to use is 10.10.1.0/24.
Think of the Virtual Network Gateway as an appliance rather than a network component. It will manage all external connections to and from your network. You configure the gateway as either an Express Route gateway or a VPN gateway. For this example, we consider only the VPN gateway. A Point to Site VPN is not restricted to one connection. It is not a one to one relationship, it is many to one. In theory, you could authorise numerous external endpoints to connect to your network through a single VPN gateway. Likewise, you might create multiple site to site connections through a VPN gateway that connect multiple on premise networks into your Azure VNET. When you create multiple connections this way they all share the bandwidth that is available to the gateway.
This is enough to configure the Point to Site VPN, although it isn’t useful yet because nothing is connected to it. The next steps connect a pre-existing application hosted in an App Service to the Azure VNET via a Point to Site VPN.
Think of the Point to Site VPN address pool as analogous to the address pool managed by a DHCP server. As clients connect they are allocated an address from the pool. If the pool is exhausted new clients cannot connect.
You cannot simply connect any App Service to your VNET through a Point to Site VPN. Only App Services running in Standard or Premium service plans have access to this feature.
- In the Azure Portal select the App Service you want to connect and then select the Networking option. Under VNET Integration, click “Setup” and then select the network you created earlier. If the Point to Site VPN connection is not configured on that network then it will not be selectable. When the connection process is complete you’ll see something like this
- Clicking “Click here to configure” takes you to a screen which is a good summary of how all the networking is configured.
At this point the App Service is connected to the Azure VNET. Now is a good time to test it. This can be achieved by deploying a VM into the backend subnet. This can host a simple API endpoint that can be called from the App Service.
I have a trivial .NET application that does that here. Essentially it is the MVC starter application with a slight modification. The client application should be deployed to an App Service where it will call the Server application (a simple Web Api project) which should be hosted on a VM connected to the Azure VNET. All this Web Api server application does is construct a string containing the IP address of the server it is hosted on and the IP address reported by the caller. You’ll need to remember to override the client application’s
BaseApiUrl application setting in the App Service blade in the Azure portal to reflect your environment.
If this all works you know the Point to Site VPN is functioning and that traffic is being routed onto the VNET from the App Service correctly. You’ll also be able to see the IP address that is being presented to the VM by the App Service. This should be in the address pool range of the Point to Site VPN connection, in this case 10.10.1.0/24. I like to test this step before moving on the on premise connection because it makes troubleshooting at that stage simpler.
So, what have we achieved? We have connected a App Service hosted in Azure to a VM hosted also in Azure using a Point to Site VPN. One thing that is important to realise is that whilst on the face of it you have a simple connection from one Azure resource to another, you must remember that by definition the Point to Site VPN is routing traffic via the Internet. Remember your VPN gateway has a public IP address so the VPN tunnel from the App Service is routing onto the Internet and then back again. It is also sharing the bandwidth available to the VPN Gateway so you must consider this in your designs. While this configuration will be suitable for some scenarios, in others you may be better off using Express Route to provide a more predictable connectivity solution.