• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

At the previews posts, we covered the basics of routing traffic from/to on-premises, inspecting all traffic through Azure Firewall, and configuring the DNS for accessing the Private Endpoints. In this scenario, I am experimenting with connectivity between on-premises, the Hub & Spoke networks and a second level peered network (a network that is peered behind the Spoke network).

Recap of Scenario 1 & 2: We have a Hub network, two Spoke networks and an IPSec VPN connection with my on-premises network. We established routing all traffic through the Azure Firewall for inspection & configured DNS for accessing the Private Endpoint from on-premises & all Azure VNets.

In the third scenario, I am adding a new Spoke VNet, the “Azure 2” peered with my hub, and a third VNet, the “Azure 3” that is only peered with the “Azure 2” VNet. To enable connectivity between the “Azure 3” VNet and the rest of the networks, including the on-premises, we need a router at the “Azure 2” VNet. This can be an NVA or Azure Firewall. In my case, I added an Azure Firewall. The Azure Firewall of “Azure 2” VNet has the private IP: 192.168.200.64.

• Azure 3 VNet, VM Subnet Route Table:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.200.0/28 NH 192.168.200.68

• Azure 2 VNet, AzureFirewallSubnet:
  • 10.0.0.0/0 NH Internet
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.0.0/20 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4

• Azure 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.200.68
  • 192.168.4.0/24 NH 192.168.200.68
  • 192.168.5.0/24 NH 192.168.200.68
  • 192.168.0.0/20 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.64

• Azure Hub VNet, AzureFirewallSubet:
  • 10.0.0.0/0 NH Internet
  • 192.168.200.0/28 NH 192.168.200.68
  • 10.100.0.0/16 NH 192.168.200.68
• Azure Hub VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Azure Hub VNet, GatewaySubnet:
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.5.0/24 NH 192.168.2.4
  • 192.168.4.4/32 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4
  • 10.100.0.0/16 NH 192.168.2.4
• Spoke 2 VNet, VM Subnet:
  • 10.0.0.0/16 NH 192.168.2.4
  • 192.168.4.0/24 NH 192.168.2.4
  • 192.168.0.0/24 NH 192.168.2.4
  • 192.168.200.0/24 NH 192.168.2.4

Routing Example

Let’s describe a packet’s journey. The On-premises Server X (10.0.2.10) makes sends a packet to 10.100.0.4. 1st hop the packet goes to the default gateway, reaching the on-premises VPN device, in our case the RRAS. The RRAS has a custom route for 10.100.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway The Azure VPN Gateway has a custom route for 10.100.0.0/16 and forwards the packet to the HUB Azure Firewall, 192.168.2.4. The HUB Azure Firewall has a custom route for 10.100.0.0/16 and forwards the packet to the “Azure 2” Azure Firewall, 192.168.200.68. The “Azure 2” Azure Firewall does not have a custom route, but it has a route for 10.100.0.0/16 that is automatically populated by the VNet peering. The Azure FIrewall knows to forward the packet through the VNet peering and reaches the destination.

You can find more commends and tests in the below diagram with the whole solution.

Diagram: (Click here to download a high-resolution SVG image)

References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Azure Routing Experiences | Scenario 2 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 3 appeared first on Apostolidis Cloud Corner.

• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

Scenario 1: Hybrid connectivity through Azure VPN gateway

At the start, I created the on-premises network, using a RRAS (Windows Server 2019 with Routing & Remote Access) to act as the router/VPN device and a Server with DNS service. The Azure estate has three VNets, in a hub & spoke topology. One HUB and two Spokes, connected with the HUB with VNet peering. There is no peering between the spokes. My Azure HUB network has three subnets, one has a VPN Gateway, the second has a VM, and the third has an Azure Firewall. In this first scenario, the Azure Firewall acts only as a DNS Proxy. It is not included in routing.

• On-premises network: 10.0.0.0/16
• HUB VNet Address Space: 192.168.0.0/22
• HUB GatewaySubnet: 192.168.1.0/24
• HUB VMSubnet: 192.168.0.0/24
• HUB Firewall Subnet: 192.168.2.0/24
• Spoke1 (storage account): 192.168.4.0/24
• Spoke2 (VM): 192.168.5.0/24

The first spoke has a Private Link to my storage account. The second spoke has a VM.. Azure VPN Gateway knows all routes of its VNet, the peered VNets & the routes propagated from the VPN connection. From on-premises, we can reach all resources using the VPN connection interface ( in RRAS I added a custom route “192.168.0.0 255.255.0.0 interface:AzureGW”)

From the VM of the HUB VNet (192.168.0.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet.

To access the Private Endpoint of the Storage account we need some more resources & configuration. The storage account, as all PaaS services (like Web App & Azure SQL) responds only to URI and not to IP. Since we have connected a Private Endpoint to the Storage Account, the Public Access is blocked. So, in order to connect to the storage account, we need the aprostore.file.core.windows.net to translate to the private IP of the storage account, the 192.168.4.4. The proper way to achieve this is by using DNS.

First, we need to create a Private DNS zone and link it to the HUB VNET. For accessing blob storage we need a Private DNS zone with the name privatelink.blob.core.windows.net, for the file we need privatelink.file.core.windows.net. More services here. Then add the Storage Account Private Endpoint record to the Private DNS Zone. Now there is an A record azappsa with IP 192.168.4.4. Now, all Azure resources at the linked VNet, the HUB, are able to resolve the DNS records of the Private DNS Zone. We cannot resolve the records of the Azure Private DNS Zone from on-premises. To do so, we need a DNS server on Azure, to use as a conditional forwarder. This can be a Windows or Linux VM with DNS services or in my case, the Azure FIrewall with the DNS proxy enabled (I will use the whole functionality of the firewall to my next scenarios). I enabled the DNS Proxy on Azure, using default Azure DNS, and I added a conditional forwarding at the on-premises DNS “blob.core.windows.net -> 192.168.2.4” and “file.core.windows.net -> 192.168.2.44”. Now, I can successfully resolve the private IP of the storage account using its name, and be able to connect to it to both blob and to files with SMB access.

From the VM of the Spoke2 VNet (192.168.5.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet. I added a second route “192.168.4.0/24 Next Hop: Virtual Network Gateway” & changed the VNet DNS to 192.168.2.4 (the Azure Firewall) to be able to access the Spoke1 VNet for storage access.

DNS & Routing example

DNS: The on-premises Server X, 10.0.2.10, makes a request to https://azappsa.blob.core.windows.net. At first, it asks the DNS to resolve the URL to an IP. The DNS has a conditional forwarder about blob.core.windows.net, and asks the Azure Firewall, 192.168.2.4. Azure Firewall has a linked Private DNS zone that has a host record for azappsa.blob.core.windows.net and it resolves to 192.168.4.4. This information routes back to Server X. Now Server X knows that the IP address of azappsa.blob.core.windows.net is 192.168.4.4.

Routing: To go to 192.168.4.4 first it asks its Default Gateway, in our case the RRAS. The RRAS has a custom route for 192.168.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway. The Azure VPN Gateway has a custom route for 192.168.0.0/24 BUT it also has a route for 192.168.4.4/32 that is automatically populated by the VNet peering. The /32 route is more specific than the /24 route, so the VPN Gateway forwards the packet directly to the Private Endpoint, bypassing the Azure Firewall. (At the Azure Routing Experiences | Scenario 2 we will see how we will force the traffic through the Azure Firewall.

Please find below the whole solution diagram, I tried to make it as analytic as possible, without messing with too many lines. Also, I have some notes and tests below.

References:
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 1 appeared first on Apostolidis Cloud Corner.

Peering is a feature that allows to connect two or more virtual networks and act as one bigger network. At this post we will see how we can connect two Azure Virtual Networks, using peering and access the whole network using one VPN Gateway. We can connect Virtual Networks despite if they are in the same Subscription or not.

I have created a diagram to help understand the topology.

• We have a Virtual Network with Site-2-Site VPN wto On Premises. It can also have Point-2-Site connection configured. The VNET A.
• We have another Virtual Network at the Same Subscription that we want to connect each other. The VNET B.
• Also we can have a third Virtual Network at a different subscription. The VNET C.

In sort we need those peerings with the specific settings:

• At the VNETA Peering VNETA to VNETB with “Allow Gateway transit”
• At the VNETA Peering VNETA to VNET
• At the VNETB Peering VNETB to VNETA with “Use Remote Gateway”
• At the VNETB Peering VNETB to VNETC
• At the VNETC Peering VNETC to VNETA with “Use Remote Gateway”
• At the VNETC Peering VNETC to VNETB

In order to be able to connect all those networks and also access them using the VPN Connection there are four requirements:

• The account that will be used to create the peering must have the “Network Contributor” Role.
• The Address Space must be different on each other and not overlap.
• All other Virtual Networks, except the one that has the VPN Connection must NOT have a VPN Gateway deployed.
• Of course at the local VPN device (router) we need to add the address spaces of all the Virtual Networks that we need to access.

Lets lab it:

• HQ 192.168.0.0/16 –> The on-premises network
• VNET A 10.1.0.0/16 –> The Virtual Network that has the VPN Gateway (At my lab is named “devvn”)
• VNET B 10.229.128.0/24 –> THe virtual network at a different subscription of the Gateway (At my lab is named “Network prtg-rsg-vnet”)
• VNET C 172.16.1.0/24 –> The virtual network at the same subscription as the Gateway Network (At my lab is named “provsevnet)

The on-premises network is connected with Site-to-site (IPsec) VPN to the VNETA

Now we need to connect VNETA and VNETB using Vnet Peering. in order to have a Peering connection we need to create a connection from VNETA to VNETB and one from VNETB to VNETA.

Open the VNETA Virtual Network, go to the Peerings setting and press +ADD

Select the VNETB and check the “Allow Gateway transit” to allow the peer virtual network to use your virtual network gateway

Then go to the VNETB, go to the Peerings setting and click +ADD.

Select the VNETA Virtual Network and check the “Use Remote Gateway”  to use the peer’s virtual network gateway. This way the VNETB will use the VNETA’s Gateway.

Now we can contact the VNETB network from our on-premises network

a multi-ping screenshot:

• From 10.229.128.5 (VNETB) to 192.168.0.4 (on-premises) & the opposite
• From 10..1.2.4 (VNETA) to 10.229.128.5 (VNETB)  & to 192.168.0.4 (on-premises)

The next step is to create a cross-subscription peering VNETA with VNETC

Open the VNETA and create a peering by selecting the VNETC from the other Subscription and check the “allow gateway transit”

Then go to the VNETC and create a peer with the VNETA and check the “use remote gaeway”

With the two above connections we have connectivity between the on-premises network and the VNETC.

The final step, to enable the connectivity between VNETB & VNETC. To accomplish this just create one peer from the VNETB to VNETC and one from VNETC to VNETB.

Ping inception:

In order to have client VPN connectivity to the whole network, create a Point-2-Site VPN at the VNETA. You can follow this guide: Azure Start Point | Point-to-Site VPN

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Connect two or more Azure Virtual Networks using one VPN Gateway appeared first on Apostolidis Cloud Corner.