Azure Transit VNET Single Arm Deployment Architecture

[dspears]

Cloud deployments have been evolving over time as the Cloud Providers provide new options for integration. A very popular AWS deployment is the GWLB which in its simplest deployment model is a single armed deployment. There have been requests for a similar architecture for Azure. After putting in some thought and lab time, I was able to find the following architecture that can handle all the flow patterns in a one arm security deployment.

To create this environment, I started with the Panorama automated deployment plugin and deployed the inbound stack:

Post deployment, I shut down the trust interface in the template stack and changed my NATs in the NAT policy to a Source NAT inbound traffic with the untrust interface (versus the trust) and deployed an Application Gateway. The result was the following architecture:

The following set of diagrams walk through the various flows for this deployment. Requests are Green and the server responses are in Red. Each step in the flow is also numbered. The first flow is using the Azure Public Load Balancer and is often deployed for non-HTTP traffic. In this flow the backend targets for the Public Load Balancer are the VM-Series NGFWs.

The following flow depicts inbound web application traffic through an Application Gateway. There is a UDR on the subnet that App Gateway is deployed in that redirects spoke VNET traffic to the Internal Load balancer. After inspection the traffic is routed via normal VNet Peering to the target. A UDR for the App Gateway subnet is on the spoke VNet with a next hop of the internal load balancer.

Outbound traffic is handled by a default route UDR on the spoke subnets. This UDR sends traffic to the internal Standard Load Balancer. The traffic is sent to a VM-Series NGFW and processed. It is then affected by an outbound NAT policy and forwarded to the internet. The response is sent back to the NGFW and forwarded directly to the origin server in the spoke VNET.

The next diagram shows the traffic flow for east west traffic between separate VNet spokes within a transit VNet architecture. Subnets in both spokes have a UDR with a default route that points to the internal load balancer. Since this is a standard load balancer, there is no need to SNAT the traffic on the VM-Series FW. In this case a NAT negate policy is used to keep East West traffic from getting affected by an outbound SNAT rule.

There are multiple methods to deploying the VM-Series in an Azure VNET architecture. Every design has nuances. The goal with this article is to provide another option for customers to choose from.

[Crenzy]

Good article with clear diagrammatic representation.

One quick question: In the 'Azure - Outbound flow'  scenario, what is the need for the traffic from spoke subnets to flow through the internal LB? Especially if the reverse traffic is flowing directly from NGFW to the spoke VMs?

[dspears]

The Outbound flow is when a server resource initiates a connection to the internet.  The request goes to the internal load balancer so that outbound flow is handled resiliently by the NGFWs.  This way if a firewall fails,  the load balancer will send requests to other firewalls.  It also supports scaling the firewalls out via ScaleSets to support more capacity. The FW SNATs the traffic as it leaves to go to the internet which forces the reply to come back to the same firewall before getting sent back to the requesting server.

[Anthony81]

Hi All 

I am specifically looking at the scenario of deploying PA VM series firewalls in Azure to protect only east west traffic between Azure spokes.

I am using the Transit VNET common firewall Architecture where the PA VM series are sitting behind an Azure Internal load balancer 

Routing steps I have in mind are as below 

1. Configure UDR's  on the spoke subnets for the east west traffic with the next hop address as the front end IP of the Azure loadbalancer 

2. On the loadbalancer I am setting up one Load balancing rule with an HTTPS probe to the PA VM series firewalls as the backend pool members 

3. Configure Security policies on PA firewalls allowing the east west traffic . Change the default intrazone rule to deny 

Now the question is should I be configuring the Virtual router in PA with static routes ? If so what should be the next HOP for the routes in the PA ?

Should I also be setting up Azure UDR's on the trusted subnet of the PA 

Is there any Nating I need to worry about when its only about east west traffic ?

Thanks 

[michaeloleary]

Thanks for the article!