I've stumped myself, and think I've been staring at this too long. I have our ASA configured so that when an AnyConnect client connects, before any username or password is entered, the correct group is selected for the client in the "Group" field. If someone selects another group from the dropdown, it will reset back to the correct one BEFORE they enter any credentials. We don't care from what IP or source network the connection originates. Nothing complex happens about the decision making. One group for everyone, and the other group choices are for my own testing. What I can't seem to recall is how I did this--and it was actually on purpose. Now I need this disabled so I can do some testing with those other group choices.
How did I make Anyconnect use the correct group before any authentication is done? No certificates are being used to authenticate, nothing at all at this stage. A clean, freshly installed client that has never connected will select the correct group after the user enters our ASA's hostname & clicks connect (or enter).
I must be missing something so simple, although I do sometimes find unique approaches to a solution and may have done something unusual to accomplish this. I hope someone will see this and say "you did this....". I've looked at the config dozens of times, can't find any rules or policies to explain this. It could be this was accomplished simply by disabling something on the other profiles, but I can't find what that might be. All are configured for both clientless & SSL connections. All have aliases & show in the client.
Feeling 'toopid here. ASAs are running 8.4(7)3. AnyConnect is 3.1.05152
Not quite as deliberate as I thought. Told you I'd looked at it too long.
Turns out it appears I've discovered a bug in 3.1.05152. I went back to 2.5.6005 and I could pick any group I wanted & it would stick. Removed that and installed 3.1.04066--worked fine. Went back to 3.1.05152 and it will only let me select the first group unless I manually edit the .anyconnect file (in Linux) and type in another group name there.
I've repeated this with both Windows & Linux 64-bit OS versions. It might be related to our environment & the fact that we don't use customized profiles or certificates for auth, but in the most simple authentication config it seems reproducable.
Banged my head on the wall for hours chasing this, and it's a likely bug!
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...