Azure Web App Vnet Integration - Hub and Spoke Scenario

Integrating Web Apps with virtual network allows us to access the resources which is located within our private network space, however web apps will be still be accessible from internet. App Service Environment could be possible solution if you wish to make your Web App completely private.

In this blog I will be discussing the 3 possible use cases.
  1. Integrate Web Apps with VNet and verify connectivity between Web App and a VM which is deployed within the same VNet. 
  2. Web App Integration in Hub and Spoke 
  3. Establish connectivity between On-Prem network and Azure Web App
Use Case 1 - Simple

We need to have the following things to meet the goal with use case 1.
1. Virtual Network - Ansible-vnet - Address Space -10.0.0.0/16

2. Provision a Gateway Subnet - Address Space - 10.0.1.0/24
3. Virtual Network Gateway - WebApp-GW : SKU - VpnGw1

4. Create Point to Site in WebApp-GW - Address Space : 172.16.201.0/24

5. Since, SKU - VpnGw1 is used, IKEv2 VPN should be unchecked. (This can be checked if BASIC SKU in use while provisioning Virtual Network Gateway)
6. Lets Integrate Web App to  WebApp-GW

7. Lets go the Gateway and check, if connection has been established by Web App or not.
At the button, you can see the allocated IP.

8. For testing, I have deployedVM in Ansible-Vnet to test connectivity. IP: 10.0.0.6

9. Web App > Advance Tools> Go
10. Click at  Debug Console > CMD
11. TCPPING 10.0.0.6:3389 (Make sure RDP port is open or try with any other open port)


Use Case 2  - Hub and Spoke - Perfect World Scenario

Hub VNet Name: Hub-Vnet
Address Space: 10.1.0.0/16
Spoke VNet Name:  Spoke-VNet
Address Space: 10.3.0.0/16
Lets establish peering between Hub VNet and Spoke-VNet
Activities to be performed in Spoke-VNet:
1. Goto Spoke-VNet > Click at Peering and  + Add
Since, Spoke-VNet does not have gateway, it will use HUB-VNet gateway when required.  After sometime, you can see the following



2. There should be two way peering, so lets Go to HUB-VNet and Click at Peering and Add
Here, we have checked "Allow gateway transit" as Spoke-VNet does not have gateway. And, will be using Gateway of HUB-VNet when required to communicate outside. 

 Once peering is establish you can see the following.
3. Create a VM in Spoke-VNet.
4. Test the connectivity between Web App Integrated with Hub-VNet and VM in Spoke-Vnet. Go to Web App "Hub08" > Advance Tools > Go



With this,web app is communicating with VM deployed in Spoke-VNet.

Use Case 3 - Integrating Web App with Spoke VNet.

Currently, SpokeVNet is peered with Hub-VNet, i.e, "Use Remote Gateway" is enabled. Because of this, we can not spin Virtual Network Gateway in Spoke-Vnet. So, lets uncheck "Use Remove Gateway" from Peering configuration and save it.
1. Remove "Use Remote Gateway" from Spoke-VNet Peering configuratoion and Save it. 

 2. Create Virtual Network Gateway

Common Error Message:
When you integrate Web App with VNet, it will though a error message as shown below, however if you refresh the page, you will it will show "Connected", its looks like a bug. 


Failed to add Virtual Network to Web App
Adding network "Hub-Vnet" * to web app "Hub08"* failed.: Gateway did not finish the operation in time


 (* name of VNet and Web App)


 Lets trying TCPPING from KUDU (Web App > Advance Tools> Go ) to the VM which is deployed within the Same VNet i.e. Hub-Vnet



As expected you will see the following error message


(Put screenshoot)


D:\home>tcpping 10.1.0.4:3389
Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 10.1.0.4:3389

Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 10.1.0.4:3389

Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 10.1.0.4:3389

Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 10.1.0.4:3389

Complete: 0/4 successfull attempts (0%). Average success time: 0ms




Lets go to Virtuall Network Gateway of Hub-Vnet and verify if web app is connected?






 Connection : 0 


Lets check the SKU of Hub-Vnet-GW.  Its VpnGw1. As per micrososft documentation, if you are not using Basic SKU then IKEv2 VPN  should be disabled.







Now, Go to the web app, HUB08, Networking and Click configure. Click at Disconnect and Setup once again by selecting "Hub-Vnet". This time you will not see any error message. Now, the following in gateway. 


Now it will response to TCP Ping as well. 







Comments

Post a Comment

Popular posts from this blog

Deploy Palo Alto in Azure

Image
There are many ways to deploy Palo Alto Firewall in Azure. Out of those options today I will discuss how Palo Alto can be configured to protect your Azure workload. This setup is suitable for Proof of Concept only. Planning-Includes Minimum Requirement - Without HA Logical Diagram:  Create Virtual Network Name: PAN-VNet Address Space: 10.0.0.0/16 Subnet Name: Management Subnet Address Space: 10.0.1.0/24 Subnet Name: Untrust Subnet Address Space: 10.0.2.0/24 Subnet Name: Trust Subnet Address Space: 10.0.3.0/24 Resource Group: PA-VNet    Subnet Spin Web Server Virtual Machine  Name: SecureWebServices Image: Windows Server 2016 Resource Group: Services Network: PAN-VNet Subnet: Trust Role: Web Server (IIS) Installed Change NSG rules of Web Server to accept request on port 80, if you wish to test the web request. However, later on, this behaviour will be controlled through firewall. Spin Palo Alto Firewall Virtual Machine Name: vmseries300 Im
Read more

Demystifying System and User Define Routes of Azure

Image
As Virtual Network is created, Azure automatically create its own route tables for that Virtual Network, so that all the packets which enters the virtual network can traverse within its address prefix and leave the subnet for its destination. These are known as the Default Routes . We can’t modify these routes; however, we can add our custom routes on top of default routes for the traffic leaving the subnet. These custome route is known as User Define Routes . In this case, we are modifying the default behaviour of packets routing but still the internal and external routing of packet is done by virtual network to ensure that our packets are never hijacked.  In another word, we are adding routes and requesting virtual network to routes traffic in the way we want. So far its not possible to route the traffic independently bypassing the Azure Virtual Network routing mechanism and for security reason I do not think this will ever be possible. Common Use Case of UDR:  Every bus
Read more