cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2953
Views
0
Helpful
2
Replies

ASA Group-Lock and IP Pools

pixelchimp
Level 1
Level 1

Hi,

we have a Cisco ASA, that has two Client IPSEC VPN profiles (tunnel groups) - one for admins and one for normal users.Each tunnel group uses a different IP Pool. on the inside of the ASA is another firewall, which allows the users access to resources based on the IP address they have (admin users ip pool is allowed to do more etc).

this works fine, however we would like to prevent a normal user from being able to log into the admin tunnel group (assuming they obtained the PCF file for the admin profile) - i believe the correct way of doing this is via group-lock - we have setup our RADIUS server to send back Class (25) and that all looks fine (doing a debug aaa common 255 shows correct policy being assigned etc (ie, non admin user gets given the normal user group policy).

However, as we have implemented the restrictions to take place based on IP address on an internal firewall - the user still gets an IP address in the Admin IP Pool, not the user pool (when authenticated via the admin tunnel group).. is there any way to influence this?

either deny a user connecting to the admin tunnel group all together if they are not part of the correct group-policy (returned by RADIUS in attribute 25) - this is the preferred option.

or ensuring a normal user trying to authenticate via the admin profile still gets a normal user IP Pool address, not a admin pool address?

thanks for you assistance.

g

2 Replies 2

Herbert Baerten
Cisco Employee
Cisco Employee

Hi g,

if you really want to use group-lock,  you'll have to configure this:

group-policy GP-users attributes

   group-lock TG-users

group-policy GP-admin attributes

   group-lock TG-admin

I.e. in each group-policy, you specify which tunnel-group the user must land on to be allowed to use this GP.

So if a normal user connects to TG-admin and radius pushes GP-users, the connection will fail.

A variant of this is where you don't configure the above, but have the Radius server send the "group-lock" attribute in addition to the class attribute.

Now since you're using Radius, there are various other ways to achieve the same result.

The easiest is probably to remove the pool from the tunnel-group, and put it in the group-policy.

This way you can even delete one of the 2 tunnel-groups, so everyone connects to the same TG but gets a different GP from Radius, and the GP defines the pool.

Alternatively you can define the name of the pool (and possibly other group-policy attributes) on the Radius server as well (so then you don't even need 2 group-policies). Or go even one step further and have the Radius server push the IP address itself (so you don't need any pools on the ASA, and you can even define a "fixed" ip address per user ).

And if that is not enough choice, you could also do it using DAP (dynamic access policy) where you can define rules similar to:

1. if tunnel-group == A and radius.class == B then deny access

2. if tunnel-group == B and radius.class == A then deny access

3. else allow access

I hope this helps, if you want to know more about any of the options just shout

Herbert

Herbert,

brilliant, i didnt know you could assign a pool to a group-policy, i thought it was limited to a tunnel-group..  that would solve the issue then. thank you very much, I'll test this out..

g