topic We actually managed this to in Network Security

FTD registering to FMC scenario

tellis002 — Fri, 21 Feb 2020 13:55:27 GMT

Afternoon everyone,

I have a project, involves one FMC appliance, and I will be joining about 14 5506x's (FTD image) to the server. So the sites that will be getting the 5506x with the FTD image, they just have a basic internet connection, no vpn tunnel, etc.

So, with that information, how should i go about registering the 5506x's to the FMC server? I mean, to make any configuration's to the 5506x you have to have it registered to the FMC. But, before i send out the 5506x to the remote site, i need to get the following configuration below configured on the 5506x.

Basic configuration of 5506x:

- outside interface dhcp setroute

- inside interface static IP address

- PAT

- no access allowed inbound

Ideas: pre-register the 5506x, via management interface with it being local on the site where the FMC is located. Make my configurations on the 5506x. Than ship the 5506x out, it gets the dhcp setroute, static inside IP address is configured, PAT, etc. everyone internally has internet. Than someone local on that site, would have to inform me what their public IP address is, i could than ssh to the outside of the 5506x FTD image, delete the configure manager add command (as the previous command would reference a private IP address and of course wouldn't find the FTD at that point due to no VPN tunnel, MPLS, etc.) and than re-configure the configure manager add using the NAT ID to the public IP address that would be nat'd at a different physical location to the FMC.

Following, in the FMC, join the 5506x back using its own outside public IP address and re-deploy policies.

🙂 think that will work? is there a better way to go about this?

Thanks! - Tony

Hi

yogdhanu — Sat, 24 Sep 2016 15:10:29 GMT

The approach would be best to pre-register the device and then install it and then re-register the sensor.

Isnt possible to use the

Eduardo Ferreira Fernandez — Mon, 10 Oct 2016 22:15:49 GMT

Isnt possible to use the local management in 6.1 to do this?

I dont really know how to do it, i tried to find the commands but as my device is already registered i cannot do it, there is some commands as configure https-access-list in the Threat Defense CLI, maybe you can do something with that GUI, i never used ...

I think the best approach

Oliver Kaiser — Tue, 11 Oct 2016 05:35:42 GMT

I think the best approach would be to register your sensors using the Public IP of your FMC. Just setup a network segment for registering the devices and simulate your end-scenario this way.

When the ASAs are being deployed at the new site they will automatically try to connect to your FMC and you can re-register the devices on the FMC side without touching all firewalls and changing the manager ip.

Just use FQDNs to register your devices on FMC. When the devices get shipped to the remote sites just change the DNS entries and you are done.

p.s. make sure FTD can use the DNS Servers you add with "configure network" at the remote site.

Hello Tony,

a.lukoyanov — Tue, 18 Oct 2016 07:36:22 GMT

Hello Tony,

Did you manage to solve the problem?

I'm working on the same project right now and have the following idea:

1) register FTD with FMC locally. FQDN is used to register device.

2) pre-configure the FTD including:

- MGT interface has Inside interface as a default gateway

- PAT translation MGT_IP:TCP8305 -> Outside_Interface_IP:TCP 8305.

- Access Policy to allow connection from outside to Mgt interface

3) re-register FTD with FMC using

- "configure manager add DONTRESOLVE natidstring keystring" on FTD

- change DNS settings so that FQDN is resolved as Outside Interface IP address, so FMC can connect to remote FTD

Regards,

Alex

So, I have been working

tellis002 — Tue, 01 Nov 2016 15:27:46 GMT

So, I have been working through my project and came across an interesting problem. If a site does not have a backup vpn solution, you are forced to register the FTD device through its own access control policy, nat, route, etc., using the NAT ID feature.

The problem is, if you registered it at a local site with a different IP address (management IP address on FTD), than ship it out. The site receives the devices and plugs everything, everything flows through FTD just fine. But, now you need to change the management IP address (to reflect remote site network) to get it registered back to FMC.

The problem is, I change the management IP address on FTD and FMC and couldn't get it re-registered. So, reaching out to TAC, they said i would have to delete the previous registration and re-register it due to how FMC holds registrations. They said it will not be a problem because FMC will pull the policy that is currently on FTD device and use that.

So we did that. HOWEVER, the FMC did pull the policy, but it when it re-applies (this is all automatic and you can't change this), it deletes the configuration while it is re-appling the same one it pulled from it. But, once FMC gets to the NAT and routes being deleted, FMC can't finish re-deploying the policy because it broke itself and there is no connection possible back to FMC as it deleted its own NAT and routes. We confirmed this by going in the back end way to the actual ASA code, NAT and route's were gone. We did this twice.

Therefore, TAC stated this is a oversight on this type of design and I will have to use a VPN.

Ahh!!!!

We actually managed this to

a.lukoyanov — Tue, 01 Nov 2016 15:49:03 GMT

We actually managed this to work in the following way.

We are not changing mgt address of remote host. We actually created security zone called branch_mgt. Assigned interface to it and gave the ip address to that interface (lets call it IP address A). This address is the default gateway for branch FTD management interface (lets call it ip address B).

During the preconfig we assigned IP addr. B to management interface and set default gateway to ip addr A. This ip addr A was assigned to local switch vlan ABC to provide connectivity to FMC.

We also ensured that in VPN configuration both Branch Inside network and Branch management network were included in protected network section.

After we did preconfig we simply connect Branch FTD management interface to interface assigned to branch_mgt security zone

Yeah i can see that working,

tellis002 — Tue, 01 Nov 2016 15:58:45 GMT

Yeah i can see that working, that makes sense. As long as the management IP address doesn't change when you are using the FTD device as the path to connect to FMC I don't foresee this being a problem.

It still makes me nervous with registering a FTD management interface to FMC while using the FTD as its path. I mean, would if the IP addresses need to change or someone screws up a route or NAT or something. There is NO way to locally change it back on the FTD device to get it re-registered.

I feel cisco should give us SOME local configuration options on FTD, but there are none.

Thanks - Tony

At the moment, we need to

a.lukoyanov — Tue, 01 Nov 2016 16:16:40 GMT

At the moment, we need to have some cheap equipment on branch site which can provide us connectivity to branch FTD management interface. That can be any VPN capable device.

We also need to make some cabling instructions for local staff.

So when we lost connection to branch FTD we can ask locals to connect FTD to the small VPN device so we can configure branch FTD

Hi Tony,

Oliver Kaiser — Tue, 01 Nov 2016 22:58:32 GMT

Hi Tony,

I have tested the scenario you described and do not agree with TAC. I have got it working just fine without re-registering the device since that would cause the chicken-egg issue you have described.

Initially it did not work and FMC did not connect to sensor again but after changing the Host configuration at Device Management > [Sensor Name] > Devices > Management and restarting sftunnel processes via pmtool on CLI it re-connected just fine. (v. 6.1.0 build 330)

I will test this again and report back in more detail tommorow.

Really that is interesting,

tellis002 — Wed, 02 Nov 2016 13:31:20 GMT

Really that is interesting, if I could get more information on this, that would good to know. Also, how did you restart the 'sftunnel' process? Or i think i found it:

admin@FireSIGHT:~$ sudo pmtool restartbyid sftunnel

Some more features that I got working last night on FTD, worked without issue. I did have to get into the actual ASA cli on the FTD, do some show commands to verify what I was pushing to it was actually being configured.

- ospf

- about 12 sub-interfaces (customer wanted router on a stick)

- dhcprelay on each inside interface

After another test I have

Oliver Kaiser — Wed, 02 Nov 2016 18:49:42 GMT

After another test I have found that a restart of the sftunnel process is not neccessary, I just had to give FMC some time to reconnect to the sensor.

Here is how I tested the change of IP:

1. Register sensor with FQDN sensor.example.com

2. Configure FTD data interfaces (mgmt [10.0.0.1] and outside [1.1.1.1]) and configure PAT for TCP/8305 from outside to sensor management IP 10.0.0.100

3. Relocate sensor and change management ip address to 10.0.0.100. Set default-gateway to FTD data interface mgmt [10.0.0.1].

4. Change DNS A record for sensor.example.com to outside [1.1.1.1]

5. Wait for ~10min

6. Verify sftunnel connect via netstat -a and deploy configuration again to verify connectivity is working correctly between sensor and fmc.

Let me know if you have any questions.

We also could translate both

a.lukoyanov — Wed, 16 Nov 2016 11:28:21 GMT

We also could translate both source and destination addresses to solve the connectivity problem between FMC and sensor. This translation should be made on FMC and Sensor sites.

They will connect to each over using IP addresses as if they are not separated by NAT devices.

On FMC site:

FMC_Local -> Sensor_Local:8305 should be translated to FMC_Global -> Sensor_Global:8305

On Sensor site:

Sensor_Local:8305 -> FMC_Local should be translated to Sensor_Global:8305 -> FMC_Global

Sorry it took me so long to

tellis002 — Thu, 23 Feb 2017 13:29:35 GMT

Sorry it took me so long to get back to this. But Lukoyanov is exactly right. After going through some scenario's, this is what cisco stated is supported:

1. either mpls or vpn connection to the management interface, these routes CANNOT be via the FTD device

2. put a public IP address on the management interface and connect it directly to the internet. of course at that point you need to have two public ip addresses for the site

Just wanted to let you know

Oliver Kaiser — Thu, 23 Feb 2017 13:36:20 GMT

Just wanted to let you know why they dont support anything else at the moment. You could NAT the management address for a connection to FMC but if for whatever reason you would have to re-register your FTD device to FMC it would remove the static routes and nat configuration during the registration process, which will leave you with a device that cant receive configuration from the FMC because it deleted the required network configuration.

I talked with an engineering lead about this in december and they are working on a solution, but at the moment we can only work around this issue with the methods you posted.

Yeah that is exactly what i

tellis002 — Thu, 23 Feb 2017 13:39:44 GMT

Yeah that is exactly what i found in my testing. Was very confusing with what was happening but i could confirm it all by going into the back end of the FTD and getting into the ASA cli and doing some show commands.

Sure enough, nats, etc, the device was breaking itself so it couldn't finish.

Re: Hello Tony,

antonkolev — Tue, 31 Oct 2017 18:54:21 GMT

I did it without this step below
- PAT translation MGT_IP:TCP8305 -> Outside_Interface_IP:TCP 8305.

Re: Just wanted to let you know

bstewart — Sat, 24 Mar 2018 06:57:58 GMT

As of a year later (March 2018) and Version 6.2.3 (at least, the beta as of a month ago), there was still no good solution. You need either an extra network or a separate NAT device (which could be a cheap Linksys or equivalent, or could be NAT functions on your Internet router if you have a spare port.)

It's possible to configure the FTD using DHCP for the management port, if you're careful enough, so that you can set it up with the FMC at HQ, then ship it out and plug it all back in, but you still have to use the FTD to provide the NAT for the management port, so if that ever gets messed up (say, because you deployed a bad configuration) you don't have a way to fix it remotely.

Re: Just wanted to let you know

ramos1 — Wed, 30 May 2018 15:21:10 GMT

I hope Cisco is watching this thread. I've struggled with this problem in a lab environment and arrived more or less at the same solutions mentioned above. I've burned too much time trying to figure something out that should be straightforward. Furthermore, I do not find these "solutions" acceptable. Its quite baffling that this is still an issue. Very disappointing.

Re: Just wanted to let you know

Edgar Almonte — Wed, 22 Aug 2018 02:17:03 GMT

What if you change the flash to ASA instead of FTD and then you can use the ASA to do a site to site VPN. You can assign the SFR module an IP address on the inside network and use that IP to connect to your FMC. Your FMC would be on the other end of the VPN tunnel and it would use the inside IP of the SFR module to manage it.

https://www.cisco.com/c/en/us/support/docs/security/firesight-management-center/200321-Management-of-SFR-Module-Over-VPN-Tunnel.html

HTH Edgar