Hey Checkyourlogs Fans,
Today I was working with a customer that has a requirement of keeping internet traffic flowing back through their head office after we migrate VM’s to Azure using Azure Site Recovery. The reason for this is that they have purchased a security appliance that they want to keep on-prem for the foreseeable future. By default when we move a Virtual Machine to Azure using Azure Site Recovery the Route Tables for the Subnet override what is inside the VM.
Let’s have a look at the problem at hand.
What you see below is a Virtual Machine that I have recently migrated to Azure using Azure Site Recovery. I have a Site to Site VPN configured so it can communicate with local resources in the source data center.
The issue is that I have existing NAT Rules created from that flow traffic through to this VM. However, it’s default gateway route 0.0.0.0 is being overridden by Azure.
Let me show you.
Now, when you look at the default route table inside the VM, it would appear that my internet traffic (Default Gateway) has a persistent route to 10.10.0.254. This won’t work because this machine needs to have a route that points to its local subnet in Azure which is 10.17.0.1.
I checked the IP Address, and I am indeed going out through azure at this time for internet.
I want the traffic to flow back through the source gateway of 10.10.0.254, not 10.17.0.1. We can check the route table of the VM in Azure by checking the diagnostic settings inside the VM.
Here is the route table for the new Azure VM.
As you can see above the Default 0.0.0.0/0 Route has the next hop of the Internet.
We need to change this to a User Defined Route.
NOTE: The Routing order in Azure is User Defined Route, BGP Route, and then System Defined.
The above Default Route is a System Defined Route.
To fix this, we need to create a new Route Table and associate it with the subnet that is being used by this VM.
More information can be found here: https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-create-route-table-portal
First, create a new Route Table.
Add the route and configure it to go back through the Virtual Network Gateway.
Associate it to the Subnet
Review the new effective routing table and test.
The last step is configuring an Azure Feature called Forced Tunneling. For this, we will need to do some configurations in PowerShell.
Install-Module -Name AzureRM Connect-AzureRMAccount Get-AzureRMResourceGroup Get-AzureRMVirtualnetworkGateway -ResourceGroupName to-az-dr03 Get-AzureRMLocalNetworkGateway -ResourceGroupName to-az-dr03 $LocalGateway = Get-AzureRmLocalNetworkGateway -Name "TriconElite-HQ" -ResourceGroupName "tc-az-dr03" LocalGateway $VirtualGateway = Get-AzureRmVirtualNetworkGateway -Name "tc-az-dr03-vnet1-GW" -ResourceGroupName "tc-az-dr03" $VirtualGateway #Here is the secret command to configure Forced Tunneling Set-AzureRmVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway $VirtualGateway
NOTE: The Forced Tunnel setting Set-AzureRMVirtualNetworkGatewayDefaultSite only works on a Route Based Virtual Network Gateway, not a Policy-Based Virtual Network Gateway. I had to recreate my Virtual Network Gateway to get this working.
The last step was to validate things were working from an Azure VM in my Virtual Network.
The IP Address for the 2nd hop is now my on-prem firewall. This proves that the traffic for the internet is now flowing back through my datacenter instead of out through Azure.
I hope this post helps you out and that you enjoy it.