Strange service match for firewall rules

[Graham1]

I am witnessing a strange matching situation, and trying to find out if this is expected.

We splitting our Servers to a new VLAN (long overdue and don't get me started).  

I have created a new rule:
src: 10.95.20.0/24
dst: 10.95.0.0/20
svc: Active Directory Application
action: Accept

This rule is just below:
src: 10.95.20.0/24
dst: 10.95.0.0/20
svc: (Negate) Active Directory Application
action: Accept

I am find that the logs for rule 4 are matching for tcp/389, eventhough it should match rule 3.

fw up_execute src=10.95.20.20 ipp=6 dport=389 dst=10.95.0.71
Rulebase execution ended successfully.
Overall status:
----------------
Active clob mask: 2
Required clob mask: 2
Match status: POSSIBLE
Match action: Accept

Per Layer:
------------
Layer name: Std-EXTFW1 Network
Layer id: 0
Match status: POSSIBLE
Match action: Accept
Possible rules: 1 3 4 16777215

The Active Directory Application object is using recommended Match Settings.  According to what I read in documentation, it should be working under rule 3.

Am I missing something major?

Thanks in advance.

[Wolfgang]

@Graham1 one simple question to start…. How about the policy install after adding the new rule, done ?

[PhoneBoy]

The Active Directory application requires more than one packet to match successfully.
Apparently, the relevant traffic isn't matching the signature, which is why it is falling through to the next rule.
To fully understand why, you would need to take packet captures and open a TAC case: https://help.checkpoint.com 
In this case, you should use the LDAP service (TCP 389), which will match on the first packet. 

[the_rock]

My personal experience with fw up_execute command is, lets just put it bluntly, very inconsistent. I find it works properly MAYBE 50% of the time, so I would not rely on it too much. 

What do you see in the logs?

Andy

[Graham1]

@Wolfgang Yes this policy is installed and active.

@PhoneBoy I have already tried support and their suggestion is to remove rule 4 since it is overlapping rule 3.  I just didn't think it should be "inconsistent" in the is way.  What you are saying does make sense however

@the_rock The logs confirm what fw up_execute confirm what the logs are saying in that some packets are matched by rule 3 and other packets are match by rule 4.  all on tcp/389

I guess my only re-course in the instance is to create a service group with the match services in the app object.

[the_rock]

I know sometimes disabling/re-enabling rule can also work, just remember to install policy after every change.

Andy

[PhoneBoy · Accepted solution]

The rules don't overlap, the issue is the signature isn't matching everything for whatever reason.
Easiest way to resolve this is to use a group of simple TCP/UDP services instead of the Active Directory signature.