Tech Talk: Leveraging AWS to Deploy Cisco Next-Gen Firewalls

In the midst of new location builds, datacenter builds, and migrations there is a critical component to the whole connectivity piece: Internet Access. Internet access is typically the first connectivity piece when building a new datacenter or office location as it provides for easy WAN integration at low risk and low cost with the implementation of IPSec Tunnels.

PTP recommends the Cisco Firepower Threat Defense (FTD) Next Generation Firewall (NGFW) Platform for its performance, manageability, scalability and security at a competitive price point. The center of the unified management of the firewalls is the Firepower Management Center (FMC), which provides easier management of distributed firewalls through the central management dashboard. The challenge, however, is when building these locations with the FTD NGFW’s there are no computers or servers to host the FMC or the FMC may have already been implemented at a different location. Also, when there is no connectivity until the FW’s are built then how do you achieve connectivity without compromising changes in the production environment?

One way to accomplish this is to implement a temporary FMCv in Amazon Web Services (AWS) cloud. Since the communication between the FTD and the FMC is secured via an SSL-tunnel over TCP8305, building a temporary FMC in AWS allows for getting the NGFW’s up and running, code updates, basic policy / NAT implementations, and so forth. AWS’s marketplace allows for fairly easy installation of the FMCv. However, following the Cisco FMCv for AWS setup guide is recommended as there are certain items that need to be followed to ensure proper communications and gaining access to the appliance.

This method allows you to get the FW’s operational at the new location with no interruption to the production environment. You can also configure VPN tunnels to gain access to remote locations and you can test other policies prior to full implementation. [One caveat with the FMC running with a temp. license is that the VPN tunnels only support DES encryption. This needs to be considered before building the tunnels.]

Overall that’s great, but here’s the catch…

This now needs to be migrated to the current production FMC, if there is one. If not, then the migration is typically a fairly simple one as devices don’t need to be upgraded. Once an ESX server arrives at the new facility, or utilizing an ESX server at the current facility, you can build the FMC to be identical as the current FMC. You then must perform a back/restore of the configuration from the temp FMC in AWS.

With an FMC currently in production, things get a little more complex. As with most migrations, the new NGFW’s are usually running an up to date version of code and the FMC is usually running the same version. This normally means that the production FMC needs to be upgraded to the same version currently running in the cloud. So, what does that exactly mean? As with any FMC upgrade, you first perform the upgrade, then a re-deploy needs to be completed. The purpose of the re-deploy is that the Snort process is updated on the FMC and needs to be updated on the NGFW’s prior to anything else. That means, the Snort versions and any/all other versions of the FMC sub-processes need to be verified prior to importing the policies from the temp FMCv.

Once the export/import of everything is complete, then the migration of the FMCv can be completed. This is something that will need to be accomplished during an approved change window as the devices will go off-line while this happens. With this, you will also need to follow the process for changing the FTD MGMT address and the FTD FMC address. This process is typically straight forward, although suspending the HA configuration is necessary so the standby firewall does not have its configuration erased.

While this isn’t the only method for implementing Cisco’s FTD solution at new locations, it does provide for a fairly simple and non-intrusive way of getting the devices operational and on the network without production disruption. Then, if migrating to the customer/final FMC can be accomplished prior to the location move, it allows for the location to gain full access to the production FMC and become one step closer toward migration without the worry during the migration week-end. This allows for FMC/FTD implementation at the new location with very little production risk.

It's not just about the technologies, but how to put them into play to maximize their value and to do so with with a plan for success. That's how we approach projects at PTP.