I have currently 1 firewall VM-Series deployed on Azure. We plan to deploy a second for HA. My question is : is-it recommanded to configure the cluster in Active/Passive mode ? Or to configure the 2 VM-Series as active FW with Azure Load Balancer (what is the risk to have assymetric trafic) ?
The picture sent is based on the "common firewall" architectecture and it's our configuration (we are not on configuration with East-West and North-South architecture).
Just to be sure : in this configuration based on on "common firewall" with the private LB (10.110.0.21), is-the traffic flow in red in the following picture is correct for traffic coming from On-premisses to App servers ?
Hi @jeromecarrier ,
The green path should be the correct, not the red one.
When traffic is forwarded to the internal LB (10.10.0.21), it will do what it is designed to do - select VM FW from the pool and forward the traffic to it.
On the FW (in the PanOS virtual-router) you need route for AppX VNet pointing to the subnet gateway for the private subnet - 10.110.0.1 from where it will follow the routing from the VNet peering and reach the desired Vnet
I would like to have your opinion. In the digram provided in my last post, if I need to create a DMZ for applications reachable from Internet, what is your recommandation regarding the network design ? To add a dedicated network card on my VM-Series (I can create 8 nic) dedicated for the DMZ and create the same approch than the private zone : a DMZ zone on the transit vnet with an LB (to be able to route the traffic an our 2 Vm-Series) ? Or juste create a new vnet and route the traffic to the current LB (10.110.0.21) but it's more difficule in this case to isolate the traffic between DMZ and the other vnet (App01, App02..) ?
Hi @jeromecarrier ,
For Inbound traffic I would strongly advise to use Azure Gateway LoadBalancer (GWLB).
I could suggest you our current setup:
- In addition to your current FW interface (inside and outside) you add only one interface
- The new interface is connected to Azure GWLB (Azure LB health probes are always sourced from the same IP address (22.214.171.124/32). So you will need to configure two separate virtual-routers - your existing one with route for 126.96.36.199 to inside subnet gw and second vr again with route for 188.8.131.52/32 pointing to gwlb subnet gateway)
- The DMZ application to be put in dedicated Vnet. If you need east-west traffic to that Vnet (on-prem or between vnets), you need to peer it with the security hub vnet (where the fw is)
- Deploy public LB in front of the VM instances and associate that LB with GWLB
- In this case you need to configure the LB to be used for outbound traffic for the VMs as well, because you cannot use default route in UDR and GWLB
If you don't want to use public LB for the inbound traffic you can use single public IP assigned to the VM server and again associate it with GWLB.
In both case (public IP or public LB) when associated with GWLB traffic flow would be:
public client --> public LB -> GWLB --> PAN FW --> public LB --> VM server
I'm not sure to understand your last comment. Currently, we have the following design. With this design, the DMZ zone is behind the private zone and it's curious for me to have a DMZ in a "private" zone.
My objective is to move the DMZ to avoid to route the traffic to the private zone to reach server in DMZ but all traffic from Internet or private zone or On-Prem to DMZ must be controlled by our VM-Series. I'm not sure if the bellow evolution is what did you said in your last past. On both VM-Series (who manager east-west and north-south traffic in the common firewall architecture), I add a new interface connected on the DMZ zone inside my vnet DSI_HUB. I create peer between vnet DMZ_Infra / DMZ_Project and the new DMZ zone and I add an LB on the zone (same approach than private zone). The UDR from On-premisses is changed for DMZ network to route the traffic to DMZ_LB.
What is you opinion ? Is-it correct ? Is-it not the better ?
Hi @jeromecarrier ,
Your proposed solution for adding separate internal LB for DMZ is not bad actually. But my humble opinion does it really worth it?
What value are you adding by creating dedicated interface and LB for traffic to DMZ Vnet? I don't want to argue, I want to understand if I am missing something.
Having all DMZ subnets in separat Vnet already segment/separate it from the rest of the Vnets.
Having routes for all traffic (outbound, inter-vnet and on-prem ) pointing to the private LB assures that any traffic from and to that Vnet will pass over the FW.
The only benefit I can see in separate DMZ interface and LB is that you will have separate security zone, which is good to avoid unskilled FW admin adding over-permissive rule (for example instead of adding rule allowing any on-prem to Vnet DSI, if source is not specificed rule will also match traffic from DMZ. By moving the DMZ to dedicate zone previous rule will not match traffic from DMZ even if source is set to any).
As I said it is good solution, but my main problem with it - it is not scalable. What if you need to add more DMZ Vnets in the future? If I remember correctly it was eight and you already have used three. Eventually you will run out of interfaces.
If you believe your environment wouldn't grow beyond the max number of vnic for VM-Series FW go for it. You cost may increase as you will have to pay for more LBs, but you will have dedicated security zone which will give you more easy to understand and maintain security policy.
I personally don't like the whole idea for using public LB for inbound traffic. Assigning multiple IPs in outside interface on the FW...Joggling with the NAT... I would still strongly recommend you to consider Azure GWLB. Inbound traffic make much more sense when using GWLB and it is much more scalable. The only problem with GWLB is that you still need to have internal LB if you need intrer-vnet traffic
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!