Want to deploy an ASA5506-X (running FTD v6.2.2) to a remote site and then be able to set up and manage a Site-to-Site VPN back to HQ where FMC server is located.
A) Is this even possible?
B) What is the best way to do this?
Remote FTD -----> Internet -----> HQ --> FMC
It is possible but complicated given the current product capabilities (i.e. as of 6.2.2).
Deploying remote/branch locations can be a bit tricky. You need to establish connectivity between the FTD’s management interface and the FMC in order to push data plane configuration to the FTD. BUT without a data plane connection how do you establish the FTD management interface connection to the FTD?
Essentially you are left with four options:
• As of version 6.1 of the FTD software, there is an on box manager called the Firepower Device Manager. However, it is only available for physical appliances. This means that any virtual FTD devices won’t be able to use the Firepower Device Manager and are only configurable via the FMC. Additionally, even if you used the Firepower Device Manager, once you have the FTD device configured and you wanted to “switch over” to having it managed by the FMC all its data plane configuration is wiped out in preparation for the FMC to push a new configuration down. So the use of the Firepower Device Manager should only be used when you want to manage each remote/branch location in a decentralized fashion.
• Have a router at the remote/branch location already configured with a VPN/MPLS link to the HQ LAN so that the FTD’s management interface can have an internal IP address yet still have a data path to the FMC prior to configuring the data plane.
• Put the FTD’s Management NIC on the public facing side of the network with a public IP.
• Pre-configure the FTD’s Data Interfaces, Routing, and Policies while it is connected to a LAN that gives IP access to the FMC. Either via a staging/lab environment that can emulate the remote/branch location’s network design. This option is most dangerous of all because once this FTD is installed at the remote/branch location its data path to its management interface is through itself. This means that a misconfiguration of the data plane could sever the management NIC’s access to the FMC, thus severing your ability to undo the configuration change!
To register branch FTD to HQ FMC, Do we need to assign public ip on management interface ? I think if we have VPN/MPLS link to HQ, we can register. RIGHT ?
Any connectivity that gets tcp/8305 to and from the remote FMC is acceptable.
There are at least 3 different ways:
1. Private IP with an independent MPLS, VPN or other connection.
2. Public IP directly Internet-connected.
3. Private IP with NAT on the appliance pre-configured to translate it to a public IP (usually requires staging the device at main office before shipping out).
Remote management has been broken since FTD came out - it's one of the main reasons we haven't deployed FTD for our customers yet. (We're an MSSP - managing remote customers is what we do, and it's frustrating that Cisco never bothered testing the process during design.) For ASA hardware, we use split-image ASA+FP, so we can set up the ASA to do NAT (using CLI to configure the ASA's management interfaces, then either CLI or ASDM to set up NAT), and then use the NAT to reach the FP management port. But with FTD we can't do that - you need the remote manager to set up the NAT, but you need the NAT to access the remote manager, and CLI doesn't help.
So besides ranting, here's what choices we've documented
- Some of our customers have dedicated management networks, over MPLS or other VPN tunnel devices, and we use those. That's mostly common in data centers. It's way overkill for a 5506.
- Some of our customers have routers with spare ports, or switches that have spare ports so we can access the router, so depending on who manages them, we could do NAT on the router to reach the FTD management port. The switch in between makes more sense in an HA environment (where we'd already be using switches), but it's more awkward if the data pipes are 10Gbps (where we'd need to put in a 1Gbps interface also) than if it's all 1Gbps.
- We're NOT going to put in a $50 Linksys firewall next to the management port on a multi-$100K 9300. It just looks dumb. But we might put in a 3G/4G wireless device if the customer's location allows that and has a reliable signal, or some fancier Out-Of-Band device that also provides a serial connection.
Do you know whether FTD shares the ASA's "feature" that the management port can't be in the same subnet as the Outside data interface? Combining all the management and Outside data into the same subnet means we don't need NAT to support them all. (I used to know, but it's been a while and it was something I only found out the hard way, not from reading documentation.)
I agree with your rants, for what it's worth.
FTD CAN have the management and outside interfaces in the same subnet. The routing instances for the data plane are distinct from the management plane.
Management exposed to the public internet just so the FMC can control the firewall sends like a little bit of oversight. I understand that a lot of remote sites will have routers and other devices in front of the firewall, but there are sure a lot of sites that would leverage a single device to do this job.
The question really isn't wether it not it can, but rather should we be putting our management of the device that is supposed to be protecting other networks on a publicly accessible network...
It does seem a bit contrary to what those of us who've been doing networking for any time have learned - isolate the management, don't expose it publicly etc. But if you look at current generation products like SD-WAN appliances they are plug and play based on registration via their Internet-facing interfaces. Still, they aren't security appliances so your point is valid.
The Firepower management is secured in that it only allows ssh and tcp/8305 for the sftunnel (proprietary implementation of SSL/TLS) and does support further restricting those with ACLs. Personally I'd at least try to NAT it on an Internet-connected router with an additional ACL where I have that option.
I am trying to solve the same problem. How should I configure the direct access to the management Nic? Do I use a free Nic or should the Diagnostic port be directly connected to the internet? Should it be assigned the public IP in the Interfaces tab? Is there a guide available?
Best regards, S.F.
I just finished deploying this with the internet facing management IP address on a single 2140. The FMC is sitting behind an HA pair of 2140's at the HQ site.
One thing to remember if your FMC is behind a NAT device, you need to configure the FTD at the remote location with the DONTRESOLVE and NAT key and when you add it to your FMC you need to specify that NAT key as well.
I setup a 1:1 NAT for the FMC and only allowed TCP8305 on the ACP from the single IP address for the remote location.
Cool! Could you give us a diagram (or at least a bullet list) of how you've got the different interfaces configured? Between Outside, Management for FTD, and Management for FXOS. Thanks!
With respect to the Previous replies, is it not possible for us to console into a device running the FTD ( get access to the CLI )
Set up a management IP
Further make us of the mgmt IP to telnet or FDM to access the device and set up NAT
It would be necessary to set up NAT for some customers, as the are still apprehensive about giving the mgmt Interface a Public IP
With just the initial mgmt IP and NAT configured ( if this were a device that directly connected to the ISP, no router was there in front)
We then make use of FMC, to further push config by making use of mgmt IP of the FTD Sensor