Forum Discussion
ASR Failover network architecture
I'm new to Azure and I have requirement to set up disaster recovery for an on-prem server. I am aware of the process in replicating the server to the cloud. However, I am not able to grasp how networking should be in a disaster situation.
Server is in 172.x.x.x network and I know that s2s VPN should be set up between the Azure network and the on-prem network And Azure network and on-prem can't be on the same subnet for s2s to work. So when I failover to cloud, how would the cloud server talk to the on-prem network? And devices in on-prem talk to the server in the cloud?
- Hi phantom2000.
Setting up disaster recovery for an on-premises server using Azure Site Recovery (ASR) requires careful planning of your network architecture to ensure that, in the event of a failover, the communication between on-premises devices and the cloud server is maintained seamlessly. Here's a high-level overview of how you can set up the networking for this scenario:
Create a virtual network in Azure: Set up a virtual network (VNet) in Azure with an address space that does not overlap with your on-premises network's address space. For example, if your on-premises network is using the 172.x.x.x address space, you could use the 10.x.x.x address space for the Azure VNet.
Set up a VPN gateway in Azure: Create a virtual network gateway within the Azure VNet, which acts as the VPN endpoint in the Azure cloud. Configure it as a VPN gateway type and attach a public IP address to it.
Set up a VPN gateway on-premises: Configure a VPN gateway on your on-premises network. This could be a hardware VPN device or a software VPN solution such as Windows Server Routing and Remote Access Service (RRAS).
Establish a site-to-site (S2S) VPN connection: Set up a site-to-site VPN connection between the on-premises VPN gateway and the Azure VPN gateway. This will create a secure tunnel between your on-premises network and the Azure VNet, allowing devices in both networks to communicate with each other.
Configure Azure Site Recovery: Configure ASR to replicate your on-premises server to the Azure VNet. During the configuration, you can choose the Azure VNet and the appropriate subnet for the replicated server.
Update DNS settings: In the event of a failover, you will need to update the DNS settings for the devices in your on-premises network to point to the new IP address of the server in the Azure VNet. This can be done manually, or you can automate it using Azure Automation or another scripting tool.
When a failover occurs and your on-premises server is replicated to the Azure VNet, the cloud server will be assigned an IP address from the Azure VNet address space. Since you've established a site-to-site VPN connection between the Azure VNet and your on-premises network, devices in your on-premises network will be able to communicate with the cloud server using its new IP address through the VPN tunnel. Similarly, the cloud server will be able to communicate with devices in your on-premises network.
Keep in mind that this is a high-level overview, and your specific setup might require additional configuration or adjustments based on your unique requirements and network topology. Can refer below article for all necessary setup required:
https://learn.microsoft.com/en-us/azure/site-recovery/physical-azure-disaster-recovery
When configuring a disaster recovery (DR) solution for an on-premises server with Azure Site Recovery (ASR), it is essential to ensure that the networking architecture is set up correctly to support failover and failback. This involves creating a network architecture that allows for seamless connectivity between the on-premises network and the Azure network in the event of a disaster.
Here are a few key points to consider:
Establishing connectivity: In order to provide connectivity between on-premises and Azure networks, a site-to-site (S2S) VPN should be set up. This allows for secure communication between the on-premises network and Azure virtual network (VNet).
Creating subnets: When setting up the Azure VNet, ensure that subnets are created for the resources that will be created within Azure, such as the ASR target virtual machine. This VNet should be on a different subnet than the on-premises network. It is also recommended to create a subnet specifically for the VPN gateway.
Configuring routing: Once the S2S VPN is set up, you will need to configure routing between the on-premises network and the Azure VNet. This is usually done using a VPN gateway, which can be set up in Azure to route traffic to and from the on-premises network.
Configuring failover: In the event of a disaster, the Azure virtual machine will failover to the Azure VNet. During failover, the Azure virtual machine will be assigned a private IP address from the Azure VNet, which will allow it to communicate with the on-premises network via the S2S VPN.
Configuring failback: Once the on-premises network is restored, the Azure virtual machine will need to failback to the on-premises network. During this process, the routing will need to be reconfigured to ensure that traffic flows correctly between the on-premises network and the Azure VNet.
In summary, the key to establishing a successful DR solution with ASR is to create a network architecture that allows for secure connectivity between the on-premises network and the Azure VNet via a site-to-site VPN. Once this is set up, routing can be configured to ensure that the Azure virtual machine can communicate with the on-premises network during failover and failback.
- In a disaster recovery scenario, you typically set up a VPN connection between your on-premise network and your Azure virtual network. When you failover to the cloud, your on-premise devices would route traffic to the cloud-based virtual machine over the VPN connection.
To allow your cloud-based virtual machine to communicate with your on-premise network, you would need to set up a static route on your on-premise network that directs traffic to the cloud-based virtual machine. This is usually done using a router or firewall.
To allow devices on your on-premise network to communicate with your cloud-based virtual machine, you would configure your VPN connection to allow for bi-directional communication. This can be done by setting up a custom route or a policy-based routing configuration on your VPN device.
