Hi Rohit, The same url can be used with the Anyconnect client also. If you type in https://<ASA fqdn/ip address>/Anyconnect in the 'Connect To' field in the client, it will connect to that CP. ... View more

Interesting. So traffic flows both ways after tunnel is established from the other end? Can you check the cef route for this source and destination: show ip cef exact-route 192.168.2.100 192.168.10.30 One suggestion i have is to create 2 new ACL's like this: access-list 150 permit ip host 192.168.2.100 host 192.168.10.30 log access-list 150 permit ip any any and  access-list 189 permit ip host 192.168.2.100 host 192.168.10.30 Apply the ACL 150 on the LAN interface: interface GigabitEthernet0/0 ip access-group 150 in and then do a "debug ip packet detail 189" for this traffic alone. Send 1 icmp echo request matching traffic defined in ACL 189. Logs should show you process-switched packets which match this 189 ACL and what features it goes through on then router. "undebug all" after this step. ... View more

Hi Rohit, Yes, you can do this. The way to go about this is group-url's. You can configure a group-url on any connection profile and if the user goes to that specific url, he/she falls into that connection profile automatically.  Say you configure a connection profile named Anyconnect-CP tunnel-group Anyconnect-CP webvpn-attributes  group-url https://<ASA fqdn/ip address>/Anyconnect enable  Now when users go to https://<ASA fqdn/ip address>/Anyconnect, they will only have uname-password prompt and logging him will take him to that CP directly.   ... View more

This is because when you have a dynamic nat in place for internet, VPN return traffic from LAN to VPN pool will also hit this unless exempted in an identity NAT or NAT exempt like you created above. In your case, the dynamic nat is : object network obj_any nat (inside,outside) dynamic interface This doc may help understanding a bit more: https://supportforums.cisco.com/document/44566/asa-83-nat-exemption-example-basic-l2l-vpn-and-basic-ra-vpn ... View more

Your crypto map looks to be configured to initiate and respond, so no problems there. For IKE to trigger, there needs to be interesting traffic that hits the interface that has the crypto map applied [GigabitEthernet0/1 in your case]. One possible reason that could be the cause is that you have a dynamic nat enabled for 192.168.2.100 to go out to the internet, so when traffic is initiated from that host towards 192.168.10.30, dynamic nat takes over and you no longer match interesting traffic. Can you check is you have a dynamic nat in place? Also any reason you have "ip source-route" in place on this router? ... View more

Hi, This is the schema file for the local policy, not the local policy itself. Looks like the AnyconnectLocalPolicy.xml file is not created by default on installation on Mac and Linux. This should be fixed in the next major Anyconnect release. If you have a Windows machine, can you copy the AnyconnectLocalPolicy.xml from it and put the same in the /opt/cisco/anyconnect folder on the MAC? ... View more

You would need to change it in the Anyconnect Local Policy xml file (AnyConnectLocalPolicy.xml). The locations for different OS's are given here: http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect31/administration/guide/anyconnectadmin31/ac09localpolicy.html#wp1055371 Thanks Rahul ... View more

Hi, Maybe you are not falling into that tunnel-group SSL? By default, you will fall into the DefaultWebvpnGroup unless you choose the TG via a dropdown or directly access the group via a groupurl. Example: When no 'tunnel-group-list' or 'group-url' is configured: Accessing https:// will take you to DefaultWebvpnGroup. When 'tunnel-group-list enable' is configured under webvpn, you will get a dropdown of tunnel-groups to choose from [provided you have an alias defined for the group] When group-url is configured for a particular TG, say https:// /test , on accessing that URL, you are taken to that group directly. So basically, you would need to check which group you are hitting. Running 'debug webvpn 255' should also show you this. Thanks Rahul ... View more

IOS IPS auto update from cisco.com is disabled as of now. You may want to check this for more info: http://tools.cisco.com/security/center/viewBulletin.x?bId=566&year=2013 ... View more

Hi Roberto, Looks like this bug has been resolved and the fixed images should be 8.2.5(29) and 8.4.4 both of which should be out shortly. Thanks Rahul ... View more

Hi pgustafson, Hmm sounds interesting. Ideally, the certificate authentication should not have anything to the ip communicator control flow. Now a good way to start would be collect Wireshark captures on the vpn adapter to see where exactly the connectioin is broken. Is there any usage of certificates with the CM and the ip communicator itself? I am looking more into the direction that maybe the wrong certificate is being used for the connection between client and CM. But that again is with the limited knowledge with the CIPC call flow. IMO comparing good vs bad captures are the way to go for this one.  Have you done this already? Thanks Rahul ... View more

Config looks good. If you are on a terminal session, it should show up with terminal monitor enabled. You might just want to turn off logging monitor in case you have a large number of syslogs turning up. Thanks Rahul ... View more

Hi Newt, 2. Now I am able to understand the issue better. But unfortunately I haven't seen this issue before .It would be interesting to see if the AC is able to access the user certificate store after the password change. A good way to start troubleshooting is we can disable auto Cert selection and if we are getting any certs back at all. Also another step would be to try the same with the machine store on the laptop and see if we are still not able to detect the cert. IMHO, even with passwd change, there should be no restriction in cert access on any store. If you still have access to the setup , it would be good to open up a TAC case on this issue. 7. Yes. I believe this behavior has changed with the bug CSCtk08899. During the vpn connection process, there are multiple ssl sessions open (you probably would have noticed multiple cert prompts when using untrusted certs) and one of the them is the one for vpn downloader where checks are made to see if there is any change in image/xml file etc. Now this connection required the IE settings  that you mentioned and hence the failure. These settings are used as default as a part of the downloader process using Anyconnect connection with the 3.0 client (basically forces its use). 8. Good question. We do get a lot of issues where only few (sometimes even just one ) machines are affected. Now a good step always to go by with the DART of the working vs the non-working machine. In most cases, its usually when the end user installs certain applications or makes specific changes to the settings. The best way to understand what a good connection is to go through the Anyconnect files in the DART logs. The more you look into the steps that take place during a connection, the easier it is to figure out where exactly it is failing. Thanks Rahul ... View more

Hi Newt, Thanks for your questions. Answers posted below: 1. Yes, you need a setting in the client profile to achieve this and it Automatic certificate Selection is enabled by default (you wont be prompted). In order to change this, check the Disable Automatic Certificate selection option under the Preferences (Part2) section on the ASDM profile editor. The xml tag for the same is false 2. Frankly, I haven't seen this sort of issue before. But a few questions I do have. How did you know the password had to be changed, did any logs come up on the ASA? And at point during the connection did it fail, after you entered uname and passwd? And what aaa server did you use? 3. Now the CA servers for the client and server need not be the same for authentication. Each side does the validation of the peer certificate independently. So if you use Thwate for the ASAs certificate and local CA server for clients, the clients will be able to validate the ASA cert because it already has the Thwate root certs in its cert store (for most public CAs) and the ASA wil be able to validate the clients cert because it has the root cert that you created when you enabled the LOCAL CA feature. So this is most definately possible. Most common deployments have internal CAs generating client certs and a public cert for the ASA from a well known CA. In the case of SSL, Local CA server serves as a good substitute for internal CA server. 4. Unfortunately there isn't one. But I will soon be posting a doc on pki on CSC, where I will cover details on certificate and dual factor authentication also. For now this document will help to understand a bit more on the dual factor auth process http://www.networkworld.com/community/node/24291 5. I had this question long ago So basically the levels are different for different commands. But in most cases the debug level 255 gives you the most detailed ( sometimes packet dumps ) . I would not recommend you to run 255 levels for all commands because in many case you probably would end up having too many debugs which doesn make sense. I would say a level of 11 should suffice in most cases (any value between 11-254 is the same level for most debugs) 6. You might want to check out the details on devices supported for Android, coz there are a few which aren't supported. Also there was an issue with certificates not visible on the apple Anyconnect store in a recent app release. But I believe that should be fixed in the latest release. So you might just want to make sure everyone is one the new release for Anyconnect. Othere than these, there is nothing that is a major standout in these devices for Anyconnect. But again, with changes made to devices and OS, there might be issues as some of these changes don't go well with the Anyconnect app. ... View more