Solved: ipsec vpn cisco asa and acs 5.1

ngo duyen · ‎12-30-2011

we have configured ipsec vpn cisco asa authentication by acs 5.1:

Here the config in cisco vpn 5580:

access-list acltest standard permit 10.10.30.0 255.255.255.0

aaa-server Gserver protocol radius

aaa-server Gserver (inside) host 10.1.8.10

key cisco

aaa-server Gserver (inside) host 10.1.8.11

key cisco

group-policy gpTest internal

group-policy gpTest attributes

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value acltest

tunnel-group test type remote-access

tunnel-group test general-attributes

address-pool localpool

default-group-policy gpTest

authentication-server-group Gserver LOCAL

authorization-server-group Gserver

accounting-server-group Gserver

tunnel-group test ipsec-attributes

pre-shared-key cisco123

In the ACS, we config a group user: VPN users. all user VPN in that group. ACS have access policy: if user in group "VPN users", ACS permit access.

when we connect from a VPN Client to the server, all user connect success. When we see monitor log in ACS, each user success connect also get

error:

22040 wrong password or invalid shared secret

(pls see the attach picture)

the system still work but I dont know why we get the error log.

Thanks for any help you can provide!

Duyen

camejia · ‎01-03-2012

Hello Duyen,

I think I have narrowed the issue. When authenticating VPN Remote Access using RADIUS we need to keep in mind that the Authentication and Authorization are included on the same packet.

As per your configuration, the ACS is defined as a RADIUS server (aaa-server Gserver protocol radius) and the Tunnel Group for VPN is getting authenticated and "authorized" against that server:

authentication-server-group Gserver LOCAL

authorization-server-group Gserver

As stated above, the RADIUS request/response includes Authentication and Authorization on the same packet. This seems to be a misconfiguration issue as we should not be configuring the "authorization" under the Tunnel Group.

Please remove the authorization under the Tunnel Group:

no authorization-server-group Gserver

Please test the connection again and verify the ACS logs. At this point there should only be one sucessful log reported on the ACS side.

The "authorization-server-group" is meant for LDAP authorization when authenticating against an LDAP server as well in order to retrieve the authorization attributes from the server. RADIUS does not need the command as explained above.

Hope this helps.

Regards.

View solution in original post

jonmarso_07 · ‎12-31-2011

Friend you have configured the same shared secret on both devices?

ngo duyen · ‎12-31-2011

thank Jonatas,

But client success to connect to vpn server so I think key mismatch doesnt happen here.

ngo duyen · ‎01-02-2012

have you got any idea to help me ?

thanks

camejia · ‎01-03-2012

Hello Duyen,

I think I have narrowed the issue. When authenticating VPN Remote Access using RADIUS we need to keep in mind that the Authentication and Authorization are included on the same packet.

As per your configuration, the ACS is defined as a RADIUS server (aaa-server Gserver protocol radius) and the Tunnel Group for VPN is getting authenticated and "authorized" against that server:

authentication-server-group Gserver LOCAL

authorization-server-group Gserver

As stated above, the RADIUS request/response includes Authentication and Authorization on the same packet. This seems to be a misconfiguration issue as we should not be configuring the "authorization" under the Tunnel Group.

Please remove the authorization under the Tunnel Group:

no authorization-server-group Gserver

Please test the connection again and verify the ACS logs. At this point there should only be one sucessful log reported on the ACS side.

The "authorization-server-group" is meant for LDAP authorization when authenticating against an LDAP server as well in order to retrieve the authorization attributes from the server. RADIUS does not need the command as explained above.

Hope this helps.

Regards.

ngo duyen · ‎01-05-2012

thank, it work