Cisco Firepower Management Center - Managing Sensors Across the WAN

Submitted by dash on Mon, 08/06/2018 - 21:15

This article was written after migrating 3 sites with a virtual FMC at each site controlling a pair of FTD firewalls at each site, down to a single virtual FMC controlling all 6 firewalls at the 3 sites.  The version of code running on FMC at the time of migration was 6.2.3.2 (build 42).  Prior to this migration, we had migrated from Cisco Defense Center controlling a single Firepower ASA/IDS to Cisco Firepower Management Center and FTD(s).  During this initial migration, we took several things into consideration;

  • Centralized Management
  • Logging (rsyslog at each site forwarding to central Splunk server)
  • WAN
    • Latency
    • Bandwidth
    • Messages generated per second
  • Number of sensors managed by FMC
  • Enterprise Topology

 

The whole point of management center is to have a single point of management.  The biggest challenge when we originally designed our FMC deployment was the WAN utilization while centralizing FMC.  With WAN bandwidth coming at a premium, we initially deployed a virtual FMC at each location to manage the edge firewalls at each site.  The problem we faced here was that the Cisco eStreamer eNcore application for Splunk was only receiving e-streams from one FMC.  After reviewing the configuration of the application in Splunk, we noticed that we could only specify a single FMC.  So, what did we do?  We purchased the license for Cisco Support hoping Cisco TAC could shed some light on how to bring in eStreaming from multiple FMC(s).  The Cisco part number for this is FP-SPLUNK-SW-K9.  After purchasing this, we quickly discovered that there is only support for a single FMC or a pair of FMC(s) in HA.  Cisco TAC recommended consolidating our FMC(s) at each location into a centrally managed single FMC or a pair of FMC(s) in HA.  Of course we were back to where we were when we originally deployed FMC!!

Exporting configuration was the first step in this process.  We decided to leverage our Disaster Recovery data center for this centralized model simply due to it's geographical nature of our enterprise footprint.  This meant exporting the following from our FMC(s);

  • Access Control Policy
  • Alert Configurations
  • Intrusion Policy
  • NAT Threat Defense
  • Platform Settings Threat Defense
  • QOS Policy

**Manual screen shots are required for platform specific configuration such as interface IP, failover, routing, and DHCP.

All versions had to be identical between FTD sensors and their FMC(s).  The easiest part of this process was deleting the registration of the management center from the FTD and re-registering the FTD(s) to the central FMC.  Adding in the device specific manually was tedious, but as long as you captured that configuration manually, it should be easy.  Make sure you have access via OOB/management interface or any other means as your interface IP addressing and routing information will be gone.

With a single FMC managing all of our FTD firewalls, we were now able to get eStreamer eNcore to show statistics and analytical data for all of our firewalls.  We noticed a significant increase in our Splunk license limit as well.  Before the changes, we were averaging 15 gig of logs per business day  with 2 firewalls and after ingesting eStreamer traffic from 4 additional firewalls, it jumped to 20-21 gig of ingestion.  This is a considerable difference, so it's clear that eStreamer eNcore does add significant logging considerations.

Having the eNcore eStreamer for Splunk app now functional is informative and allows us to see quick statistics in one central place.  FMC is great, but having the cool graphs and dashboards that are in Splunk is even better.  This also allows us to be able to see what sensors are the busiest or the most vulnerable as well.  The migration completed, it was well worth the effort.  The WAN links did not see a large increase in utilization like we had originally expected.  Obviously there is additional traffic, but nothing that is saturating the links requiring additional bandwidth.