cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
676
Views
0
Helpful
3
Replies

downloadable ACL failing on uauth..... PLEASE HELP!!!

dave.jones
Level 1
Level 1

Hello.

I am trying to get DACL's working on my FWSM (2.3(3)) From ACS 4. The users authentication is passes through to an RSA 6.1 token server. The user authenticates fine, however the ACL is not downloading.

The bebug shows the following as the user authenticates:

alloc_rip 0x1ec7670

new request 0x345 --> 0 (0x1ec7670)

no user or password - start from getuser

add_req 0x1ec7670 session 0x345 id 0

RADIUS_GET_USER

radius mkreq: 0x345

old request 0x345 --> 0 (0x1ec7670), state 1

wait user - new user testuser. get pass

RADIUS_GET_PASS

radius mkreq: 0x345

old request 0x345 --> 0 (0x1ec7670), state 3

wait pass - pass '***'. make request

RADIUS_REQUEST

radius.c: rad_mkpkt_authen

attribute:

type 1, length 10, content:

attribute:

type 4, length 6, content:

attribute:

type 5, length 6, content:

attribute:

type 26, length 33, content:

Vendor ID 0 0 0 9, type=1, len=27:

send pkt 192.168.1.1/1645

rip 0x1ec7670 state 7 id 0

rip 0x14190a0

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

fb 18 71 56 d7 c4 ad e2 73 30 a9 2e cf 5c 65 3a

: info 0x345

session_id 0x345

request_id 0x0

user 'testuser'

response '***'

app 23

reason 2

skey 'key'

sip 192.168.1.1

type 1

rad_procpkt: ACCEPT

attribute:

type 26, length 61, content:

Vendor ID 0 0 0 9, type=1, len=55:

attribute:

type 25, length 31, content:

RADIUS_REQUEST

radius.c: rad_mkpkt_authen

attribute:

type 1, length 27, content:

attribute:

type 4, length 6, content:

attribute:

type 5, length 6, content:

attribute:

type 26, length 33, content:

Vendor ID 0 0 0 9, type=1, len=27:

send pkt 192.168.1.1/1645

rip 0x1ec7670 state 7 id 0

rip 0x14190a0

: chall_state ''

: state 0x7

: timer 0x0

: reqauth:

fb 18 71 56 d7 c4 ad e2 73 30 a9 2e cf 5c 65 3a

: info 0x345

session_id 0x345

request_id 0x0

user '#ACSACL#-IP-TEST-443f6681'

response '***'

app 23

reason 2

skey 'key'

sip 192.168.1.1

type 1

rad_procpkt: REJECT

abort request 0x345 (0)

RADIUS_DELETE

remove_req 0x1ec7670 session 0x345 id 0

free_rip 0x1ec7670

radius: send queue empty

As you can see the radius request is being rejected and ACS shows the following error in its failed attempts log:

"DACL request from device is not acceptable"

This is the is the configuration on the FWSM relevant to the problem.

access-list DMZ_VENDOR-IN extended permit tcp any host 172.25.25.25 eq telnet

access-list DMZ_VENDOR-IN extended permit tcp any host 172.25.25.25 eq https

access-list DMZ_VENDOR-IN extended deny ip any any

!

!

access-list UAUTH-ACL extended permit tcp any host 172.25.25.25 eq telnet

access-list UAUTH-ACL extended permit tcp any host 172.25.25.25 eq https

!

access-group DMZ_VENDOR-IN in interface DMZ_VENDOR per-user-override

!

aaa-server RADIUS protocol radius

aaa-server RADIUS max-failed-attempts 3

aaa-server RADIUS deadtime 10

!

aaa-server RADIUS-GROUP protocol radius

aaa-server RADIUS-GROUP max-failed-attempts 3

aaa-server RADIUS-GROUP deadtime 10

aaa-server RADIUS-GROUP (AAA) host 192.168.1.1 KEY timeout 5

aaa-server RADIUS-GROUP (MSFC_FWSM) host 192.168.2.1 KEY timeout 5

!

aaa authentication match UAUTH-ACL DMZ_VENDOR RADIUS-GROUP

!

virtual http 172.25.25.25

virtual telnet 172.25.25.25

the ACS acl is very simple for testing purposes:

ACL NAME: test

permit ip any host 192.168.100.100

deny ip any any

the DACL is applied to the users profile.

Many thank for any help on this issue.

3 Replies 3

jhillend
Level 1
Level 1

You are probably running into bug CSCsc89235. This issues is resolved in ACS 4.0, but you have to upgrade your FWSM software to minimum version 2.3(3.13).

Hello,

can you post the entire config of the module ?

Regards,

GNT

The problem appears to be a bug in the FWSM code that we we're running 2.3(3)2 and also in 2.3(2). Version 2.3(4) appears to resolve this issue.

This is a result of the FWSM generating two RADIUS request packets with the same ID for the ACL instead of one. Subsequently the ACS server will reject the request for the ACL but still authenticate the user.

However ACS requires the access list to have a permit statement to the virtual telnet address to work correctly or it will produce the same ACS log entry.

"DACL request from device is not acceptable"

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: