Hi JG, I have tried IP based network restriction;

Default Group settings - In Per Group Defined Network Access Restrictions Section

Box ticked for Define IP-Based Restrictions

Table Defines : Denied Calling/Point of Access Locations

All AAA Clients * * entered

This stops VPN clients connecting through the PIX, (though it does the job of allowing only admin access to the users in the admin group)

Am I missing something?

Very common problem. I've solved it twice over the last 6 years with ACS. I'm sketchy on the details. But here goes. First option to explore is using RADIUS for VPN access, then TACACS on all the Cisco switches and PIX firewall. That would make it alot easier. I think that with TACACS, you can build a NAR based on TCP port number instead of IP address....

http://www.cisco.com/en/US/products/sw/secursw/ps2086/products_tech_note09186a0080858d3c.shtml

So you'd have a group with 3-4 Administrators that can access PIX CLI, and another group of VPN users that can't access the PIX but can VPN in. So on the VPN group, put a NAR that restricts access to SSH/Telnet TCP ports?

This comes up everytime I install an ACS server, (every 2-3 years), and it's always a trick.

Please let me know if this works for you. And if it doesn't, let us know how you fixed it. I think I can get back into the ACS I last did this with and take a look, but I'd have to call up and make a special trip.

I have tried implementing NARs but it doesn't work, it doesn't seem to differentiate between VPN access and access to the PIX, it either permits or denies access.

I have even tried denying access based on SSH (All Clients,22,*) and that doesn't work (it actually ignores it).

You should choose only VPN device, in IP based NAR with condition deny. Now all would be allowed other then vpn.

It should surely work.

Regards,

~JG

Hi JG

I've tried that but no luck, just to confirm that the users use the PIX as a VPN device to connect in, but I want to restrict them admin access to the PIX.

IP-based NAR filters work only if ACS receives the Radius Calling-Station-Id (31) attribute. The Calling-Station-Id (31) must contain a valid IP address. If it does not, it will fall over to DNIS rules.

Please check the radius debug and see what we are getting

Regards,

~JG

Hi JG, I'm using TACACS for this setup, am I right in thinking that NAR's don't work well with TACACS?

Hi JD,

I would suggest you to check this link about Attributes for IP-Based Restrictions used by TACACS+ protocol,

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.1/user/SPC.html#wp766385

Now you should be able to check what attributes your firewall is sending.

Regards,

~JG

Yeah. I just made this work. Exact same situation. ASA with VPN access authenticates via RADIUS to ACS, then I set up tacacs in the ASA and authenticated SSH via TACACS to the ACS. I built NAR, and I did "IP Based access restriction", then chose "Denied Calling point", chose the ASA only, any port, any source address, applied the NAR to a group of users, and users in that group can now VPN in, but they can't SSH in.

And the guy next to me just figured out another way. He did a "Per Group Defined NAR" in ACS, and "Define IP Based Restriction", and Table Defines "Permitted Calling point". Then he chose just the ASA-VPN client which uses RADIUS. All other clients are denied, so that means that group can ONLY VPN in, and can't SSH in. SSH is a second AAA client, with TACACS as the protocol. So there's 2 AAA clients for the ASA, one using RADIUS and one using TACACS.