Cisco Secure Client XML overwrite issue

[Tony Greensmith]

Hello, any help appreciated.

I am having issues when trying to assign a different group policy to a user where the group policy contains a different client profile (XML) to the one used to connect in the first instance. This is what I am trying to do.

Always-On user VPN initiates after Windows logon (at desktop). User logs in, Cisco ISE detects AD group membership and pushes alternate firewall group policy. This group policy contains a client XML profile which has Always-On turned off (TND is still turned on but set to DoNothing for Untrusted network). The new XML is downloaded but the original remains. This leaves Cisco Secure Client operating in a weird way in that is cannot decide which one to load if the VPN is disconnected.

If I push an alternate client XML profile which has other settings changed but Always-On is still enabled then it removes the initial XML leaving only one.

It is as though the change of the Always-On setting is too much of a difference and so Cisco Secure Client chooses not to remove the original.

Any ideas? Cisco Secure Client 5.1.2.42 - Firepower FTD 7.1.0.1

[tvotna]

From the description it's not quite clear why you need this and which profile attributes differ between the two profiles. In general, software works as designed when it removes all of the profiles with always-on disabled when the client connect using the profile with always-on enabled. This behavior is documented somewhere. On the other hand, I tend to agree that AnyConnect behavior should be configurable when multiple profiles exist on the client, especially when one of them has always-on. Currently it is not. I believe the client merges global setting from all of the profiles sorting them in lexicographical order (having multiple profiles is valid), but not sure what happens with always-on setting in this case.

[Tony Greensmith]

Thanks for replying.

The requirements comes from needing a temporary exemption from the Always-On function, to allow for the user to disconnect for a short period. The only things which change are the "Allow Disconnect" option being enabled, on Untrusted network "DoNothing" and the removal of Always-On.

It is to solve a minor issue we have.

If there is something documented which says there can be multiple profiles without Always-On, which I believe can be done, but only 1 profile if Always-On is chosen I would hope someone can point me in the right direction.

[stsargen · Accepted solution]

If an AlwaysOn profile is present in the client profiles directory all other profiles will be deleted.  It is not possible and not supported to have multiple profiles installed when an AlwaysOn profile is present.

[Tony Greensmith]

Thanks. It is interesting that it downloads the alternate XML and allows it to run, but as soon as the disconnect happens traffic is halted. All help is appreciated.

[tvotna]

@Tony Greensmith, hmmm.... I believe that users can be exempted temporarily by assigning them another group-policy with the same AnyConnect profile, but with always-on disabled:

group-policy ... attributes
 always-on-vpn disable

This will override profile setting.

I'm not sure what happens with the connection in this case though. I mean, will it be possible to disconnect it or <AllowVPNDisconnect>true</AllowVPNDisconnect> is required in the original always-on profile? Perhaps @stsargen can explain or you can test this.

Also, why do you need to change profile to "<UntrustedNetworkPolicy>DoNothing</UntrustedNetworkPolicy>"? Do you mean that client attempts to reconnect automatically due to TND if "<UntrustedNetworkPolicy>Connect</UntrustedNetworkPolicy>" + "<AlwaysOn>false" is configured in the new profile? The entire feature and its configuration is really confusing...

[Tony Greensmith]

@tvotna If always on VPN is enabled, and Untrusted network is set to DoNothing, this conflicts. Essentially no traffic ever passes as Always-On blocks traffic until connected and DoNothing in TND never fires up the VPN.

Hence disabling Always-On is the the only way to allow traffic to pass if TND does not auto-start the VPN.

My use case is minor and a small exemption. If the options are either a) one Always-On VPN only and no others, or b) multiple Non-Always-On VPN profiles only;

then so be it. It seems like that is the behaviour I am seeing.