Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
k_b
Contributor
Jump to solution

S2S VPN - IKE fragmentation / Support of RFC7383

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=&solut... 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.

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

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.

View solution in original post

0 Kudos
10 Replies
G_W_Albrecht
Legend
Legend

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 !

CCSE CCTE CCSM SMB Specialist
0 Kudos
k_b
Contributor

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.

0 Kudos
G_W_Albrecht
Legend
Legend

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

CCSE CCTE CCSM SMB Specialist
0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos
k_b
Contributor

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

0 Kudos
Chris_Atkinson
Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
k_b
Contributor

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.

0 Kudos
Chris_Atkinson
Employee
Employee

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

CCSM R77/R80/ELITE
0 Kudos
PhoneBoy
Admin
Admin

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.

0 Kudos
k_b
Contributor

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events