In this article, I wanted to demonstrate how we can add a Firepower Threat Defence appliance to an FMC located at another site. Let’s take a fictitious scenario to provide some context to why and how we configure the FTD device the way we do.
Scenario Currently Synack Corp has one Firepower Management Center (FMC) and Firepower Threat Defence (FTD) appliance located at their HQ site in the UK. More recently the company has expanded and opened a new branch office located in Ireland. They have decided that they will deploy a vFTD to protect their infrastructure and that it should be centrally managed using the current FMC. The devices are currently running version 6.2
We have a few ways listed below in which we can set this new device up, but we also need to bare in mind that we need to establish a connection with the management interface on the remote FTD.
Using the Firepower device manager is out of the question since this is only used to manage physical devices locally.
Configure a VPN tunnel between the new branch and the HQ – this means we could have an internal IP address on the remote management interface and we wouldn’t need to consider NAT.
Make the remote FTD’s management interface public facing. This isn’t recommended best practice but if it is done then at least 2 public IP addresses are required, one for the management and one for the data port and both interfaces need to be added to the outside zone. If the FMC is behind a NAT device we have two options you can do to form a communication path between the FMC and remote device.
Remote FTD device needs a static IP address that the FMC can reach
Set up static NAT for communication between the FMC and remote device
We can also pre-configure the remote FTD in a staged environment. This is considered the most dangerous of them all because the data path to the management interface is through itself. If any misconfigurations occur, the administrator could lose the connection between the FTD and FMC and configurations cannot be reversed.
Now that I have mentioned some of the considerations lets get back to our scenario. In this example, I will be accessing the remote FTD via the public management interface that has a static IP address assigned. Providing we have configured the management interface and verified that we can SSH to the device we will start to provision the device using the following steps.
Enter the following command >configure manager add DONTRESOLVE [key] [NAT_ID] — Where [key] enter your own key, this will be used to add the device to the FMC later so remember it. Where [NAT_ID] enter a unique ID, if you are configuring more than one remote site these will need to be different on each device. The purpose of ‘DONTRESOLVE’ is to tell FTD that we don’t have an IP for the FMC as it is sat behind a NAT’ed device.
Issue the following command on the remote FTD > show managers — the status should show as ‘pending’.
Add Remote FTD to FMC
Return to the FMC and following these steps.
Go to Device > Device Management and add a device by selecting Add > Add Device in the upper right side if the screen.
The add devices screen appear and now we enter the relevant information related to the remote FTD appliance.
Host: Enter the management public IP address for the remote device
Display name: Enter a meaningful name
Registration Key: This is the same key entered on the remote FTD, in my case it was cisco123
Group: Assign the device to any relevant group
Access Control Policy: Create or assign a pre-existing policy
Smart Licensing: Select your licenses
Click the ‘Advanced’ section and enter the unique NAT ID you specified on the FTD, in my case it was 12345
Click ‘Register’ if you have finished and the FMC will go and find the device (this may take a few minutes).
Verify Device Has Joined FMC
Head back over to the SSH session of the remote FTD and issue the >show managers command again. If the FMC has successfully found the device you should receive the output as shown in the image below.
Added notes 16/01/18 – When you try things that you know shouldn’t work!
While playing with the FMC and FTD in a lab environment, I wanted to see what would happen if I tried to specify an IP address on FTD when it was behind a NAT device. The following is what I observed:
FMC fails to associate itself with the FTD device because FTD sends a TCP reset. Judging by the Wireshark capture you see below, it looks as though the TCP Reset occurs because the FTD device isn’t listening on port 8305 for the public address, hence the reason you need to specify ‘DONTRESOLVE‘ and a ‘NAT-ID’. This tells me I first noticed this behaviour on an ASA firewall that was sat in front of my FMC, here are the logs:
%ASA-6-302013: Built outbound TCP connection 12253 for OUTSIDE:184.108.40.206/8305 (220.127.116.11/8305) to DMZ:10.1.1.20/32870 (18.104.22.168/32870) %ASA-6-302014: Teardown TCP connection 12253 for OUTSIDE:22.214.171.124/8305 to DMZ:10.1.1.20/32870 duration 0:00:00 bytes 0 TCP Reset-O
The log above shows that a connection from 10.1.1.20 was sent to the NAT IP address of the FTD device 126.96.36.199 with a destination port of 8305. The port 8305 is used for secure communication between appliances and it is required that a network permits this traffic. On the last line, we can see that a TCP Reset-O was sent back to the FMC, this shows that the TCP reset was sent from outside the Firewall, we can also verify this by taking a look at the Wireshark capture below.
After the PSH, ACK messages are sent from the FMC, we see in the above screenshot that there is a ‘SYN’ from the FTD NAT followed by a ‘RST, ACK’ from the FMC NAT address 188.8.131.52. This sort of behaviour indicates that the remote device (FTD) is not listening on port 184.108.40.206:8305.