About 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". ... View more

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. ... View more

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. ... View more

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. ... View more

I do have a feature request in queue to allow for the selection of fields that get logged, but not adjustment of the size itself.  The ability to remove the unnecessary fields would easily fulfill my need for smaller files since about 1/3 - 1/2 of the data is not used in my case. On Bluecoat reporter, yes, it sucked!  I was referring to the ProxySG's themselves, they had a feature to adjust the size and interval of sending a log file.  When they sent the file, the previous was removed so there was never a case where it would re-send the same log data, which from Palo Alto's reponse above is how there device would act if you were to send logs multiple times per day. On the Panorama note, I'm on a recent implementation of it, the 4.1.1 release and 4.1.1 on my 2050s and it does seem to be much better now in reporting.  Though, it is lacking still one major need.  There does not appear to be a way to generate reports on ranges of IP addresses (so for example, all of a given server farm in a datacenter).  I've found a manual workaround though -- I created a new rule on my 2050s that explicitly match that server farm range with only the action of logging in place, no URL/etc applied. I placed that just before the final "allow any any" rule (we use our 2050s just for web filtering, there's separate firewalls between them and our Internet edge).  This seems to solve that issue as I am able to generate reports based on a given rule name. One note though, if you're looking to add Panorama "after the fact" -- out of the box there's no way to suck in the policy from a live PA.  It was a tedious process but I was able to do so through comparing the XML files that the device and panorama save out when doing a "save/export named configuration snapshot".  It was still a lot of work though, because you have to fully nuke/erase the PA-2050s policy (well, anything that you try to push from Panorama) to make it work.  I've succesfully done this w/ 4 x 2050s now, so it's doable if you keep at it.  It was easier though in the long run than managing 4 independant boxes (non-HA). David. ... View more

"What is dumb?"  -->  The fact that the unit creates such a massive CSV file, with no way to tune that file in terms of either size or what fields are stored.  We have had nothing but issues with our third-party log management product (which is in no way Palo's fault), but as a result, I've attempted a number of times to generate simple reports from the raw CSV files and it just can't be done when the file reaches such a massive size.  As an example, try opening a 2GB CSV file in Excel.  Excel will choke badly on that.  I wouldn't every suggest doing that, but there may be cases where it's needed, like us, where we're in transition from a 3rd party tool to Panorama for log management/reporting. Palo is a great product, but at times I feel as though the marketing got in the way.  Small features that I've come to love from my former Bluecoats are not even in the roadmap?  It boggles my mind.  Such an advanced firewall on some pieces, such limited options on others. David. ... View more

This is dumb.  My log files are huge, several GB each. ... View more