Introduction
This is quite a complex topic and can still be a tricky one to get right but I have developed a proven methodology that can be used very successfully.
I have now used this methodology multiple times to transition from old layer 4 port based firewalls to ‘next generation’ layer 7 firewalls. The first transition I performed also included the provisioning of a new WAN at the same time however subsequent transitions were in the same untrust IP prefix on the same circuit.
The method I will be writing about can be followed to achieve your end goal as long as you have a free untrust address in your existing public range. That is to transition from vendor A to vendor B gradually whilst also avoiding the need to put in place a ‘change freeze’ on the old firewall cluster. The keyword here is, gradually. There is a lot of talk about doing the transition in one big bang but that is often just not feasible for a lot of businesses. Network connectivity is vital for virtually all business functions that the allowable downtime generally is minimal.
In my example case the transition was from zone based Juniper Netscreen clusters to Palo Alto PanOS clusters. As mentioned, I was also provisioning a new WAN at the same time for the first transition performed however the same basic method has been used subsequently when the WAN circuit remains the same.
Overview
The steps taken have definitive boundary’s of the work involved. A high level view of the changes involved include:
- Perform basic setup of the new firewall cluster and configure a basic setup including HA (This can be done off-site for the firewalls eventual install location)
- Perform a bulk creation of all objects from the old firewall (This can be a reason to learn a scripting language such as python to assist you in this bulk translation / creation of firewall objects)
- Configure the untrust / management interfaces of the firewall and configure the switch up-link ports in preparation
- Physical install of the Firewall in the intended location
- Create a layer 3 point to point link between the old and new firewalls utilising a specific transit zone and RFC 1918 routes between the clusters
- Migrate each prefix / zone at a time as required
It is still a complex operation but of course like most complex issues, if you break it down into it’s composite parts, the change is actually quite straightforward. In the methodology I’ll go over the steps one by one for how I achieved my zone based firewall vendor transition.
Transition in Depth
Set-up the new WAN
Now this one obviously only applies if you happen to be setting up a new WAN at the same time and this post would be become somewhat epic if I tried to include all of the steps involved in setting up a new active/active BGP enabled WAN. Therefore I’ll keep this short. Setup your new WAN however you prefer. Provision a dedicated new untrust VLAN which you can provision your new firewall clusters untrust interface within.
Initial configuration of the firewall cluster
The initial configuration of the firewall includes the following:
- HA
- Management / untrust interfaces
- Object translation / configuration
- General setup
This install could be a base copy of the existing firewall cluster or it may be slightly different depending on your preference however the easiest way would be to implement in similar as possible to the original cluster. The one new addition you should make is the provisioning of a new zone for transit traffic between the firewall clusters.
Layer 2 setup of the core switch should also be established and configured in advance. VLANs should be used for each prefix. I suggest you create a cable map detailing all required connections to ensure a smooth physical install.
Physically install the new firewall cluster
The new firewall cluster should be installed and all network connections made in it’s final position.
Configure transit zone
The transit zone and point to point link will be used while zones exist across both firewall clusters. The zone requires a simple setup, I found the best setup involved the following configuration:
- Implement transit zone on both firewall clusters
- Create point to point interfaces across this new zone / VLAN
- Implement static RFC 1918 routes on each cluster to direct all non local private address traffic across the transit zone
- Allow any inbound / outbound policies can be installed on the old firewall cluster
Once Implemented, the control of traffic across the firewall transit zone can be fully controlled from the new firewall cluster.
Configure new VPN tunnels
New VPN tunnels should be configured in advance to ensure remote sites can have their routes adjusted to reach sites behind the new firewall cluster as each zone / prefix is migrated. Of course I’m making a rather large assumption here that you are using route based tunnels. If you aren’t, try them, you’ll love them.
Policy installation
The methodology used for the transitions was as follows. All policy was established and installed in advance on the new firewall cluster. This can be done during normal working hours as it does not impact the existing environment while still on the old firewall cluster.
When migrating from layer 4 firewalls to layer 7 aware firewalls there are different methods which may be used. I would suggest if you have limited exposure to layer 7 firewalls then you perform a direct migration of all policy in a layer 4 style not utilising the layer 7 technology app-id until you have confirmed the new firewall cluster is passing all traffic as expected. Once you have completed the migrations then you can transform and adjust your configuration gradually to reach a best practice app-id configuration. Once you have experience though, it can be sensible to migrate and transform your configuration to an app-id configuration concurrently.
The one part that is key here is the use of the ‘transit’ zone in the created policy. The thing to really bear in mind is the fact the prefix may be in either of two different zones. From the new firewalls cluster perspective, any traffic sourced or destined to a prefix which is reachable over the transit zone requires the transit zone included in the policy in addition to the zone which will be used once the prefix has been migrated locally. This takes some thought as you go through the policy but if in doubt add the transit zone anyway.
Zone / prefix migrations
The final migrations should be completed in a quiet period. It involves the following final steps:
- Install new VPN routes on remote firewall clusters
- Configure the migrated prefixes gateway addresses on the new cluster interfaces
- Shutdown those interfaces for the prefixes which are being migrated on the old firewall cluster
- Monitor the new firewall traffic flows to ensure that required traffic flows are not being blocked
The configuration changes causes the gateway addresses on the old cluster to cease operation and the newly installed gateways on the new cluster to take over. All of the newly installed policy comes in to play and those prefixes which have been migrated will now be using the new firewall interfaces as their gateway and the traffic sourced or destined for a prefix on the old cluster will be traversing the transit link. The first rule of routing is that the most specific route to a network will be used. When the interface is shutdown on the old firewall cluster the connected route is removed from the route table and the RFC 1918 routes are used as the next most specific route to reach the destination prefix. Vice versa on the new firewall the newly added gateway addresses cause new connected routes to become active on the new cluster.
Palo Alto firewalls have superb traffic monitoring capabilities and allow us to see the traffic traversing the firewall. You can drill into the traffic types traversing the firewall and should be able to determine if you see traffic which should be getting through your policy. It can often help to have colleagues assist during this final phase to ensure that once a prefix has been migrated that all expected traffic types are working as expected.
Conclusion
Quite a lengthy blog post and I hope I have explained well enough to show that it is possible to migrate firewall vendors without having to implement a change freeze and perform a full migration of all networks in one go.
Hope this can help others with a similar task. Let me know how you get on and good luck!
