TechnologyDec 13, 2016

Integrating Azure Web Apps With Existing Virtual Networks

Bryan Sakowski

In looking at Azure Web App deployments, consider a typical application stack consisting of a web front end communicating with a database back end. Azure offers a capable database Platform-as-a-Service (PaaS) option in Azure SQL Database, but sometimes, you still need a full-blown SQL Server installation due to licensing restrictions, application compatibility, or any number of other reasons. Web Apps only operate on public facing endpoints up through the Standard pricing tier, and for security reasons we want to avoid opening up SQL Server ports directly to the internet. A solution for securely connecting a Web App to resources in an Azure client Virtual Network (VNET) or on-premises is VNET Integration, which allows a Web App to communicate with specified routes over an encrypted VPN connection.


Microsoft offers instructions for starting from scratch and creating a new VNET, but for a company that is already running workloads in an existing VNET, possibly with site-to-site VPN already connecting the Azure environment to on-premises networks, the exercise is less straightforward. When VNET Integration was first introduced, it lacked support for V2 VNETs (i.e., VNETs deployed using the Azure Resource Manager model), and once that capability was available, the only way to configure it was using PowerShell. Now it is possible to accomplish all of this, including the Azure networking and VPN configuration, from within the Azure Portal. There are a few assumptions and prerequisites to consider:

  • App Service Standard or Premium plans are required for VNET Integration.

  • We are assuming all resources are deployed in the same subscription using the Azure Resource Manager (ARM) model in the Azure Portal.

  • A Route-Based VPN Gateway type is required for the VNET (policy-based VPN Gateways and ExpressRoute are not supported).

  • Outbound bandwidth from the VNET to the Web App is billed at standard data transfer

  • In order for traffic to route properly, your network addressing should not include overlapping subnet ranges.

To configure the solution, we first need to add a VPN Gateway to the VNET if it doesn’t already exist. In the Azure Portal, go to New and add a Virtual Network Gateway from the Marketplace. Provide a resource name, attach it to the Virtual Network, and specify the requested network addressing in the provisioning wizard. Make sure to create it as the Route-Based VPN type and then wait for the operation to complete, which may take up to 45 minutes.

Once the gateway is provisioned, we’ll need to add Point-to-Site configuration to the gateway. The App Service Plan containing the Web App will establish certificate-based Point-to-Site VPN connectivity to the VNET, essentially operating as a VPN client. Azure will manage the certificates for you, so there is no need to generate these on your own. Open the Virtual Network Gateway resource, then in the settings pane select Point-to-site configuration. Here, create an Address Pool within a private IPv4 address space that will not conflict with any of your existing subnets to avoid potential routing problems.


To configure the VNET Integration feature, you can now proceed to open the Web App resource blade in the Azure Portal, go to Networking in the Settings section, and click Setup under VNET Integration. The Virtual Network should now be eligible to select, so click to add it to the Web App configuration. After a few moments, you can view the VNET Integration settings by clicking Click here to configure.


One final option is to enable private connectivity between your on-premises networks and the Web App through the VPN Gateway. If you have already configured site-to-site VPN, you will need to add routes to the Point-to-Site Address Pool created earlier on your on-premises VPN device. If you have not yet created a site-to-site VPN connection, make sure you include the Address Pool subnet in your device’s route-based VPN configuration. Depending on your addressing scheme, you may need to add custom routes to the App Service Plan configuration as well.

There are other methods of configuring private connectivity to your Web App resources. Hybrid Connections offer a quick way to add TCP-based encrypted connections to on-premises hosts, generally with minimal firewall changes. Azure App Service Premium plans enable the use of App Service Environments, which allow you to deploy dedicated Web App instances directly within a VNET in addition to supporting integration with Azure ExpressRoute.

Are you interested in exploring Microsoft Azure deployment and integration options? Credera has extensive experience in cloud infrastructure design and implementation. If you have questions or would like to discuss cloud and infrastructure solutions, contact us at

Have a Question?

Please complete the Captcha