Hi, I took over an Azure Site Recovery (ASR) Project with about 13 VMware machines which are replicated in Azure. Currently, the Azure environment includes: 1x Hub vNet with the VPN Gateway. 1x Spoke vNet (Prod) with already running instances, including one Domain Controller. Peering exist with the Hub vNet. 1x Spoke vNet (DRMain) which has the same CIDR range has the on-premises and it will include the VM after the failover. There is no peering with the Hub vNet because the VPN S2S is active. The idea from the previous colleague was certainly to proceed as below in case of a failover: Cut the VPN S2S connection. Create a peering between the DRMain vNet et the Hub vNet. Run the recovery plan to restart the machine in the DRMain vNet. Update the DNS for the vNet DRMain to point to the Domain Controller already running in the Prod. In that situation there won't be an overlap with the on-premises network because the VPN will be disconnected. In regards to the failback from Azure to on-premises, we'll need to activate the VPN for the resynchro. However, when reading through the document https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-prepare-failback#reprotectionfailback-components , I can read the following: > For retained IP addresses the configuration server needs two NICs - one for source machine connectivity, and one for Azure failback connectivity. This avoids overlap of subnet address ranges for the source and failed over VMs This might be a stupid question but if the on-prem network has the same IP range than the vNet, how can I have both NICs in different subnet ? Can anyone shed some light on this ? Thanks in advance Nicolas

Failback while retaining the IP addresses ?

Nicolas 111

Hi,

I took over an Azure Site Recovery (ASR) Project with about 13 VMware machines which are replicated in Azure. Currently, the Azure environment includes:

1x Hub vNet with the VPN Gateway.
1x Spoke vNet (Prod) with already running instances, including one Domain Controller. Peering exist with the Hub vNet.
1x Spoke vNet (DRMain) which has the same CIDR range has the on-premises and it will include the VM after the failover. There is no peering with the Hub vNet because the VPN S2S is active.

The idea from the previous colleague was certainly to proceed as below in case of a failover:

Cut the VPN S2S connection.
Create a peering between the DRMain vNet et the Hub vNet.
Run the recovery plan to restart the machine in the DRMain vNet.
Update the DNS for the vNet DRMain to point to the Domain Controller already running in the Prod.

In that situation there won't be an overlap with the on-premises network because the VPN will be disconnected.

In regards to the failback from Azure to on-premises, we'll need to activate the VPN for the resynchro. However, when reading through the document https://learn.microsoft.com/en-us/azure/site-recovery/vmware-azure-prepare-failback#reprotectionfailback-components, I can read the following:

> For retained IP addresses the configuration server needs two NICs - one for source machine connectivity, and one for Azure failback connectivity. This avoids overlap of subnet address ranges for the source and failed over VMs

This might be a stupid question but if the on-prem network has the same IP range than the vNet, how can I have both NICs in different subnet ?

Can anyone shed some light on this ?

Thanks in advance
Nicolas

SadiqhAhmed-MSFT 37,686 Reputation points Microsoft Employee

2020-06-03T20:48:27.447+00:00

For S2S VPN same subnets cannot be used at multiple locations.
Would be interested to know what exactly you are looking for?
Nicolas 111 Reputation points

2020-06-04T15:14:23.17+00:00

Yes, I know the same subnets cannot be used. For that reason, the VPN connection is deleted before starting the protected VM in Azure.

Therefore, this means that later when the customer failback, he will have anyway to use a different on-premises network addressing than he had initially. In other words, Azure Site Recovery allows you to failover machines into Azure while keeping the same IP addresses, but for the failback, you have to use a different network addressing than the original production.

Am I correct
SadiqhAhmed-MSFT 37,686 Reputation points Microsoft Employee

2020-06-11T17:03:45.617+00:00

As far as I know, you need to have VPN S2S/ExP route connectivity between the failed over VM’s subnet(In Azure) and the Configuration server.
Now since we retained the IP’s in Azure, that means a similar subnet exists in our On-Premise environment as well.
If the subnet address range is same for Azure and Onpremise, we cannot have Connectivity between them.
So we have a configuration Server Failback NIC in a separate Subnet, with a different range and connect it with the Azure subnet(failed over subnet).
This allows communication within Config server and protected items.
The other NIC of the Config server remains in the original subnet in OnPremise Vnet, so that CS can communicate with the original VM’s and push the delta changes using MT.
Nicolas 111 Reputation points

2020-06-15T05:55:43.453+00:00

Thank you for your response which confirms my thoughts.

Regards
Nicolas
SadiqhAhmed-MSFT 37,686 Reputation points Microsoft Employee

2020-06-15T06:13:13.22+00:00

Thanks for the reply.

Please do not forget to "Accept the answer" wherever the information provided helps you to help others in the community.