Integrate your app with an Azure virtual network
This article describes the Azure App Service VNet Integration feature and how to set it up with apps in Azure App Service. With Azure Virtual Network, you can place many of your Azure resources in a non-internet-routable network.
Azure App Service has two variations:
- The multitenant systems that support the full range of pricing plans except Isolated.
- The App Service Environment, which deploys into your virtual network and supports Isolated pricing plan apps.
The VNet Integration feature is used in multitenant apps. If your app is in App Service Environment, then it's already in a virtual network and doesn't require use of the VNet Integration feature to reach resources in the same virtual network. For more information on all of the networking features, see App Service networking features.
VNet Integration gives your app access to resources in your virtual network, but it doesn't grant inbound private access to your app from the virtual network. Private site access refers to making an app accessible only from a private network, such as from within an Azure virtual network. VNet Integration is used only to make outbound calls from your app into your virtual network. The VNet Integration feature behaves differently when it's used with virtual networks in the same region and with virtual networks in other regions. The VNet Integration feature has two variations:
- Regional VNet Integration: When you connect to Azure Resource Manager virtual networks in the same region, you must have a dedicated subnet in the virtual network you're integrating with.
- Gateway-required VNet Integration: When you connect to virtual networks in other regions or to a classic virtual network in the same region, you need an Azure Virtual Network gateway provisioned in the target virtual network.
The VNet Integration features:
- Require a Standard, Premium, PremiumV2, or Elastic Premium pricing plan.
- Support TCP and UDP.
- Work with Azure App Service apps and function apps.
There are some things that VNet Integration doesn't support, like:
- Mounting a drive.
- Active Directory integration.
Gateway-required VNet Integration provides access to resources only in the target virtual network or in networks connected to the target virtual network with peering or VPNs. Gateway-required VNet Integration doesn't enable access to resources available across Azure ExpressRoute connections or works with service endpoints.
Regardless of the version used, VNet Integration gives your app access to resources in your virtual network, but it doesn't grant inbound private access to your app from the virtual network. Private site access refers to making your app accessible only from a private network, such as from within an Azure virtual network. VNet Integration is only for making outbound calls from your app into your virtual network.
Enable VNet Integration
Go to the Networking UI in the App Service portal. Under VNet Integration, select Click here to configure.
Select Add VNet.
The drop-down list contains all of the Azure Resource Manager virtual networks in your subscription in the same region. Underneath that is a list of the Resource Manager virtual networks in all other regions. Select the virtual network you want to integrate with.
- If the virtual network is in the same region, either create a new subnet or select an empty preexisting subnet.
- To select a virtual network in another region, you must have a Virtual Network gateway provisioned with point to site enabled.
- To integrate with a classic virtual network, instead of selecting the Virtual Network drop-down list, select Click here to connect to a Classic VNet. Select the classic virtual network you want. The target virtual network must already have a Virtual Network gateway provisioned with point-to-site enabled.
During the integration, your app is restarted. When integration is finished, you'll see details on the virtual network you're integrated with.
After your app is integrated with your virtual network, it uses the same DNS server that your virtual network is configured with, unless it's Azure DNS Private Zones. Currently, you can't use VNet Integration with Azure DNS Private Zones.
Regional VNet Integration
Using regional VNet Integration enables your app to access:
- Resources in the virtual network in the same region that you integrate with.
- Resources in virtual networks peered to your virtual network that are in the same region.
- Service endpoint secured services.
- Resources across Azure ExpressRoute connections.
- Resources in the virtual network you're connected to.
- Resources across peered connections, which includes Azure ExpressRoute connections.
- Private endpoints.
When you use VNet Integration with virtual networks in the same region, you can use the following Azure networking features:
- Network security groups (NSGs): You can block outbound traffic with an NSG that's placed on your integration subnet. The inbound rules don't apply because you can't use VNet Integration to provide inbound access to your app.
- Route tables (UDRs): You can place a route table on the integration subnet to send outbound traffic where you want.
By default, your app routes only RFC1918 traffic into your virtual network. If you want to route all of your outbound traffic into your virtual network, apply the app setting WEBSITE_VNET_ROUTE_ALL to your app. To configure the app setting:
Go to the Configuration UI in your app portal. Select New application setting.
Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.
If you route all of your outbound traffic into your virtual network, it's subject to the NSGs and UDRs that are applied to your integration subnet. When you route all of your outbound traffic into your virtual network, your outbound addresses are still the outbound addresses that are listed in your app properties unless you provide routes to send the traffic elsewhere.
There are some limitations with using VNet Integration with virtual networks in the same region:
- You can't reach resources across global peering connections.
- The feature is available only from newer Azure App Service scale units that support PremiumV2 App Service plans.
- The integration subnet can be used by only one App Service plan.
- The feature can't be used by Isolated plan apps that are in an App Service Environment.
- The feature requires an unused subnet that's a /27 with 32 addresses or larger in an Azure Resource Manager virtual network.
- The app and the virtual network must be in the same region.
- You can't delete a virtual network with an integrated app. Remove the integration before you delete the virtual network.
- You can only integrate with virtual networks in the same subscription as the app.
- You can have only one regional VNet Integration per App Service plan. Multiple apps in the same App Service plan can use the same virtual network.
- You can't change the subscription of an app or a plan while there's an app that's using regional VNet Integration.
One address is used for each plan instance. If you scale your app to five instances, then five addresses are used. Since subnet size can't be changed after assignment, you must use a subnet that's large enough to accommodate whatever scale your app might reach. A /26 with 64 addresses is the recommended size. A /26 with 64 addresses accommodates a Premium plan with 30 instances. When you scale a plan up or down, you need twice as many addresses for a short period of time.
If you want your apps in another plan to reach a virtual network that's already connected to by apps in another plan, select a different subnet than the one being used by the preexisting VNet Integration.
The feature is in preview for Linux. The Linux form of the feature only supports making calls to RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Web or Function App for Containers
If you host your app on Linux with the built-in images, regional VNet Integration works without additional changes. If you use Web or Function App for Containers, you must modify your docker image to use VNet Integration. In your docker image, use the PORT environment variable as the main web server's listening port, instead of using a hardcoded port number. The PORT environment variable is automatically set by the platform at the container startup time. If you use SSH, the SSH daemon must be configured to listen on the port number specified by the SSH_PORT environment variable when you use regional VNet Integration. There's no support for gateway-required VNet Integration on Linux.
With regional VNet Integration, you can use service endpoints. To use service endpoints with your app, use regional VNet Integration to connect to a selected virtual network. Then configure service endpoints on the subnet you used for the integration.
Network security groups
You can use network security groups to block inbound and outbound traffic to resources in a virtual network. An app that uses regional VNet Integration can use a network security group to block outbound traffic to resources in your virtual network or the internet. To block traffic to public addresses, you must have the application setting WEBSITE_VNET_ROUTE_ALL set to 1. The inbound rules in an NSG don't apply to your app because VNet Integration affects only outbound traffic from your app.
To control inbound traffic to your app, use the Access Restrictions feature. An NSG that's applied to your integration subnet is in effect regardless of any routes applied to your integration subnet. If WEBSITE_VNET_ROUTE_ALL is set to 1 and you don't have any routes that affect public address traffic on your integration subnet, all of your outbound traffic is still subject to NSGs assigned to your integration subnet. If WEBSITE_VNET_ROUTE_ALL isn't set, NSGs are only applied to RFC1918 traffic.
You can use route tables to route outbound traffic from your app to wherever you want. By default, route tables only affect your RFC1918 destination traffic. If you set WEBSITE_VNET_ROUTE_ALL to 1, all of your outbound calls are affected. Routes that are set on your integration subnet won't affect replies to inbound app requests. Common destinations can include firewall devices or gateways.
If you want to route all outbound traffic on-premises, you can use a route table to send all outbound traffic to your ExpressRoute gateway. If you do route traffic to a gateway, be sure to set routes in the external network to send any replies back.
Border Gateway Protocol (BGP) routes also affect your app traffic. If you have BGP routes from something like an ExpressRoute gateway, your app outbound traffic will be affected. By default, BGP routes affect only your RFC1918 destination traffic. If WEBSITE_VNET_ROUTE_ALL is set to 1, all outbound traffic can be affected by your BGP routes.
How regional VNet Integration works
Apps in App Service are hosted on worker roles. The Basic and higher pricing plans are dedicated hosting plans where there are no other customers' workloads running on the same workers. Regional VNet Integration works by mounting virtual interfaces with addresses in the delegated subnet. Because the from address is in your virtual network, it can access most things in or through your virtual network like a VM in your virtual network would. The networking implementation is different than running a VM in your virtual network. That's why some networking features aren't yet available for this feature.
When regional VNet Integration is enabled, your app makes outbound calls to the internet through the same channels as normal. The outbound addresses that are listed in the app properties portal are the addresses still used by your app. What changes for your app are the calls to service endpoint secured services, or RFC 1918 addresses go into your virtual network. If WEBSITE_VNET_ROUTE_ALL is set to 1, all outbound traffic can be sent into your virtual network.
The feature supports only one virtual interface per worker. One virtual interface per worker means one regional VNet Integration per App Service plan. All of the apps in the same App Service plan can use the same VNet Integration. If you need an app to connect to an additional virtual network, you need to create another App Service plan. The virtual interface used isn't a resource that customers have direct access to.
Because of the nature of how this technology operates, the traffic that's used with VNet Integration doesn't show up in Azure Network Watcher or NSG flow logs.
Gateway-required VNet Integration
Gateway-required VNet Integration supports connecting to a virtual network in another region or to a classic virtual network. Gateway-required VNet Integration:
- Enables an app to connect to only one virtual network at a time.
- Enables up to five virtual networks to be integrated within an App Service plan.
- Allows the same virtual network to be used by multiple apps in an App Service plan without affecting the total number that can be used by an App Service plan. If you have six apps using the same virtual network in the same App Service plan, that counts as one virtual network being used.
- Supports a 99.9% SLA due to the SLA on the gateway.
- Enables your apps to use the DNS that the virtual network is configured with.
- Requires a Virtual Network route-based gateway configured with an SSTP point-to-site VPN before it can be connected to an app.
You can't use gateway-required VNet Integration:
- With Linux apps.
- With a virtual network connected with Azure ExpressRoute.
- To access service endpoint secured resources.
- With a coexistence gateway that supports both ExpressRoute and point-to-site or site-to-site VPNs.
Set up a gateway in your virtual network
To create a gateway:
Create a gateway subnet in your virtual network.
Create the VPN gateway. Select a route-based VPN type.
Set the point-to-site addresses. If the gateway isn't in the basic SKU, then IKEV2 must be disabled in the point-to-site configuration and SSTP must be selected. The point-to-site address space must be in the RFC 1918 address blocks 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
If you create the gateway for use with App Service VNet Integration, you don't need to upload a certificate. Creating the gateway can take 30 minutes. You won't be able to integrate your app with your virtual network until the gateway is provisioned.
How gateway-required VNet Integration works
Gateway-required VNet Integration is built on top of point-to-site VPN technology. Point-to-site VPNs limit network access to the virtual machine that hosts the app. Apps are restricted to send traffic out to the internet only through Hybrid Connections or through VNet Integration. When your app is configured with the portal to use gateway-required VNet Integration, a complex negotiation is managed on your behalf to create and assign certificates on the gateway and the application side. The result is that the workers used to host your apps are able to directly connect to the virtual network gateway in the selected virtual network.
Access on-premises resources
Apps can access on-premises resources by integrating with virtual networks that have site-to-site connections. If you use gateway-required VNet Integration, update your on-premises VPN gateway routes with your point-to-site address blocks. When the site-to-site VPN is first set up, the scripts used to configure it should set up routes properly. If you add the point-to-site addresses after you create your site-to-site VPN, you need to update the routes manually. Details on how to do that vary per gateway and aren't described here. You can't have BGP configured with a site-to-site VPN connection.
No additional configuration is required for the regional VNet Integration feature to reach through your virtual network to on-premises resources. You simply need to connect your virtual network to on-premises resources by using ExpressRoute or a site-to-site VPN.
The gateway-required VNet Integration feature doesn't integrate an app with a virtual network that has an ExpressRoute gateway. Even if the ExpressRoute gateway is configured in coexistence mode, the VNet Integration doesn't work. If you need to access resources through an ExpressRoute connection, use the regional VNet Integration feature or an App Service Environment, which runs in your virtual network.
If you use peering with the regional VNet Integration, you don't need to do any additional configuration.
If you use gateway-required VNet Integration with peering, you need to configure a few additional items. To configure peering to work with your app:
- Add a peering connection on the virtual network your app connects to. When you add the peering connection, enable Allow virtual network access and select Allow forwarded traffic and Allow gateway transit.
- Add a peering connection on the virtual network that's being peered to the virtual network you're connected to. When you add the peering connection on the destination virtual network, enable Allow virtual network access and select Allow forwarded traffic and Allow remote gateways.
- Go to the App Service plan > Networking > VNet Integration UI in the portal. Select the virtual network your app connects to. Under the routing section, add the address range of the virtual network that's peered with the virtual network your app is connected to.
Manage VNet Integration
Connecting and disconnecting with a virtual network is at an app level. Operations that can affect VNet Integration across multiple apps are at the App Service plan level. From the app > Networking > VNet Integration portal, you can get details on your virtual network. You can see similar information at the App Service plan level in the App Service plan > Networking > VNet Integration portal.
The only operation you can take in the app view of your VNet Integration instance is to disconnect your app from the virtual network it's currently connected to. To disconnect your app from a virtual network, select Disconnect. Your app is restarted when you disconnect from a virtual network. Disconnecting doesn't change your virtual network. The subnet or gateway isn't removed. If you then want to delete your virtual network, first disconnect your app from the virtual network and delete the resources in it, such as gateways.
The App Service plan VNet Integration UI shows you all of the virtual network integrations used by the apps in your App Service plan. To see details on each virtual network, select the virtual network you're interested in. There are two actions you can perform here for gateway-required VNet Integration:
- Sync network: The sync network operation is used only for the gateway-dependent VNet Integration feature. Performing a sync network operation ensures that your certificates and network information are in sync. If you add or change the DNS of your virtual network, perform a sync network operation. This operation restarts any apps that use this virtual network.
- Add routes: Adding routes drives outbound traffic into your virtual network.
Gateway-required VNet Integration routing
The routes that are defined in your virtual network are used to direct traffic into your virtual network from your app. To send additional outbound traffic into the virtual network, add those address blocks here. This capability only works with gateway-required VNet Integration. Route tables don't affect your app traffic when you use gateway-required VNet Integration the way that they do with regional VNet Integration.
Gateway-required VNet Integration certificates
When gateway-required VNet Integration is enabled, there's a required exchange of certificates to ensure the security of the connection. Along with the certificates are the DNS configuration, routes, and other similar things that describe the network.
If certificates or network information is changed, select Sync Network. When you select Sync Network, you cause a brief outage in connectivity between your app and your virtual network. While your app isn't restarted, the loss of connectivity could cause your site to not function properly.
The regional VNet Integration feature has no additional charge for use beyond the App Service plan pricing tier charges.
Three charges are related to the use of the gateway-required VNet Integration feature:
- App Service plan pricing tier charges: Your apps need to be in a Standard, Premium, or PremiumV2 App Service plan. For more information on those costs, see App Service pricing.
- Data transfer costs: There's a charge for data egress, even if the virtual network is in the same datacenter. Those charges are described in Data Transfer pricing details.
- VPN gateway costs: There's a cost to the virtual network gateway that's required for the point-to-site VPN. For more information, see VPN gateway pricing.
The feature is easy to set up, but that doesn't mean your experience will be problem free. If you encounter problems accessing your desired endpoint, there are some utilities you can use to test connectivity from the app console. There are two consoles that you can use. One is the Kudu console, and the other is the console in the Azure portal. To reach the Kudu console from your app, go to Tools > Kudu. You can also reach the Kudo console at [sitename].scm.azurewebsites.net. After the website loads, go to the Debug console tab. To get to the Azure portal-hosted console from your app, go to Tools > Console.
The tools ping, nslookup, and tracert won't work through the console because of security constraints. To fill the void, two separate tools are added. To test DNS functionality, we added a tool named nameresolver.exe. The syntax is:
nameresolver.exe hostname [optional: DNS Server]
You can use nameresolver to check the hostnames that your app depends on. This way you can test if you have anything misconfigured with your DNS or perhaps don't have access to your DNS server. You can see the DNS server that your app uses in the console by looking at the environmental variables WEBSITE_DNS_SERVER and WEBSITE_DNS_ALT_SERVER.
You can use the next tool to test for TCP connectivity to a host and port combination. This tool is called tcpping and the syntax is:
tcpping.exe hostname [optional: port]
The tcpping utility tells you if you can reach a specific host and port. It can show success only if there's an application listening at the host and port combination, and there's network access from your app to the specified host and port.
Debug access to virtual network-hosted resources
A number of things can prevent your app from reaching a specific host and port. Most of the time it's one of these things:
- A firewall is in the way. If you have a firewall in the way, you hit the TCP timeout. The TCP timeout is 21 seconds in this case. Use the tcpping tool to test connectivity. TCP timeouts can be caused by many things beyond firewalls, but start there.
- DNS isn't accessible. The DNS timeout is 3 seconds per DNS server. If you have two DNS servers, the timeout is 6 seconds. Use nameresolver to see if DNS is working. You can't use nslookup, because that doesn't use the DNS your virtual network is configured with. If inaccessible, you could have a firewall or NSG blocking access to DNS or it could be down.
If those items don't answer your problems, look first for things like:
Regional VNet Integration
- Is your destination a non-RFC1918 address and you don't have WEBSITE_VNET_ROUTE_ALL set to 1?
- Is there an NSG blocking egress from your integration subnet?
- If you're going across Azure ExpressRoute or a VPN, is your on-premises gateway configured to route traffic back up to Azure? If you can reach endpoints in your virtual network but not on-premises, check your routes.
- Do you have enough permissions to set delegation on the integration subnet? During regional VNet Integration configuration, your integration subnet is delegated to Microsoft.Web. The VNet Integration UI delegates the subnet to Microsoft.Web automatically. If your account doesn't have sufficient networking permissions to set delegation, you'll need someone who can set attributes on your integration subnet to delegate the subnet. To manually delegate the integration subnet, go to the Azure Virtual Network subnet UI and set the delegation for Microsoft.Web.
Gateway-required VNet Integration
- Is the point-to-site address range in the RFC 1918 ranges (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
- Does the gateway show as being up in the portal? If your gateway is down, then bring it back up.
- Do certificates show as being in sync, or do you suspect that the network configuration was changed? If your certificates are out of sync or you suspect that a change was made to your virtual network configuration that wasn't synced with your ASPs, select Sync Network.
- If you're going across a VPN, is the on-premises gateway configured to route traffic back up to Azure? If you can reach endpoints in your virtual network but not on-premises, check your routes.
- Are you trying to use a coexistence gateway that supports both point to site and ExpressRoute? Coexistence gateways aren't supported with VNet Integration.
Debugging networking issues is a challenge because you can't see what's blocking access to a specific host:port combination. Some causes include:
- You have a firewall up on your host that prevents access to the application port from your point-to-site IP range. Crossing subnets often requires public access.
- Your target host is down.
- Your application is down.
- You had the wrong IP or hostname.
- Your application is listening on a different port than what you expected. You can match your process ID with the listening port by using "netstat -aon" on the endpoint host.
- Your network security groups are configured in such a manner that they prevent access to your application host and port from your point-to-site IP range.
You don't know what address your app actually uses. It could be any address in the integration subnet or point-to-site address range, so you need to allow access from the entire address range.
Additional debug steps include:
Connect to a VM in your virtual network and attempt to reach your resource host:port from there. To test for TCP access, use the PowerShell command test-netconnection. The syntax is:
test-netconnection hostname [optional: -Port]
Bring up an application on a VM and test access to that host and port from the console from your app by using tcpping.
If your app can't reach a resource on-premises, check if you can reach the resource from your virtual network. Use the test-netconnection PowerShell command to check for TCP access. If your VM can't reach your on-premises resource, your VPN or ExpressRoute connection might not be configured properly.
If your virtual network-hosted VM can reach your on-premises system but your app can't, the cause is likely one of the following reasons:
- Your routes aren't configured with your subnet or point-to-site address ranges in your on-premises gateway.
- Your network security groups are blocking access for your point-to-site IP range.
- Your on-premises firewalls are blocking traffic from your point-to-site IP range.
- You're trying to reach a non-RFC 1918 address by using the regional VNet Integration feature.
CLI support is available for regional VNet Integration. To access the following commands, install the Azure CLI.
az webapp vnet-integration --help Group az webapp vnet-integration : Methods that list, add, and remove virtual network integrations from a webapp. This command group is in preview. It may be changed/removed in a future release. Commands: add : Add a regional virtual network integration to a webapp. list : List the virtual network integrations on a webapp. remove : Remove a regional virtual network integration from webapp. az appservice vnet-integration --help Group az appservice vnet-integration : A method that lists the virtual network integrations used in an appservice plan. This command group is in preview. It may be changed/removed in a future release. Commands: list : List the virtual network integrations used in an appservice plan.
For gateway-required VNet Integration, you can integrate App Service with an Azure virtual network by using PowerShell. For a ready-to-run script, see Connect an app in Azure App Service to an Azure virtual network.