Fuel Voices: ASA to PAN Migration — A Real World Example

Posted by Ian P Johnston on Feb 9, 2017 9:30:00 AM


Fuel_ASA to PAN_Johnston.pngFuel Member Ian P Johnston, a security engineer and analyst, outlines his real-world experience migrating from ASA to PAN Firewalls, and the importance of adjusting his policies to a more consistent, named zone structure.

Introduction

I work for a large, global corporation, as I’m sure many of you do, too. The corporation’s global network was not planned, as a whole, from Day 1, but the networks of several divisions, takeovers and mergers which have made it what it is over recent years. The corporation’s Data Centers (DCs), particularly their boundary firewall protection from the internet, are the subject of this brief article on a real-world ASA to PAN Firewall Migration.

The Initial Situation

The corporation had three Internet Access Points (IAPs) and one Disaster Recovery (DR), site. The Americas’ IAP and DR site are in North America; the European IAP is in London; and the Asian IAP is in Singapore. These IAPs were “protected” by Cisco ASA firewalls, Bluecoat proxies, and HP Tipping Points. The plan was to move to Palo Alto Networks NGFWs and replace all of these devices. However, the DCs did not have a consistent configuration: The number and names of the DMZs differed, as did their VLAN numbers, methods of connection, and capacity. My aim was to move to a single, global standard using PAN NGFWs.

An example of the relevant sections of an ASA configuration for such an IAP firewall is shown below:

interface GigabitEthernet0/0

  description Outside Interface

  nameif outside

  ip address 192.168.1.7 255.255.255.0

!

interface GigabitEthernet0/1

  description *** Citrix DMZ ***

  no nameif

!

interface GigabitEthernet0/1.901

  description *** Citrix Prod-DMZ ***

  vlan 605

  nameif CitrixProd

  ip address 192.168.241.65 255.255.255.224

!

interface GigabitEthernet0/1.903

 description *** Citrix Dev-DMZ ***

 vlan 606

 nameif CitrixDev

 ip address 192.168.241.97 255.255.255.224

!

interface GigabitEthernet0/2

 description Outside Interface

 nameif outside

 ip address 10.10.10.1 255.255.255.0

interface Port-channel2

  port-channel load-balance src-dst-ip-port

  no nameif

!

interface Port-channel2.911

  description ** web servers **

  vlan 886

  nameif DMZ1

  ip address 192.168.109.1 255.255.255.0

!

interface Port-channel2.912

  description ** SQL servers **

  vlan 887

  nameif DMZ2

  ip address 10.70.248.1 255.255.255.0

!

interface Port-channel2.913

  description ** dual homed servers **

  vlan 888

  nameif DMZ3

  ip address 10.70.249.1 255.255.255.0


An 802.1Q trunk carries several VLANs, identified by their VLAN number; the matching interfaces on the ASA firewalls were also identified by these VLAN numbers (see the table above for examples). The VLAN numbers obviously differed between the DCs, as did the ways in which the DMZs connected to the firewalls:
  • Two were 802.1Q trunks over Cisco Port Channels (LACP Ethernet trunks ) to an L2 distribution switch;
  • One was a gigabit Ethernet link to an L2 access switch for each DMZ;
  • One was an 802.1Q trunk over a gigabit link to an L2 distribution switch for the DMZs.
This is shown in the network drawing below, though the drawing is simplified to a great degree. First, all of the equipment is in HA pairs; second, clouds are only shown for the DMZs, not the L2 access switches; and third, the names are simplified.

The Proposed Solution

The way that PAN NGFWs handle 802.1Q trunks is slightly different than Cisco. They are more like sub-interfaces. Each sub-interface is associated with a VLAN tag, so why not have sub-interfaces 1 through 4, associated with DMZs 1 through 4, at each global IAP?

The relevant VLAN tag for each DMZ can then be associated with the relevant sub-interface at that IAP, and the ASA “name” can be written in to the description. Don’t forget to include the device and port to which the interface is connected.Fuel_ASA to PAN_Johnston Callout

PAN NGFWs implement security through zones, rather than using access-lists applied to interfaces through access-groups as used by Cisco. An important design point for my global security solution is, therefore, the zone names.

My naming convention for all things Panorama is to prefix them with a “P,” for Panorama, and a few initials to specify where that configuration is found. For example, my addresses and address groups, services and service groups, are P-A-<name>, P-AG-<name>, P-S-[tcp udp]-<port>, and P-SG-<name> respectively; <name> and <port> are replaced by a descriptive name and/or IP address, and <port> is replaced by port. The zone names that I use are:

P-Z-inside       P-Z-outside     P-Z-dmz1        P-Z-dmz2        P-Z-dmz3        P-Z-dmz4

After using the PAN Migration Tool (PAN-MT) a few times in the lab, it became obvious that it translates the Cisco ASA nameif value into the related zone name. It also has a manual step to “translate” the ASA physical interface in to a PAN physical interface (e.g., interface GigabitEthernet0/0 in to ethernet1/1). I realized that by editing my saved copy of the ASA configuration file, I could edit the nameif and interface values to give me the values I wanted in my PAN-MT output.

The table from above, but edited to give the values I want as input to the PAN-MT:

interface ethernet1/1

 description connected to switch123:1/7

 nameif P-Z-L3-outside

 ip address 192.168.1.7 255.255.255.0

!

interface ethernet1/21

 description DMZ trunk, to switch789:1/1

 no nameif

!

interface ethernet1/21.1

 description ** Citrix Prod-DMZ **

 tag 901

 nameif P-Z-L3-dmz1

 ip address 192.168.241.65 255.255.255.224

!

interface ethernet1/21.2

 description ** Citrix Dev-DMZ **

 tag 902

 nameif P-Z-L3-dmz2

 ip address 192.168.241.97 255.255.255.224

!

interface ethernet1/24

 description connected to switchabc:1/1

 nameif P-Z-L3-inside

 ip address 10.10.10.1 255.255.255.0

! interface Port-channel2

! the port-channel is combined with the other DMZs

! in the ethernet1/21 ten Gig interface on the PA-5060

!

interface ethernet1/21.3

 description ** web servers **

 tag 911

 nameif DMZ1

 ip address 192.168.109.1 255.255.255.0

!

interface ethernet1/21.4

 description ** SQL servers **

 tag 912

 nameif DMZ2

 ip address 10.70.248.1 255.255.255.0

!

interface ethernet1/21.5

 description ** dual homed servers **

 tag 913

 nameif DMZ3

 ip address 10.70.249.1 255.255.255.0


The number of DMZs doesn’t line up with the drawing, but you get the idea. We tried to use an LACP trunk for the outside interface, but there was an issue in PAN OS 7.0.6 that prevents the members of the trunk on the backup firewall showing as up. (Note: PAN OS 7.1 introduced LACP pre-negotiation on the Passive device.)

We upgraded the inside and DMZ interfaces to 10G from the various gig interfaces and port-channels that they were on the ASAs. To keep things “standard,” we configured all DMZ trunks with six sub-interfaces/VLANs; when there were less than this (e.g., APAC), we used dummy VLAN tags on the switch’s 802.1Q trunk and firewall’s sub-interfaces.

Note that I used only the PAN-MT set style output: It’s much easier to work with than the XML. I also used a dummy PAN NGFW configuration as input to the merge stage of the PAN-MT — basically a configuration snapshot from a PA-5060 configured with Device and Network settings (i.e., interfaces, zones, virtual-router, but no IP-addresses or routes)  but no objects or policies.

The Method

The change has the following steps over a one-week period:
  • Freeze changes on the ASA firewall pair ! Day 0, a week before the migration
  • Execute the ASA to PAN migration:

    1. Complete the configuration of the NGFW’s L3 interfaces and routes
    2. Create the objects in P-DG-L3-<site>
    3. Create the rules in P-DG-L3-<site>          ! no later than COB Day 2
    4. Test by inspection. This is a lengthy process of comparing ASA ACL entries and NAT rules to their equivalents on the NGFW.       ! this will take days 3 through 6
    5. Commit to Panorama
    6. Commit to NGFWs in P-DG-L3-<site>
    7. Test by inspection             ! day 7
    8. Shutdown the switch interfaces that connect to the ASAs and bring up the switch interfaces that connect to the PANs

  • Steps 1, 2, and 3 use the set style output of the PAN-MT;
  • I configure the interface IPs, VLAN tags, and routes on the DC NGFWs, not on Panorama;
  • Step 8 is the only time that traffic to/from the Internet will be interrupted;
  • I have one device group per site in Panorama, called P-DG-L3-<site>, and they all have P-DG-internet-access-L3 as their parent.
I sorted out many issues in the test-migrations I ran:
  • I removed icmp and icmp-<whatever> from all service-groups in the ASA configuration.
  • I defined a few services to handle named, Cisco services that were not recognized (e.g., set device-group P-DG-L3-som service domain protocol udp port 53).
  • I created service-groups to handle a few other named, Cisco services.
  • The post-NAT address often uses the pre-NAT address by mistake; this had to be fixed in the post-migration, Panorama device-group configuration.
  • I never could figure out how to get the routes from the PAN-MT, so I just built a spreadsheet to do it.
  • I also used a spreadsheet to produce set lines to add “log at session end,” “log forwarding destination,” and ‘security profile group” to each and every rule.

Conclusion

I’ve now used this process many times in test and four times in production, with great success. Just realize that you’ll need to run it several times in test to get used to it and discover the quirks of your network and firewalls configurations, and it really does take days to compare all of the post-migration Palo Alto Network Security and NAT rules with their pre-migration ASA equivalents.

I hope that this has been interesting and will be a help to some of you in real life, or at least in your working life!


Corporate Global Network - pre Change

 

Corporate Global Network - post Change


Get Involved!

Interested in contributing to the Fuel for Thought blog? We are currently seeking members to join the the Editorial Subcommittee for Fuel’s Community Development Council!
Apply Today
Fuel for Thought allows us to develop and share valuable resources, stories, events and case studies to the Fuel community — and we could use your help to grow it. Whether you’re keen to weigh in on a hotly debated topic, explore the latest cybersecurity trends, or offer a fresh perspective on industry news, we’d like to hear from you!

Connect with Jaclyn Moriarty, our Editorial Coordinator, or select "Join the Community Development Council" on the volunteer interest form to apply.

 

Topics: Cybersecurity, Fuel News, Hot Topic, NGFW, ASA to PAN Migration

Posts by Topic

see all

Subscribe to Blog Updates

Recent Posts

Posts by Topic

see all