How to use IKE over TCP?

[jan9358]

Hello everyone,

a few days ago, we changed our remote access authentication method from username/password to certificate+username/password.
For 95% of our users, everything is working fine. But some other users can't connect to the VPN anymore. The Endpoint Connect client asks the user for his certificate, and then runs in a timeout.

We were already able to find the problem: After asking for the certificate, the Endpoint Client sends a 7000 Byte IKE packet over UDP/4500 to the gateway. According to the MTU of 1500, the packet is fragmented into 5 pieces. 
In the packet captures, you can see that this packet never arrives at the VPN Gateway, because it gets lost on its way. 

The exact same issue is addressed in the R81 Remote Access VPN Administration Guide: 
https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_RemoteAccessVPN_AdminGuide/Topics-...

The guide says, the solution in this case is IKE over TCP, so there are no fragmented UDP packets, but a regular TCP session instead.

My question here is: How can we use this feature? 

Until now, I couldn't find any article describing how to activate IKE over TCP. I just found some commands for 1500 embedded appliances, but not for regular Gaia R81.10. 


VPN Gateway is VSX R81.10 JHF T66.
Endpoint Connect Client is E87.20 on Windows 10.


Thank you in advance!

[Timothy_Hall]

IKE over TCP 500 was originally introduced to permit VPN connectivity through crappy low-end router/firewall devices that did not properly track the state of UDP "connections" and would not allow IKE replies on UDP 500 back through them.  Pretty much all of these devices out there these days can track state for UDP sessions now.

If you'd like to use it, first you'll need to turn on support for it under Global Properties...Remote Access...VPN Authentication...Gateways Support IKE over TCP and reinstall policy; you may need to refresh the site for the VPN client as well.  However I believe if a Check Point VPN client senses that IKE UDP 500 connectivity is not working correctly, it will try the slightly newer Visitor Mode first which essentially tunnels IKE via TCP 443 which should always be allowed. 

You'll need to ensure that Support Visitor Mode is checked on the gateway object under VPN Clients...Remote Access; once again you may need to refresh the VPN site after installing policy to ensure the VPN client knows that this alternative connectivity mode is available.  Visitor Mode is probably the better solution here vs. IKE over TCP 500, as port 443 should always be allowed; can't recall exactly which alternative method the VPN client will prefer or if the VPN client can be influenced to use one or the other.

[Tobias_Moritz]

Have you checked, if the option is enabled in Global Properties?

SmartConsole -> Global Properties -> Remote Access -> VPN - Authentication -> IKE over TCP -> Gateways support IKE over TCP?

Back in the days when we used Check Point Remote Access, our solution for users behind some ISP or router who struggles with the udp/4500 datagrams but not blocking them totally (e.g tunnel gets interrupted after some minutes) was to force the VPN client to use visitor mode (which just uses tcp/443).

Because there was no option in client for that (not sure if this changed in recent versions), we ended up offering a small self-service tool which enables or disables a local client firewall rule which blocks udp/4500 to gateway. Quite a bad hack, but it was a rock solid solution for the affected users.

[the_rock]

I cant seem to find that option in global properties even in R81.20...

[jan9358 · Accepted solution]

Thanks for your replys everyone!

The solution to our problem was somewhere in the middle:

Indeed, the checkbox for "Gateway supports IKE over TCP" in the Global Properties seems to be vanished in R81.10 and R81.20. The Visitor Mode was the solution here, but in a different kind than we expected. 

Enabling the Visitor Mode seems to change the complete authentication process when establishing the VPN connection. Before enabling the Visitor Mode, the authentication was completely done via UDP, and therefore resulted in multiple fragmented packets because of the ceritificate authentication.
After enabling Visitor Mode, the authentication/Main Mode is done via TCP/443, but the Quick Mode is then done via UDP again.

This was basically the same thing I was trying to accomplish by enabling IKE over TCP.

[the_rock]

So all is good now?

Andy

[jan9358]

Yes, it seems so, at least there are no more complaints from our users. Most of the affected users already confirmed that they are now able to connect again.