Panorama Firewall Rules

[Yaima President]

Ihad a very strange behavior recently on panorama. Disabled rules don't go to firewalls when a push is performed from Panorama, but I had a disabled rule on panorama which got pushed to firewalls. Please find below events in the order they appeared.

1. I had disabled a Security Rule and 2 PBF rules on Panorama and pushed the config to firewalls. It was pushed successfully, and I couldn't see disabled rules on the local firewall, which is expected behavior.

3. When I checked the local firewall after the last push, I found that along with the new rule, the disabled rule and 2 PBFs were also pushed, but when I checked back on Panorama, they were still showing disabled and there were no pending changes to commit.

My question would be if Panorama is unavailable and we need to apply a new local rule on a firewall(to block something), how can we create this new local rule and move it above the Panorama managed Pre-Rules? Correct me I am wrong, but any new local rules will be applied below all Pre-Rules and above the Post-Rules.

good point... I would imagine you would need to go device\setup\panarama settings and disable policy and objects, you will get the option to copy the policies to the local device, then add the required policy and when up and running stick it back on paranormal.

Of course there's the nuclear option where you sever completely from Panorama and import all of the objects/policies into the local configuration - but that will likely cause quite a bit of work to put it back under the control of Panorama.

There isn't really a good way of gathering the post- pre- and running-config, as you are trully looking for the mergesp.xml file. The only way that I know of to actually get this is by pulling the tech-support file.

I once wrote a powershell script that downloaded the security policies from a firewall using the API and created a CSV of the ruleset - I do not have it available to me at this time, but it didn't take terribly long to do. powershell parses the XML into a collection of collections that makes it "easy" to iterate through the ruleset and pull the properties you are interested in.

Regarding missing rules, when you pull the configuration from panorama - remember there are pre-rules and post-rules, and they can come from multiple levels before being pushed to the firewall. the easiest way to get the entire ruleset is to obtain the ruleset directly from the firewall. That being said, I believe I have seen the entire pre- or post- ruleset when I obtained teh configuration via, with the location listed for each rule.

I use powershell as an example simply because it is what I know, If you have someone in your organization with other scripting or programming experience, they would likely be able to come up with something to parse XML into a CSV.

once you have your XML as a variable (let's say $config) powershell represents xml as a collection of collections, so each "branch" in the XML is a property of it's parent, so for isntance $config.vsys.entry[0].ruleset.security.entry[1].name is the name of the second (computers count from 0) security policy in the ruleset of your first vsys (even in a single vsys firewall the vsys branch exists) $config.vsys.entry[0].ruleset.security.entry[1].action would be it's action (allow, deny, etc) $config.vsys.entry[0].ruleset.security.entry[100].name would be the 101st rule's name, etc

We have quite a few Palo Altos that we inherited that have many local policies. We would like to manage these policies via Panorama. Is it possible to convert Local Security Policies to Panorama Policies using Expedition? If so is there a guide on how to do that?

I think what I would do, honestly, is go get the "set" commands from the local firewalls that consitute their firewall policies, and then do some clever find/replace, and put those rules into Panorama as Pre-Rules via Panorama's CLI. You'd have to do things like set device groups, etc in the text you would paste into Panorama's cli, etc. Without seeing it in total, its hard to say, but on the surface, that sounds like the direction I would go.

In such as situation, I would do an import of the local firewall config into Panorama via the function "Import device configuration to Panorama" , which will import the devices config into Panorama as a device group and template. Expedition doesn't really gain you anything that I am aware.

Tim Thank you for responding. The firewalls in question are already in Panorama and currently use a combination of Panorama pre/post rules as well as local rules. Are you saying that it is possible to import a firewall configuration into Panorama that is already in Panorama? We tried removing the firewalls from Panorama in order to then import them but ran into a situation where we cannot automatically remove any firewalls from Panorama because the device serial #'s stick in the Panorama firewall rules. We would then have to go to each rule and remove the firewalls serial individually and there are 1000's of rules and close to 50 firewalls.

Thank you Tim for your advice. I agree with you that this may be best to attack from the CLI and possibly using the "load config partial" commands. Looking at the policies on one of my 5000 units I see close to 700 local policies and am wondering how the address objects will play a role in the load config partial functionality. I appreciate your help again.

Go to the firewall panorama setting and disable device group and template settings. When you doing that it will popup window to tick import panorama objects and policies. Enable that tick and commit then all the panorama objects and policies will be available on the local firewall. After get a backup from firewall and import it to the panorama and do the force commit ( When importing config to panorama it will create default name for the device group and template you can change it ).

I have question. I inherited a few firewalls that are partially managed by Panorama, meaning I have objects and other items pushed to the firewall from Panorama but mostly everything else is local. On the local firewall, contains all firewall rules, zones, interfaces are configured with ip addresses. The other firewalls are fully managed by Panorama. Not ideal but the real problem is I cannot create shared security rules in Panorama for all my firewalls since no zones exist for these few firewalls.

If you have a zone configured on panorama and on the firewall node, then the one on the firewall will take precedence. Once you are sure the zone configurations are equal on panorama and the firewall node, then you can remove the config from the firewall itself.

@JoergSchuetter I do not yet have a zone configured for these particular firewalls in Panorama. I wasn't sure if the commit would fail or if it would cause other issues. Based on your response, it sounds like it would push to the firewall successfully but would be overridden by local config (which is fine). Right now, I'm more concerned with having the ability to create shared security policy rules across all firewalls, so that they are consistent. I believe this will solve that issue

I'm trying to do some auditing of firewall policies. The organization that I'm working with is wanting an automated way to identify rules that have been disabled for 6 months so they can go in and delete them. The thought I had was to look at the modified date and disabled status to identify the rules - I have seen suggestions about adding this data into the description or a tag, but I'm wanting to make this as light of a lift on the org as possible.

I do not see the ability to look at that data with a custom report - because it is only intended to parse through logs not configs. I have parsed through the Security Post rules section in the api for other auditing and I don't see the Modified date in the XML output. Nor do I see the ability to hit the policy optimizer via the API. Since I want to automatically notify them on a schedule to these issues the API has been where I have historically gone to conduct audits.

In a scenario with many groups of firewall's centrally managed by Panorama.

The Panorama is running in a appliance without HA.

What we should do when Panorama is outage by a problem and we have to do any change in the Firewall Policies?

Best Regards,

Marcelo Castro

2.) only create "post rules" within Panorama. Then, if Panorama is out of service, you can always connect directly to the firewall and make emergency changes that will override any of the Panorama-pushed post-rules.

If you are comfortable with working with the XML config directly converting your pre-rules to post-rules would be as simple as copy and pasting them into the proper areas. That would be my recommended way of doing this.

Once this is done it can be a pain to pull back into Panorama, we have had to do this for a site we were bringing online once and also when a site was no longer able to connect due to ISP changes. Both times there were unique challenges bringing it back into Panorama.

I would like to know if there is a method to delete multiple rules associated to a single ip address from panorama ?? That single ip is permitted on several firewalls for communication and the server holding that ip was decommissioned and so the rules relating to it need to be cleaned up from all the existing firewalls.

I am able to get bulk list of firewall rules from Global search from panorama, but removing that particular ip from each of the listed firewall rules by looking int to each rule seems to be painful task, hence checking if there is any shortcut way to get this done faster .

3a8082e126