What to do in case vFMC fails?

[nihalsalim]

As we all know that vFMC doesn't support HA. What would be the ideal way(workaround) to migrate to a new FMC in case the one in production fails?. I understand that the backup needs to be restored on to the newly deployed vFMC. But what about the IP address of new vFMC? Should that be kept same?. Also I have seen that when backup is restored, it will show the managed devices as it is from the old vFMC with a red indicator. But I don't think the sftunnel will work automatically between the new vFMC and managed FTDs. Add FTD HA and VPNs to the mix, what is the solution? Thoughts?

[nihalsalim · Accepted solution]

Here's what the TAC answered. Please note that the new vFMC must have the same IP as old one and you should do the commands from both FTDs if it is in HA.

Problem Description:

=================

• The fastest way to recover the FMCv if it failed.

Action Plan:

=================

• I just wanted to let you know that if the FMC failed this will not take any effect on the traffic since it’s only manage device.
• Have a backup from the running FMCv
• Create another FMC virtual machine and keep it ready.
• Restore the backup on the new FMC VM
• Disable the old FMC VM from the network.
• Restart the SFtunnels from the FTDs by the following script ( with root access) :

===================================================================

root@FP:~# manage_procs.pl

****************  Configuration Utility  **************

1   Reconfigure Correlator

2   Reconfigure and flush Correlator

3   Restart Comm. channel

4   Update routes

5   Reset all routes

6   Validate Network

0   Exit

**************************************************************

Enter choice:

=====================================================================

Enter the options 5 “Enter button”, 4 “Enter button”, 3 “Enter button”, 0 “Enter button” in order.

• Then try the same script from the new FMCv ( with root access).

[Marvin Rhoads]

Thanks for the update.

I could be wrong but I believe the target fresh FMCv for the backup needs to have matching Snort rules and VDB versions.

Can you confirm?

[nihalsalim]

Yes. This requirement comes when the backup is restored to the new vFMC.

https://www.cisco.com/c/en/us/td/docs/security/firepower/60/configuration/guide/fpmc-config-guide-v60/Backup_and_Restore.html#ID-2200-00000297 

Before You Begin

• Confirm that the VDB version in the backup file matches the current VDB version on your appliance. See Viewing Dashboards for more information.

• Remove any licenses added to your appliance after a backup has completed before restoring the backup to avoid a conflict on restore. See About Firepower Feature Licenses for more information.

  Confirm the appliance does not have the same intrusion event data as stored in the backup, because restoring the backup under such conditions creates duplicate events. See About Intrusion Events for more information.

The first time I migrated, sftunnel was the only thing affecting me. It just shows FTD under managed devices without any communication (failed deployments). Had to add the FTD as a new device with different management IP as VPN config was getting deleted when I tried to remove the existing non-functional FTD. After adding I changed the source device in VPN settings and deployed again.

I am planning to implement the new solution in the coming days and update how sftunnel responds and how licensing is affected. Just posted it in case someone needed it more than me.

[Marvin Rhoads]

Yes, thanks - that's what I was thinking about.

It looks like just the VDB and not the SRU or Geolocation db needs to match. (Though I'd probably go ahead and make SRU current first on the target server.)