- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Check Point Proactive support
Free trial available for 90 Days!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
The 2022 MITRE Engenuity ATT&CK®
Evaluations Results Are In!
Now Available: SmartAwareness Security Training
Training Built to Educate and Engage
MITRE ATT&CK
Inside Check Point products!
CheckFlix!
All Videos In One Space
We have attempted to do something which I expected to work and has not. Can anyone see a flaw in my plan here...
R80.10 (jumbo 103) management server
R77.30 gateway cluster
R77.30 second line firewall cluster to a more secured network zone
There's a shared LAN in-between the two clusters.
All routing etc. is all fine, this is just about Access roles and user identity.
We have (currently working) Mobile VPN (SSL) users with a native application rule allowing a user to Remote Admin (Famatech Ramin) or RDP through the Internet gateway cluster, where the connection is decrypted and then routed via the shared LAN to the second line cluster, where we have a rule allowing the *entire* Office Mode Pool to access a server within that more secure zone. This is working fine.
What we wanted to do today was to limit that access on the second pair to specific users. Traditionally I would have used ipassigment.conf to allocate specific users an IP address, created objects for these and used them on the second line firewalls. We wanted to be more 'up to date' and use access roles to achieve this in a better and more manageable way.
We enabled Identity Awareness on the second line firewalls, unticked all methods with the exception of Identity Sharing *from* the gateway cluster. We created an Access Role with a *LOCAL* Check Point user group as the 'users' and the Office Mode IP Pool as the network. and added this to a rule that looks like this:
We see the connection come through the gateway cluster and get decrypted, then we see it reach the second line cluster but the rule does not seem to be applied, even thought the username *is* recognised and logged.
I have redacted the username here but it is the same in both fields on both log entries. You can see from the ORIGIN that the connection is allowed, and decrypted by fwl-0001 and then the second line firewall fwl-0010 drops it (at the cleanup rule).
Should this work?
Any thoughts on why it doesn't would be much appreciated.
An Access Role can be any combination of User/IP/AD Machine.
Clearly it's seeing the user, but it's not matching the IP or AD Machine (which I assume is set to "any" in this case).
What does pep show user all show in this case?
Yes, the machine is set to ‘any’ in the Role:
The network is set to the office mode pool(s) – but removing these and setting to ‘any network’ does not make it work.
The pep show user all results are interesting:
The gateway firewall shows lots of users, all obtained from 127.0.0.1 and includes the Check Point Mobile test user for this job ‘emerson3’ and gives the IP address as the correct office mode pool address applied to this connection:
The second-line firewall has a list of users, all obtained from 10.157.30.3 (the LAN side IP address of the primary member of the gateway cluster) – all as one would expect.
And these users are all users on the LAN who have some access *through* the second-line firewalls.
The test user (who is a local Check Point mobile user only and not an AD user) is visible on the gateway as soon as I authenticate with Check Point mobile. The first time I tested it today this user did *not* appear on the second-line firewalls.
I reverted to the old rule (allowing the whole office mode IP pool) over the weekend. Then today when I put the Role back in the rule and tested again, the second-line firewalls, displayed the test user (in pep show users all) even before I tried to access through the second-line to the secure zone.
When I did test it…it all worked!
Here’s the user with its ID on the outer gateway and on the second-line:
Why did it not work before? No idea, but the ‘pep show user all’ command helped me to get to this point anyway, so thanks very much for that!
I am pleased that we have been able to pass user details from the gateway to the second-line firewalls with *NO* user capturing method on the second-line firewall other than ID sharing from the gateway cluster; this is what I hoped would work and it has!
Following your suggestion to ue that command, I looked up PEP and PDP etc. in the Identity Awareness guide and I understand the purpose of each process but I can't find what PEP and PDP stand for? It's help to know for committing it to memory.
Thanks again for your reply.
I don't remember what pdp/pep mean as an acronym, but: pdp is responsible for acquiring the identifies, pep distributes to the gateways.
Perhaps the "E" in pep means "enforcement" in this case
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY