Panorama Out Of Sync

[xcz504d1114]

I just installed Panorama to my existing deployment, the firewalls are connected to Panorama, but the shared policy is out of sync. How do I get Panorama to house the current configuration on the firewalls? Currently with no configuration on the Panorama, I assume pushing commit will wipe my firewalls, that is obviously not feasible.

Thanks,

Craig

[rmonvon]

Hi...You will need to define the policies/rules in Panorama and the shared policies/rules can be pushed down onto the PA device(s).  The shared policies/rules can be pre- or post- and these will be merged with the existing rules on the PA device(s).  The existing policies/rules on the PA devices will not be erased when you push addt'l rules from Panorama.

Thanks.

[jhansf5]

To echo rmonvon's comment... you can safely commit the shared config.  So long as you have not created any conflicting pre-rules in a firewall's device group, it will not break your existing policies.  To my knowledge, the only way to get the local device policy and objects into Panorama is by manually creating it.

That said, you might look at using pre and post rules to make things more maintainable in your environment...

We have firewall pairs at each of our remote offices that are managed by Panorama.  I used the same zone names at each site (in fact the firewalls were all configured according to a very specific config standard).  My rules for Internet access, MPLS, and local DMZs are all in the 'pre' and 'post' section of the rulebase.  These rules use the same security profiles enterprise wide - when I need to tune out a false positive, enable a signature, etc, I can change the profile in Panorama and do a global push. My local rules use global objects whenever possible.

When I wanted to enable Wildfire, all I had to do was add the file blocking profile in my global rule.  In 5 minutes time, I had deployed Wildfire enterprise-wide.

When we stand up a new domain controller, I can simply add it to our 'domain controller' group object.  Syncing to managed devices means that all rules, global and local, pick up the new IP.

In our deployment, the local device policy is used only for site-specific rules.  Each site has, at most, 5 or 6 local rules.  Everything else comes from shared policy.

[daswafford]

It can be done, though Palo Alto will tell you otherwise :-).  If you're still interested, here's how I did it.

We installed 4 x PA-2050s which we duplicated all by hand (no HA pairs).  Panorma came later.  I got tired of re-doing the same stuff, it felt stupid, so I figured out a hack that works, but still involves some scheduled downtime.

First, you want to figure out which device will become your point of reference (i.e. the policy that you want Panorma to use).

Second, from that device, go to the management settings and do this sequence:

  - Save Named Configuration Snapshot

  - Export Named Conf. Snapshot

Third, the file you just saved is the device policy/configuration in raw XML format.  Keep this handy.

Fourth, Login to a freshbuild of Panorma.

Do the same, exporting it's XML snapshot.  You'll need both, as the base formatting for each are slighly differnet and some things cannot be straight cloned (device name, IP, etc)

Fifth, Go back to Panorama, and create a few dummy rules/objects (an address or two, a URL filtering "pre" rule, and a decyrption "pre" rule).  The idea here is to get an understanding of the syntax changes between PAs and Pan XMLs (I have no idea why they are different, but some were when I did this (3.1.9 - > 4.1.1)

Sixth, Re-Export the current Panorama XML file

Seventh, Compare the dummy Panoarma rules/objects to the existing PA device's XML.  Note syntax changes.  Now delete the dummy rules/objects.

Eight, start copying a few small sections from the device XML to the Panorma XML file's "pre-rules" section (for example, just the "addresses" section).  We are doing small chunks because the process breaks easily -- if you do to much, you won't know what broke the import.

Ninth, Upload the revised Panorma XML file to the Panorama box.

  - Import Named Conf. Snapshot

  - Load Named Conf Snapshot

Repeat forever until done! :-), Yes, it is tedius, I spaced this out over 2-3 days to make it a little easier to digest haha!

EDIT -- LOL!  I just realized that I described the process to IMPORT the policy  to Panorma, but not how to finish and tie it to the PA devices.

To fully manage your devices using Panorama's policy, you will end up needing to schedule downtime for each unit (one at a time).  Basically it boils down to this, you have to nearly nuke the PA firewall, earasing all items that appear in Panoarma's policy (it won't overwrite an existing rule/object, instead it will fail when you push it).

So in my case, it involved deleting all objects, addesses, profiles, and rules.  A quick way of that is also by manipulation of the device XML file.  It WILL kill all traffic going through the device.  Then, link the device to Panorama and push the new policy from Panorama down.

DO A BACKUP BEFORE NUKING YOUR CONFIG!!!!  :smileylaugh: I shouldn't have to say that but you know, someone will forget haha!

It will eventually work, just don't rush the rule moves or you will spend more time re-doing it/troubleshooting what didnt take.  I know have a Panorama 4.1.1 box managing 4 x 2050s on 4.1.1, works like a charm now!

David.

ps. I know, it's an old post that I'm replying to, but PA's support will just flat out say "it can't be done"... not a great answer, when this type of logic [the import process] could easily be built into Panorama.  The export could be done in real-time if the PA allowed the overwriting of existing rules/objects.

[xcz504d1114]

I'm glad you replied! I was actually working on doing that exact procedure, but hadn't had time to try and test it, but I'm glad to hear that it does work! And thanks for the tip on taking it bit by bit as opposed to the full push at once.

Just out of curiousity, what causes the downtime? I might have misunderstood, but exporting from the device, then importing to Panorama with overlapping rules doesn't seem like it would create an outage.

Thanks,

Craig

[daswafford]

One more note of context...

I'm in a critical 24x7 environment, so if you're careful and the existing design is flexible, the downtime should be minimal.

In my case, our PA's were in-line physically to upstream edge firewalls.  We did a failover to the upstream firewalls to shift traffic from one PA to another.  I nuked the "standby" PA, got it in sync, then failed the firewalls back.  Now things could go bad (if they do, do another fail-over), otherwise move to the next PA.   This only works if you're layered though, and also not in HA on the PA side.  Our PAs are just doing web filtering, so we have them set-up this way to reduce the risk of impact.

[daswafford]

Hey Craig,

I didn't want to manage rules in both places just on the Panorama side (all of our devices are identical -- we just use them for web filtering). So I had to nuke all existing rules and objects on the PA-2050s prior to pushing config from Panorma to them.  (If an existing address, object, rule, etc, exists that is identical, the push will fail).

David.

[xcz504d1114]

That's what I was afraid of, failing the push due to overlapping. Thanks David!

[daswafford]

One more note -- I "bug" I think, on my install of Panorama, it was defaulting to a different URL database, so the category names available from it DID NOT match the PA devices.  Thgouh a support case, I found that you need to manually set it to use "Brightcloud", what the PAs use.  I don't recall the full command but it was something like "set system urldatabase brightcloud".  I think you'll find a setting under the XML relating to that, I think the defautl was "surfcontroL".

[xcz504d1114]

Good to know! That would definitely cause a bit of a migration issue!

Thanks again David,

Craig

[mikand]

Hopefully someone form PA see these instructions and can push them into Panorama so Panorama will just "Do you wish to import the configuration from device 1.2.3.4?" 🙂

[xcz504d1114]

I agree! A 'merge' configuration and a 'import and replace' configuration option would be nice, without it, it really makes a later purchase of Panorama a tedious and risky task; both from a security perspective of mis-configuration potential since you don't see what's already configured on the PAN firewall, and from an outage perspective because in order to do this, I have to break my HA pair, wipe one, and rebuild it through PAN.

[rmonvon]

A feature request has been submitted for the import of device config into Panorama.  I encourage you to contact your Palo Alto account team and add your name to the FR. Thanks.