About Tim_Adelmann

Hey everyone, I am currently trying to migrate a configuration of a Cisco ASA to PAN using Expedition.   Unfortunately, the tool is not properly migrating the NAT and corresponding security rules.   One example: We have a NAT rule that translates the public IP (1.2.3.4) to the private IP (10.1.1.1). In ASA the security policies are using the post-NAT IPs so the security policy says (Untrust Any -> DMZ 10.1.1.1 allow). To achieve the same in PAN ruleset the pre-NAT IP should be used (Untrust Any -> DMZ 1.2.3.4 allow), which does not happen in Expedition. It creates on security rule similar to the ASA rule with the post-NAT IP. And, even stranger, it creates additional security rules with name prefix "DNAT", the pre-NAT IP as Destination but with Source-IPs that are not related to this traffic at all.   In the example above, the ASA has the "Untrust Any -> DMZ 10.1.1.1 allow" rule. Expedition creates: 1. Name: abc123 -> Untrust Any -> DMZ 10.1.1.1 allow 2. Name: DNATxzy123 -> VPN 10.5.0.0/24 -> DMZ 1.2.3.4 allow 3. Name: DNATdef567 -> DMZ2 10.2.0.0/24 -> DMZ 1.2.3.4 allow and some more rules like that.   To me it looks like Expedition takes the NAT rule from ASA and creates "DNAT"-security rules based on all the ASA security rules that could potentially match for the post-NAT IP. But this is really not helpful.   And the worst part of it: The rule that is really needed to allow the traffic (Untrust Any -> DMZ 1.2.3.4 allow) is not created by Expedition.   What am I doing wrong here?   Thanks, Tim ... View more

Hey everyone, I am currently trying to migrate a configuration of a Cisco ASA to PAN using Expedition. Unfortunately the customer is not only using the "normal" inbound rules on ASA but also outbound rules.   ASA rule processing is a bit different from PAN: Packet arrives from source (maybe 10.1.1.1) on interface 1/1 -> Packet is send through inbound rules of ingress interface -> Routing etc. -> Packet is send through outbound rules of egress interface -> Packet is send to the destination (maybe 10.2.2.2) on interface 1/2.   It could be that there is a inbound rule on interface 1/1 like that: Source 10.1.1.1 Destination any Service any Action allow   On interface 1/2 there could be an outbound rule like: Source 10.1.1.1 Destination 10.2.2.2 Service tcp-22 Action allow   And sometimes it is the other way around (inbound rule more specific than outbound rule). In some rare cases there are exact matches (same rule on one interface inbound and another one outbound).   Expedition handles all inbound and outbound rules as security policies and writes them all into the PAN ruleset in a top-down-way. This results in a ruleset that is different from the one on the ASA.   In the example above, if the inbound rule is matched first, the destination 10.1.1.1 would be allowed to communicate everywhere on the PAN. But on the ASA the traffic would go the outbound rules later on and would eventually be blocked based on that.   Is there any way in Expedition to match the incoming and outgoing rules together in order to create rules for the PAN that would result in the same security level like the ASA ruleset with both type of rules?   Any hint is highly appreciated.   Thanks, Tim ... View more