Checkpoint using draft NAT-T Standard in VPN

[Sajid_Abbas]

Hi,

So we've been having frequent issues between our Gaia appliances and AWS where they keep going down randomly.

Recently we've got some positive updates that upon rekeying AWS rejects Checkpoint proposals especially on NAT-T standard. According to AWS, they reject because checkpoint is using draft-ietf-ipsec-nat-t-ike-02_n instead of RFC3974.

I would find this highly surprising given the profile of Checkpoint and that we would be the only one having this issue. 

Anybody having this or similar issue not with AWS but with any other technology.

Sajid

[PhoneBoy]

Just to clarify, are you terminating a VPN between AWS and an on-premise Check Point gateway?

What version/hotfix level of code?

Also, have you opened a TAC ticket to investigate?

(Also, I assume you mean RFC3947, not RFC3974, which is about SMTP)

[Sajid_Abbas]

Hi,

Yes we are terminating VPN on our on-premise gateway. Version is R80.10 JHF70.

TAC case has been going on for quite a while and we are expecting a custom hotfix. AWS are stating that Checkpoint gateway send draft proposal standard and not the RFC3947 (you're correct).

If that indeed is the case, I assume we can't be the only one having these major issues.

Sajid

[PhoneBoy]

I know some customers are terminating VPNs to Check Point gateways in AWS versus terminating on the AWS VPN gateways.

[PhoneBoy]

Just to update, we have a fix for this in R80.20 (Gateway).

For R80.10, you should be able to request a hotfix from the TAC for this.

[Bogdan_Tatomir1]

Hello,

We are facing the same issue right now. We have been stable for around 1 year on R80.10 gateways, and for the last 2 months, we had terrible stability issues with AWS tunnels. Upon investigation we found the root cause was the same as mentioned by OP.

On top of the fact that with no changes were brought to the configuration, the tunnels broke after 1 year with no logical explanation, and the fact that while the draft CKP is using is from 2002 and the RFC was just released in 2005, that surely doesn't give enough time to integrate it in the code, the most annoying part is that we opened a ticket to TAC and the engineer says no such hotfix exists.

Dameon Welch-Abernathy‌ would you be able to help here?

Best regards,

Bogdan

[PhoneBoy]

I did a quick search of past SRs and find at least one reference to this hotfix.

Please send me your SR# privately.

[PhoneBoy]

Just to update, it looks like we fixed this issue in R80.10 JHF 151 and above.

It is specifically noted as PMTR-14920.

[Sajid_Abbas]

Hi Dameon,

We upgraded our firewalls to JHF169 hoping it would resolve all these issues. After this, the VPN only stay alive up for Phase 1 lifetime and do not come up. Instead now we have to bring it up manually.

The issue is so worsened that it doesn't seem beneficial to open another TAC case, and we're just going to roll back to JHF121 which was better (although not fully resolved).

Sajid

[PhoneBoy]

As the issue should have been resolved by this JHF it would be best to open a TAC case so we can properly debug/resolve the issue.

[Bogdan_Tatomir1 · Accepted solution]

Hello,

Thank you for the info. And I'm sorry I was not able to update here also. So the resolution that worked for us was a compound one:

- we upgraded to JHA take 169, as instructed by TAC

- on AWS side we deleted the vpn connection (formerly created in format of vgw-xxx 8 chars long) and created a new one with the exact same settings. This fell into the new 17 characters naming convention which apparently also runs on newer software

This created a stable environment. Also for others reading, make sure you use VTIs with AWS and directional match instead of just the community name in the VPN column in the rulebase.

Side note: After just upgrading to JHA 169 without rebuilding on AWS side, we were seeing two IPSEC SAs created for a permanent tunnel, with one tunnel per gateway pair, which would cause traffic to not flow correctly.

Hope this helps anyone else to fix this issue.

[Sajid_Abbas]

Hi,

We do have an option of terminating CGW in AWS but that's a whole other cost and design. Does it really solve the underlying issue as you still need connectivity back into AWS VPC.

We are in the process of obtaining/implementing a hotfix from TAC. Do you know when will R80.20 update be available for gateway. Website says 2018.

Sajid

[PhoneBoy]

If both endpoints are Check Point it does resolve a lot of potential compatibility issues (but does have different costs as well).

Once traffic is in one VPC it can go to others (assuming you configure VPC connectivity).

R80.20 timelines have not been finalized.

You are welcome to participate in the production R80.20 EA: Want to join R80.20 EA activities?‌

[Khalid_Aftas]

Hi,

We started having this exact same issue with your AWS VPN after upgrade to R80.20 + latest HF.

It seems that the fix in r80.10 is not protfixed to R80.20 ? please advise