Best practice for Azure Firewall Disaster Recovery

Question

We are looking into our Disaster Recovery plan and wanting to refine it for our Azure services. We currently have multiple connectors that are pointed at public IPs that are on our Azure Firewall that are DNAT'd to their perspective VMs. In the event of a regional outage, our VMs can easily be moved over to US East from US West, but we have no such plan for the Azure Firewall.

We are looking for the best practice for our firewalls in this regional outage case. Is there a way to failover our firewall to the US East region with the same public IPs?

Answer 1

@Everett Brandeau

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you would like to know the best practices for Azure firewall with disaster recovery.

I could not find any specific documents for Azure Firewall, however, it should be similar to any other Networking resource.

Can I keep a public IP address after failover?

• You can't keep the public IP address for a production app after a failover.
• When you bring up a workload as part of the failover process, you need to assign an Azure public IP address resource to it. The resource must be available in the target region.
• https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-common-questions#can-i-keep-a-public-ip-address-after--failover

Can I keep a private IP address after failover?

• Yes. By default, when you enable disaster recovery for Azure VMs, Site Recovery creates target resources, based on source resource settings.
• For Azure VMs configured with static IP addresses, Site Recovery tries to provision the same IP address for the target VM, if it's not in use

For more information : Retain IP addresses during failover

Now, to answer your actual query,

Just like a VPN Gateway or any other PaaS resource in the VNet,

• ASR can replicate the subnet configuration
• But it will not be able to replicate the actual resource
• You will be required to deploy it prior to the migration in the target region's VNet
  or
  Deploy it during the migration using template. (minor downtime to be expected)
• I believe you will be using an Azure Firewall Policy.
  • The target region Firewall Policy must instead use the Public IP created in that target region
  • You can use an ARM template to
    a. either define the Firewall and Firewall Policy configuration
    b. or export the Firewall and Firewall Policy configuration from the existing one and modify the Public IP settings
  • Post which you can use this new Firewall in the target region since the Private IPs of the VMs are going to be the same.
  For 3rd party services that may be referencing the Public IP of the Firewall,
  • You can consider using Azure Traffic Manager
• Your exact scenario is documented here : https://learn.microsoft.com/en-us/azure/site-recovery/concepts-traffic-manager-with-site-recovery#azure-to-azure-failover
• Traffic Manager uses the Domain Name System (DNS) to direct client requests to the most appropriate endpoint, based on a traffic-routing method and the health of the endpoints.

Traffic Manager is not a proxy or a gateway, and it does not see the traffic passing between the client and the service.

These docs may come handy:

• How can I stop and start Azure Firewall?
• Deploy Azure Firewall with Availability Zones - ARM template
• Microsoft.Network firewallPolicies Templates

Also, I came across this blog which might help you with automation : https://techcommunity.microsoft.com/t5/azure-network-security-blog/backup-azure-firewall-and-azure-firewall-policy-with-logic-apps/ba-p/3613928#:~:text=The%20Logic%20App%20runs%20every%20three%20days%20to,your%20Firewall%20and%20Firewall%20Policy%20deployments%20as%20required.

Hope this helps.

Thanks,

Kapil

Answer 2

Hi,

Azure Firewall doesn't support Disaster Recovery as of today. As I understand your setup, you have client application/ servers connecting to Azure Firewall's Public IP which inturn gets DNAT'd to the servers in Azure VNET. When the failover happens, you will need to update all your clients to use the failed over Azure Firewall IP address and this needs to be scripted at your end to make your scenario work.

Let me know if you have any follow up questions.

Regards,

Karthik Srinivas