Office Mode traffic hitting Cleanup Rule despite correct Identity Awareness

[jennyado]

Hello everyone,

We are currently investigating an Identity Awareness behavior in a Remote Access VPN deployment and would like to know if anyone has experienced something similar.

Environment

• Remote Access VPN (Endpoint Security VPN Client)
• Office Mode IPv4 addresses
• Authentication through Microsoft Entra ID using SAML
• Identity Awareness enabled
• Access Role-based policy
• Ordered Access Role rules implemented after TAC recommendation

Background

Originally, our environment used a nested inline layer to control access for Remote Access VPN users. We noticed that a significant amount of traffic was hitting the Cleanup Rule of the inline layer, causing users to lose access to resources that should have been allowed.

To mitigate this, TAC recommended replacing the inline policy with ordered Access Role rules. During the last few months, we gradually migrated all VPN user groups to these ordered rules, placing them above the original inline layer.

Our expectation was that, once the migration was complete, the inline layer (including its Cleanup Rule) would no longer receive traffic.

However, after completing the migration, we are still observing similar behavior.

Observed behavior

Traffic from the same Office Mode client successfully matches the expected ordered Access Role rule, but other connections from the same user/IP later hit the Cleanup Rule of the lower inline layer.

From the traffic logs, we can see that the user and group information are correctly identified.

During a remote session with TAC:

• PDP Monitor showed the expected IP-to-user, group and role associations.
• Authentication through Microsoft Entra ID completed successfully.
• User group membership appeared to be correctly resolved.
• TAC suggested enabling Browser-Based Authentication as the recommended solution.

Documentation reviewed

According to Check Point documentation, the identity sharing process works as follows:

• The PDP detects the user login.
• The PDP performs the group membership lookup.
• The PDP calculates the matching Access Roles.
• The PDP creates an Identity Awareness Session associated with the source IP.
• When traffic arrives, the PEP queries the PDP for the current identity associated with the source IP before evaluating the Access Role-based policy.

This makes us wonder whether the issue could be related to the persistence or synchronization of the Identity Awareness Session rather than the authentication process itself.

Questions

1. Has anyone experienced Office Mode traffic intermittently matching a Cleanup Rule even though the user is successfully authenticated and the correct Access Role is visible in the logs?
2. Is there any known scenario where the PDP contains the identity, but the PEP cannot consistently use that identity during policy evaluation?
3. TAC recommended enabling Browser-Based Authentication. Is this recommendation intended to improve identity persistence/synchronization between the PDP and the PEP, or does it address a different limitation?
4. Has anyone deployed Browser-Based Authentication in a Remote Access VPN environment using Microsoft Entra ID (SAML)? If so, did it resolve similar Access Role matching issues, and were there any noticeable side effects?

Any insight or similar experience would be greatly appreciated.

[jennyado]

I was searching for other options and in our R81.20 environment, we believe Identity Cache Mode is a possible solution. We seek your validation on the following:

• Proposed Principle: Enabling pep control identity_cache_mode enable changes the logic from "prefer to delete" to "prefer to keep".
• Stability: This maintains sessions for 24 hours by default, preventing the "Identity Flapping" we see during SAML updates.
• Manufacturer Best Practice: The R81.20 guide explicitly states: "Do not disable the Identity Cache Mode".
• Full Coverage: It stabilizes all protocols (TCP/UDP/ICMP), which is critical for our VPN users.

Any insight or similar experience would be greatly appreciated.

[PhoneBoy]

Without knowing more about the actual rules and traffic involved, it’s possible it may not be related to Identity Awareness.
Also, version/JHF level is relevant for discussion purposes.

[jennyado]

Environment Versions:

• SMS: R82 Take 91
• Azure Cluster: R81.20 Take 141

The affected rule is configured with an Access Role object in the Source field. This object is configured with the Office Mode network in the Network section and the Internal User Group object in the Users section, following the naming convention EXT_ID_<role_name>, as described in the documentation.

Further down in the policy, there is the rule containing the nested policy (Inline Layer) that was initially configured. In the parent rule, the source is defined as the Office Mode network object, while the child rules use the previously mentioned Access Role objects.

Additionally, the Cleanup Rule of the nested layer is configured with the Accept action due to the behavior observed and discussed during the previous analysis.

[emmap]

You may have hit this issue: https://support.checkpoint.com/results/sk/sk184717 

[PhoneBoy]

Yeah, that seems to track here, which means you should upgrade the gateways to R82 to resolve the issue.

[Chris_Atkinson]

I agree with Emma, for added context which "Identity Awareness" sources are you using out of interest?

Remote Access, Identity Agent etc...

[jennyado]

Just Remote Access