3rd Party Firewalls in Azure

You can use 3rd party firewalls in Azure but there are some differences in how High Availability works.

Standard firewall H/A works via lower level network communication to move IP addresses between devices (e.g. gratiutous ARP), but the underlying network in Azure/AWS/etc won't support that approach. There are APIs to inform Azure that an IP address has moved to a different device, but at time of writing this approach results in very slow failover (1min+).

The current vendor pattern architectures use a load balancer and two separate active firewalls to provide resilience. In Azure there are two main types of Load Balancer:

• "Public" which resembles load balancer on a stick (or one-armed load balancing) without SNAT, just changes the destination IP.
• "Private" or "Internal" which is a sort of software defined version of routed load balancing, traffic is forwarded to the backend pool members but the destination IP is not changed.

Inbound Flows

For an inbound connection to a public IP address that fronts a single service, use a Public load balancer with the firewalls set as the backend. The load balancer will then re-write the destination address to whichever firewall it decides to use. This needs the firewall to DNAT traffic to the actual destination, and SNAT to ensure return packets go via the same firewall. This looks like the below, red text refers to IP addresses:

This is fairly limited because not many networks would deploy a pair of firewalls to front a single service. Multiple services are more complicated and there are a few big constraints:

• The firewall normally uses destination IP address to direct traffic, but in the above scenario the load balancer has set the destination IP as the firewall itself.
• With typical one-armed load balancers you can have a different SNAT address for each service, but Azure Load Balancer doesn't do SNAT.
• A "private" type load balancer would maintain the original destination IP address, but you can't apply public IP addresses to them, Microsoft's use-case for those is strictly internal.
• A "public" type load balancer could be put infront of a private one to have separate load balancers for service and firewalls, but the backend pool hosts need to be on the local subnet with the Azure Load Balancer.

The only option for non-web traffic is to use the "public" type load balancer with either a separate IP addresses on every firewall for every service, or a separate port on every firewall for every service, which will get complicated fairly quickly so will become problematic at scale:

For web traffic a nicer solution is to use an Application Gateway on the outside to load balancing the service (backend pool = actual servers) and the inside a private/internal load balancer doing the firewall H/A (backend pool = firewalls). The destination IP address for the entire flow is the backend server, so no DNAT is required and neither is one IP on every firewall per service.

There is also a feature "gateway load balancer" that seems to do away with the need for SNAT on the firewalls but I've not played with it yet: https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/dmz/nva-ha.

Outbound Flows

Outbound traffic can be load balanced using a "private" load balancer sat on the "inside" of the network, which maintains the original destination while providing H/A via the available firewalls. This looks the same as the first diagram.

References

Vendor Model Architectures
https://docs.fortinet.com/document/fortigate-public-cloud/6.0.0/use-case-high-availability-for-fortigate-on-azure/224311/basic-concepts
https://www.paloaltonetworks.com/resources/reference-architectures
https://blogs.cisco.com/security/secure-cloud-for-azure

F5 docs on cloud failover, Azure seems slower than other platforms: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/userguide/performance-sizing.html MS docs on public/private load balancer in Azure:
https://docs.microsoft.com/en-us/azure/load-balancer/components