In a previous article I described some of the challenges faced when deploying and migrating to Azure virtual WAN. In this post, I am going to cover some of the high level issues faced when deploying next-generation firewalls to secure virtual hubs.
No ingress traffic
At the time of writing this article, there is no ingress traffic capability. This is a limitation of the fabric. At present there is a load balancer for outbound traffic to the members of the managed application, but there is no inbound load balancer yet. This feature is currently in early preview.
Everything is active-active
The firewalls that were being replaced by this migration were an active-passive pair with a shared cluster IP for their front end address. With a shared configuration and only one active node, any device communicating with the cluster such as VPN gateways only needed to be configured as if there was only one device.
To deploy a VPN to an active-active pair requires VPN targets to support multiple entry points. Systems that are whitelisting your IP addresses require both addresses to be provided. Access list configurations for the devices need to be identical or troubleshooting could be difficult.
Where does my return traffic go?
Due to the active-active nature of the deployments and the way the load balancer works, in the firewalls default configuration asymmetric routing between the firewalls is highly likely. To overcome this, network address translation is required to be enabled.
How do I manage my devices?
The next-gen firewall network interfaces are connected to the virtual hub network. This network is only routable within the virtual WAN or through a gateway directly attached. This means for an environment with multiple secured hubs, the management server for your firewall devices must exist within the virtual WAN in order to manage all devices.
Managing the devices via their internal interface presents some other challenges but these are more vendor specific.
How do I scale my devices?
When deploying the managed application, you select a scale unit size to support the deployment. Once selected this size is fixed. To scale the system in size requires you to deploy a new managed application instance of the appropriate size to the virtual hub and then cutover. While the operation is relatively straight forward and network impacts minimal, you will get new Public IP addresses and will need to revisit whitelists and VPN configurations. Choose your scale units carefully.
These are just some of the things that must be considered prior to selecting Next-Generation firewalls as your firewall of choice for securing an Azure Virtual Hub.