IKE traffic not processed if source port is other than UDP 500

[GatM]

Since updating to R80.10 (from R77.30) we had stability issues with VPN tunnels to our branch offices where we use different vendor products (Bintec). Updating to R80.20 and R80.30 did not solve the problem. We went though all the basics and removed any inconsequences in configuration on both ends (which weren't an issue when peering with R77.30 or earlier) and tried different configurations with little result.

Eventually we discovered the remote router uses different source ports (not UDP 500) when acting as a IKE initiator (or sending IKE sa delete messages). The Check Point ignored these IKE messages (though the rulebase did allow them to be delivered). This resulted in problems in the phase 2 rekeying procedure because IKE SA tables on both ends got out of sync.

We fixed this matter by fixing/forcing the source port at the Bintec to UDP 500 with a fix provided by their (very reponsive and cooperative) support center. So you might think now: problem fixed, why raise the issue here?

Well, I'm still curious about the  "not our problem, go to Bintec" statement we received from Check Point via our service provider when we raised this issue. I still believe Check Point should've fixed their part of the problem too.

When our service provider raised the issue at Check Point the answer was that the sourceport should be 500 no matter what, if a NAT is present is should switch to UDP4500 as described in RFC 3947 chapter 4. End of story, no fix from Check Point.

However, investigating the matter and reading RFC3947 I found out that it states the following in chapter 3:

 Recipients MUST reply back to the source address from the packet (see
   [RFC3715], section 2.1, case d).  This means that when the original
   responder is doing rekeying or sending notifications to the original
   initiator, it MUST send the packets using the same set of port and IP
   numbers used when the IKE SA was last used.

   For example, when the initiator sends a packet with source and
   destination port 500, the NAT may change it to a packet with source
   port 12312 and destination port 500.  The responder must be able to
   process the packet whose source port is 12312.  It must reply back
   with a packet whose source port is 500 and destination port is 12312.
   The NAT will then translate this packet to source port 500 and
   destination port 500.

Reading the above my conclusion is that if Check Point would be compliant with IKE standards it should have responded to the IKE messages coming from source ports other than 500 and the instability shouldn't have occured. It doesn't really matter what the reason is for chosing another sourceport, it should just reply to that port.

Can someone please enlighten me why it does not behave in compliance with RFC3947 and will this behaviour be changed in future releases? For this matter I prefer to communicate directly with Check Point rather than through our service provider (they consider the case closed too). As I can imagine other customers may run into this problem when upgrading to R80 too I prefer to keep the answer in public, Thanks!

[PhoneBoy]

If your gateway is subject to NAT, then we will allow the use of a different source port for the IKE negotiation.
In the case where NAT is NOT going on, there should be no reason a remote gateway cannot initiate an IKE negotiation from UDP source port 500.
The section of RFC3947 you cited only seems to apply when NAT is involved.

[GatM]

Hello Phoneboy, I agree with you that the initiator should communicate with source port 500. In case of the Bintec routers I was able to change the configuration to do just that.

However, that's not the point I'm trying to raise. The RFC is very clear that the responder MUST reply to original source port, even if the source port is not 500. R80.x nog longer replies to IKE traffic originating from other source ports, though the RFC states it should.

Any customer migrating to R80.x with ipsec tunnels to other vendor equipement should be aware of this behaviour and I'm curious why Check Point is not following the RFC by design.

[Wolfgang]

GatM,

as @PhoneBoy mentioned, the details of the  RFC you are showed are only for the case in NAT.

Maybee you can try to force NAT-T from CheckPoint Gateway following Check Point Security Gateway initiating an IKE negotiation over NAT-T  and your gateways on both sites are using NAT-T.

Wolfgang

[GatM]

The implementation of ipsec in the Bintec router is running the IKE traffic through its own NAT for some reason. It worked fine with R77 but at R80 Check Point suddenly no longer accepted IKE traffic from different source ports. I changed config in the Bintec, but am still curious why Check Point chose for this new behaviour and not comply with the RFC.

[PhoneBoy]

If it worked previously, it might be worth a TAC case to help understand why.