The root issue here is that you can only match one rule per overall Access Control layer (including sublayers), and you are using a Unified policy. When using Legacy you can match one rule in the main Access Control Layer (probably what was allowing your Endpoint VPN users too), and then match the needed application for MAB users in the Legacy MAB layer. But with Unified you can only match one rule, and Endpoint VPN clients cannot match a MAB application rule as it isn't for them, but MAB users *CAN* match a rule intended for Endpoint VPN users and not get access to the MAB application they were expecting.
The Check Point ATC instructors ran into the same thing when attempting a Unified MAB policy for the new CCSE R81.10 class. Look at this screenshot:
The original issue was the webapp_* was inaccessible after logging in to the MAB portal. The fix was to move rule 10 in front of rule 7, because the webapp_* was located on the A-LDAP server and rule 7 was matching the traffic but not allowing access to the needed application object. Once rule #10 was moved in front of rule #7 it started working, this was originally suspected to be a bug but I believe is expected behavior. Here is my more detailed explanation for this ATC lab situation:
In just about every rulebase I've seen, as a best practice VPN-related
rules are added just after the Stealth rule and not just in front of the
Cleanup rule. This is because these rules are normally specifying a
specific VPN Community and you don't want rules with the default VPN
Community of Any to be matching VPN traffic inappropriately, as this can
allow undesired traffic to/from the tunnel, and can be confusing when
trying to look at logs matching your VPN rule and not seeing anything
hitting it because the traffic is matching some earlier unexpected rule
instead.
This VPN rule placement worked in the site to site VPN lab, but not in
the MAB lab because of the LDAP rule. Only one rule can match traffic
in a single policy layer. In this case the LDAP rule #7 matched the
http traffic, but the MAB user could not bring up the site. This is
because a MAB user MUST match a MAB application to be able to access
something through the tunnel, full stop. Service http in rule 7 is not
a MAB resource. This is not a problem in legacy mode with MAB in a
separate layer, as in that case LDAP rule 7 would be matched completing
that layer, then the MAB object would get explicitly matched in the
second/next layer thus granting access to the MAB user.
I have not received confirmation that my explanation is plausible from R&D, but I'm pretty sure it is correct. So I think the takeaway here is that if you are using Unified MAB policies allow all MAB applications first (which Endpoint Security will not match), then have rules matching and allowing Endpoint VPN traffic.
The root issue here is that you can only match one rule per overall Access Control layer (including sublayers), and you are using a Unified policy. When using Legacy you can match one rule in the main Access Control Layer (probably what was allowing your Endpoint VPN users too), and then match the needed application for MAB users in the Legacy MAB layer. But with Unified you can only match one rule, and Endpoint VPN clients cannot match a MAB application rule as it isn't for them, but MAB users *CAN* match a rule intended for Endpoint VPN users and not get access to the MAB application they were expecting.
The Check Point ATC instructors ran into the same thing when attempting a Unified MAB policy for the new CCSE R81.10 class. Look at this screenshot:
The original issue was the webapp_* was inaccessible after logging in to the MAB portal. The fix was to move rule 10 in front of rule 7, because the webapp_* was located on the A-LDAP server and rule 7 was matching the traffic but not allowing access to the needed application object. Once rule #10 was moved in front of rule #7 it started working, this was originally suspected to be a bug but I believe is expected behavior. Here is my more detailed explanation for this ATC lab situation:
In just about every rulebase I've seen, as a best practice VPN-related
rules are added just after the Stealth rule and not just in front of the
Cleanup rule. This is because these rules are normally specifying a
specific VPN Community and you don't want rules with the default VPN
Community of Any to be matching VPN traffic inappropriately, as this can
allow undesired traffic to/from the tunnel, and can be confusing when
trying to look at logs matching your VPN rule and not seeing anything
hitting it because the traffic is matching some earlier unexpected rule
instead.
This VPN rule placement worked in the site to site VPN lab, but not in
the MAB lab because of the LDAP rule. Only one rule can match traffic
in a single policy layer. In this case the LDAP rule #7 matched the
http traffic, but the MAB user could not bring up the site. This is
because a MAB user MUST match a MAB application to be able to access
something through the tunnel, full stop. Service http in rule 7 is not
a MAB resource. This is not a problem in legacy mode with MAB in a
separate layer, as in that case LDAP rule 7 would be matched completing
that layer, then the MAB object would get explicitly matched in the
second/next layer thus granting access to the MAB user.
I have not received confirmation that my explanation is plausible from R&D, but I'm pretty sure it is correct. So I think the takeaway here is that if you are using Unified MAB policies allow all MAB applications first (which Endpoint Security will not match), then have rules matching and allowing Endpoint VPN traffic.
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)Fri 10 Jan 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Sessie 32: Infinity External Risk Management (CyberInt)
.png "Wolfgang"){kind=avatar}
