VPN Requirements

[melcu]

First of all hello!  I don't want to be "that guy" but I have another one on the list that's a little tricky 🙂

I have a request for Remote Access VPN with Endpoint Client  but in a different approach.

 1 IP Pool  for Client Based VPN  for laptops

 1 IP Pool for Client Based VPN for Phones (iOS and Android)

1 IP Pool for Contractors

For each IP Pool there should be a way to reserve a specific IP address for a certain user  (so based on user).

first 2 pools should be all-way-in (full tunnel mode) but the 3rd one should be split-vpn.

Pools 1 and 2 will be authenticated by Azure

Pool 3 will be authenticated by ISE.

My first thought was to have 3 different virtual systems each with it's own Office Mode  BUT no! no VSX so it has to be the same machine.

I know about the ipassignment.conf but this seems to be something beyond this point.

Is this even possible ?

Thanks 🙂

Alex

[G_W_Albrecht]

I would ask CP TAC if that is possible!

[melcu]

Unfortunately this is a Request for Proposal and I cannot ask TAC (or I mean I could but on another UC 🙂 ).

I'll head to the local SE to see his thoughts.

[PhoneBoy]

You can do the split tunneling (or not) per group with this: https://support.checkpoint.com/results/sk/sk114882 
You can only configure one IP Pool per gateway in the UI.
However, you can have different pools configured for groups in ipassignment.conf: https://support.checkpoint.com/results/sk/sk33422 

[Duane_Toler]

Your best bet is to use user-based access roles if you're looking to control policies for each user type.

Depending on your centralized user identities (Cisco ISE, Microsoft NPS, SAML) you can do identity server-side things such as RADIUS Accounting depending on your needs. Your RADIUS Accounting updates can feed into other devices/endpoints to pass along the intelligence/telemetry kind of info.

You could look into the option of using DHCP for your VPN clients. You can allow your office mode subnet to be a large network (172.16.0.0/14 on VSX1 ,172.20.0.0/14 on VSX2 ,172.24.0.0/14 on VSX3) and have your DHCP dole out smaller subnets, but I don't think the user identity is passed as part of the DHCP discover or request.  You'll have to dig deeper into this yourself.  This is an untested scenario, so YMMV.

I'd still suggest access roles as that's more manageable, and look into your own capabilities for RADIUS Accounting.

[melcu]

Thanks Duane, but I as already said there's no VSX here.

I thought about the other parties to do DHCP, Authentication, 2-factor and so on but it's quite unclear how this will work especially when they what to have  user groups in security policies and also  based on the AD group to be matched in different Remote Access  Pool, policy, static IP. 
But what will happen when a user is in two groups ? As far as I know all LDAP groups are checked and the first match is the allowed one (or denied).

What if a user is also a Windows and an Android user.  The AD account is the same.  I bet he will be put random in groups

Lots of variables in this issue.

[Duane_Toler]

Ah, I misinterpreted your statement about VSX. Apologies.

Your best bet here is access roles.  You can use access roles to match against AD security groups and/or entire OUs.  If a user is in both AD groups, and you need differential policies for those groups, then you need to create multiple access roles and use those in your rules.  When you do this, you no longer need to use "legacy user access" rules with the RemoteAccess community.  Just use the access role in the Source column and make rules as usual.  If you want to restrict/allow per AD group (access role), then build your policy that way, whatever you were expecting.  You can also configure the access role to apply when connecting from a specific VPN client, so the user group + VPN client can be bound together.  IIRC, all the mobile device VPN clients are the same (Capsule Connect) so I don't think you can limit "users with iOS client" and "users with Android client".  You can choose between the Endpoint Connect client (Windows/Mac) and mobile clients (Capsule).  Sounds like you're about to have a bunch of Access Roles. 😄 

Keep in mind 2 distinct components: authentication vs. authorization.  For decades, we've thought we had to consider these as one (well, RADIUS does).  However, that's not true.  🙂  Don't fret about the authentication portion too much.  If you want limit VPN-eligible users, that's ok and you can do that with LDAP groups in SmartConsole if you want.  The access policy takes care of the authorization part.  Keep that in mind and build the policies accordingly and you'll be in good shape.

You still need an LDAP account unit to pull user identity and information, and the gateway will gather all of the LDAP server group info into the unified user record, and update the identities.  Be sure you have Identity Awareness enabled, do not use AD Query (it's effectively broken anyway and not worth the trouble), and be sure the Remote Access source is enabled.  Preferably, use Identity Collector as well (replacing AD Query).

When users connect, you can run "pep show user all" to see the user details of the user records.