- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
4 Likes | |
3 Likes | |
3 Likes | |
2 Likes | |
2 Likes |
User | Likes Count |
---|---|
11 | |
4 | |
3 | |
2 | |
2 |