Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Migration for Cisco ASA to PAN: Security rules based on DNAT

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Migration for Cisco ASA to PAN: Security rules based on DNAT

L1 Bithead

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

4 REPLIES 4

L6 Presenter

@Tim_Adelmann what version of expedition are you using?  If you have a destination NAT rule, expedition reads the NAT rule and create a matching security rules tag with "DNAT" , the destination address is auto corrected by expedition , in your case , the destination in security policy should be auto corrected as pre-nat IP .  For the security policy that has destination IP with post-nat IP, that could be you have a security policy in asa config and expedition just migrated it as is.  In the "Monitor" -"Migration Log", you can review changes expedition done.  Also in the NAT rule , there is a matching security rule and warning tab , you can see more details message. 

@lychiang I am using Expedition 1.2.40.

Unfortunately the security rules with "DNAT" tag do not match the NAT policy.

The NAT policy has source "any" but the auto-created security policies are using sources from other security policies that are existing in the ruleset and not related to the NAT policy.

Hi @Tim_Adelmann we will need the original Cisco ASA config for reviewing the issues, can you please write email to fwmigrate@paloaltonetworks.com . Thank you 

Hi @lychiang, I will check with my customer, if I am okay to share the ASA config with you.

  • 1943 Views
  • 4 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!