How do I change the local id for an IKEv2 IPsec VPN?

[Mathias_Weidner]

Hi,

I'm using a Checkpoint VSX with R77.30, configuring it via SmartConsole.

There I have set up an IPsec VPN with IKEv2 to a Cisco device.

The peer is telling me that he gets an odd remote-id for this VPN, so that I have investigated this using `vpn debug trunc` and looking into $FWDIR/log/ikev2.xmll afterwards. There I found the following:

less $FWDIR/log/ikev2.xmll

...
<Exchange serial="71386" Peer="ipsec-peer" Dir="Outbound" Type="Authentication">
<peerIP>1.2.3.4</peerIP>
<Message Valid="Yes" Initiator="Yes" Response="No" higherVer="No">
<arrivalTime>2018-12-10T20:17:59</arrivalTime>
<MsgID>1</MsgID>
<initSPI>d6f9fd7e1034a6cd</initSPI>
<respSPI>3ab383fc5bf849bd</respSPI>
<Next>Encr</Next>
<Version>2.0</Version>
<Type>Authentication</Type>
<Length>320</Length>
<Payloads>
<Payload Type="IDi" Next="Auth" Length="12" Critical="No">
<Type>IPV4_ADDR</Type>
<Data>9.a.b.c</Data>
</Payload>
...

The remote-id that the peer mentioned is my local-id (IDi) in the debug file (9.a.b.c). This is the address of the management interface of the Checkpoint.

What I want to configure instead of 9.a.b.c is the address of the outgoing interface (5.6.7.8). I have looked up the VPN Administration Guide for R77 Versions but didn't find an answer.

Can anyone help me?

Thanks,

Mathias

[PhoneBoy]

Do you have Link Selection configured with the correct IP Address?

This is set here:

After you've done this, renew the VPN certificate and install policy:

[Steve_Vandegaer]

I tried this but it didn't resovle the issue. 

[Maarten_Sjouw]

Which choice did you make, the main IP or the actual external interface IP?

[Peter_Baumann]

Hi all,

We have selected here "Selected address from topology table" and used the externalIP.
The Gateway Object was defined with the RFC1918 IP (InternalIP).

It seems that IKEv2 is not using the setting in "Link Selection", it uses the "General Properties" IPv4 Address.
We tried many settings but IKEv2 is always using as the IDi the Gateway IPv4 Address.

Does someone know how to change this without chaning the IPv4 Object IPv4?

Thanks,
Peter

[Michael_Horne]

Hello,

I have this problem to and I found the sk44978 "Check Point gateways always send main IP address as IKE Main Mode ID" that I thought explained it: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Then I was confused again when I got to the bottom of the solution as it states: 

"For R80.30:

In R80.30, Check Point gateways no longer use the main IP of the gateway as IKE ID, when using IKEV2, and when link selection is configured to use another interface than the main IP (which is the default)."

I have currently experiencing this problem and we are running R80.30, We have the gateway explicitly configured to use the external public IP address:

In the ikemonitor.snoop capture that we took, it is clear to see that the ID is set the main IP of the firewall cluster:

The Cisco router terminating the site to site IPsec has to match the 10.88.1.30 for the connection to be successful

Should this truly be fixed in R80.30, or is the SK mistaken?

Thanks,

Michael

[figdungiven]

Hi Michael, I am having the exact same issue on r80.30. I have configured an interface with an external IP and have selected this in the Link selection but as above the Checkpoint firewall still uses the internal IP within the IDi payload. Did anyone ever get back to you on this from support?

[_Val_]

Main mode IP for IKEv2 should use one set up through Link Selection, as SK states, with R80.30 and up. Make sure you install policy after the change. If not working, please raise with TAC

[Michael_Horne]

Checkpoint keep saying that Link Selection should work with IKEv2 in R80.30.  This has never worked for me and we always have to go back to Ikev1 for tunnels where we need to set the local ID.

[johnnyringo]

I agree; CheckPoint is woefully mistaken in saying that Link Selection settings will influence the IKEv2 ID, regardless of software version.   The only way to set the IKEv2 ID is to change the Main IP of the gateway (IP address referenced in SmartConsole).   In my case, this means the Management server and gateways communicate via Internet, which is stupid, but it does work.  

FYI: the Link Selection -> Source IP address setting will influence the source IP address of the packet when initiating.  You can easily see this in a packet capture:

# (eth0 = 10.0.0.2/24, route to 203.0.113.188 10.0.0.1, eth1 = 10.1.1.111/24)

[Expert@check-point-cloudguard-byol-1-vm:0]# tcpdump -n -i eth0 host 203.0.113.188
14:41:09.095484 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:17.033617 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:17.094507 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:28.407587 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:42.199983 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:43.199885 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:44.406724 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]
14:41:44.614057 IP 10.1.1.111.isakmp > 203.0.113.188.isakmp: isakmp: parent_sa ikev2_init[I]

For CheckPoint gateways behind an NAT, this setting needs to be overridden to "topology table -> (IP address of external interface), or "IP address of chosen interface".  Leaving this as the main IP will cause the CheckPoint to perform IP spoofing against itself and all VPNs will fail, whether IKEv1 or IKEv2.  

[johnnyringo]

FWIW though I came across this thread while troubleshooting an R80.40 standalone gateway in Google Cloud (the clusters do not have this issue because their Main IP is the floating external IP address).  Even after setting the other side to accept the CheckPoint's Main IP, I still could not get policy-based VPNs working when the CheckPoint side initiated traffic. 

Running debug crypto ipsec on the other side (Cisco), it would show the CheckPoint sending the main IP in the Phase 2 Transform sets.  The Cisco would then reject the SA request because it was expecting either public IPs or private IPs, not a mix of both.

In working with support it seems there is a fix for this in the latest R80.30 Jumbo Hotfix.  Here's the steps:

1. Verify the other side will accept the CheckPoint's Main IP as the IKEv2 remote ID.  On a Cisco router for example, this is done with match identity remote address under crypto ikev2 profile
2. Upgrade CheckPoint to latest  R80.30 Jumbo Hotfix, which should be Take 273
3. Under IPSec VPN -> Link Selection -> Always use this IP address -> Statically NATed IP, enter the public IP of the gateway (example: 192.0.2.21)
4. Set Link Selection -> Source IP address settings to to either topology table (ip address of external interface) or IP address of chosen interface.  I prefer the latter just in case the eth0 IP address changes.  
5. Under IPSec VPN -> VPN Advanced, Verify NAT Traversal is enabled, which is the default
6. Verify the other side also has NAT-T support

An initial SA with the public IPs as /32s will then be created, even without traffic:

+-----------------------------------------+-----------------------+---------------------+
| Peer: 203.0.113.188 - cisco-router    | MSA: ffffc9004aebb220 | i: 1  ref:     2    |
| Methods: ESP Tunnel PFS AES-128 SHA1 g..|                       |                     |
| My TS: 192.0.2.21                     |                       |                     |
| Peer TS: 203.0.113.188                    |                       |                     |
| MSPI:	   800001 (i:  1, p:  0)          | Out SPI: cf538552     |                     |
| Tunnel created:      Apr 16 16:49:15    |                       |                     |
| Tunnel expiration:   Apr 16 17:49:15    |                       |                     |
+-----------------------------------------+-----------------------+---------------------+

Then, when either sides sends interior traffic, additional SAs will be brought with the interior subnets:

+-----------------------------------------+-----------------------+---------------------+
| Peer: 203.0.113.188 - cisco-router    | MSA: ffffc9004aebb6f8 | i: 0  ref: -- 60/60 |
| Methods: ESP Tunnel PFS AES-128 SHA1 g..|                       | i: 1  ref:     3    |
| My TS: 10.22.222.0/24                    |                       |                     |
| Peer TS: 172.31.33.0/24                   |                       |                     |
| MSPI:	   800002 (i:  1, p:  0)          | Out SPI: 0cf6c107     |                     |
| Tunnel created:      Apr 16 16:51:53    |                       |                     |
| Tunnel expiration:   Apr 16 17:51:53    |                       |                     |
+-----------------------------------------+-----------------------+---------------------+

I'll admit here I don't fully understand why this only works when NAT-T is enabled, and it smells more like a hack that a design fix.  But thought I'd pass it on.

[imamuzic]

We found a way to configure R81.10 gw to use IP address for IKEv2 ID according to link selection "Calculate IP based on network topology" setting:

This command needs to be executed on the gateway:

ckp_regedit -a SOFTWARE/CheckPoint/VPN1 BestRoutingSenderIP True

This workaround is described in sk108600 under "Scenario 2 - IKE Main Mode negotiation fails on 3rd party peer because it expects FQDN as ID".

[johnnyringo]

Interesting.  Do you know if it's required for R81.20?  Reason I ask is I noticed the IPSec VPN Link Selection settings changed between versions for HA Clusters in GCP:

IP Selection by Remote Peer

1. R81.10: Always use this IP address > Main IP
2. R81.20: Always use this IP address > Statically NATed IP: <Public IP of the Cluster>

Outgoing Route Selection > Source IP Address settings

1. R81.10: Manual > IP Address of chosen interface
2. R81.20: Automatic

[imamuzic]

Not sure if this 'ckp_regedit' fix is required on R81.20 too, but in R81.10 without this fix the gateway always uses the Main IP as IKEv2 ID. The only exception from this (per our testing) is if you use "Selected address from topology table" or "Statically NATed IP" options under "IP Selection by Remote Peer" section combined with "Operating system routing table" under "Outgoing Route Selection" section. The only trouble in this case is that you end up with a single IKE ID that must be accepted by all IKE peers which is fine in a typical Internet perimeter scenario, but in our case we had a multiple point tu point links terminated on their respective external interfaces connecting to respective IKEv2 peers. Wihtout modifying remote peer's configuration or routing topology, this 'chkp_regedit' fix was the only way to make Check Point GW behaves as, for example, Cisco ASA/FTD or Palo Alto regarding using IP address as IKEv2 ID.

[karmarin]

Hello imamuzic.

From what I understood, did you manage to send the interface ID depending on where the traffic comes in?? ... My scenario is:

I have two WAN links with different ISPs and the problem I'm having when establishing the VPNs is that the Cluster ID is sent, so the Third Party FWs know my connection through the Cluster's internal IP, so I'm looking for my FW to present itself with the IP where it receives the connection, that is, if the connection comes through ISP 1, my checkpoint responds with the IP of that interface and if it comes through ISP 2, it responds with the IP of this interface.

I don't know if it was the same thing you had, if so, did it work for you with "chkp_regedit"?

Regards

[imamuzic]

we had a similar issue and 'chkp_regedit' solved it... I hope you will make it too.

Regards,

Igor