- Install Cisco Anyconnect
- Download Anyconnect From Asa
- Asa Anyconnect Config
- Cisco Asa Troubleshoot Anyconnect Vpn
- Setting Up Cisco Anyconnect
Asa-firewall/pri/act# sh vpn-sessiondb anyconnect Session Type: AnyConnect Username: beck@vpn-tun-grp3 Index: 12579 Assigned IP: 192.168.236.194 Public IP: 84.163.80.247 Protocol: AnyConnect-Parent SSL-Tunnel License: AnyConnect Essentials Encryption: 3DES Hashing: none SHA1 Bytes Tx: 552426724 Bytes Rx: 264841827 Group Policy: vpn. We have implemented Remote access VPN on ASA and integrate with onelogin cloud base OTP service, where we have LDAP server and onelogin provide RADIUS service to provide LDAP+OTP base authentication. In my VPN config we just tell use onelogin RADIUS for authentication and everything working fine but now if i want to create multiple Group and provide authentication base on group. Open the Cisco AnyConnect Secure Mobility Client, this should display the new connection; The Windows computer has a User and Computer certificate issued by the same Windows CA that signed the certificate in use on the ASA, and therefore they should mutually trust each other and successfully authenticate. On the ASA run the command debug aaa. From the ASA CLI enable the command debug webvpn and ensure logging is enabled logging enable and logging console 5. Set the ciphers back to medium to see a longer list of supported ciphers, with the command: ssl cipher tlsv1.2 medium. Login to the Remote Access VPN and observe the webvpn debug output on the ASA console.
Install Cisco Anyconnect
I recently came across an issue where our team was unable to log into one of our Cisco ASA firewalls running code version 9.2(4)5 to manage the firewall. Shortly after we were notified that AnyConnect clients were unable to authenticate. SSH is configured to authenticate using TACACS and AnyConnect using RADIUS, not the same protocols but still both functions of AAA . We reviewed our remote logging server (a must have tool!) for any output from the firewall and found the following log message:
%ASA-3-113001: Unable to open AAA session. Session limit [2048] reached
After discussing the issue with Cisco TAC, they provided the following debug command to assist with diagnostics:
debug menu aaa 61
Download Anyconnect From Asa
The output of this command looked something like this:
Asa Anyconnect Config
IN USE AUTH HANDLE STATS
Max Sessions: 2048
In Use List Count: 2047
In Use List Head: 247
In Use List Tail: 765
The issue ultimately came down to the firewall not properly tearing down AAA sessions to the AAA servers and eventually hitting the max session limit where it stopped performing further AAA functions (in our case SSH login and AnyConnect VPN authentication requests). The immediate resolution was to reboot each the firewall which cleared the sessions. We were running a HA pair and AAA sessions are not HA replicated so we were able to reboot them one at a time which allowed us to avoid outage time while resolving the AAA issue.
Cisco Asa Troubleshoot Anyconnect Vpn
A quick search of the Cisco Bug site using the syslog event message ID (ASA-3-113001) reveals several known bug IDs for this event (CSCud50997, CSCuj10655, CSCtg28821, and others). We were not able to nail down exactly which bug was responsible. The short answer for us was the Cisco ASA platform has bugs (as does every platform from every vendor) and regularly patching (at least to the latest interim/minor version) is good network hygiene. We patched to the latest 9.2 minor/interim code release and have not seen another occurrence of this issue since..
Setting Up Cisco Anyconnect
Important follow-up note… the day after dealing with the issue above, we inexplicable experienced a software bug which repeatedly crashed each firewall in the HA pair until both crashed at the same time causing an outage. After the simultaneous crash occurred, both firewalls recovered and now appear stable. I have to assume whatever caused the crashing was rooted in some HA replicated information which is why they are stable after the dual reboot (which is the only way to fully clear the HA replicated state stable information from both firewalls). We were never able to find a root cause of the crash events. While I have no reason other than timing to think the two issues are related, consider this a warning… if you experience the AAA issue above, do not be surprised if it is followed shortly there after by a full firewall crash & reboot (maybe even consider enabling coredump on one of the firewalls in the HA pair just in case).