FTD registering to FMC scenario

[tellis002]

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

[yogdhanu]

Hi

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

[Eduardo Ferreira Fernandez]

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 ...

[Oliver Kaiser]

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.

[a.lukoyanov]

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

[tellis002]

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!!!!  

[a.lukoyanov]

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

[tellis002]

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

[a.lukoyanov · Accepted solution]

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

[Oliver Kaiser]

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.

[tellis002]

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

[Oliver Kaiser]

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.

[a.lukoyanov]

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

[antonkolev]

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

[tellis002]

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