VSX R82 Virtual Router creation fails: “The certificate is not valid”

[oli139405]

Hello CheckMates,

I am facing an issue while creating new VSX objects after an R82 upgrade in a Multi-Domain Management HA environment.

Environment:

- Product: Multi-Domain Security Management HA
- Primary MDS / SMS1: R82
- Secondary MDS / SMS2: still R81.20 Jumbo Take 127
- VSX Cluster: R82
- VSX Cluster object: Cluster2-DC1
- Cluster members:
- FW1-DC1: R82
- FW2-DC1: R82
- Domain Management Servers:
- DC1_Svr_1: R82
- DC1_Svr_2: R81.20 Jumbo Take 127

Current upgrade context:

We successfully upgraded the Primary MDS/SMS1 to R82.

We are still trying to upgrade the Secondary MDS/SMS2 from R81.20 Jumbo Take 127 to R82 T779, but CPUSE fails with:

Upgrade failed.
Upgrade to this version is prohibited. Use clean install.

New issue during VSX configuration:

While the Management HA environment is still in this mixed version state, we are in a critical configuration phase in the Primary DC, where the Primary MDS/SMS is located.

We need to create new VSX objects:

- 2 Virtual Router

During the creation of a new Virtual Router, the wizard completes most steps successfully:

- Checking connection with VSX: OK
- Generating VSX configuration: OK
- Pushing VSX configuration to Cluster2-DC1: OK
- FW1-DC1: VSX configuration was applied successfully
- FW2-DC1: VSX configuration was applied successfully
- Virtual Router processing completed successfully

However, the trust initialization fails for the new VR objects.

Operation report:

Establishing Trust with FW1-DC1_VR-Inside ...
The certificate is not valid.
Failed to establish trust with FW1-DC1_VR-Inside.

Establishing Trust with FW2-DC1_VR-Inside ...
The certificate is not valid.
Failed to establish trust with FW2-DC1_VR-Inside.

SmartConsole then shows the Virtual Router objects with red status / No Trust.

The issue happens while creating the VR/VS in the Primary DC, managed by the Primary MDS/SMS which is already R82.

Current suspicion:

I suspect that the VSX Virtual Router certificate / SIC trust issue may be related to the current Management HA mismatch or synchronization state:

- Primary MDS/SMS1 is already R82
- Secondary MDS/SMS2 is still R81.20 Take 127
- The Secondary upgrade is blocked by CPUSE
- The VSX cluster and gateways are R82
- New virtual devices fail during trust establishment with “The certificate is not valid”

Questions:

1. Can this VSX Virtual Router “certificate is not valid” / No Trust issue be caused by the Management HA version mismatch between Primary R82 and Secondary R81.20?

2. Should we avoid creating new VSX objects until both MDS peers are upgraded to R82 and fully synchronized?

3. After both MDS peers are R82 and synchronized, should we delete and recreate the failed VR objects, or is there a supported way to re-establish SIC/trust for these virtual router objects?

Any guidance on the correct recovery path would be appreciated.

Thanks,

[Lesley]

You need to jumbo first the R82 system due: https://support.checkpoint.com/results/sk/sk184766

Without a Jumbo you cannot create new virtual devices:

Management and Provisioning

• Failure to establish SIC (Secure Internal Communication) between Management and Gateway when creating a new gateway or Virtual System.

[Lesley]

Also make sure that all required ports are open between MGMT and 

Second are you sure you need a virtual router? Most people use virtual switch

S

[Alex-]

The CPUSE message is self-explanatory. You can't upgrade a secondary manager. You clean-install it, FTW as secondary manager, install the JHF, recreate the SIC trust with the primary and initiate a sync. The primary manager will take some time to sync everything.

Also, you don't indicate if you just use R82 baseline or with JHF. You should absolutely use the recommended JHF.

Also, labbing this before going to upgrade and DC-wide changes on half a management system would have been a good idea.