FTDs 4115 in HA A/P need to be moved to new FMC

[gihernandezn91]

good evening!

im tasked to move a pair of 4115s in HA (7.0.5) that currently run several s2s vpns, 5 anyconnect portals, ospf, nat, etc to a new FMC.

The ftds are currently being managed by a FMC1000 in version 7.0.5. The new FMC is using 7.2.5 and its currently in production with other 7.2.5 ftd being managed.

Whats the best way to move these 4115s to the new fmc without service interruption?

Do i need to manually replicate all device significant config like routing, interfaces, vpns?

Thanks

[Marius Gunnerud]

What model is the new FMC?  If the new FMC model is the same as the old FMC you could backup the old FMC and restore that backup on the new FMC (make sure the new FMC is not reachable by the FTDs), then remove the old FMC from the network and then connect the new FMC to the network.

If you do not manage the old FMC or do not have the option to restore the backup from the old FMC and remove the old FMC from the network, you will need to associate the FTDs with the new FMC which will require a bit of configuration.  But this is possible with minimal downtime since they are an HA pair. 

We can get to the steps once we have more info on the current setup, who manages what, and what can or cannot be removed from the network.

[gihernandezn91]

Hi!
New FMC is 2600.
I cant backup and restore because these two FMCs currently manage different FTDs with different configuration. I only need to import the config of this specific set of 4115s.
Im covered on the NAT/ACP/intrusion policy side with the export/import function but im lost on the device config itself.
I was thinking on breaking the HA. Register the secondary to new fmc, import ACP, NAT, etc and then replicate config manually and migrate to this ftd.
After services has been tested, import the remaining FTD and setup HA again in new FMC.

[Marius Gunnerud]

Whatever you do, do not break the HA, when you break HA the standby FTD will lose all configuration and you might have a complete outage until you have it set up again depending on how you move the FTDs.  The following is what I would recommend (you may already have performed some of these steps.)

1. export all required policies (ACP, NAT, platform settings, Health monitoring, etc.)
2. import these policies into the new FMC
3. map all interface to security zones as well as make note of any and all static and dynamic routing configuration.
4. map any DHCP or DHCPrelay configuration.
5. map all site to site VPNs and remote access VPN configuration.
6. configure the security zones to save some time during the actual migration.
7. failover to the secondary FTD and verify it is now the secondary / active FTD and the primary / standby is showing as failed.
8. unplug, or shutdown on the connected switch, all data cables from the primary FTD (leave the management cable connected)
9. from the CLI remove the existing FMC "configure manager delete" (the FTD will still maintain its running configuration, and this should also initiate a removal of the FTD from the FMC.  Verify in FMC GUI that this device has been removed before continuing.)
10. from the CLI of the primary / standby device break the failover setup "configure high-availability disable"
11. add the FTD to the new FMC, in CLI "configure manager add <ip address> <key>", add the FTD to the GUI in FMC Devices. At this point the FTD will be added to the FMC, the FMC will perform a discover where it will learn the interfaces configured on the FTD and then deploy the configured policies.  At this point you will lose all configuration that is not preconfigured in the FMC.
12. Now you need to associate the interfaces with their corresponding security zones.
13. once you have associated interfaces to security zones, verify that all interface zones in the ACP policy are not show an orange / red triangle.
14. now configure routing, site 2 site vpn, remote access vpn, and DHCP / DHCPrelay 
15. once everything is configured, unplug / remove the data interfaces of the standby / active FTD from the network (keep the management cable connected), and connect / add the primary / standalone FTD to the network and test network access.  Remember to test thoroughly as when we start with the standby unit, there will be no possibility for a rollback. 
16. when everything is confirmed OK break HA on the standby unit "configure high-availability disable", at this point all configuration should be removed from the FTD verify with "show running-config" in CLI.
17. remove FMC management from the FTD "configure manager delete"
18. add the FTD to the new FMC "configure manager add <FMC IP> <key>" and add the FTD in FMC GUI in Devices tab
19. connect the secondary FTD back to the network.
20. configure HA with the first added device as primary and the last added device as secondary.
21. when all configuration is synched verify that the devices are in active / standby state.  I have seen situations where this can take some time so if they are not in active / standby immediately after setting it up be patient, give it 10 to 15 minutes at least.

and now you are good to go on the new FMC.

[gihernandezn91]

HI!,

Thanks for the detailed steps. But im kind of lost as to why breaking HA would mean a complete outage. There would still be an active firewall with the original config.

Besides that, on step 7, is there a reason to run a failover previous to disabling HA? Whats the end goal of this?

Lastly, the main difference between this method and the one i mentioned is that instead of breaking HA, disabling it would let me keep the configuration related to interfaces and possibly routing(?) but the rest (VPNs, Qos)  I would have to either way do it manually. Is this the right assumpition?

EDIT:
I labbed this on a a pair of 1150s running version 7.2.5 and i get this error when I try to disable HA on a standby unit:

Thanks again

[Marius Gunnerud · Accepted solution]

No disabling on one firewall at a time will allow you to control which firewall is the primary in the new setup and it will allow you a rollback if you need to.  No matter what you do the only configuration that will remain on the FTD is the interface configuration (not the interface security zones).  All other configuration will need to be reconfigured either via importing and associating the policy (as in ACP policy for example) or manual configuration.

The problem with breaking HA is that the secondary FW will lose its configuration, so if you intend to keep the setup as is with regard to which firewall is primary and which is secondary I suggest to not break the HA setup outright.

As for the screenshot you posted, you will need to remove the manager before breaking the HA on the device CLI. So steps 9 and 10 in my previous post would need to be swapped around.  I will edit the post.

[gihernandezn91]

Thanks, that clears things up

As a workaround of this (before knowing your plan) i was thinking on reusing the mac addresses of the primary FTD when i failover to the standalone ftd (previous secondary) managed by the new FMC so there would not be any arp issues.

Also, I have no administration of the switches between the firewalls. Would it be ok if i just shut down the interfaces directly from the chassis (except mgmt) when i failover?

I will give this a try in my lab.

[Marius Gunnerud]

I have never tried it but I would assume that shutting down the interfaces in the chassis would be OK.  The only issue would be, depending on how you are accessing the FTDs, you might lose mgmt access to the FTDs when you are switching over to the newly configured FTD as you will need to remove the secondary FTD from the network before connecting the primary back to the network or you will end up have an IP address conflict / split-brain scenario.

So if you have an out of band access that is not dependent on the FTDs themselves, i.e. mgmt traffic does not pass through the FTDs, you can shutdown the interfaces on the FTD chassis.  Otherwise, you would need to be onsite, or have someone onsite to assist you.

[gihernandezn91]

Hi