Extending your subnet in Azure with VXLan

Continuing with networking in Azure, today I want to talk about how extend the subnets in Azure with VXLAN. To those who do not know VXLAN, it proposes to generate a virtual network to overlap a LAN which will work as base. VXLAN technology uses a layer 3 technology, in order to extend the network, as it shows the following diagram, where the same subnet exists on both sides (Azure and OnPrem):

Ejemplo de extensión de subred

So here the key is that you need a tunel between Azure and OnPrem in order to exchange traffic, but also take into account the following:

  • IP addresses of on-premises hosts are configured as additional IP addresses on the Network Interface Card (NIC) of the Azure VM (using Azure orchestration system);
  • IP addresses of Azure hosts are configured as additional IP addresses of the NIC of on-premises VM.

Whenever an on-premises host tries to reach an Azure VM it sends out an ARP request, and the on-premises Extended Network VM replies to it.

Whenever an Azure VM tries to reach an on-premises host, the Azure Virtual Router sends the traffic to the local IP address which is owned by the Azure VM running Extended Network code.

Take care and happy networking!

Advertisement

Forced Tunneling in Azure

I am not an expert on networking, but sometimes while working in Azure, I have to face some different configurations in order to fulfill customer requirements.

In this case, my customer wanted to redirect all the Internet traffic on the VMs from Azure to OnPrem. Because If you don’t configure forced tunneling, Internet-bound traffic from your VMs in Azure always traverses from the Azure network infrastructure directly out to the Internet, without the option to allow you to inspect or audit the traffic. 

And you know… nowadays, unauthorized Internet access can potentially lead to security breaches…

So, to do that I was thinking in the way I used to do those kind of things, create a table route, redirect the 0.0.0.0/0 traffic to a NVA and done, but this case was not the same, because i needed to redirect all the traffic.

So in this case what is needed is the Forced Tunneling:

Diagrama que muestra la tunelización forzada.

With that configuration any connectio from midtier and backed it is redirected back to onpremises via VPN S2S, and then the traffic can be inspected or event restricted.

The magic to achieve that scenario is to use PowerShell, there is no option to do that with the UI, you can check the full procedure in the following link: Configure forced tunneling for Site-to-Site connections – Azure VPN Gateway | Microsoft Docs

But make special attention to the following parameter:

$LocalGateway = Get-AzLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling"
$VirtualGateway = Get-AzVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling"
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway

With that you create the magic in networking, the other steps that are done in the article are more or less the same that I usually did in my implementations.

So take into account that and happy routing!