I’ve delivered many on-prem deployments, and the patterns there are predictable. You understand the topology, you control the links, and the firewall sits exactly where you place it. Moving the same technology into Azure breaks a few assumptions. Interfaces stop being physical points in the path and live behind load balancers. Routing becomes explicit and must be defined for every flow. High availability shifts from device clustering to cloud-driven failover.
This was my first deployment of VM-Series in a public cloud, and it required adjusting the way I think about traffic and control. This article highlights the differences that matter and how they change the way you design firewalling in Azure.
Interfaces
In on-prem environments you can have many interfaces — physical or logical VLANs — and use them to inspect traffic between subnets. In Azure, you get only two data interfaces: Untrust and Trust.That’s all. Traffic segmentation happens outside the firewall. It is driven by spoke UDRs, where the route to a destination must point either to the firewall interface or to a load balancer, depending on the deployment model.
Routing
Asymmetric routing in on-prem environments is undesirable and usually avoided, because firewalls expect to see the initial packets of a session, the TCP SYN.
If the first packet is missing, the firewall drops the flow by design. In Azure — and likely in other public clouds — asymmetry is built in. Load balancers steer traffic into the firewall, but return traffic does not go back to the load balancer. It goes to the subnet gateway of the firewall’s interface. This creates an asymmetric path by default, something that usually not happens in a traditional network.
High Availability
Typical active-passive HA is supported, but generally not recommended. During failover the subnets from the active VM must be reassigned to the passive VM through Azure APIs, which may take up to 60 seconds. It also does not scale well. The recommended design is to place a load balancer in front of the firewalls. The Palo Alto design guide calls this an active-active cluster, but in practice these are two independent VMs. Sessions are not synchronized, and traffic distribution is handled entirely by the load balancer.
Health Probes
An Azure Load Balancer must check VM availability before sending traffic through the NGFW. The firewall must respond to health probes. In my case, the load balancer checked whether port 443 on the dataplane interface was reachable. A management profile was required to allow this, and routing entries had to be added for the health probe source IP.
For north-south traffic, the deployment used a load balancer on both the trust and untrust interfaces. Azure probes both interfaces with the same source IP (168.63.129.16) and checks whether port 443 is open. By default, a firewall drops such traffic because the same source IP is seen on multiple interfaces — from the firewall’s perspective it looks like spoofing. To support this, the VM used two virtual routers: one for the Untrust interface and one for the Trust interface. Each VR had its own routing table, firewall can respond to the health probes form both interfaces and the necessary inter-VR routes were added to maintain traffic flow. With this setup the firewall handled Azure health probes correctly.
This deployment forced me to rethink how a firewall fits into a cloud network. I had to let go of the on-prem habit of adding interfaces and shaping traffic with physical topology. I had to accept that asymmetry is normal and design for it instead of trying to eliminate it. I had to treat HA as a platform feature, not a cluster I control. I had to build routing and VR separation around Azure’s health-check behavior, not around firewall conventions. Once I aligned my thinking with how the cloud works, the design became straightforward — but the mindset shift had to happen first.