Azure Functions networking options

This article describes the networking features available across the hosting options for Azure Functions. All the following networking options give you some ability to access resources without using internet-routable addresses or to restrict internet access to a function app.

The hosting models have different levels of network isolation available. Choosing the correct one helps you meet your network isolation requirements.

You can host function apps in a couple of ways:

  • You can choose from plan options that run on a multitenant infrastructure, with various levels of virtual network connectivity and scaling options:
    • The Consumption plan scales dynamically in response to load and offers minimal network isolation options.
    • The Premium plan also scales dynamically and offers more comprehensive network isolation.
    • The Azure App Service plan operates at a fixed scale and offers network isolation similar to the Premium plan.
  • You can run functions in an App Service Environment. This method deploys your function into your virtual network and offers full network control and isolation.

Matrix of networking features

Feature Consumption plan Premium plan Dedicated plan ASE Kubernetes
Inbound IP restrictions and private site access ✅Yes ✅Yes ✅Yes ✅Yes ✅Yes
Virtual network integration ❌No ✅Yes (Regional) ✅Yes (Regional and Gateway) ✅Yes ✅Yes
Virtual network triggers (non-HTTP) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Hybrid connections (Windows only) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Outbound IP restrictions ❌No ✅Yes ✅Yes ✅Yes ✅Yes

Inbound IP restrictions

You can use IP restrictions to define a priority-ordered list of IP addresses that are allowed or denied access to your app. The list can include IPv4 and IPv6 addresses. When there are one or more entries, an implicit "deny all" exists at the end of the list. IP restrictions work with all function-hosting options.

Note

With network restrictions in place, you can use the portal editor only from within your virtual network, or when you've put the IP address of the machine you're using to access the Azure portal on the Safe Recipients list. However, you can still access any features on the Platform features tab from any machine.

To learn more, see Azure App Service static access restrictions.

Private site access

Private site access refers to making your app accessible only from a private network, such as an Azure virtual network.

  • Private site access is available in the Premium, Consumption, and App Service plans when service endpoints are configured.
    • Service endpoints can be configured on a per-app basis under Platform features > Networking > Configure Access Restrictions > Add Rule. Virtual networks can now be selected as a rule type.
    • For more information, see Virtual network service endpoints.
    • Keep in mind that with service endpoints, your function still has full outbound access to the internet, even with virtual network integration configured.
  • Private site access is also available within an App Service Environment that's configured with an internal load balancer (ILB). For more information, see Create and use an internal load balancer with an App Service Environment.

To learn how to set up private site access, see Establish Azure Functions private site access.

Virtual network integration

Virtual network integration allows your function app to access resources inside a virtual network. Azure Functions supports two kinds of virtual network integration:

  • The multitenant systems that support the full range of pricing plans except Isolated.
  • The App Service Environment, which deploys into your VNet 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 VNet and doesn't require use of the VNet Integration feature to reach resources in the same VNet. For more information on all of the networking features, see App Service networking features.

VNet Integration gives your app access to resources in your VNet, but it doesn't grant inbound private access to your app from the VNet. 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 VNet. The VNet Integration feature behaves differently when it's used with VNet in the same region and with VNet 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 VNet you're integrating with.
  • Gateway-required VNet Integration: When you connect to VNet in other regions or to a classic virtual network in the same region, you need an Azure Virtual Network gateway provisioned in the target VNet.

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.
  • NetBIOS.

Gateway-required VNet Integration provides access to resources only in the target VNet or in networks connected to the target VNet 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 VNet, but it doesn't grant inbound private access to your app from the VNet. Private site access refers to making your app accessible only from a private network, such as from within an Azure VNet. VNet Integration is only for making outbound calls from your app into your VNet.

Virtual network integration in Azure Functions uses shared infrastructure with App Service web apps. To learn more about the two types of virtual network integration, see:

To learn how to set up virtual network integration, see Integrate a function app with an Azure virtual network.

Regional virtual network integration

Using regional VNet Integration enables your app to access:

  • Resources in a VNet in the same region as your app.
  • Resources in VNets peered to the VNet your app is integrated with.
  • Service endpoint secured services.
  • Resources across Azure ExpressRoute connections.
  • Resources in the VNet you're integrated with.
  • Resources across peered connections, which includes Azure ExpressRoute connections.
  • Private endpoints

When you use VNet Integration with VNets 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 VNet. If you want to route all of your outbound traffic into your VNet, apply the app setting WEBSITE_VNET_ROUTE_ALL to your app. To configure the app setting:

  1. Go to the Configuration UI in your app portal. Select New application setting.

  2. Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.

    Provide application setting

  3. Select OK.

  4. Select Save.

If you route all of your outbound traffic into your VNet, 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 VNet, 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 VNets 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. Note that this does not mean your app must run on a PremiumV2 pricing tier, only that it must run on an App Service Plan where the PremiumV2 option is available (which implies that it is a newer scale unit where this VNet integration feature is then also available).
  • 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 VNet.
  • The app and the VNet must be in the same region.
  • You can't delete a VNet with an integrated app. Remove the integration before you delete the VNet.
  • You can only integrate with VNets 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 VNet.
  • You can't change the subscription of an app or a plan while there's an app that's using regional VNet Integration.
  • Your app cannot resolve addresses in Azure DNS Private Zones without configuration changes

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 VNet 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 fully supported for both Windows and Linux web apps. All of the behaviors act the same between Windows apps and Linux apps.

Service endpoints

Regional VNet Integration enables you to use service endpoints. To use service endpoints with your app, use regional VNet Integration to connect to a selected VNet and then configure service endpoints with the destination service on the subnet you used for the integration. If you then wanted to access a service over service endpoints:

  1. configure regional VNet Integration with your web app
  2. go to the destination service and configure service endpoints against the subnet used for integration

Network security groups

You can use network security groups to block inbound and outbound traffic to resources in a VNet. An app that uses regional VNet Integration can use a network security group to block outbound traffic to resources in your VNet 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.

Routes

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.

Azure DNS Private Zones

After your app integrates with your VNet, it uses the same DNS server that your VNet is configured with. By default, your app won't work with Azure DNS Private Zones. To work with Azure DNS Private Zones you need to add the following app settings:

  1. WEBSITE_DNS_SERVER with value 168.63.129.16
  2. WEBSITE_VNET_ROUTE_ALL with value 1

These settings will send all of your outbound calls from your app into your VNet in addition to enabling your app to use Azure DNS private zones.

Private endpoints

If you want to make calls to Private Endpoints, then you need to either integrate with Azure DNS Private Zones or manage the private endpoint in the DNS server used by your app.

Connect to service endpoint secured resources

To provide a higher level of security, you can restrict a number of Azure services to a virtual network by using service endpoints. You must then integrate your function app with that virtual network to access the resource. This configuration is supported on all plans that support virtual network integration.

To learn more, see Virtual network service endpoints.

Restrict your storage account to a virtual network

When you create a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. You can't currently use any virtual network restrictions on this account. If you configure a virtual network service endpoint on the storage account you're using for your function app, that configuration will break your app.

To learn more, see Storage account requirements.

Use Key Vault references

You can use Azure Key Vault references to use secrets from Azure Key Vault in your Azure Functions application without requiring any code changes. Azure Key Vault is a service that provides centralized secrets management, with full control over access policies and audit history.

Currently, Key Vault references won't work if your key vault is secured with service endpoints. To connect to a key vault by using virtual network integration, you need to call Key Vault in your application code.

Virtual network triggers (non-HTTP)

Currently, you can use non-HTTP trigger functions from within a virtual network in one of two ways:

  • Run your function app in a Premium plan and enable virtual network trigger support.
  • Run your function app in an App Service plan or App Service Environment.

Premium plan with virtual network triggers

When you run a Premium plan, you can connect non-HTTP trigger functions to services that run inside a virtual network. To do this, you must enable virtual network trigger support for your function app. The virtual network trigger support setting is found in the Azure portal under Configuration > Function runtime settings.

VNETToggle

You can also enable virtual network triggers by using the following Azure CLI command:

az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.functionsRuntimeScaleMonitoringEnabled=1 --resource-type Microsoft.Web/sites

Virtual network triggers are supported in version 2.x and above of the Functions runtime. The following non-HTTP trigger types are supported.

Extension Minimum version
Microsoft.Azure.WebJobs.Extensions.Storage 3.0.10 or above
Microsoft.Azure.WebJobs.Extensions.EventHubs 4.1.0 or above
Microsoft.Azure.WebJobs.Extensions.ServiceBus 3.2.0 or above
Microsoft.Azure.WebJobs.Extensions.CosmosDB 3.0.5 or above
Microsoft.Azure.WebJobs.Extensions.DurableTask 2.0.0 or above

Important

When you enable virtual network trigger support, only the trigger types shown in the previous table scale dynamically with your application. You can still use triggers that aren't in the table, but they're not scaled beyond their pre-warmed instance count. For the complete list of triggers, see Triggers and bindings.

App Service plan and App Service Environment with virtual network triggers

When your function app runs in either an App Service plan or an App Service Environment, you can use non-HTTP trigger functions. For your functions to get triggered correctly, you must be connected to a virtual network with access to the resource defined in the trigger connection.

For example, assume you want to configure Azure Cosmos DB to accept traffic only from a virtual network. In this case, you must deploy your function app in an App Service plan that provides virtual network integration with that virtual network. Integration enables a function to be triggered by that Azure Cosmos DB resource.

Hybrid Connections

Hybrid Connections is a feature of Azure Relay that you can use to access application resources in other networks. It provides access from your app to an application endpoint. You can't use it to access your application. Hybrid Connections is available to functions that run on Windows in all but the Consumption plan.

As used in Azure Functions, each hybrid connection correlates to a single TCP host and port combination. This means that the hybrid connection's endpoint can be on any operating system and any application as long as you're accessing a TCP listening port. The Hybrid Connections feature doesn't know or care what the application protocol is or what you're accessing. It just provides network access.

To learn more, see the App Service documentation for Hybrid Connections. These same configuration steps support Azure Functions.

Important

Hybrid Connections is only supported on Windows plans. Linux isn't supported.

Outbound IP restrictions

Outbound IP restrictions are available in a Premium plan, App Service plan, or App Service Environment. You can configure outbound restrictions for the virtual network where your App Service Environment is deployed.

When you integrate a function app in a Premium plan or an App Service plan with a virtual network, the app can still make outbound calls to the internet by default. By adding the application setting WEBSITE_VNET_ROUTE_ALL=1, you force all outbound traffic to be sent into your virtual network, where network security group rules can be used to restrict traffic.

Automation

The following APIs let you programmatically manage regional virtual network integrations:

Troubleshooting

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.

Tools

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.

On-premises resources

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.

Next steps

To learn more about networking and Azure Functions: