Active/active gateways in Azure and Panorama

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Active/active gateways in Azure and Panorama

L4 Transporter

I have two gateways in Azure operating as an active/active pair. They use the load balancer sandwich topology. I'd like to manage the pair from Panorama. Having a shared policy appears to be difficult.  The two can share a security policy easily enough. But the rules in a NAT policy reference IP addresses specific to a firewall. Example; a source nat which uses the egress interface (and IP) of a gateway.

Do I need to use individual templates/device-groups/policies in Panorama? Or is there a way for the two gateways to share a policy?

 

EDIT: I can set variables in a template in Panorama and set the value of those variables for a specific device. Variables can then be used for things like interface IP addresses and route tables. However i dont seem to be able to use a variable as the IP address in a NAT rule.

Thanks Claudec. If i set the interface ip to 'none' on the source nat (interface) rule, the rule still works fine.

1 accepted solution

Accepted Solutions

L1 Bithead

The firewalls can be apart of the same Device Group and Template Stack. 

 

For inbound NAT policies, the set the source interface to the untrust NIC and the destination address to "any".  The DNAT address must be set to dynamic-destination-translation.  

 

The example below has 2 inbound DNAT policies (jump-server and web-server) and 1 outbound SNAT (for outbound internet).  Ethernet1/1 is untrust and Ethernet1/2 is trust. 

 

Screen Shot 2020-07-14 at 12.27.39 PM.png

 

(Optional & only if using Azure's public load balancer):  If you enable "Floating IP" on the load balancing rule, the original packet's destination address can be set to the load balancer's public IP.  This is useful if you have multiple applications that share the same port.  

 

Screen Shot 2020-07-14 at 12.40.38 PM.png

 

 

 

 

 

 

 

 

 

View solution in original post

3 REPLIES 3

L2 Linker

For your outbound flows, you can just configure a Panorama based NAT policy that uses a source translation that references the egress interface.

 

If for some other reason a NAT policy needs to be different on each firewall in the LB pair you could just use rule targets.

 

claudec_0-1594732907673.png

 

L1 Bithead

The firewalls can be apart of the same Device Group and Template Stack. 

 

For inbound NAT policies, the set the source interface to the untrust NIC and the destination address to "any".  The DNAT address must be set to dynamic-destination-translation.  

 

The example below has 2 inbound DNAT policies (jump-server and web-server) and 1 outbound SNAT (for outbound internet).  Ethernet1/1 is untrust and Ethernet1/2 is trust. 

 

Screen Shot 2020-07-14 at 12.27.39 PM.png

 

(Optional & only if using Azure's public load balancer):  If you enable "Floating IP" on the load balancing rule, the original packet's destination address can be set to the load balancer's public IP.  This is useful if you have multiple applications that share the same port.  

 

Screen Shot 2020-07-14 at 12.40.38 PM.png

 

 

 

 

 

 

 

 

 

L2 Linker

I don't understand how you d-nat for entire ip address range....whats the purpose of using public load balancer if you have to define sources and ports for all things?

  • 1 accepted solution
  • 6470 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!