Rule matching on sources it shouldn't

[David_Herselman]

Yes, we've successfully installed policy numerous times and are very concerned that a rule is matching any and all source IPs:

The allowed source objects:

Is there a way I can validate the rule base on a running security gateway?

Surely there is no way this could be expected behavior?

[Danny]

Please disable the rule and create two new rules:

one rule for

External -> External IP2

and another rule for

LAN -> External IP2,

then check what your log says.

Btw, why is a private 10. network called External?

[David_Herselman]

Web site provides access for a financial services company. 10.6.0.0/16 is another company's internal network range  which reaches this server through the Check Point security gateway and is therefor external to this environment. Legacy VPN subnet is handled by the router in front of the Check Point security gateway, being replaced with Mobile Access VPN, which is also technically outside of the protected environment.

[PhoneBoy]

You can poke around $FWDIR/state to see what is installed, but it probably won't be all that readable.

I strongly recommend opening a TAC case to get assistance with troubleshooting this.

[Ilya_Yusupov]

For better understanding the issue here we will need full screen shot of your rule base.

you may contact me offline iliay@checkpoint.com and i will assist you to understand the issue.

[Hugo_vd_Kooij]

What does rule 8 itself look like?

[KennyManrique]

Hi,

You can upload the log message of accepted traffic? Did you get something like sk113479:"Connection terminated before detection" in log reason for Unified Rulebase ?

Also, which version of CP components and fix level are you using (GW, Mgmt, SmartConsole)?

Regards.

[Norbert_Bohusch]

Customer of us had exactly same issue with this log message. Issue with connection hold on source column because of identity awareness although access role not used on this rule.

Is fixed in jumbo (don’t remember take) and you might need to  clear all tables by things like taking offline standby and either deleting table entries or also parallel stop of active member.

[David_Herselman]

Ilya Yusupov from Check Point was immensely helpful in tracking this down, installing the hotfix for sk134054 (Rare failure in the Identity Sharing network registration may potentially result in incorrect policy...) resolved the problem:

Gateway was running R80.10 with JHF 121 and sk134253 (Check Point response to SegmentSmack & FragmentSmack) with Identity Awareness blade inactive:

[Expert@fwcp1:0]# enabled_blades

fw vpn urlf av appi ips anti_bot mon vpn

The network security policy exclusively had the firewall blade active:

The problem appears to occur when a policy rule references identity awareness data and there is either a failure obtaining identities (eg the original SK where identity sharing was unavailable) or when the policy includes a rule which had been structured for imminent activation of the Identity Awareness blade: