With Herbert Baerten
Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn about the use of AAA (Authentication, Authorization, Accounting) for Remote Access VPN on the Cisco Adaptive Security Appliance (ASA) with Cisco expert Herbert Baerten who will answer questions on this topic. He can also answer questions on the use of various AAA protocols such as TACACS, RADIUS, LDAP and PKI (certificates), as well as the usage of the local AAA database, including Dynamic Access Policies (DAP.) Herbert Baerten is a customer support engineer at the Cisco Technical Assistance Center in Brussels, Belgium, where he has been part of the Security team since joining Cisco six years ago. His area of expertise is in security, including VPN, IPSec VPN, and SSL VPN on the Cisco IOS and Cisco ASA platforms.
Remember to use the rating system to let Herbert know if you have received an adequate response.
Herbert might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community Other Security Subjects discussion forum shortly after the event. This event lasts through December 22nd, 2011. Visit this forum often to view responses to your questions and the questions of other community members.
We would like to use LDAP to authenticate VPN users against our Active Directory. How can I configure this in such a way that only users that are member of a certain group can connect?
thank you for your question. When the ASA performs an LDAP authentication request, the AD server will (if the authentication is successful) send back a number of attributes, one of which is the "memberOf" attribute which tells the ASA what AD group(s) the user is in.
This attribute can be used in 2 ways, similar to what is described in an excellent document my colleague Nicolas Fournier wrote:
In this document, the access is granted/rejected based on the "Remote Access Permission" attribute that the user has in AD (and which is also passed to the ASA in the LDAP response).
The way to grant or deny access based on the memberOf attribute is very similar.
Method 1: using DAP (Dynamic Access Policies)
Using ASDM, create a DAP rule that matches on AAA attribute "ldap.memberOf" and the action set to "continue".
Then in the default rule, set the action to "terminate".
This way only users that are part of the group matched in the first rule will be granted access, all others will be denied.
Method 2: using an LDAP attribute map
Start by creating 2 group-policies, as described in the document:
group-policy AllowVPN internal
group-policy AllowVPN attributes
group-policy NoVPN internal
group-policy NoVPN attributes
Then set the NoVPN policy as the default one in your tunnel-group:
tunnel-group myTG type remote-access
tunnel-group myTG general-attributes
So by default, all users connecting to this tunnel-group will be denied access (because group-policy NoVPN is applied which allows 0 simultaneous connections).
Next, create an LDAP attribute map that maps the desired group to the AllowVPN policy:
ldap attribute-map VPN-LDAP-MAP
map-name memberOf IETF-Radius-Class
map-value memberOf "CN=VPNUSERS,OU=Users,DC=CISCOTEST,DC=COM" AllowVPN
What this does is create a mapping between the LDAP "memberOf" attribute and the ASA "IETF-Radius-Class" attribute (which indicates the group-policy to use). In the most recent ASA software versions, "IETF-Radius-Class" has been replaced with "Group-policy".
It also defines that the LDAP group "CN=VPNUSERS,OU=Users,DC=CISCOTEST,DC=COM" should be mapped to the group-policy "AllowVPN"
Finally, apply the attribute map to the the LDAP server(s):
aaa-server myLDAP protocol ldap
aaa-server myLDAP (inside) host 10.0.0.1
I hope this helps, if you have any follow-up questions just let me know.
My customer uses a clientless WebVPN profile where his users are redirected directly to their Outlook Web Access (OWA) webinterface using SSO. This has worked well until he changed to Exchange 2010 just a few days ago. I have to assume that Microsoft has changed some parameters on their OWA webpage, so SSO needs to be reconfigured in order to get it working again.
I've browsed through the config guides and communities on Cisco.com and I've also analyzed the POST content of the webpage - still, no success so far. As the ASA release notes state that with 8.4(2), Exchange 2010 is explicitly supported, I'd like know if you can tell me the proper bookmark and SSO parameters that solve the problem. Or is there any other possible problem source?
for Exchange 2010, I believe this should work with something like:
depending on whether your OWA server is reachable through HTTP or HTTPS.
Obviously you may want to modify the SSO variables if you use double authentication or an internal password.
If this does not work I would suggest getting captures of the traffic in the SSL tunnel (e.g. using HTTPwatch or Charles or similar tool) and to open a TAC case to analyze those captures if it's not obvious what's going wrong.
I hope this helps
Is it possible to authenticate with AAA server using SSL VPN? We have ASA 5510.
yes you can use Tacacs, Radius, LDAP, SDI, Kerberos etc. to authenticate both clientless SSLVPN (aka WebVPN) and Anyconnect (aka SSL client) users.
A very common approach is to use Radius towards a Cisco ACS server or to use LDAP towards a Microsoft Active Directory (AD) server.
These are the 2 relevant sections of the ASA 8.4 configuration guide:
Configuring AAA Servers and the Local Database
Configuring Remote-Access Connection Profiles
Furthermore you can use AAA not only to authenticate users but also to assign IP addresses, restrict access on a per-user or per-group basis, etc.
It's a very broad subject and the possibilities are endless so I hope this more or less answers your intitial question, if you have any follow up questions please don't hesitate to ask.
Thank you for your hints, yet after trying probably about thirty variants of POST plug-in and normal HTTP with POST parameter syntaxes, I have to give up. Maybe there's something different with the German Exchange OWA page (well, this one is definitely: 'submit=Anmelden'), yet I've analyzed the page with three different HTTP sniffers and belive there's nothing else left to analyze. I think the only way to solve this is going via TAC
One last question: Would you recommend to use the POST plug-in URL or the HTTP URL with advanced POST values? None of both worked for me...
1) What do you recommend on levels of authentication ? What I meant is how many forms of authentication is recommended?
If I am using LDAP with AD username and password is that good enough or do you recommend using second form of authentication. I am pretty sure that it would depend on an organizations security policy but would like to know if there are any baseline recommendations.
2) Are there any best practices you would suggest for implementing anyconnect & clientless VPN ?
This is a really tough one . As you say this is primarily a question of the organizations security policy. As often in security, there is a trade-off between security, user (in)convenience, and cost.
LDAP with AD is of course cost-effective if you already have AD and very user-friendly in the sense that the users can log in to the VPN using the same credentials as they use to log in to his workstation or laptop.
Possibly even more user-friendly is the use of a client certificate which can be used to log in without the user having to type anything but setting up and maintaining a PKI infrastructure is of course a whole other ballpark.
On the other end of the spectrum you can have a client certificate on a smartcard (or hardware token) protected by a PIN as first level, username & password (using Radius or LDAP) as second level, and a one-time-password (OTP) (using something like an RSA token or a system that sends a OTP to the user by text message to his cell phone) as third level.
So sorry for not giving you a very explicit answer but obviously the recommendations will be different for a non-profit or a small company compared to a financial, military or healthcare organization.
One basic "rule of thumb" though is that you strongly increase security if authenticating requires something that you have (like the smartcard, the RSA token or the cellphone in the example above) as well as something you know (a password).
For your second question, that's again very broad and depends on a lot of factors (how many users, where will they connect from (company or public computers), which applications, expected uptime etc etc). Just a few tips though: for Anyconnect I would recommend using the latest client version available, for clientless the most recent ASA 8.2 or 8.4 version, and be aware of memory and licensing requirements.
Consider using CSD if you want additional options to tighten security (e.g. restrict access to clients with recent Anti-Virus software installed).
Specifically for LDAP with AD, check the first question and answer in this thread on how to use DAP or an LDAP attribute map.
I hope this still helps, if you have any more specific questions I'll be glad to discuss them.
we are using Cisco ASA 8.2.3 as RAS solution for our customers. Different kind of authentication mechanisms are already deployed yet.
Now we want to use two factor authentication, where first, user needs to be verified by AD (by secure LDAP) and secondly, user needs to be verified by SMS passcode to SMS text messaging server.
We already created a separate DAP, separate Anyconnect Connection profile, separate Group Policy and separate customization page for this.
I know ASA supports this functionality but when configuring authentication server group and secondary authentication server group together you will have to fill in credentials for both on the Logon page. This is not what we want. We want users to fill in credentials for AD on Logon screen and after this user should receive SMS text message and get (pop-up) second login screen where he can enter the SMS passcode. Then logon process is completed and he should get RAS portal page.
When we test using only primary authentication AD by secure LDAP connection functions. When enabling secondary authentication you have to fill in credentials also on first logon page (instead of second logon page we would like to have). Also then, customer does not see any requests coming in on SMS text message server.
How do we need to configure the RAS environment so that it functions the way we want to?
The way (most of) these SMS systems work, is that you configure the ASA to do single authentication using Radius, where the SMS server acts as Radius server. On the SMS server you then configure the LDAP server as a back-end.
What will happen then is this:
On the login page the user enters his AD username and password.
The ASA sends this to the SMS server (using Radius).
The SMS server uses (for example) LDAP to AD to verify the credentials.
If ok, the SMS server then sends an SMS to the user's phone, and it sends back a Radius "challenge" message to the ASA, requesting an additional password.
This triggers the ASA to display a second login screen, asking just for the OTP.
The user enters the OTP received by SMS, the ASA sends this to the SMS server via Radius, the SMS server responds with a Radius access-accept or access-reject.
I know there are SMS servers available from multiple vendors so they may not all work in the same way. If you think the above is not the way yours works then please send me the documentation provided by your vendor (I assume it comes with a deployment guide or something similar) or let me know the name of the Vendor or product.
Please let me know if this helps.
thanks for the quick response. Using the information you provided last week we configured ASA authentication for SMS. Also had to change settings in SMS text message server and settings in Anyconnect client profile settings, but now everything works like a charm.
I have a question: I am using Radius for authenticating VPN users and having multiple tunnel-groups on the ASA, how can I make sure that users can only connect to the tunnel-group they are supposed to connect to (i.e. sales people to the sales group etc.)?
this can be accomplishes by configuring the Radius server to send the Tunnel-Group-Lock attribute, the value of this attribute should be the name of a Tunnel-Group on the ASA.
If a user then attempts to connect to another group, the connection will fail.
On Cisco ACS 3.x this attribute is known as cVPN3000-Tunnel-Group-Lock, from ACS 4.x on it is simply named Tunnel-Group-Lock and can be found under VPN3000/PIX/ASA attributes.
On a Radius server that does not know these Cisco specific attributes, you can speficy it as:
vendor code 3076
attribute number 85
For a complete list of attributes that you can push from LDAP and Radius, see:
thanks for your questions. One important thing to note when using time-based access restriction is that this only restricts the time period that the user can establish the connection; once established the tunnel will continue to exist even past the end of the time range allowed.
E.g. if you allow connections between 9am and 5pm, then a user who connects at 4:59pm can remain connected all night.
You can address this by also restricting how long a session can last, using "Maximum Connection Time" in ASDM, or vpn-session-timeout
So if you set the session timeout to 30 minutes, then someone connecting at 4:59pm will be disconnected at 5:29pm. However this also means that someone who connects at 9am and wishes to remain connected until 5pm, cannot do so - he will have to reconnect every 30 minutes.
There is no command that explicitly shows the active/inactive status of a certain group-policy. However you may find the following commands useful:
show time-range will show you the time ranges you have defined, and whether they are active or inactive at present.
show vpn-sessiondb ra-ikev1-ipsec will show you all current RA VPN sessions, including the time the session started (Login Time).
If you are only interested in a certain group or certain user then you can use the filter option with the above command, e.g:
show vpn-sessiondb ra-ikev1-ipsec filter tunnel-group myTunnelGroup
show vpn-sessiondb ra-ikev1-ipsec filter name JohnDoe
Or you can use ASDM to view the same information, on the Monitoring tab -> VPN Statistics -> Sessions.
On that screen you'll also see a "Logout" button, which allows you to disconnect a certain session. From the CLI you can do this with vpn-sessiondb logoff name JohnDoe
Secondly, can we give a small pop-up message to user that his Access Hours are finished and he will not be able to login using Cisco VPN Client software.
Unfortunately, no. You can define a "banner" text in the group policy but that will only be shown when the user successfully connects. When the user is denied access (because of the time-range or any other restriction in the group-policy) then he does not get to see this banner.
I was thinking of a way to achieve something similar, which would involve using ACS (which can assign different policy settings depending on the time of day) and creating an "AccessDenied" group-policy which the user can login to (so he gets to see the banner) but where he cannot do anything because a vpn-filter denies all access to the network. Let me know if you'd like to discuss that in more detail, but this requires ACS (or possibly another Radius server), it will not work with Local authentication.
Is it possible to setup both Radius authentication and Active Directory authentication on the ASA? For example, if Radius server fails, we want the users to authenticate through Active Directory.
sorry, no, you cannot use LDAP as a fallback in case Radius fails.
Per tunnel-group you can only define a single AAA server-group, and for redundancy you can define 2 (or more) Radius servers in a group, or 2 (or more) LDAP servers, but not a mix.
You may want to look into Internet Authentication Service (IAS) on Win2003 or Network Policy Server (NPS) on Win2008 which are Microsoft implementations of Radius.
The only alternative I see for you is that you define 2 tunnel-groups, one with Radius auth and the other with LDAP auth. In this case your users will have the choice of which one to connect to though, you cannot force the LDAP group to be inaccessible when the Radius server is reachable.
I hope this helps, let me know!
Thanks for your response.
You said: "Per tunnel-group you can only define a single AAA server-group, and for redundancy you can define 2 (or more) Radius servers in a group, or 2 (or more) LDAP servers, but not a mix."
For redundancy, we can setup 2 or more Radius servers in a group. Is this for Load Balancing? I see the command "VPN Load-Balancing" Is it possible to setup failover for Radius servers in a group? For example, if the Primary Radius server fails, the Secondary Radius server takes over automatically. What is the command to setup failover for Radius servers in a group?
By the way, this Q&A will end tomorrow, December 22. If we have more questions, which forum can we post the questions?
when you configure an aaa-server-group and add more than one server to it, they will not be used in a load-balancing fashion but in a failover setup.
So as long as the first server responds it is considered "active" and only this server is used for AAA. As soon as the server stops responding a few times in a row it is considered "failed" and the second server is used, and so on.
This is highly configurable, e.g. you can customize how long the ASA waits for a response, how many times a server needs to fail before it goes to failed state, how a server moves back from failed state to active state (either after 30 seconds, or only after all servers are in failed state).
One important thing to note is that the second (and third etc) server is only contacted when the first one does not respond. When the first server does respond and the response is an Access-Reject (because the user is unknown or the password is incorrect) then the ASA will honor that response and it will not try the second server.
In other words, the Radius servers should have identical user databases, you cannot use this mechanism when each Radius server knows only half of the userbase.
VPN load balancing is a whole different story - this means using 2 or more ASA's in parallel. To explain very briefly, one of these ASA's will be the 'master' listening to a 'virtual ip address' that the clients connect to. The master then redirects the client to the actual ip address of one of the ASA's in the cluster (including itself). This allows you to scale your vpn solution beyond the capacity of a single ASA.
After today if you have more questions about VPN on ASA (or VPN in general) you are welcome to start a new "discussion" in the forum. For questions about the Cisco ACS (Cisco's AAA server) like "how do I configure ACS to ..." or about AAA protocols themselves I rather recommend the forum.
Thank you for your contributions to this event!
I found all your responses quite appropriate and knowledgeable. I feel at ease with all the command-sets once I'm clear at concepts. So, I just wanted to know if there is some simple conceptual approach towards regex expressions because that's something we can't look up like all other commands using the well-appreciated '?'.
Any short and illustrative enough example or some memory trick will be most welcome. (or else/and what exact path to follow on the support documents to look up the most comprehensive set of regex expressions "in the search-disabled environments")
I have few question for you:
1. I have been using ACS for authenticating VPN remote access user on Cisco ASA. I bind the username with the tunnel using Cisco VPN 3000/ASA/PIX 7.x+ RADIUS VSA no 85 (Tunnel-Group-Lock) so that a particular host can only be used to authenticate a particular tunnel group/vpn tunnel on Cisco ASA. Say that user A can only be used for tunnel A, user B can only be used for tunnel B, and so on and so forth. The issue now is I want a user to be able to be used for two VPN tunnel, say user A can be used for tunnel A and B, but not tunnel C. Does any of you know how to implement this? I tried to manipulate the argument for the attribute using REGEX, but no use. also tried to change the VSA so it can be used twice to accomodate the tunnel, but no use also since the first will always takes place.
2. How to do low level debugging on Cisco ACS? I want to see the step by step communication between Cisco ACS and Cisco ASA during remote access vpn authentication process specially how the RADIUS attribute is exhanged (since I am using attribute 85, but I want to see other attribute).
3. Do you have any documentation regarding RADIUS and TACACS attribute that gives explanation on how the attribute is used and how to configure it on the network devices? I have found a Cisco documentation on RADIUS attribute, but it only defines what the attribute is without explaining how it works or at least how to configure it on the related device.
4. Do you know how to change the default gateway of a remote access client? So far, I notice that when I use VPN, my default gateway is always the first IP address of the pool. For example if I specify the pool 192.168.0.0/24 for a tunnel group, all VPN users will get a default gateway 192.168.0.1. Can we change this? Maybe ACS can push an attribute for this one?
Thanks a lot.
I came across this pretty interesting situation while implementing an experiment.
Topology is like this:
R1 ------serial-------- R2 --------------serial -------------- R3
And the switchports are in routed mode and in the same subnet and to achieve this, the ports connected to switches are bridged(using IRB).
Now when I created two zones and put one fastethernet and one serial interface in zone 'Inside' and the rest in zone 'Outside' and applied the inspection, Transparent ZBF works fine for the switches and ZBF works as much for the routers.
My question is: Can we somehow get the firewall to do inspection between L2 and L3 ports? To be more specific, since my interface connected to SW1 is in Inside zone and that connected to R2 is in Outside zone, can I inspect the traffic flowing from SW1 to R2 or even get the trafffic running through after applying ZBF. (It worked pretty well before admitting the interfaces to zones as the routers could ping and telnet to the switches and all the nodes here share the same routing table even after applying ZBF, which is actually raising my hope )
ok, let's address your questions one by one:
Tunnel-Group-Lock can indeed only be used with 1 tunnel-group.
Allowing a user to connect to 2 (or more) groups is going to be more difficult. The only way I can think of to achieve this is by using DAP (Dynamic Access Policies).
DAP rules (in ASDM: configuration - Remote Access VPN - Network (client) Access - Dynamic Access Policies) consist of a set of selection criteria, and a set of attributes that are assigned if the criteria are met.
In other words, you can think of each DAP rule as an "IF (criteria) THEN (apply these attributes)".
So in your example, you could do something like:
IF cisco.username = userA AND cisco.tunnelgroup = tunnelC
THEN action = terminate
And in the default rule, keep the default action = continue.
Then for userA, do not push any Tunnel-Group-Lock attribute.
On ACS, there is a file named RDS.log if I remember correctly but I'd have to look it up.
It's probably easier though to use "debug radius all" on the ASA, this will show you the entire Radius exchange including all attributes.
3. Sorry, apart from the list of attributes that is in the Configuration Guide, I don't know of any public documentation describing the attributes. Each attribute however corresponds to a setting in the group-policy, so you could check the Command Reference for all the group-policy commands (e.g. Tunnel-Group-Lock corresponds to group-lock).
4. The default gw on the client is just a "dummy" address, it is not used for anything. And hence there should also be no reason to change it. Unless of course, you have a reason that I have not considered, please let me know.
Currently we are using LDAP authentication for Anyconnect users, and an LDAP attribute map to assign different settings depending on which AD group the user belongs to (i.e. map the memberOf attribute to a group-policy).
Now we're thinking of implementing a one-time-password (OTP) solution which would be using Radius. If we do that can we also still use LDAP or is there an alternative to achieve the same functionality?
for Anyconnect and for clientless webvpn there are 2 things you can do (for Cisco VPN client only the first option applies):
1- Remove LDAP authentication, configure RADIUS authentication, and add LDAP authorization.
In this scenario, the user enters his username and his Radius password / OTP.
The ASA then first authenticates the user using Radius, and when successful, it will do an LDAP user lookup. This second step is not an authentication step (the user never enters his AD password), it's just retrieving a list of attributes from the LDAP server.
Note that in this scenario, the usernames on the OTP/Radius server have to be the same as in AD/LDAP because the user only enters one username, and this is used for both the authentication (Radius) and authorization (LDAP) steps.
2- (not for IPsec IKEv1) Use double authentication, i.e. keep your LDAP as primary authentication, and add the Radius as secondary authentication. The user will be prompted to enter his Radius username, Radius password (OTP), LDAP username and LDAP password (or if "use-primary-username" is enabled, only one username and 2 passwords).
The ASA will then first perform the LDAP authentication, if successful perform the Radius authentication next, and only if both are successful the user is granted access.
In both scenarios, Radius attributes will override group-policy settings (but in the case of an OTP server support for Radius attributes is usually very limited or non-existent), and LDAP attributes can be used in an attribute map. Both Radius and LDAP attributes can also be used in DAP rules.
I hope this helps, don't hestitate to post any follow up questions.
We have ASA 5510 ver 8.0(5)
We are having some VPN site-to-site desconnection problem, the VPN were working ok, but now the connection are not stabished, we getting this log messages:
ASA01-BA-TC# sh log
Syslog logging: enabled
Timestamp logging: enabled
Standby logging: disabled
Debug-trace logging: disabled
Console logging: list autenticaion, 19319 messages logged
Monitor logging: disabled
Buffer logging: list autenticaion, 19319 messages logged
Trap logging: disabled
History logging: disabled
Device ID: disabled
Mail logging: disabled
ASDM logging: level warnings, 138091 messages logged
licy) for user = 220.127.116.11
Dec 21 2011 06:50:17: %ASA-4-113019: Group = 18.104.22.168, Username = 22.214.171.124, IP = 126.96.36.199, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:19: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 188.8.131.52
Dec 21 2011 06:50:19: %ASA-4-113019: Group = 184.108.40.206, Username = 220.127.116.11, IP = 18.104.22.168, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:20: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 22.214.171.124
Dec 21 2011 06:50:20: %ASA-4-113019: Group = 126.96.36.199, Username = 188.8.131.52, IP = 184.108.40.206, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:21: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 220.127.116.11
Dec 21 2011 06:50:21: %ASA-4-113019: Group = 18.104.22.168, Username = 22.214.171.124, IP = 126.96.36.199, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:24: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 188.8.131.52
Dec 21 2011 06:50:24: %ASA-4-113019: Group = 184.108.40.206, Username = 220.127.116.11, IP = 18.104.22.168, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:46: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 22.214.171.124
Dec 21 2011 06:50:46: %ASA-4-113019: Group = 126.96.36.199, Username = 188.8.131.52, IP = 184.108.40.206, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:47: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 220.127.116.11
Dec 21 2011 06:50:47: %ASA-4-113019: Group = 18.104.22.168, Username = 22.214.171.124, IP = 126.96.36.199, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:48: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 188.8.131.52
Dec 21 2011 06:50:49: %ASA-4-113019: Group = 184.108.40.206, Username = 220.127.116.11, IP = 18.104.22.168, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:50: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 22.214.171.124
Dec 21 2011 06:50:50: %ASA-4-113019: Group = 126.96.36.199, Username = 188.8.131.52, IP = 184.108.40.206, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:51: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 220.127.116.11
Dec 21 2011 06:50:51: %ASA-4-113019: Group = 18.104.22.168, Username = 22.214.171.124, IP = 126.96.36.199, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:50:55: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 188.8.131.52
Dec 21 2011 06:50:55: %ASA-4-113019: Group = 184.108.40.206, Username = 220.127.116.11, IP = 18.104.22.168, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:51:16: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 22.214.171.124
Dec 21 2011 06:51:16: %ASA-4-113019: Group = 126.96.36.199, Username = 188.8.131.52, IP = 184.108.40.206, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
Dec 21 2011 06:51:18: %ASA-6-113009: AAA retrieved default group policy (DfltGrpPolicy) for user = 220.127.116.11
Dec 21 2011 06:51:19: %ASA-4-113019: Group = 18.104.22.168, Username = 22.214.171.124, IP = 126.96.36.199, Session disconnected. Session Type: IKE, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown
from the syslogs it's not clear what exactly is causing this, since the disconnect reason is shown as "unknown". I suggest enabling "debug crypto isakmp 10" and "debug crypto ipsec 10" and checking the debug output for clues on what the problem may be. If this does not help, since this issue is not related to the topic of this Ask-The-Expert event, I would kindly ask you to start a new discussion in the forum if you need further assistance.