Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
tmorgan
Participant

VPN Access Based on Machine

I have been asked to investigate how we could decommission our old Cisco ASA appliance by terminating our VPNs onto our Check Point. The Site to Site is easy and for some reason my predecessor has already brought he mobile access unlimited licence for the gateway... so far so good! The tricky bit seems to be coming with our Remote Access VPN. I have spent the last 3 days with my head in a lab, Check Mates and admin guides trying to get my head around this. I am slowly concluding this is not possible. That being said, the Check Point RA VPN seems one of the most complicated I have ever worked with and there might be a series of tick this, turn this, jump on this that might get it working!

Our current VPN setup currently is relatively simple. We have two tunnels:

  • Managed Tunnel - This has user certificate and RADIUS (OTP) authentication. Our certificates are distributed out by a windows CA and cannot be exported so we know if they have managed to connect to this tunnel, they are going to be a managed device. At this point we give them the same level of access as if they were on the wired network.
  • Unmanaged Tunnel - This has password and RADIUS (OTP) authentication. If a device connects to this, they can only access a restricted subset of internal resources. We don’t use SSL VPN as we do have one user based rule that allows IT staff to connect and re-join the domain/reissue certs etc.

This seems to me a relatively simple but effective solution to ensure we have relatively good control of what is connecting without having to involve posture checking, MDM solutions etc. This however on a Check Point seems impossible without using two separate gateways.

It looks like I can configure the gateway to do both Cert+RADIUS or Password+RADIUS but what I can’t then do is access that information to enforce different policies base upon it. It also looks like I can configure posture checking however this is very much a binary result, you pass you can have access you fail you do not get access. I could get the capsule licensing and say you fail you must use the capsule however this is more licencing and does not meet the requirement of "special it access for rejoining domain etc".

13 Replies
G_W_Albrecht
Legend
Legend

The question is: Should the same client be able to use either the managed or unmanaged tunnel ? If each user connects only to one of them, we can easily control access by two usergroups and IA Access Roles in rulebase. Otherwise, a user would need two user identities, one for each tunnel.

tmorgan
Participant

Thanks for the reponse.
Should the same client be able to use either the managed or unmanaged tunnel ?
In our case no, ideally only managed clients can connect to the managed tunnel where they need a cert and unmanged to the unmanaged tunnel where they dont need a cert. That being said the Check Point doesnt seem to have the concept of a tunnel, when it comes to RA VPN. There seems to be a remote access community but thats about it.

I feel I am missing something?

Tobias_Moritz
Advisor

Not a really good idea, sorry.

But maybe you can use IA roles as workaround, if your clients are Windows only. Create an access role where user is set to any (or better All identified users) and machines to All identified machines (or a group of computer accounts, if you have any). Use this access role to define rules to allow full intranet access, while RA-VPN clients not maching this role are hitting another rule which only allows cert rollout or AD rejoin. To get this working, you would have to use an IA mechanism which is able to see machine accounts in a reliable way (IA agents e.g.).

 

tmorgan
Participant

I had a feeling this needed a step back with a slightly different approach. I think this might be it. I will go and make a flask of coffee and get ready for an evening of check point abuse. I will let you know what I come up with.

tmorgan
Participant

@Tobias_MoritzI’ve been playing around with this idea; I think it is got merit but I can’t quite break the back of it. I have got the identity awareness blade working so what when a user connects to the network, they must have a domain machine logged in with a domain user (that is a pretty neat trick in itself!). I have then configured the mobile access blade up (ensuring that Remote Access was enabled as an identity source in Identity Awareness). I have then connected a laptop to the VPN, I can see the user’s identity, but I am not getting the machines identity. I did find this post however it never seemed to get resolved:

https://community.checkpoint.com/t5/Remote-Access-VPN/Issue-using-Machine-based-Access-Roles-with-Of...

Taking an educated stab in the dark I installed the Identity Agent software (Full Install). It seems strange this feature wouldn’t be built into the VPN client but my experience so far of the Check Point VPN is it is a bit of a confused cobweb of code. With the Identity Agent I can see it is getting the username from the computer however it is still not getting the machine name. Interestingly even when on the LAN side of the firewall, it is still does not seem able to detect the machines name.
When I open the identity agent, in the Identification Section I get “Machine Name: <Blank>” and in the Connection Status I get “Machine Identity: Not Detected”. (Just to confirm the machine is in the domain, has not tombstoned etc).

I am again at a loss, has anybody got any ideas?

0 Kudos
PhoneBoy
Admin
Admin

Using IDA with Remote Access should give you the username of the user.
I believe the machine name will come as a result of the machine's interaction with Active Directory, which will be correlated to the user as part of pdp.
Sounds like this is NOT working, and a TAC case may be in order to troubleshoot what's going on.
Unless @Royi_Priov or one of his team has a suggestion.

0 Kudos
tmorgan
Participant

Thanks for the quick response. I have contemplated a TAC case but I am also not sure if this is my incompetence or a genuine bug. I have not yet put this onto my production boxes yet as I’m a big fan of ensuring I fully understand the technology first! So this is all spun up in a lab running on evals. If this functionality should work I might try rebuilding the lab from scratch on R80.30. The lab is currently R81 just as an excuse to start getting used to the future etc. Its late here so I am going to get some shut eye but would be interesting to see what others come back with overnight.

Thanks again!

0 Kudos
Tobias_Moritz
Advisor

Let's try to figgure this out...
What do you have enabled as identity source? Only Remote Access? Remote Access and Identity Agents? Remote Access and Identity Agents and AD Query? Something other?

I'm asking because Remote Access as only identity source cannot determine the machine identity (from the gateway perspective) as far as I know. It is just not an available information. Please someone may correct me if I'm wrong here. Maybe this can work with the quite new machine auth feature of Endpoint Security VPN client (the licenced one), never tried it.

If you added AD Query (or the more modern approach with Identity Collector), the gateway can see the machine information, but you have to take into consideration that this all relies on AD security logs (that's what I meant with reliability). If the event log entries are there and gateway still does not learn identities, than PhoneBoy is right, there is some troubleshooting needed. But you said you looked on the Identity Agent side. This cannot work. You will not see machine identity learned from AD logs (by AD Query or Identity Collector) in Identity Agent on client side. You will only see, what the agent knows. To see what the gateway knows, use this command in expert mode:

pdp monitor ip <client-ip>

This will show you, what the policy decision point (PDP) knows. If you have multiple gateways and use Identity Sharing, enter this command on the gateway aquiring the identies. On the gateway which will enforce the access rules, use this command (policy enforcement point):

pep show user query cid <client-ip>

If you are on Identity Agent as only identity source, than you have to make sure, that the agent is sending machine identity to gateway. We use Kerberos SSO everywhere and this is working fine with both user and machine auth. When you are using manual password based login, this will work for user but I cannot see how this can work for machine. Nobody can enter machine credentials. But I have to say, I have never checked this in lab, maybe Identity Agent simple does not do machine auth in that case but telling gateway the identity nevertheless, but I don't think so.

Also: be carefull with the Identity Agent Full Install. It installs the packet tagging driver (which you can use to harden your access roles with the flag "Enforce IP spoofing protection". If you do not want to use this, I would avoid installing this driver by using custom agent (MSI) where you can control what is installed and what not.

PhoneBoy
Admin
Admin

To me, it seems like you could have unmanaged devices connect via Mobile Access Blade (possibly using SNX in Application Mode) and have managed devices with posture checking connect with the Endpoint VPN client?

Though I do like the access role idea @Tobias_Moritz had.
Not sure you need agents for this exactly.

tmorgan
Participant

Thanks for the response, the idea of only allowing the managed devices L3 access to the network is defiantly my preference and certainly more secure. If the "dirty dirty" unmanaged and client must go through a proxy, then that is an extra layer of security that needs to be compromised before it can start doing some real damage. If people are reviewing this post and can do this, I defiantly recommend this approach. However, we have some third parties that also use licenced software on their devices to manage services in our environment also have the remote imaging / cert replacement requirement that we need to cater for; both cannot be done over SNX.

0 Kudos
the_rock
Mentor
Mentor

I apologize if I misunderstood what you are wanting to do, but if you set up different auth methods on the gateway for vpn (which you can obviously d0), what is it exactly at that point that you can't access when people log in? Are auth methods working, but then access is messed up or something else? I know that on gateway properties, if you go to office mode and then authentication, you can choose global auth method (say username/password, radius...etc) and that will override any other method users might be configured for and you can also set up multiple auth methods on that same page, but that does not mean it will use MFA at all (just means that multiple options are available).

I worked with one of our customers for this and we set them up for radius auth and they use their AD credentials to log in via sandblast agent, and then Microsoft authenticator to confirm the log in. Im happy to help you via remote session if interested. Again, apologies if I did not understand your issue correctly.

Andy

tmorgan
Participant

Firstly, thank you very much for everyone’s help, guidance and offers for support. From memory I started on this in anger on the 12th. 9 days later of pretty much eat, sleep, checkpoint, repeat (plus a very understanding wife!) I think I have cracked what I feel is the best way to do this. I will at some point write up a detailed guide on exactly how I have achieved this using the same baby steps I have used to make any troubleshooting easier and with my justifications etc. However, until I have time to write this up, I will give a quick summary here:

My original requirement was Layer 3 VPN using Check Point. I essentially had separated my clients into two categories, managed end points I "trusted" and unmanaged end points I did definitely did not trust. The trusted clients should get full access to the network and the unmanaged clients should just be able to access a VDI environment. This is over simplified but is okay to demonstrate the point I am trying to make. When I have previously done this with other firewalls I have used two tunnels with different authentication types that then provided different levels of access. For the managed tunnel I have used certs that could only be issued to machines in the domain + the users password. For the unmanaged tunnel I have used password + a one time password. Always use two factors, if you can use multiple!

Check Point does not work like this and instead all your users essentially come in via the same tunnel. You can setup different authentication types, but you cannot then use that to make an enforcement decision. The best way to get around this is using the Identity Awareness Blade to configure rules in the policy based upon Access Roles. This is my first shout out specifically to @Tobias_Moritz for a solid suggestion! I wanted to configure two access roles, one for my managed devices and one for my unmanaged devices.

For my managed device access role, I have configured the users to be “All identified users” and the Machines to be “All identified machines”. For my unmanaged device access role, I have just configured the users to be “All identified users”, I have machines section as default. You could of course lock this down to specific groups, networks etc if you so desired.

In fact, in a production environment, you should always make permissive security policies as granular as possible. This helps to ensure that you have a good security posture, but this also helps to avoid the situation where your rule that was originally intended for VPN also starts getting used by your server farm. This doesn’t sound too bad until you try and decommission the VPN solution and have to reverse engineer all the accidental traffic that’s hitting the rule. Rant over!

When I was doing this on the LAN side of the firewall using AD Query these worked nicely and is a neat little trick to discourage people putting unmanaged devices on your network if you do not have 802.1x.

However, when I tried to use the access roles with devices on the VPN these did not work as the computer never got identified. This seems to be a limitation of using Remote Access as an identity source. This was a bit annoying and resulted in a bit more head scratching followed by another good suggestion from @Tobias_Moritz . Use the Identity Agent combined with Kerberos Authentication. Out came the pot of coffee again! After quite a bit of abuse I eventually got this working as I desired. In fact, this works so nicely I suspect I am going to disable AD Query and just use the Identity Agent with Kerberos moving forwards. As pointed out somewhere in this thread using AD logs is not really rock solid.

I am not going to bother using this on unmanaged clients as I only need their user’s identity and I can get this through the remote access blade. It might be worth noting that identities sourced from Remote Access have a higher priority than identities sourced from the Identity Agent. This means that the Identity Awareness source that gives both machine and user identities should get overrules by the Remote Access blade that just gives the users identity. However, I suspect because the Identity Agent has more information this still seems to takes priority.

PhoneBoy
Admin
Admin

I can't think of a situation where I'd use AD Query over, say, Identity Collector or one of the agents.
In any case, great work and I look forward to seeing the write-up when you have time!

And I agree with your decision not to get too deep on unmanaged clients.
If they're managed, it's a safe assumption they either have the necessary configuration/software or can easily get it 🙂

0 Kudos