topic Re: S2S VPN - IKE fragmentation / Support of RFC7383 in Firewall and Security Management

S2S VPN - IKE fragmentation / Support of RFC7383

k_b — Thu, 20 Apr 2023 06:47:05 GMT

Dear all,

We are currently facing issues when building a S2S VPN to a Cisco ASA. Due to a IPS / IDS security applicance between the two gateways, IKE packets were dropped because there are fragmentated.

The tunnel is / should be initiated by the Cisco ASA.
When testing the initiation from the CheckPoint, IKE packets fare ariving at the Cisco ASA but the replies are getting blocked.

As a workaround, the security appliance has been adjusted to not block the fragemented packets in this context, but we have to find a solution for this.

The adminstrators of the remote gateways are passing the buck to us right now. They state that the Cisco is supporting and trying to use the mechanism provided / described in RFC 7383 (https://www.rfc-editor.org/rfc/rfc7383.html) but the CheckPoint is not willing to negotiate the IKE fragmentation.

So two questions arise.

Does CheckPoint support the RFC 7383 and in case it does, must it be enabled in the configuration. Unfortunately was I not able to find anything concerning this.
Have you ever faced a similar issue when connecting to a Cisco ASA and I case you have, how have you fixed the issue?

I found the https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98074&partition=Advanced&product=IPSec but this does not really give a hint for what I am looking for, atleast for my understanding.

Anyway I wonder if this RFC / the support of the RFC is really the issue. Why?

When the IDS / IPS is active we see no packet at all from the remote gateway. How can the (missing?) support for the RFC on the CheckPoint then be the issue?
Even if the CheckPoint does not support the RFC. Why does the Cisco ASA not send smaller packets by configuring the local input / interface settings?
The VPN is established via 500/udp and the usage of PSK. The initial packets should not be too big.

Thanking you in advance.

Re: S2S VPN - IKE fragmentation / Support of RFC7383

G_W_Albrecht — Thu, 20 Apr 2023 07:02:06 GMT

As the CP includes a very goog IPS this topology is rather looking strange... I would assume that without the 3rd appliance as MITM all would work !

Re: S2S VPN - IKE fragmentation / Support of RFC7383

k_b — Thu, 20 Apr 2023 07:32:22 GMT

The CPs are part of a larger network, which is (also) protected by the IPS, so that CPs would not any impact of the other aspects / parts of the larger network. And yes you are correct: Without the 3rd appliance everything is working well. But we do not have any impact on this device, this is like a part of the network in between which we are only using.

Re: S2S VPN - IKE fragmentation / Support of RFC7383

G_W_Albrecht — Thu, 20 Apr 2023 07:34:10 GMT

So i would assume that the 3rd appliance is the culprit...

Re: S2S VPN - IKE fragmentation / Support of RFC7383

PhoneBoy — Fri, 21 Apr 2023 19:58:55 GMT

From your description, it sounds like the middle device is the culprit, not our gateway.
This is going to require a TAC case: https://help.checkpoint.com

Re: S2S VPN - IKE fragmentation / Support of RFC7383

k_b — Sun, 23 Apr 2023 14:06:26 GMT

Hi,

Thank you so far for the replies. Yes, the IPS is currently causing the issue but only because the IKE packets are getting fragmented. As described in the RFC it is recommended to avoid such a fragmentation by implementing RFC 7383. For simplfy the whole case I would like to ask only following two questions.

Does CheckPoint support the RFC 7383 and in case it does, must it be enabled in the configuration?
Did you ever encountered such an fragmentation issue in the past? And in case you did, how did you solve this?

With kind regards

Re: S2S VPN - IKE fragmentation / Support of RFC7383

Chris_Atkinson — Sun, 23 Apr 2023 14:45:24 GMT

What is the MTU between points A & B, have you isolated where the fragmentation occurs?

Re: S2S VPN - IKE fragmentation / Support of RFC7383

k_b — Mon, 24 Apr 2023 04:23:23 GMT

Hi,

The MTU size is 1500 bytes. The fragmentation takes place between the ASA and the ISP, I guess directly at the ASA. This device is supporting the mentioned RFC and tries to negotiate this IKEv2 fragmentation with the CheckPoint. Due to the fact that the CheckPoint (at least in the current configuration) does not response as expected to this negotiation, the ASA does not use the fragmentation on the IKEv2 level and sends out a the fragmentated IP packets.

Re: S2S VPN - IKE fragmentation / Support of RFC7383

Chris_Atkinson — Mon, 24 Apr 2023 07:24:34 GMT

Why are they being fragmented if there is no MTU mismatch - how big are the IKE messages!?

Re: S2S VPN - IKE fragmentation / Support of RFC7383

PhoneBoy — Tue, 25 Apr 2023 02:09:21 GMT

I also only see one TAC case where this RFC is even mentioned, much less any mentions in documentation and such.
Based on what you've described, support for this is an RFE that should be consulted with your local Check Point office.
If you want 100% confirmation, please consult with the TAC.

Re: S2S VPN - IKE fragmentation / Support of RFC7383

k_b — Tue, 25 Apr 2023 15:56:55 GMT

Thank you all so far. I will contact the TAC and try to get an confirmation.

Re: S2S VPN - IKE fragmentation / Support of RFC7383

eakselrod — Thu, 16 Nov 2023 12:26:57 GMT

The solution can be easily be found by searching

ike fragmentation

in the support center.

It is the first result

https://support.checkpoint.com/results/sk/sk126092
Please note that the RFC state clearly:

2.4. Using IKE Fragmentation

IKE fragmentation MUST NOT be used unless both peers have indicated
their support for it. After that, it is up to the initiator of each
exchange to decide whether or not to use it.

In my opinion the real questions are 2:

1) Why the customers are not moving to OCSP which is what is recommended these days and the following OCSP for IKEv2 explain this in details https://datatracker.ietf.org/doc/html/rfc4806

2) Why the CRL grew so much and why it is not being cleaned (removing revoked certs). There is no reason CRL will grow to such sizes that will require fragmentation. If it does , the root cause need to be investigated and resolved.