How to Connect Azure Web Apps To On-Premises

In this post, I will explain how app services, or web apps, can be connected to external users or services.

No App Service Is an Island

The purpose of an app service is to allow someone or something to connect to it, or for it to connect to something, and do some service. Internal users or external clients need to connect to a line-of-business (LOB) application interface. Partners or suppliers need to connect to an application via an API. Or an application might need to integrate with some external service, such as a database.
Azure App services allow you to have external connectivity. Of course, an app service can be accessed across the Internet. We take that for granted. But what if you don’t want to share your service for all to see? What if IP filtering or x.509 security is not enough? There are some alternatives that you can use in your architecture.

VNet Integration

A Standard, Premium, or Isolate app service plan offers the ability for an app service to connect with a virtual network via a point-to-site VPN. The virtual network must have a VPN gateway that is Basic/Dynamic, VpnGw1 or a higher size, and configure for point-to-site connectivity.

Once an app service is connected to a virtual network, you can:

• Enable the app service to talk with Azure virtual machines on that virtual network.
• Hop to on-premises via site-to-site VPN connections also make by that gateway.

The point-to-site VPN connection inherits the SLA of the gateway in question. There are some limitations:

• The connection speed is limited to what the gateway can offer (80-100Mpbs using the Basic size gateway).
• An app service plan can support connections to just 5 virtual networks.
• An app service can connect to just one virtual network.

TCP and UDP connections should work fine but some things that you might want to do will not work over the point-to-site connection:

• Mounting a drive
• Active Directory integration
• NetBIOS

Hybrid Connection

This is a feature that I really like and in conversations that I’ve had, it seems to be an approach that few are aware of. However, it has been available for years in the Basic, Standard, and Premium plans.

If you read the official documentation, you’ll see all sorts of phrases such as BizTalk, service bus and relays that will make this sound very complicated. I’ll boil this solution down to some simple points:

1. You configure a logical connection on your app service or web app.
2. A small agent, the Hybrid Connection Manager, is downloaded and installed on a Windows Server (2012 or later) running in the remote network (on-premises or anywhere) that you need to communicate with.
3. You log into your Azure subscription in the Hybrid Connection manager and select the logical connection in your app service.
4. The Hybrid Connection Manager will initiate a secure tunnel out (TCP 80/443) to your app service in Azure.
5. Your app service can now communicate with TCP-based services, on Windows or Linux, in the remote network via the Hybrid Connection Manager.

The obvious example here is that an app service can integrate with a database that cannot be hosted in Azure. The beauty of this approach is that it is light-touch. You do not need to create inbound firewall rules, VPN tunnels, or ExpressRoute connections. A small relay agent makes an outbound connection and that’s pretty much it!
You cannot use hybrid connections to:

• Mount a drive
• Connect via UDP
• Access dynamic port TCP services
• Use LDAP, which sometimes uses UDP
• Support Active Directory

Azure Service Environment (ASE)

The ASE is a solution where you deploy one or more single-tenant Isolated tier app services plans in an environment that is connected to a virtual network. This means that every instance in the app service plan is already in the virtual network, and can communicate directly with Azure virtual machines in the same network without needing any VPN or hybrid connections.
An internal ASE, deployed using an internal load balancer presents your Isolated tier app services to users/systems via a single private IP address. You can route to that private IP address in a number of ways:

• A web application gateway
• Third-party firewall appliances (virtual machines) in a front-end subnet
• From remote or on-premises networks using a site-to-site VPN or ExpressRoute connection

That last option is more scalable than the VNet Integration option that I mentioned earlier in this article. The app service plan is already in the virtual network, so one a virtual network has a connection to elsewhere, the app service plan inherits that connection. For example:

• VPN: If you have 30 site-to-site VPN connections to the virtual network, then the app service plan is shared on those 30 tunnels.
• ExpressRoute: If you connect a virtual network to 50 offices via an MPLS network, then the app service plan is connected to all 50 locations.
• VNet Peering: If you peer your virtual network, then the app service plan can route across those peered connections.

What to Use?

With all these options, what should you do? I think there will be lots of variables to consider, but here are some thoughts:

• If you require an app service to connect to a virtual network, then VNet integration is probably a good choice.
• If you are using VNet integration with a virtual network, then you can relay to on-premises via site-to-site VPN.
• Note that a gateway will limit VPN speeds and VNet integration is not available to the Basic tier.
• If you are using the Basic tier, hybrid connections are the only option.
• Hybrid connections are good for accessing TCP-based services in a remote network without messing with WAN, VPN, or inbound firewall rules.
• Unfortunately, hybrid connections might be ruled out if installing a Hybrid Connection Manager is not possible, for example, on a partner/customer network.
• ASE is suitable if you need an isolated deployment, and offers much greater scalability and simpler networking than VNet integration.

Related Article:

• Use Azure ExpressRoute Private Peering & Azure Virtual WAN to Connect Privately to Microsoft 365