S2S VPN cannot be connected R82.10 Build 464 - Invalid Key Exchange payload

[Exonix]

Hello All,

I have two CP gateways: one cloud-managed (vR82.10) and another on-premises-managed (vR80.40). The cloud-managed firewall is also configured as a cluster (two 3950s) with ISP redundancy, but at the moment I am configuring the VPN with only one provider. I configured a basic site-to-site VPN, but it’s not working:



the same error in the Debug:

<Exchange serial="2775920" Peer="IP of my FW" Dir="Inbound" Type="Initial">
        <peerIP>IP of my FW</peerIP>
        <Message Valid="Yes" Initiator="Yes" Response="No" higherVer="No">
                <arrivalTime>2026-01-11T20:39:10</arrivalTime>
                <MsgID>0</MsgID>
                <initSPI>d96446baa5702e5c</initSPI>
                <respSPI>0000000000000000</respSPI>
                <Next>SecurityAssociation</Next>
                <Version>2.0</Version>
                <Type>Initial</Type>
                <Length>420</Length>
                <Payloads>
                        <Payload Type="SecurityAssociation" Next="KeyExchange" Length="48" Critical="No">
                                <prop ID="1">
                                        <encr>AES-256</encr>
                                        <prf>PRF-SHA256</prf>
                                        <integ>HMAC-SHA2-256</integ>
                                        <Key-Exchange>Group 20 (384-bit random ECP group)</Key-Exchange>
                                </prop>
                        </Payload>
                        <Payload Type="KeyExchange" Next="Nonce" Length="264" Critical="No">
                                <Method>14</Method>
                                <Key>**********</Key>
                        </Payload>
                        <Payload Type="Nonce" Next="Notify" Length="24" Critical="No">
                                <ndata>**********</ndata>
                        </Payload>
                        <Payload Type="Notify" Next="Notify" Length="28" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>NAT detection source IP</Type>
                                <spisize>0</spisize>
                                <ndata>**********</ndata>
                        </Payload>
                        <Payload Type="Notify" Next="None" Length="28" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>NAT detection destination IP</Type>
                                <spisize>0</spisize>
                                <ndata>**********</ndata>
                        </Payload>
                </Payloads>
        </Message>
        <Message Valid="Yes" Initiator="No" Response="Yes" higherVer="No">
                <arrivalTime>2026-01-11T20:39:10</arrivalTime>
                <MsgID>0</MsgID>
                <initSPI>d96446baa5702e5c</initSPI>
                <respSPI>0000000000000000</respSPI>
                <Next>Notify</Next>
                <Version>2.0</Version>
                <Type>Initial</Type>
                <Length>38</Length>
                <Payloads>
                        <Payload Type="Notify" Next="None" Length="10" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>Invalid Key Exchange payload</Type>
                                <spisize>0</spisize>
                                <ndata>00 0e</ndata>
                        </Payload>
                </Payloads>
        </Message>
        <final_state>message sent</final_state>
        <peerdesc>IP of my FW</peerdesc>
        <final_status>failure (final)</final_status>
</Exchange>

 
The Debug on my FW is a bit different - In the logs, the firewall hostname is shown instead of its IP address:

<Exchange serial="14064076" Peer="HOSTNAME of the 3950" Dir="Outbound" Type="Initial">
        <peerIP>Cluster 3950 IP</peerIP>
        <Message Valid="Yes" Initiator="Yes" Response="No" higherVer="No">
                <arrivalTime>2026-01-11T20:39:11</arrivalTime>
                <MsgID>0</MsgID>
                <initSPI>d96446baa5702e5c</initSPI>
                <respSPI>0000000000000000</respSPI>
                <Next>SecurityAssociation</Next>
                <Version>2.0</Version>
                <Type>Initial</Type>
                <Length>420</Length>
                <Payloads>
                        <Payload Type="SecurityAssociation" Next="KeyExchange" Length="48" Critical="No">
                                <prop ID="1">
                                        <SPI>d96446baa5702e5c</SPI>
                                        <encr>AES-256</encr>
                                        <prf>PRF-SHA256</prf>
                                        <integ>HMAC-SHA2-256</integ>
                                        <dh>Group 20 (384-bit random ECP group)</dh>
                                </prop>
                        </Payload>
                        <Payload Type="KeyExchange" Next="Nonce" Length="264" Critical="No">
                                <Group>14</Group>
                                <Key>*************</Key>
                        </Payload>
                        <Payload Type="Nonce" Next="Notify" Length="24" Critical="No">
                                <ndata>*************</ndata>
                        </Payload>
                        <Payload Type="Notify" Next="Notify" Length="28" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>NAT detection source IP</Type>
                                <spisize>0</spisize>
                                <ndata>*************</ndata>
                        </Payload>
                        <Payload Type="Notify" Next="None" Length="28" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>NAT detection destination IP</Type>
                                <spisize>0</spisize>
                                <ndata>*************</ndata>
                        </Payload>
                </Payloads>
        </Message>
        <Message Valid="Yes" Initiator="No" Response="Yes" higherVer="No">
                <arrivalTime>2026-01-11T20:39:11</arrivalTime>
                <MsgID>0</MsgID>
                <initSPI>d96446baa5702e5c</initSPI>
                <respSPI>0000000000000000</respSPI>
                <Next>Notify</Next>
                <Version>2.0</Version>
                <Type>Initial</Type>
                <Length>38</Length>
                <Payloads>
                        <Payload Type="Notify" Next="None" Length="10" Critical="No">
                                <Protocol>0</Protocol>
                                <Type>Invalid Key Exchange payload</Type>
                                <spisize>0</spisize>
                                <ndata>00 0e</ndata>
                        </Payload>
                </Payloads>
        </Message>
        <final_state>received message</final_state>
        <peerdesc>HOSTNAME of the 3950</peerdesc>
        <final_status>failure (final)</final_status>
</Exchange>

I already tried configuring the VPN with group 14 and without PFS — nothing helped. The Settings of the VPN. With the same settings we have already anothe VPN to CP 1900 (This will be replaced with the 3950)

I would appreciate any help 🙏

[AttiqRahman786]

With ISP Redundancy on 3950s, You might want to change the settings in "Link Selection" under IPSec VPN settings on the cluster object.
When you say I have configured VPN on one ISP link, does this mean you have selected that specific IP under the option "Always use this IP address"?

With the firewall hostname mentioned in the logs, I suspect that is your issue for phase 1.

[Exonix]

After configuring ISP redundancy, the link selection is greyed out.

By “with one ISP,” I mean that I am using only the IP address of the first (active) ISP as the remote peer. You can see this on the first configuration pucture.
I also think that the hostname may have an impact, but I haven’t found a way to resolve this yet.

[TurgutKaplanogl]

Hello,

Did you check without "Apply settings to VPN traffic" ? In other words it would be useful to test by selecting the relevant External interface only via Link Selection. You can proceed based on the outcome you get from there. (Of course, while performing this test, you should plan accordingly if you have multiple VPN sites.)

If it works this way, you can use the HA settings under the Link Selection section for redundancy.

Thank you

[Exonix]

Hi @TurgutKaplanogl 

wow, after unselect the "Apply settings to VPN traffic" the "Link Selection" is active again. Let me test it.

[Vincent_Bacher]

Just noticed this while skimming through your debug logs - I might have spotted something, though I haven't had time to verify it thoroughly:

In the IKE exchange, Firewall 2 appears to be proposing DH Group 20 (384-bit ECP) in the Security Association payload, but the actual KeyExchange payload contains <Group>14</Group> (2048-bit MODP). Firewall 1 then rejects this with "Invalid Key Exchange payload" error code 0x0e (which is decimal 14).

This looks like a potential DH group mismatch or misconfiguration on the initiator side. Might be worth checking that the IKE Phase 1 proposal configuration is consistent on both gateways - specifically that the DH groups match on both sides.

Could be completely off here since I didn't dive deep into it, but thought it was worth mentioning in case it helps.

[Exonix]

This is a good point, because when I changed the DH group to 14, the key exchange remained at group 20 on both firewalls. I thought this was a bug. As you can see in the configuration screenshots, DH is set to 20 — so why does it show <Group>14</Group> then? No matter which groups I specify, it always remains <dh>Group 20 (384-bit random ECP group)</dh> and <Group>14</Group> 😤

[Vincent_Bacher]

Since I can't see anything at the moment, I would suggest submitting a ticket to TAC.

[Exonix]

I just have opened it...

[the_rock]

Did you try change it to DH 14 to see if that makes any difference?

[Exonix]

yes, I tried, but it didn't help, and moreover, I still saw DH 20 in the logs...

[CaseyB]

Are the 3950s running the new R82.10 Build 464 or the original Build 271 + JHF-22?

I ask because when I upgraded ours, GCM ciphers no longer work in Phase 1, we have an open TAC case. So, you might also be hitting an IPsec bug.

[Exonix]

I upgraded it to version 464 before proceeding with any configuration. Did you encounter this bug in the latest update???

[CaseyB · Accepted solution]

Yes, we were using GCM ciphers without issues on Build 271, the upgrade to Build 464 broke them. It doesn't seem like much of a stretch that you could also be running into an IPsec bug.

[Exonix]

how long has your ticket been open?

[CaseyB]

Since last Wednesday, we did a troubleshooting session Thursday and collected logs / debugs.

[Vincent_Bacher]

I'd recommend to press the escalate button then.

[Exonix]

they just closed my Ticket, because one my side 80.40 is out of support...  🤦‍

[_Val_]

It's probably time to upgrade...

[Exonix]

we can't just upgrade with one click and one day. And my request was't about this system, but about 82.10...

[AttiqRahman786]

did you try selecting specific address from topology?
we can look at it in a remote session if you want.

[Vincent_Bacher]

I don’t mean to sound impolite, but R80.40 has been end of life since April 30, 2024. Even in large organizations, that should have provided enough time to plan for an upgrade—I work in a big organization myself, so I understand things can take longer.

By the way, did you open the ticket for the R82.10 device or for the R80.40 one?

[Exonix]

No, no, you’re not being impolite, because you’re not closing this topic 😊
I opened a Ticket for 82.10 (for a certain Customer), because there is no way to open for 80.40. Now I reverted it to 271. I hope it helps...

[_Val_]

With all due respect, it is not exactly clear. Your logs show R82.10 sends an IPsec error to your GW. It does not mean the error is the R82.10 fault. 

Do you have other FWs successfully creating VPN tunnels with either peer?

[the_rock]

Thats unfortunate, but is there any way you could upgrade that side?

[Exonix]

It will take a lot of time, which we don’t have. I just reverted a snapshot to Take 271, hope it will help. By the way, I had another problem with this version, so I wouldn’t be surprised if it works on R81.

[the_rock]

I hope for good results.

[ikafka]

Hi,

Simple suggestion: Check your devices that you created other side.  Since the two devices are managed from different locations (on-premises and cloud), check the gateway objects you created on both sides. it should not be Interoperable Devices.  Because I saw this error in the first screenshot you shared, and our customer had set it as an Interoperable device.

Additionally, you can share vpn tu list IKE command output.

[Exonix]

Hi @ikafka 
In my case, this was indeed an interoperable device. I will check it later, after restoring availability following the revert.

[Exonix]

Hi @ikafka when I create a Check Point Host or Gateway, they are added to the management server, which I don't need, right? Which object should I create correctly? I belive this: