Checkpoint R81.20 VPN Tunnels - mismatch of IKE ID setting (IKEv2)

[seanmc12]

ok, I'm not a beginner, but still pretty new.

I have 6 Firewalls, 1 3800 at each of our 4 remote sites and an HA pair of 6700s at our main office. Over the past couple of weeks, we have battled the same issue at each of our sites and this morning, are seeing the same dang issue at one of our remote sites.

We have 2 VPN tunnels, Pri and Sec, for each site. The tunnels will run fine for awhile and then out of the blue, 1 of the 2 tunnels will go down and disappear from my Tunnels and Monitoring view. ALL tunnels are using the same exact settings with exception to the IP addresses.

Same error each time at every location: mismatch of IKE ID setting (IKEv2)

Route based VPN Tunnel

Encryption is Prefer ikev2, support ikev1,

phase1

EA - AES-256

DI: SHA-256

DHG: Group 5

Phase 2:

EA: AES-256

DI: SHA256

DHG: Group 5

Tunnel Mgmt: Set perm tunnels - All tunnels in community

VPN Tunnel Sharing: One VPN Tunnel per Gateway Pair

Advanced:

IKE phase1 - 480 min

IPsec Phase2 : 3600 seconds

Properties: Disable NAT inside the VPN community

No other settings are set in the VPN community.

I have opened a half dozen or more cases with CP TAC, do trouble shooting each time and end with the same unknown result. After a bit of resetting on both sides, we are able to get the tunnels back up, but this is a massive friggin Oracle work stoppage every single time.

Anyone else seeing anything like this now or recently?

[the_rock]

Is "keep ike SAs" enabled from global properties?

Best,

Andy

[CaseyB]

What happens if you set it to strictly IKEv2?

[the_rock]

Thats an excellent point, missed that part...definitely could be an issue.

Best,

Andy

[seanmc12]

We did test setting it to IKEv2 only and the tunnels would not come up. Thier tunnel is terminating  to our externally facing IP..12.2xx.xxx. In the error message, they are saying we are sending them an incorrect IKE ID and are seeing 10.xxx.xxx.xxx which is the private IP on the external interface of our CP FW. CP TAC says that most third party vendors do not care what IKE you send them, but this vendor does. So in a couple of hours, the vendor is going to change their IKE ID from the 12.2xx.xxx to the 10.xxx.xxx ip that we are sending and CP TAC is saying that may resolved the issue. I will update this post as soon as that change is made to see if the issue is resolved.

[the_rock]

What is enc domain set to on your and their end? I know most people say as long as you have emty group on CP side, thats good enough, but I always set it same on both ends, so say if other side is Fortigate, just do 0.0.0.0/0 and emty group on Check Point and that works excellent for ikev2.

Best,

Andy

[the_rock]

This was also interesting discussion about the subject

Andy

https://community.checkpoint.com/t5/Security-Gateways/Unnumbered-VTI-to-3rd-party-gateway/m-p/137471...

[CaseyB]

Who is the third-party firewall vendor?

[mbinns_2024]

Hi Sean, 

I have exactly the same issue, did you manage to get this resolved?

IKE ID mismatch and sending a particular IP that now isn't accepted by the OCI side. 

Kind Regards

Marc

[seanmc12]

ISSUE RESOLVED. THANKS TO EVERYONE THAT CONTRIBUTED.

Here is what I found, learned and ultimately what resolved the issue.

1. On the Oracle side, there are specific settings for them to use IKEv1 or IKEv2.

2. On the Checkpoint side, the settings are: Prefer IKEv2, support IKEv1,  IKEv2 only, or IKEv1 for IPv4, IKEv2 for IPv6.

3. When the checkpoint side is set to IKEv1, checkpoint, from what we saw on my system, offers the Private IP of the CP firewall as the IKE ID. When the CP side is set to IKEv2, the CP side offers the Link Selection IP, which by default is usually the externally facing IP for the site unless you've changed it. When the CP side is set to Prefer IKEv2, Support IKEv1, the CP side offers both the Private IP and the Link selection IP as available IKE IDs to Oracle.

4. AWS does not seem to care what you send them as the IKE ID as long as all of the other information matches up, but ORACLE does restrict what IKE it accepts.

5. We tried IKEv2, support IKEv1 and Oracle was establishing and terminating the VPN Tunnels because their side does not have a 2 IKE ID...either or solution. They failed to tell me they were only looking at IKEv2. I changed my system to IKEv2 only, which should have forced the CP Firewall to only use the Link selection ID.

6. Working with CP TAC, CP said that I stumbled upon a software bug in R81.20 Jumbo HF 41. One of the issues of the bug was that, even when set to IKEv2, it still let the CP FW present both IKEv1 and IKEv2 as IKE IDs to Oracle, which caused Oracle to terminate the tunnel.

7. THE FIX....I upgraded the mgmt server, log server, all of the remote and HA on premise Firewalls to Jumbo Hotfix 43. Then we verified that all the tunnels were set to IKEv2. Oracle changed/verified that their side was using IKEv2 and receiving the Link Selection IP as the only IKE ID, which in our case was set to the externally facing IP address. We've been up and running with this configuration for over a week now and have not had a single issue with VPN Tunnels dropping since making the upgrade to HF43.

Hope this helps folks and thank you to everyone that chimed in. Kind of a weird one.