Deploying new firewalls in a greenfield environment is a fairly straightforward task. However, replacing an existing solution with new firewalls is more challenging. Sadly it’s not quite a case of plug and play; the existing environment will already be supporting applications and services. Starting over with the firewall policy is rarely an option.
A large part of my day is centered around firewall conversions, or migrations. This is a task that can vary from “dead simple” to “dead hard” and is dependent on many factors. However, there are things you can do to make life easier, and get the conversion right the first time. The tips and best practices here will frequently refer to Fortinet products, but much of this can be applied to any security migration.
Garbage in, garbage out
Like any computer process, the quality of the conversion output is dependent on the quality of the input. Before you start any conversion project, it’s important to perform thorough housekeeping on the existing firewall policies. This means removing redundant rules and unused objects and generally imposing order on your policies. If the legacy firewall uses a centralized network address translation (NAT) table, remove or lock down rules that have “any” for the source AND destination network. Comparing centralized and policy-based NAT tables is a topic in it’s own right, but a tightly defined NAT table will reduce the number of rules created in the new world.
Select your tools
There are various ways in which you can prepare your migration. Many customers choose to use a product like FortiConverter, but there are other commercial tools out there. Some valiant individuals do it with unspecialized tools such as sed, awk, or a humble spreadsheet. It’s entirely possible that you’ll end up using a combination of tools, depending on the complexity of your configuration.
It will always take longer than you think
Allow yourself plenty of time. This may sound obvious, but the more time you can spend on preparation of your config, the better the outcome will be. Hand-checking that your new policy closely matches your legacy environment may be laborious, but it’s the best way to reduce the number of snags that crop up during your change window. Check, check again, and check once more.
Keep it Simple
Once you’ve selected your new firewall, it’s tempting to turn on all the bells and whistles on the first day. However, to make your life easier I would recommend you only migrate features you are using right now. During your cutover, you need to give yourself the least amount of work to do. Whilst your goal may be to have all the lovely user and device identification features turned on, you don’t want to worry about this when your are trying to troubleshoot critical features such as VPNs. The fancy stuff can be added easily at a later stage, but on day one, firewall features should be the priority. Don’t be tempted to re-number network interfaces or change your routing philosophy at the same time; you are asking for trouble.
Prepare some User Acceptance Tests (UAT)
For critical business applications, many organizations have a suite of tests that ensure that everything is running nicely. However, for more than a few organizations, the only way of knowing something isn’t working is when the phone rings. To avoid this, make sure you have up to date tests for any critical applications that cross the firewall. This can be as simple as a script, but could involve sophisticated application and network monitoring tools; just make sure you have something. From experience, it’s very easy to waste time chasing false negatives: reports of systems or services that were actually broken before the migration, and are no less broken afterwards.
Fail to prepare, prepare to fail
This should be obvious, but prepare a roll out plan, and, more importantly, a rollback. Decide how much time you are going to need for your cutover, then double it. If anything doesn’t work the way it should, allow yourself time to fix-forward, and don’t be too hasty to retreat. Make sure that your compatriots on the server/application/networking teams are aware of the change, and even better, will be on-hand during it. It’s also worth asking the question whether they have any planned outages that coincide with yours. Don’t assume they’d tell you, because experience tells me otherwise.
If you’ve been careful in the previous stages, you should expect to do the cutover in a single outage window. Firewall migrations, especially large ones, are never easy. But with proper planning they can at least be straightforward. And if something doesn’t work on the night, it is almost always the ARP cache on the router. You won’t need it, but good luck!