Maestro Management (magg0) Interface Requirement

[Simon_Macpherso]

Hello,

Currently we have a management interface connected as a bond (magg0) which is used to manage the security group. There is also an external IP allocated to a separate bonded interface for internet access. 

It is my understanding that outside of VSX, there is no requirement to use the dedicated management interface to manage the device, and the bonded external interface can be used to manage the cluster.

We have a multiple Maestro environments where we want use the external interface to manage the security group.  The main reason is that we are observing problems negotiating S2S IPSEC VPNs with 3rd parties that have a requirement to use IKEv2.  

Maestro is presenting the management IP as the gateway IKE ID instead of the “real” public IP allocated to the external interface. With ikev1 with both internal and external (3^rd party) peers this is not a problem.

I just want to confirm here what the procedure is to switch over to using the external interface to manage the security group. Please confirm the following steps. 

1. Assign a dummy IP to the eth1-mgmt interface 
2. Assign the external interface IP to the security group
3. Assign the external interface IP to SMO in Smart Console.
4. Update IPSEC link selection 'Always use this IP address' value to 'Main address' (currently configured as 'Selected address from topology table' specifying the external interface IP). 
5. Install policy

Or

1. Assign a dummy IP to the eth1-mgmt interface 
2. Assign the IP previously assign to management interface (magg0) to external interface IP
3. Update IPSEC link selection 'Always use this IP address' value to 'Main address' (currently configured as 'Selected address from topology table' specifying the external interface IP). 
4. Install policy

We have multiple VPNs to third party peers which use the existing SMO IP, so the second option here might be best to minimize disruption. 

@Anatoly 

Regards,

Simon

[Anatoly]

Hi Simon,

I would go with the 1st option, however, please take a look on sk179005. It may help you to avoid this change, if missing distribution by default is the only issue here.

Thank you,

[Simon_Macpherso]

Hi @Anatoly 

I'm not sure DXL is the issue here as the issue is isolated to negotiating with peers using IKEv2. 

Regards,

Simon

[Wolfgang]

@Simon_Macpherso did you investigated TAC and they recommend this as solution ?

Do you know Check Point gateways always send main IP address as IKE Main Mode ID 

There is a hint for IKEv2 

Using "DNS Resolving" or "Link probing" in "Link selection" with IKEv2,  will result in the gateway using its main IP as IKE ID.”

Are using one of the mentioned features in your current configuration?

[Simon_Macpherso]

@Wolfgang I have a TAC open but they have not commented on whether or not the solution I outlined should be configured. 

We inquired about this a while ago and @Anatoly mentioned the management interface (magg0) was not required when running in gateway mode, and any interface can be used for management. We haven't had a requirement to address this until now.  

I've reviewed sk44978 which does describe the issue.

Of the 2 scenarios outlined in the SK it links to - sk33822 - scenario 1- seems to be the only solution. This entails configuring the gateway to use a FQDN as the Main Mode ID type instead of the default IP address.

This is also a per gateway change which will apply to all connections. It cannot be configured per VPN community (we previously asked TAC about this and they advised an RFE would be required)

There will be impact to existing 3rd party VPN gateways that are using IP address as the Main Mode ID type. As part of this change, we would need to ensure existing 3rd party gateways support FQDN as the Main Mode ID type and if they are able to implement the change on their end. If they can, we’d need to coordinate the change with each 3^rd party to minimize disruption.

The SK states the IDs are not necessary for Checkpoint gateway. TAC are advising us that Checkpoint to Checkpoint VPNs will indeed be impacted. Considering the requirement that both sides authenticate using the same ID method and ID values, as the sites where we have a requirement to change the main mode type on have VPNs to the majority of our internal sites, we would need to change the main mode type to FQDN on all gateways that have VPNs between them.

Based on this, would it not be easier to remove the dedicate management interface from the configuration? 

We have since deployed a couple of Maestro environments without a management interface which are operating fine.