Migrating Anyconnect users to new device

[kyrreliaaen]

Hello

We have implemented a new ASA (on FTD2130) remote access VPN service and are looking at options to migrate users to the new service without having the end users manually changing things on their end (ideally).

I thought I'd reach out to the community and ask what our options are before I start breaking things :)

Thank you for your time :)

[Karsten Iwen]

Are both the old and the new firewall online while you are in the migration phase? Then just point the FQDN used for RA-VPN to the new device.

[kyrreliaaen]

Both units will be online during the migration phase, but the FQDN will change. I figured changing the DNS entry might cause trouble with the SSL certificate because of this but I may be mistaken?

I should probably have mentioned this earlier but it slipped my mind.

[Karsten Iwen]

Does the FQDN have to change? If not the migration of RA-VPN users would just be a change in DNS. Both units can have the same certificate and all users will just connect to the new IP.

If the FQDN has to change for other reasons, then the new firewall needs a certificate with the new name. For this scenario you can change the FQDN in the AnyConnect profile. The users connect to the old ASA, download the changed profile and next time they will connect to the new firewall.

[kyrreliaaen]

The FQDN has to change due to various policies and branding etc, so this is a given unfortunately.

I changed the "server list" entry in the profile on the old ASA to use the new device a while ago but this does not appear to have had the desired effect. Maybe I failed to grasp something fundamental here...

[Karsten Iwen]

1. Look at the profile at your test-client: Is the changed profile available?
2. If not, is the profile assigned to the right group-policy and the client is using the right group-policy?
3. If the right profile is used do some other changes and reconnect to see if the new profile is downloaded.

[kyrreliaaen]

Thank you very much for taking the time to assist with this!

Having located the profile on my test client I see that the new FQDN is listed in the "server list" entry, but when starting AnyConnect it will still use the old FQDN.

I renamed the "profile" folder, killed the AnyConnect client, started anew and authenticated against the old FQDN. The profile got downloaded and the "server list" FQDN is the new device. The client still insists on using the old one despite this. I made a small change in the profile and the file on disk got updated when authenticating, so I'm fairly comfortable the profile is being downloaded as it should.

I have to admit I am at a loss here - all seems to be in order, except that it's not.

[Karsten Iwen]

 perhaps something is wrong with your server-list. This is how it could look like:

	<ServerList>
		<HostEntry>
			<HostName>My Company VPN</HostName>
			<HostAddress>vpn2.company.com</HostAddress>
		</HostEntry>
	</ServerList>

Also do an nslookup to check if the HostAddress (vpn2.company.com in my example) really points to the new IP.

[kyrreliaaen]

The server list is as per your example. The only difference is that we've used the FQDN as the HostName, but that should not make any difference.

I did change the HostName just to see what would happen, and I am now noticing that the new FQDN is available in the drop down list on the client, but it's not the "preferred" entry - the old FQDN is still the pre selected one. I did not really notice this as I've been staring at the same UI for so long things are starting to look all the same, but this change made it pop out more.

nslookup/host returns the correct IPv4 and IPv6 address for the new VPN service, and when manually entering the new FQDN in the AnyConnect client everything works as it should, except for the "manually entering" part :)

[Karsten Iwen]

Well, that is strange and here I'm out of ideas ... Perhaps someone else kicks in with a solution.

[kyrreliaaen]

Strange indeed!

Thank you for your efforts - with your help I've eliminated a few potential fault sources :)

[Rahul Govindan]

This may because the client is still holding on to the preference of the last successful attempt. Try naming your new Hostname to something that would be alphabetically higher than the old one. Once you do that and download the new profile, go and delete the preferences file from the following locations:

C:\Users\<UserName>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\preferences.xml

C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\preferences_global.xml

Once you delete these files, quit and re-open the client again. This time, the new Profile should be the preferred one in the "Connect To" field. The old entry will show up in the drop down as long as the old profile is still located on the client machine.

[kyrreliaaen]

Hello

I've renamed the hostname to "A something something" which is alphabetically higher than the old FQDN. The new entry now appears above the old one in the drop down but the old FQDN is still selected.

I'll see about deleting the files as you suggest but it's not really the "zero touch" solution I was hoping for. Asking thousands of users to locate and delete files on their systems.. I shudder to think of the consequences :P

I may have to resort to a popup asking users to kindly type in the new hostname themselves. It's not elegant but it might work...