AnyConnect 2.5/3.0 with external F5 failover

[Robert Gartley]

Hello all! I have an interesting situation here and I'm trying to see if anyone has tried to do this.

1. For this example all clients are WinXP
2. I'm doing Always-On VPN with AnyConnect 2.5/3.0 at the moment. Note the Always-on!
3. AnyConnect has the Disconnect feature disabled... again.... note the Always-on.
4. My head end ASA's are between 2 data centers. We'll call them Prod and DR for this example.
5. Prod is an ASA HA failover pair while DR is a single ASA
6. Between the Prod and DR, I have external F5's doing DNS failover to vpn.acme.com

As Prod goes down, DNS automagically updates via the F5's and vpn.acme.com then points to DR. When the clients that we're connected to Prod try to reconnect, they continue to try to reconnect to Prod even though DNS is updated. The client is never rechecking DNS. (I can verify this via Wireshark) I also have DPD configured as well for 20 seconds to enfore reconnect.

I've found that restarting the AnyConnect service resolves the issue, but our machines are locked down and users can't restart services. A reboot obviously works as well but telling the user to reboot is a bit cliche in this day and age.

Is there any magic setting in the AnyConnect client to tell it to do a "true" reconnect when reconnecting? I've tried this with the following client versions to no avail.

2.5.2001

2.5.2014

2.5.2017

3.0.0629

Thanks for your time!

Rob

[Marcin Latosiewicz]

Rob,

It looks like you're describing exactly symptoms of:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtg24945

... which should be fixed ;-)

Can you check if workaround would work for you?

This was first spotted for ASA+anyconnect and GSS for DNS load balancing.

Marcin

[Robert Gartley]

Marcin,

Thanks for the tip! Although this does sound exactly like what I'm experiencing, the workaround doesn't resolve the issue. I've tried the workaround on both the AC 2.5.2014 and AC 3.0.0689 clients without good results.

Although it didn't work, I believe that this is pointing be down the right path. I'll be experimenting with it a bit. Worst case, I'll be calling TAC shortly to open a case.

If anyone has any other ideas though, I'm welcome to them.

Thanks again,

Rob

[Marcin Latosiewicz]

Rob,

IMHO the bahvior regarding reconnect and DNS caching should not depend on configuration.

I would advise to open a TAC case, first of all we need to check if you actually do DNS during resolution second check out the profile and third ... well depending on behavior but it might be a possibility that the bug I have given you is not fixed in some circumstances.

But anyway a TAC case should be fastest, can you please post the # once you have it (if you choose to follow my suggestion)

Marcin

[Robert Gartley]

Marcin,

Thanks for your reply. I've opened TAC case #616713117 to address the issue.

Rob

[Marcin Latosiewicz]

Thanks Rob,

Can you please check your private messages on forums?

Marcin