I have a TAC case open to see if any good documentation exists for this, but I did get a basic installation up and running using SDM 2.5. Unfortunately SDM will NOT recognize that Anyconnect is installed even though it is. You will need to install the Anyconnect packages manually and then setup the rest in SDM.
First...install Anyconnect packages. I use the Window and Mac packages. TFTP them onto the router and install them using: (from conf t)
webvpn install svc flash:/windows_package_name.pkg sequence 1
webvpn install svc flash:/mac_package_name.pkg sequence 2
It will install and your config will have lines like this:
webvpn install svc flash:/webvpn/svc_1.pkg sequence 1
webvpn install svc flash:/webvpn/svc_2.pkg sequence 2
Now you can go into SDM and run the wizard....
Hope this helps!
-Andy
Updating: I got a reply on my TAC case....here are the URLs Cisco sent me:
Here is the IOS SSL VPN Data Sheet that explains what features are available
www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6657/product_data_sheet0900aecd80405e25.html
Here is the IOS SSL VPN CLI Configuration Guide:
www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ssl_vpn.html
Here are several IOS SSL VPN Configuration Examples & TechNotes:
www.cisco.com/en/US/products/ps6657/prod_configuration_examples_list.html
Has anything changed physically in your environment that could be causing radio frequency interference? or have the clients moved further away than normal? I looked up that syslog message and got the following:
Q. What does error message mean: "Packet to client xxxx reached max retries, removing the client"?
A. The Packet to client xxxx reached max retries, removing the client error message means that the AP disassociates the client because the client did not respond to max keep-alive messages sent by the AP. This can be an indication of a bad RF. Configure this command on the AP in order to eliminate this issue and to enable the client to not lose the connection:
packet retries 128 drop-packet
The increase of packet re-tries to 128 with the drop-packet option is a workaround for the bad RF problem. Refer to Configuring the Maximum Data Retries for more information on this command.
Taken from: http://www.cisco.com/en/US/products/hw/wireless/ps4555/products_qanda_item09186a0080094cdc.shtml
Best Answer
I would start with looking at the router logs by using
show log
.Like any cisco, if logging is enabled, you should see at least some
%DOT11
messages like%DOT11-6-ASSOC
,%DOT11-6-DISASSOC
...To enable logging with a 10kB buffer (default is 4096bytes):
If nothing obvious appears from the logs, you could try to activate some debugs on the router:
That should help to troubleshoot the issue.
Be sure also to disable
logging console
as logging on the serial console generates a cpu interrupt for any character (hence a high cpu usage), and preferterminal monitor
if you're debugging from a vty (telnet/ssh).A syslog server would be quite useful also. It will store all the logs from the router, and they can then be processed (script of some kind, your eyes...) on the server.