08-11-2018 05:33 AM - edited 03-12-2019 06:52 AM
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?
Solved! Go to Solution.
08-15-2018 10:08 PM
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:
=================
Action Plan:
=================
===================================================================
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.
08-15-2018 10:08 PM
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:
=================
Action Plan:
=================
===================================================================
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.
08-15-2018 10:20 PM
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?
08-15-2018 10:32 PM
Yes. This requirement comes when the backup is restored to the new vFMC.
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.
08-16-2018 01:12 AM
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.)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide