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.