Split Tunnelling route table issue following r81.10 upgrade

[Net_Works]

Hi All,

We have recently upgraded our perimeter firewall cluster (pair of CP7000 appliances) to r81.10--take79 which seemed to have effected our split tunnelling configuration -- initially after the upgrade, the size of the routing table grew to 3mb; I know this does not sound big but we observed over 28000 routing entries. We were able to fix this by issuing the following to the registry: “ckp_regedit -a SOFTWARE\\CheckPoint\\VPN1 use_range_extension_policy 1”

This command has summarized the routing table to 376KB (equates to just under 5000 routing entries). The issue we have now is all the public IP addresses that were and should have been sent to the VPN Gateway, are now being routed out of the clients local gateway. 

Just need to find a fix that keeps the routing table summarized and all internet addresses routed to the  VPN gateway.

Thanks in advance.

[PhoneBoy]

VPN1 use_range_extension_policy appears to be related to Split Tunneling for Office 365 and similar apps.
More specifically, it allows Office 365 and similar applications to be routed to the Internet while routing everything else to the VPN gateway.
I can see it in an internal SK (sk176303) and, from the SR I was able to find, TAC was who told you about it.

R81.20 has native support for this particular feature and it’s documented in the Remote Access VPN guide: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RemoteAccessVPN_AdminGuide/C...
In previous releases (R80.40 - R81.10 with appropriate JHF), the procedure must be requested from the TAC.

Now, to your specific issue: I suspect this particular parameter was only tested for the use case it was intended (dynamic split tunneling).
From reading your TAC case, it doesn’t appear TAC gave you the full procedure.
Please request from TAC the full procedure from sk176303 and ensure the appropriate IP addresses are not excluded from hub mode.
Otherwise, I can only suggest to continue working with TAC on this.

[Net_Works]

Thanks @PhoneBoy  — you are correct regarding my case with TAC but some of the details from them have been vague hence the post to Checkmates. I’ve gone through my SR and there has been no mention (to me anyway) of the internal sk176303 — I’ll be sure to pick this up with them Monday.

Anyway, thanks for providing the details above — this has been very helpful (the most to date in fact). I’ll update the post once I’ve complete my session with TAC.