I’ve successfully set up a corporate remote access VPN with LDAP authentication. Currently, my firewall policy includes an access role that permits any Active Directory (AD) user to access internal resources.
However, I’d like to restrict access to specific resources for certain users. To do this, I created a new access role containing only two users and configured the firewall policy to limit access to select resources for this role. I’ve positioned this new firewall policy above the existing policy that applies to all AD users.
The issue I’m facing is that when users from the restricted access role connect and attempt to access resources, the traffic seems to bypass the restricted firewall policy and instead matches the open policy below it. The restricted policy isn’t registering any hits.
Do you have any insights into why this might be happening?
Well, it should not.
Check if the users get associated with the correct Access Roles. After they connect to the gateway, run
pep show user query usr USERNAME
on Expert shell of the gateway. It should show that the identity source (“Client Type”) is Remote Access and what Identity Roles are assigned. Make sure these are correct.
(The USERNAME will match by substring, so searching for paul may also find paula, paulton etc.)
If they are not, your Access Role isn’t working for some reason.
edit: I just realised you mentioned that it wasn’t matching the access-role correctly. So the below isn’t the answer you need, however it will be applicable once you get the access role to work.
This is an order of operation issue, because you need to explicitly deny their access to everything below the explicit allow rule.
If they are still and AD user, then they match the all AD users role and rule.
The Access role with the two users only matches for those specific source and destinations in that rule, but if you don’t have a deny rule then anything that doesn’t match the rule continues down the rulebase to hit the all AD users and allows them.
Assuming you have the rules:
| Rule # |
Source Users |
Source |
Destination |
Action |
| 1 |
2 specific |
Remote_Access |
Limited Access |
Allow |
| 2 |
All AD Users |
Remote_Access |
Everything |
Allow |
| 99 |
Any |
Any |
Any |
Deny |
In the above scenario, the2 specific users match rule 1 and it allows the traffic to the Limited Access group, however if they try to access Everything, then it doesn’t match rule 1, but it does match rule 2 so allows the access, and never gets as far as the default drop rule 99.
What you need is something along these lines:
| Rule # |
Source Users |
Source |
Destination |
Action |
| 1 |
2 specific |
Remote_Access |
Limited Access |
Allow |
| 2 |
2 specific |
Remote_Access |
Everything |
Deny |
| 3 |
All AD Users |
Remote_Access |
Everything |
Allow |
| 99 |
Any |
Any |
Any |
Deny |
In this scenario they do not get as far as rule #3 as if they try to access anything outside of the Limited Access group, they get explicitly denied by rule 2, while everyone else will not match rule 1 or 2 and go right to rule 3.
Have you configured the gateway to acquire identities from Remote Access logins? Make sure the option is ticked on the Identity Awareness blade.
I will try this, thank you very much.
Thank you for this. Yep, I had this in mind but it’s not matching the access role as discussed. I see your other comment, thank you, it could be the issue.
Thank you
Thank you, yes it’s enabled.
It should also show you in the Login records on the log server what access-roles are assigned.
This may be a mismatch between login IDs and LDAP usernames.
You may be logging in with BobA as the usernames, however the LDAP username may be [email protected], so that’s why the access role doesn’t match. The firewall knows that the remote access IP is associated with BobA, but you have used the LDAP identity of [email protected] in the access role.
Its the difference between the sAMAccountName and UserPrincipalName as configured in AD. You need to ensure that your LDAP lookup matching is correct.
You are likely logging in with the UPN or UID (BobA), so you need to set your LDAP Lookup Type to this so it can successfully take the username as provided from the VPN client to the gateway, look it up in LDAP and retrieve the sAMAccountName and/or group membership which can then be used in the Identity Awareness engine to tie the login name to the AccessRole.
Though it does depends entirely how you have authentication set-up 
This is useful, thank you very much.
