Support Center > Search Results > SecureKnowledge Details
VPN tunnels with 3rd party peers fail because of mismatched IDs Technical Level
  • VPN tunnels with 3rd party peers fail because of mismatched IDs.
  • user.def granular encryption ranges tables: subnet_for_range_and_peer and max_subnet_for_range, are not affecting encryption IDs in R80.20, once ike_enable_supernet is set to "false". This causes VPN tunnels with 3rd party peers to fail because of mismatched IDs.

The issue occurs when the R80.20 feature "supernetting per community" is enabled.


This problem was fixed. The fix is included starting from:

Check Point recommends to always upgrade to the most recent version (upgrade Security Gateway / upgrade Cluster).


In R80.20 and R80.20 Jumbo Hotfix Accumulator Takes lower than 43, you can disable the feature "supernetting per community" to resolve the issue.

Note: The feature "supernetting per community" continues to work when you configure the value of the parameter "ike_enable_supernet" to "true" in the management database using the GuiDBedit Tool (see sk101219).

  1. Connect to the command line on the Security Gateway / each Cluster Member.

  2. Configure the value of the kernel parameter "enable_supernet_per_community" to "0":

    fw ctl set -f int enable_supernet_per_community 0


    • This command configures the required parameter value in the current session, and also in the $FWDIR/boot/modules/fwkern.conf file (to survive reboot).

    • It can take some time before the new configuration applies because the existing connections can still establish VPN tunnels using the old IP address ranges.

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Give us Feedback
Please rate this document