- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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
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:
I tried this but it didn't resovle the issue.
Which choice did you make, the main IP or the actual external interface IP?
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
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
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?
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
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.
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.
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:
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY