About pulukas

I've only used the Migration Tool a few times and not with Checkpoint, so I'm not sure where you would look.   But you really should post this question over in these other discussion forums.  The migration tool developers monitor that forum and respond to questions.  They are not over here on the general topics forum very often.   https://live.paloaltonetworks.com/t5/Migration-Too l-Discussions/bd-p/mt_discuss ... View more

If you are still having problems, try searching the Migration Tool Discussion forum.  Or post there as the migration tool engineers monitor that forum. https://live.paloaltonetworks.com/t5/Migration-Tool-Discussions/bd-p/mt_discuss ... View more

Also remember that this traffic will source from the mgmt interface by default. ... View more

If you have enough interfaces (or can use q-tags), you could configure the layer 3 replacement for the ASA in parrallel with your existing v-wire.  Then the PA will start by mirroring your existing setup.  Then you can slowly convert your rules to more application specific with inspections as you monitor the traffic.   You should also check out the migration tool to see how this can help you get a first pass at the conversion of your rules from ASA to PA.   https://live.paloaltonetworks.com/t5/Migration-Tool/ct-p/migration_tool ... View more

The hardware models are suppose to be the same.  But the main reason the configurations do not work is that the interface configurations are different among the various models.  In your case, the two models have the same interface setup so your configurations will match when you do the import.   If the interface layouts were different you would have to manipulate the names of the interfaces in the xml file prior to import to make the transition. ... View more

I don't have a way to test right now, but I am pretty sure you cannot load a version 5 config into a version 6 device.  There are a number of formating changes that occur during the upgrade process from 5 to 6.   If you could upgrade the existing device from 5 to 6 then you could migrate the configuration by export/import.   You can rollback the upgrade.  So if you can schedule some downtime to upgrade the existing 2050 to grab the updated configuration then rollback to keep production the same.   But if you are worried about potential issues with the upgrade,  I feel like upgrading in place on the 2050 and running for a week is your better option anyway.  This way you only change on variable at a time instead of upgrading both the OS and hardware together.  This way you can be sure of the source of any issues. ... View more

Do you have a security profile attached to the rule?   I'm wondering if that traffic may be hitting a threat id that has an action for reset both. ... View more

I think the nuance here that Palo Alto is missing and I would hope would update in PanOS, is that the inclusion of data in the syn packet during the handshake is a violation of the strict tcp syn handshake outlined in RFC 793.   https://tools.ietf.org/html/rfc793   Thus it is entirely reasonable to drop the connection at the point where the syn plus data packet is received.  And this is indeed how strict tcp syn check works on both Juniper and Checkpoint firewalls.   Hopefully, the PA team will recognize that having strict tcp syn check is a feature that should be on by default to prevent this type of invalid communication. ... View more

You can use this procedure to force an update for the url on your PA.   https://live.paloaltonetworks.com/t5/Management-Articles/Update-a-URL-to-Reflect-New-Category-in-PAN-DB/ta-p/56250   You may also want to check your cache setting to a shorter period.   Device Tab — Setup Menu — Content ID tab — URL filtering options box   http://puluka.com/home/techtalknetworking/129.html ... View more

I feel your pain.  I've done a number of conversions from local to Panorama device groups and they are not at all fun and a whole lot of work.  But in the end the effort is worth it.   Start with deciding how many groups the 60 devices can be reasonably divided into.     Collect all the common across all group settings.   Create a naming convention so that all objects will be consistently created.   Determine if all policy can be held in the group of if some local policies will be required.  And if they are needed then choose the pre or post common rule set model for the group.   I tended to create most objects as global so they could be used across the groups.   Start with a small device and make the naming convention changes and system harminizations.  Once ready I used this process to get the devices into Panorama.   I would run these procedures with a lab PA and lab Panorama until the scripts were well honed   create a rollback file for both the device an panorama before starting so there is an easy fallback point   Create the Panorama group Export the local configuration and create backup snapshots Import the local configuration as a file to panorama.  This will just be used as a source to import objects to global. Use load config partial [filename] to pull objects from this file into the shared objects in Panorama object order: tags addresses address groups services service groups custom applications profiles profile groups Security policies nat policies application override policies   delete all the local cofiguration objects but do not commit Add the device to panorama commit and override from panorama   Schedule the migrations. ... View more

'received local id is X.X.X.X'    I believe this is telling you that the Cisco is sending the proxy-id with your public ip address.  You will need to check the configuration on that side to remove this setting and put in the ACL on the Cisco tunnel that you need. ... View more

There is a forum specifically for the Migration tool that is monitored by the developers.  You will likely have quicker and more direct responses there.   https://live.paloaltonetworks.com/t5/Migration-Tool-Discussions/bd-p/mt_discuss ... View more

You will both have to choose a subnet to NAT the other company network to and apply a NAT rule on your tunnel traffic.   This document outlines the procedures for the process.   https://live.paloaltonetworks.com/t5/Documentation-Articles/Configuring-route-based-IPSec-with-overlapping-networks/ta-p/53337 ... View more

This is a nice work around but this is not a hit counter and not a CLI option as requested.   This custom report is looking a logged sessions over the report time period and further reporting by your filter choices.   The desired function is a BY RULE hit counter.  Traffic hits the rule a counter is incremented and this continues until the cournter is reset manually or the firewall rebooted.   We typically use this during active live troubleshooting sessions to reset the counter and confirm traffic generated is live hitting the expected rule.  Or to reset the counters after we think no more traffic should hit a rule and turn at a later time and confirm there is no increment of the counter.   The function is not yet implemented in PAN. ... View more