Episode Transcript:
Hello PANCasters. Today we are going to talk about migrating to Palo Alto Networks firewalls. This is when you have an existing environment with another firewall in place and are migrating over to a Palo Alto Networks firewall. There are a few things to be aware of that can help you make sure the migration goes as smoothly as possible.
To start with, some of the things we will discuss are just things that can happen with any migration or even just replacing a physical device but, more importantly, we will also go through some of the gotchas which are more to do with understanding that vendors do things differently and what you should be aware of with Palo Alto Networks firewalls.
John Arena is a Professional Services Consultant with a background in Technical Support for Palo Alto Networks and a passion for educating and sharing knowledge with customers.
The first thing I want to talk about is Network Address Translation or NAT for short. What NAT gives you is generally the same across vendors but how it is configured and what it actually does at a lower level can vary between vendor implementations. There’s no right or wrong way as NAT will be tied to the way packets are processed on different devices but you just need to be aware that how it is configured on your existing firewall may not be the best way to do it on a Palo Alto Networks firewall. So what are some of the things to note?
So, let’s discuss bi-directional NAT policies — that is both source and destination NAT are applied on the same policy. This is common where you may be hosting a server which is accessible from the Internet but it also needs NAT to be able to initiate connections to the Internet for things like updates. In this case, it may be worth splitting these into their own separate source NAT and destination NAT policy. Without getting into too much technical detail, the way a bidirectional NAT policy works is different to having two individual NAT policies for source and destination NAT and in some scenarios, bidirectional NAT will not work properly.
The second thing to be aware of is the way NAT and security policies work for destination NAT, specifically with zones and IP addresses.
For the NAT policy, the destination IP refers to the original IP (so the pre-NAT IP address) and the zone is based on a route lookup of the same pre-NAT IP.
For the security policy, the destination IP is the same as in the NAT policy, being the original or pre-NAT IP address, however the zone will be based on the route lookup for the post-NAT IP address.
Don’t worry, you don’t need to memorize this as we will have this documented but just remember there are some specific requirements on configuring NAT and security policies on Palo Alto Networks firewalls which may be different to what you are used to.
Let’s move on to number two.
I have discussed this in a previous episode which looked at security policies and this is a key thing to note if you are just starting out with Palo Alto Networks firewalls. There are two default policies at the end of your security policy including the interzone default rule which denies traffic between zones. These rules do NOT have logging enabled by default. So you’ve migrated to the firewall, you have added all your policies to allow traffic but a lot of things are not working and the strange thing is you are not seeing any denied traffic in the logs. This could be why. You can either add a deny catch all at the bottom with logging enabled or else you can override the default rules to enable logging on these.
OK, onto number three. As a general summary, you need to be aware that UDP sessions can become stale when routing changes occur and this can often be seen when doing migration. Let’s look at the reasons, how to find it and how to fix it.
So like most firewalls, Palo Alto Networks firewalls are session based which means when a session is built, it is based on certain information including things like protocol, ports and of course zones. What can happen with a UDP session is that if there is a routing change, the destination zone may change however the session still has the old zone listed. In this case the traffic is not forwarded because the zones don’t match. Normally this is not much of an issue as the session should time out; a new session comes in and gets built with the new correct zones based on the new routing. The problem is when traffic constantly comes in, as is the case with UDP which is connectionless, the session never times out. I have personally seen this with both DHCP and VOIP traffic where the session never times out. This doesn’t affect TCP as it is connection oriented so the session will ultimately time out when no response is received and a new session is then established.
There is no quick way to find out if this is happening — but if you are aware of the details, that is UDP sessions not working and routing has changed, then you can look at the specific session on the firewall and check the destination zone is what you expect and that it also matches the expected route.
The fix is simply to clear those stale sessions. Depending on what is impacted you can clear individual sessions, or all sessions to a particular destination (like a DHCP server) or all sessions of a particular application (like sip).
This particular issue can be seen at other times as well but it’s something to note for migrations given there is the potential for routing changes during the migration window.
And the final one. This is probably relevant to any device migration, not just moving to a Palo Alto Networks firewall. There are obviously external devices which connect to a new firewall. Any physical changes can sometimes need some manual intervention, for example maybe ARPs need to be cleared if IP addressing is being re-used. There could also be changes required on the upstream and downstream devices, for example static routes may need updating.
If it is a new type of setup then there also may be some pretty significant changes like adding trunk ports to the firewall and potentially a vlan has been missed. Really the point of this is to just make you think that although the new firewall obviously is the biggest change to your environment, there are external factors to consider as well. That’s not to say don’t look at the firewall, obviously it is the place to start but if you cannot find any issues on the firewall, maybe don’t discount it could be something external.
Now I have a couple of things before we wrap up. Firstly, we have a tool called Expedition which has been designed to help in migrating configs from other vendors to Palo Alto Networks. If you currently have a large number of security policies, manually trying to migrate them is not only time consuming but prone to error so Expedition can really help out. Just search for Palo Alto Networks Expedition to get more information on the tool. And if you feel you need further expertise for planning or doing the migration, our Professional Services team may be able to help with various consulting options to help ensure the migration is successful.
So there we have it and these are the four things I think are important to know when you are planning a migration to a Palo Alto Networks firewall.
Thanks for listening and as always, don’t forget to head to live.paloaltonetworks.com where you can not only find the transcript for this episode under the PANCast section but a whole lot of other useful information.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
