Access remote FTD using FDM via outside interface

[Travis-Fleming]

Hello, I have an FTD I am looking to deploy remotely to a home user. Over kill I know. Wondering about being able to manage that guy via FDM via the outside interface? I have an ACL to allow my public to the LAN side of the FTD. I can ping the outside interface. Is there a command or something in fdm that I can designate the outside interface to also be the management interface? Or (because the FTD is acting as a site-to-site vpn device for the honme user) do I re-ip the FTD MGMT interface IP to one in the local LAN?

We have 50+ asa 5505's that are near eol, and looking to replace with NGFW 1010's, so just doing a test now. Device woudl be a site-to-site vpn for the home user, and supplying PoE to their cisco phone.

[Marvin Rhoads]

FMC has to manage the FTD device via a dedicated management interface. The outside data path interface cannot do dual-duty in that respect.

Most people end up using one of two options:

1. Stage the device at your main site with the policies necessary to translate the management address or carry it via site-site VPN when deployed remotely, or

2. Use a second public address to assign to the management interface and connect that to your FMC which has a NATted public address and ACL allowing only the remote FTDs inbound. (That's obviously not feasible for a small site with a single dynamically assigned IP address.)

[Travis-Fleming]

What if we don't want to use an FMC for this but the built in FDM? We have some 50+ ASA 5505's we wish to replace. In theory could a guy either:

A - plug the mgmt port into an open port on the FTD to get it an IP, then when the FTD joins the VPN you could access the mgmt via that inside VPN address? (When I do this the MGMT port becomes ICMP pingable, but I cannot get to the HTTPS web management.)

B - Send a small 4 port work-group switch and plug the mgmt port into it, then a patch cable from switch to FTD?

We really use the solution for home users to build a site-to-site VPN so they can access our Citrix and Cisco Phone environment. The ASA 5505 was perfect, but they are going away from that.

[Marvin Rhoads]

Do you really want to manage 50 remote firewalls one-by-one?

Are you aware of Cisco Defense Orchestrator?

https://www.cisco.com/c/en/us/products/collateral/security/defense-orchestrator/datasheet-c78-736847.html

https://www.youtube.com/watch?v=twQ1GI-GA-A

Since it uses the REST API and not the sftunnel connection under the covers you can use it with the outside interface.

https://docs.defenseorchestrator.com/Configuration_Guides/Onboard_Devices_and_Services/Onboard_Firepower_Threat_Defense_Devices/0200_Onboard_a_Firepower_Threat_Defense_Device_Using_Username%2C_Password%2C_and_IP_Address

[Travis-Fleming]

Yeah we have looked at Orchestrator, but the company I work for does not want to go to the cloud like that, so I"m kind of forced to. We have the virtual FMC so we are limited there to the amount of FTD's we can manage there as well.

I"m guessing I"m just missing a small step in my setup? I can ping the mgmt interface, but it does not browse. The 10.10.52.0/24 subnet is my LAN for my site-to-site. We do have a bridge (bvi) interface setup for the ports on the FTD and setup with DHCP, however the .2 is out of the scope.

===============[ Proxy Information ]================
State : Disabled
Authentication : Disabled

> show network
===============[ System Information ]===============
Hostname : at-test-ftd01
Domains : mydomain.com
DNS Servers : 172.16.1.160
172.16.1.161
Management port : 8305
IPv4 Default route
Gateway : 10.10.52.1

======================[ br1 ]=======================
State : Enabled
Channels : Events
Mode : Non-Autonegotiation
MDI/MDIX : Auto/MDIX
MTU : 1500
MAC Address : 70:0F:6A:CD:93:8C
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 10.10.52.2
Netmask : 255.255.255.0
Broadcast : 10.10.52.255
----------------------[ IPv6 ]----------------------
Configuration : Disabled

===============[ Proxy Information ]================
State : Disabled
Authentication : Disabled

[Travis-Fleming]

Would my simple solution be to nat my mgmt interface out my public with a static port number? So I woudl connect to 1.2.3.4:8080 if 1.2.3.4 was my public, and 8080 was my port number?

[Marvin Rhoads]

You didn't mistakenly setup an FMC during testing did you? "show managers" will check that.

If you like FMC and are concerned about the scalability of FMCv, note that 6.5 introduced the FMCv 300:

FMCv 300 on VMware

We introduced the FMCv 300, a larger Firepower Management Center Virtual for VMware. It can manage up to 300 devices, compared to 25 devices for other FMCv instances. You can use the FMC model migration feature to switch to the FMCv 300 from a less powerful platform.

[Travis-Fleming]

Interesting I"ll have to look at v 6.5, I was unaware of that.

And no, it's managed locally. I have odly anough an ASA 5505 running a site to site vpn near my test FTD device, and if I change the mgmt interface IP to that subnet and directly connect the mgmt interface to that other 5505 I can get in and FDM works great. I just need to get FDM working on the FTD itself over the site-to-site vpn, or over the outside interface. Can you help with that piece?

[Marvin Rhoads]

I will have to try the scenario you have in a lab. I usually work with larger deployments where the Firepower device has an internal network we can leverage for connections. The challenge is coming in on one interface and needing to talk to a service that's bound to another interface on the same device. We need to instruct FTD it's "ok" to go out the inside interface en route to the management interface or otherwise set it up to be managed somehow, preferably not making your FDM administrative interface publicly exposed.

I completely understand the use case you're asking about though and we should be able to do it all on one box. 

[Travis-Fleming]

Perfectly explained! I will continue to try things in my lab as well. Yesterday I reimaged it back to factory to start over and try as time allows today.

[Travis-Fleming]

Hey any luck with this? I have my new 1010 device now in our lab with our complete setup. I can access the mgmt interface from the public IP, but not the internal. I"m not having any luck myself. Odly enough from outside the network I can't ping the internal IP address I have assigned to the mgmt interface, but if I"m on a PC connected to the FTD I can ping that IP. Doing a system support trace I can see allow on my ping as well.

Going to tinker with routes to the diagnostic interface to see if this helps.

[Travis-Fleming · Accepted solution]

I have a working solution to meet our needs for this. MGMT interface is using the data interface as the gateway. Then I just go to the LAN IP address and I"m able to manage the device. This is better then over public I think. Then once a site-to-site VPN is established, it works to connect via the inside LAN interface IP, instead of what is deamed the MGMT ip.

[Daniel Fjortoft]

Hi Travis! We are currently doing a bit of testing on the 1010 with the FDM. In my opinion, Cisco should make it possible to do HTTPS remote access on the outside interface even if the firewall is running AnyConnect. Meanwhile, we are trying to access the FDM over VPN. The tunnel is up and running, and we have allowed all traffic from main office to the site LAN. We can connect to other devices in the LAN (192.168.200.0/24). The FDM is reachable on the 192.168.200.1 from devices on the LAN, but not from the main office network. The Management interface is configured with 192.168.45.45, and “Use the Data interfaces as the gateway”. Nothing is plugged into the physical management port on the FDM. What are we missing? Currently running version 6.5.

[Travis-Fleming]

Hey Daniel, I had that same similar issue when I started. Because you have it setup to use the "data interface as the gateway" you won't connect to the MGMT IP for web mgmt, but instead the LAN IP you have configured, either though the bridge interface IP that comes out of the box, or if you removed that and assigned a static to an individual LAN interface. If that does not work you can try this command to allow all access to the LAN IP in the mean time until you can get in, but you'll need to console to the device:

configure https-access-list 0.0.0.0/0

[Travis-Fleming]

I"m having the exact same problem in my lab when I setup like you. I've created a Cisco TAC case. Will report the solution when one is found.