topic Re: Panorama: how to manage Security/NAT policies in General Topics

Panorama: how to manage Security/NAT policies

fjwcash — Fri, 19 May 2017 21:43:48 GMT

This is something we're struggling with. How do you write Security Policies and NAT Policies in Panorama when each firewall uses different IPs for NAT and the Security Policies include the IPs in them?

On our FreeBSD firewalls, this was easy. We just used generic variables in our rules scripts such that the rules were the same across all the firewalls, with a separate/unique config file on each firewall that was read into the scripts (to populate the generic variables).

Is everyone just using generic Security Policies that only specify the Source/Destination Zones, the Application, and the Services? How do you push out NAT Policies that are site-specific?

I have not found any way to do this in Panorama. Any pointers to documentation on best practises for this kind of setup would be nice. Having to touch 50 separate firewalls in order to add a new Security Policy is a bit of a pain. 🙂 The few bits of documentation I've found just show how to add policies into Panorama, without listing any best practises or examples.

Re: Panorama: how to manage Security/NAT policies

Raido_Rattameister — Sat, 20 May 2017 00:05:56 GMT

You can nest device groups.

First you create Address object into parent device group.

Then into every firewall device group with correct ip.

Create rule in parent device group using address object.

You can move around in hierarcy and verify that child device group is using IP from child device group.

And if you push policy into firewall then it uses correct IP.

Re: Panorama: how to manage Security/NAT policies

fjwcash — Tue, 30 May 2017 18:29:59 GMT

Hrm, interesting. I'll have to play around with that a bit.

Thanks for the tip.

Cheers,

Freddie

Re: Panorama: how to manage Security/NAT policies

fjwcash — Tue, 30 May 2017 21:01:25 GMT

Okay, so would create a parent Device Group that will hold all of the Security Policies and NAT Policies, and whatnot, using generic Address Object names for things. Use a generic, non-routable IP for the value of the Address Objects. There wouldn't be any firewalls associated with this Device Group.

Then create separate Device Groups for each firewall, nesting them all underneath the parent DG. Recreate each of the Address Objects from the parent DG, assigning the correct IPs for that firewall into the AOs.

Did a couple of test rules using the above, and it appears to work. Will need to play with this some, as this would also require having all the Zone configuration and whatnot configured in the Templates.

Re: Panorama: how to manage Security/NAT policies

Sec101 — Tue, 18 Dec 2018 15:59:21 GMT

are you talking about "overriding" that address object in the lower device groups, or actually creating another object?

Re: Panorama: how to manage Security/NAT policies

Carlos-Jimenez — Thu, 28 Nov 2024 17:54:15 GMT

I think this solution works only if you are using an object for the NAT rule, but if you are using PAT (Translate using the IP address of the untrust interface), I see we cant add an object for that, I only accepts a hardcoded IP address, so we cant use the object overriding unfortuntely.

If we try to commit a NAT rule (PAT) that is referencing an IP address of the untrust interface, but that ip address does not exist on the firewall, it will fail the commit.

Still trying to find a solution to this an avoid having NAT rules on 2 separate child Device groups (one for each firewall) while the Firewall Policies and SSL decryption policies on the Parent Device group.

Re: Panorama: how to manage Security/NAT policies

Carlos-Jimenez — Thu, 28 Nov 2024 20:30:35 GMT

Solved based on the provided solution 🙂

The way the firewall was configured was to use the IP address of the Interface., In the example below the interface IP was set to 1.1.1.1/32.

So if we just change the way the NAT was configured, to use an object instead of the IP address of the interface, and for the object we use the exact same IP address of the interface, then NAT still works, and this allows us to do the object overriding on the child Device groups for 2 Different Firewalls that are sharing the same NAT policies from a Parent Device group.