PIX User Downloadable ACL Problems

[tonynt]

I recently opened a TAC case on an issue I was having with user downloadable acl's on a radius server. I'm using the user acl's on a intranet pix firewall that protects some servers. We have programmers that need special access to them and I was trying to have the acl's assigned dynamically. It turns out that TAC said even though I had the ACLs correct and they were being applied to the user, I have to have the same acl permitting traffic on the interface that the incoming traffic is flowing. This didn't make sense to me due to the fact that my goal was to get rid of the permanent acl's and not have to worry about using source IP addresses. I could just have the user login via http and he/she gets the acl. Then eventually the uauth timer activates and removes the ACL thus not leaving a hole on the PIX. I may totally be missing the purpose of downloadable ACLs so if someone could shed some light on the subject I would appreciate it :) I anyone has a workaround or other solution to the problem I'm having please feel free to post! Thanks ahead of time!

Tony

[paddyxdoyle]

I am looking into this myself at the moment

Have a look at this post, it looks as though the information you are being told is correct and infact you use ACLs to restrict access on an allready present interface access-list. The interface access-list is processed first.

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1dd6b50d/2#selected_message

HTH

Paddy

[tonynt]

Hey Paddy,

So assuming this is a very shortened version of my outside interface ACL.

access-list permit tcp any host 172.20.12.5 eq 80

access-list permit tcp any host 172.20.96.15 eq 443

and this is my user acl,

permit tcp any host 172.20.4.130 eq 3389

Due to the fact that the specific user acl or a more broad acl does not exist on my interface acl the traffic permitted in my user acl will never work correct?

Thanks again for all the help,

Tony

[d-g-c · Accepted solution]

For authentication and downloadable ACL's to work you need two ACL's on the PIX, the interface ACL and the authentication ACL. You can think of the interface ACL as a trigger for the authentication ACL in that it must allow traffic through to trigger the authentication. It must also permit the same traffic as the auth acl which means it is sometimes easier to make the interface acl more permissive and the auth acl more restrictive.

e.g. if you have users on 192.168.1.0 /24 on the inside interface and you want to authenticate them to allow terminal services access you could if you want configure the inside access list to permit all traffic from 192.168.1.0 /24

! inside auth trigger for 192.168.1.0

access-list inside_access_in permit ip 192.168.1.0 255.255.255.0 any

but deny all in the authentication acl meaning all traffic required authentication/authorisation first.

! authentication for 192.168.1.0

! don't authenticate DNS and ICMP

access-list inside_authentication deny udp 192.168.1.0 255.255.255.0 any eq 53

access-list inside_authentication deny icmp 192.168.1.0 255.255.255.0 any

! authenticate everything else.

access-list inside_authentication permit ip 192.168.1.0 255.255.255.0

!apply access lists

access-group inside_access_in in interface inside

aaa authentication match inside_authentication inside RADIUS

Your ACS/RADIUS ACL would them be configured to

! term serv

permit tcp 192.168.1.0 255.255.255.0 any eq 3389

! http

permit tcp 192.168.1.0 255.255.255.0 any eq 80

Which would provide term serv and http access to an authenticated user. Your logs would show authorization denied for all other access from that user after authentication.

hope this helps.

[tonynt]

Hey d-g-c,

That helped greatly. Thanks for your time!

Tony