Add Remote Firepower Firewall to Firepower Management Center

7
3643

This guide is something that I have seen requests for in multiple places including the Cisco supportforums. I recently had to complete this process for some new Cisco Firepower FTD firewalls so I am going to document it. Without further ado, how to add a remote Firepower firewall to a local Firepower Management Center.

Look above to see a sample diagram of what we are looking at as our end goal. After the guide below, that is what our topology will look like.

I have an enterprise main campus and smaller remote sites, such as the one we are working with today. This site has a Firepower 5506X running the FTD image. I want to manage this firewall (and the others) with Firepower Management Center (FMC). Normally the process would be easy if this firewall was onsite at my main campus. I would just follow this easy guide Cisco provides. This case is different though. My remote site has a single static IP. I don’t have a second public, routable IP address that I can assign the management port so I can register the firewall with FMC. That is the reason for this guide. It’s not too crazy, but there are some important details to follow. This process we will be using today was partially outlined in a published Cisco Doc, but a few steps were still unclear. I am working from that doc and adding in the rest of the details I was looking for in more of a step by step guide. Let’s get started.

Configuring the Remote Firepower Firewall and FMC

Port-Forwarding – Main Campus

Very quick note on step one. You need to setup port forwarding on your main campus firewall for port TCP8305. The end goal is that the FMC will send and received the TCP8305 traffic as your outside, public IP address for each of these remote Firepower firewalls. Your main campus will also need to allow the TCP8305 traffic in both directions in its ACLs.

Initial Management Port Setup

Assign management port an IP address (the one that will eventually be the outside interface)

  • configure network ipv4 manual 10.0.0.X 255.255.255.0 10.0.0.1
  • **Note** – change this info out with your public IP address for the remote location.

Add a manager (Firepower Management Center)

  • configure manager add < IP address or hostname > <registration key>
  • The registration key is a unique key that you need to enter on both the firewall and FMC. This can be anything at all that you make up but must match on both sides.
  • If your FMC and FTD Device are separated by a NAT device like another firewall or NAT’ing router, you need to use a different command:

Connect the firewall to FMC

  1. Log into your FMC and add the device. You will need the public IP you assigned in step 1 and the registration key.
  2. Then, go to Devices -> Device Management -> and click the Add Device button in the top right corner from within FMC.

Access Policy Creation

  • Once the device is added, create the following access policy. This trusts the traffic on port TCP8305 that FMC uses in both directions. Sub in your IP addresses for the ones below. This would be your public, outside subnet IP address and then the internal IP that you will eventually assign to your management port.https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200868-configuring-firepower-threat-defense-ft.html#anc12

NAT Policy Creation

Create the NAT policy below. This NAT policy translates the internal management IP to the outside, public IP address for port TCP8305. There are two rules, one for both source 8305 and destination 8305 traffic as sometimes the FMC initializes the traffic and sometimes the firewall itself will.https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200868-configuring-firepower-threat-defense-ft.html#anc12

Configure new interface settings

Configure your inside and outside interfaces. Your outside interface will be the same IP address that your originally assigned to the firewall management port in step 1. Your inside IP address needs to be on the same subnet as the internal management IP you selected earlier.

Deploy all changed settings

Now that all your settings are entered and the policies are all created, you can deploy the settings. This is enough to connect the firewall to Firepower Management Center fully and allow the firewall to work as we need it to in the remote location.

Rearrange the Cables

Now you need to move the cables around. Connect the interface designated as the inside to your switch at the remote location. Connect a cable from the management port to this same switch. Lastly, connect the internet circuit to the interface you designated as the outside interface.

Change the management port

  • Console into the firewall and change the management port IP address one more time. Remember that internal subnet management IP you used earlier? You want to use that here. In the case of the images above, that would be 192.168.0.100. Same command that was used earlier:
  • configure network ipv4 manual 192.168.0.100 255.255.255.0 192.168.0.1

Verify

Now, because you created the NAT rules earlier concerning port 8305, Firepower Management Center should be able to communicate with your firewall. Any traffic to the outside interface on TCP\8305 will be port forwarded to the management port. You can now use your local Firepower Management Center to manage a remote Firepower firewall. You can add more access policy rules, configure more NAT rules such as a dynamic NAT rule, etc. FMC should have what it needs to finish the configuration.

7 COMMENTS

  1. Hello Kevin,

    Thanks you for this post, I begin to execute the steps but I was wondering: in the “Configuring the Remote Firepower Firewall and FMC” section second step is to assign a management port an IP address. Is this to be done on both sites ? or only on the remote site ? Is there a way to undo this action if I no longer want to assign an address to the management port ?
    Maybe you should assign addresses for your sites in the firt figure so that we can assess the difference between to sites just in seing their IP addresses ?

    Thanks in advance for your asnwers.
    Frederique

    • The management port is important here and you need to have an IP configured on it. Your “main” site will need it’s management port NAT’ed to a public IP as well with access permitted on port TCP\8305. FMC does its work off of that management port, so yes, you would need to keep an IP on it if you would like it to remain joined to FMC.

      A small summary that might explain it better:

      1. put a publicly reachable IP on the management port so you can reach it from the main campus.
      2. Add the FW to FMC and prepare needed configurations (Like the NAT and trust screenshots I shared)
      3. Deploy the new config
      4. Change the management port IP from the public IP you started with, to the private IP (from the NAT step you previously did) so the management port can continue to be reachable on TCP\8305

  2. Kevin I have attempted to accomplish this setup and I am having problems with the NAT translation on the remote end. That configuration does not seems to work on my 5506H-X FTD. Running 6.2.3.14 code. When I look at the nat translations I am not getting any hits. Packet captures verify mgnt interface is sending traffic to my FMC and that my hub FMC is sending traffic to the remote end. Has to be a NAT problem. Any thoughts?

    • I’d say check to make sure it matches the screenshot as close as possible for the NAT portion and the access policy portion. If you want, I can take a look if you wanted to send me a screenshot at [email protected]. It’s probably something quick and easy since it sounds like you got the majority of it done.

  3. Hi Kevin, we’re deploying 1120 and 1140 Firepower firewalls to our environment that are in a remote location. We’ve configured IP’s on them through their local FDM. If I add then add them to our FMC, will it wipe the configuration we had done prior to shipping them to the remote locations since the FMC is pushing the configuration? Thanks for any advice you can provide.

    • Hey Jason, if you do that, when you add it to FMC, a lot of the config will get wiped out. With that being the case I don’t even bother setting anything up for the most part until it is added to FMC.

  4. This is actually not possible on the Cisco 1010. Believe me – I tried. I was on the phone with TAC for six hours until a senior engineer came online and told me there wasn’t a way to do it. He literally told me flat out that there are processes that you have to change internally to get it to work and that if you reboot the router they would reset and it would be broken again. This is an internal defect (CSCvg51446) that prevents natting to the MGMT port through firewall. It is being tracked by a Cisco internal bug and is set to release in 6.7. Secondly there is absolutely no way to protect the MGMT port if you put it on the internet unless you put a router in front of it. All the security ACL’s you hear people mentioning are related to SSL, HTTP, or SSH. There is currently no ACL for blocking the MGMT port when accessing TCP 8305. I thought this was absolutely crazy and the senior engineer suggested that I vote on it as a feature set? https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr83833
    If it is a “nice to have”, why are you tracking it as a bug? I personally don’t care that it is a proprietary protocol or cert based. I think the fact that cisco never thought of protecting the MGMT port with any kind of ACL is ludicrous.
    You could just put this out on the internet because it has certs and a proprietary connection, but how many things have we seen hacked that we thought would be totally secure. Why do people run VPN’s in VPN’s (Yes, they do when you’re trying to move classified materials)? Because people figure stuff out. I would not feel good risking the security of my company, and my job for that matter, on a single layer of protection that would gain someone access to a device that could put down my network.
    If your company has unlimited funds and you can pull off a fully out of band management network, great. Otherwise, NAT at HQ, put a router in front of the MGMT port and NAT there, set up an ACL only allowing the trusted IP’s and only to the trusted port, and if you want one extra layer of obscuring – move the port so people don’t immediately know what it is. If you can pull it off and have a newer router – create a vpn back to HQ from that small router to protect the MGMT port. Not much else you can do at this point as this is really the only option right now.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.