Dziś krótko, o migracji Cisco ASA do Palo Alto z użyciem narzędzia se stajni Palo – Expedition [migration tool].
Od razu co cię nie zapewne nie uda automatycznie –
- Zony – prawdopodobnie wszystkie interfacey będą przy migracji w osobnych strefach więc może ich być zdecydowanie za dużo – stąd ręczna robota – konsolidacja stref i wszystkie zależności – security, naty.. Ja tutaj dodatkowo z cli zmieniałem nazwy wszystkim strefom dodając ‚-zone’ na końcu. Polecam Notepad++ i ręczną automatyzację. rename zone … to …
- NAT’y – o ile source naty przejdą pewnie poprawnie o tyle destination, ze względu na specyfikę Palo Alto będą wszystkie do poprawki, wiadomo obie zony zewnętrzne na zewn. IP i translacja do środka. Komplementarnie trzeba wszystkie polityki security poprawić – zony WAN do LAN, z zewn IP 🙂 Dodatkowo ważne aby zwrócić uwagę na kolejność reguł NAT !
- Obiekty – pewnie będzie tutaj zabawa bo serwisów będzie mnóstwo zaciągniętych z ASY. Co więcej może wystąpić sytuacja gdzie nie był wskazany typ UDP czy TCP – do poprawki w Expedition na etapie migracji. Mogą się pojawić sytuacje gdzie dany serwis będzie źle zampowany do portu np ‚domain’ mi zamapowało do portu 6500 🙂
- Duplikaty nazw – pewnie będzie tego sporo, na Palo sprawdzana jest unikalnosć nazw wielu obiektów.
- Interface’y – na etapie migracji w Expedition dobrze od razu zmienić. Warto pamiętać aby wrzucić ‚czysty’ konfig z Palo aby potem nie było duplikatów.
Co da się automatem ?
- obiekty
- reguły security [weryfikacja i poprawki]
- naty j.w
- interface’y
- tunele ipsec s2s
Do uzupełnienia miałem tagi, które pojawiały się w expedition ale nie aplikowały się do polityk. Zrobiłem ręcznie przez CLI z udziałem excel i notepad++
Finalnie dostajemy spory bałagan – za dużo stref, za dużo obiektów, brak reguł aplikacyjnych, duplikaty. Przy mniejszych migracjach na pewno warto rozważyć migrację ręczną bez użycia Expedition tylko wyklikanie wszystkiego ‚ręcznie’
Na koniec – samo przepięcie, jak w każdym przypadku przy zmianie urządzenia stojącego na brzegu i mającego po drugiej stronie sprzęt nad którym nie mamy kontroli, warto zapewnić sobie na czas przepięcia udział administratorów providera aby mogli poczyścić tablice arp i ewentualne statyczne przypisania mac i/lub port security.
Ze swojej strony na palo oczywiście dobrze jest pamiętać o odpowiednio długim oknie serwisowym [w 5 min raczej to nie zadziała] oraz o kilku fajnych poleceniach jak:
- test arp [wysyłanie GARP z palo aby inne urządzenia odświeżyły wpisy]
- test vpn [aby zainicjować tunele IPSEC]
Tyle na szybko 🙂