XML Profile mismatch and XML download issues

[NGJ]

Hi
I need to change the trusted DNS servers in my Secure Client XML profile.

Historically we deployed the XML profile via SCCM and we have start before login & always on configured.
Trusted DNS Servers in the profile are currently DNS1 & DNS2. DHCP allocates DNS1 & DNS2

ON LAN
If I add DNS3 & DNS4 to my laptops XML Profile (Now contains all 4 DNS servers), this causes no issues. If I then change the LAN DHCP to allocate DNS3 & DNS4, renew my IP....as the XML already contains the new DNS servers DNS3 & DNS4, all is good on the LAN.

REMOTE VPN
I'm struggling here.
If I attempt a VPN connection, as the xml file on the headend is now different to what's on my laptop, understandably the connection fails. The headend is a FTD (managed via FMC).

Option1:
Ideally, I know best practice is to make same changes on headend XML and allow profile to be downloaded for remote clients. This fails, it's a separate issue that I'm waiting on TAC to assist.

Option2
As a workaround I'm looking to see if it's possible to prevent connection issues with the mismatch of the xml profiles.
Can this matching be disabled on the headend? i.e. do I actually need to specify the XML Profile in the Anyconnect Client Profile? Can I leave blank - will this bypass the matching and allow connectivity via the XML already on the client laptop?

Im hoping to update the XML profile, and push via SCCM.
For remote clients who are offline and unable to get the new XML - as it stands they will be unable to connect once I make the change on the headend, as they still have the old XML.

Hope that makes sense

As I await TAC to provide support on the download issue, the issue is.....
We have IKEv2 RA VPN. Client Services are enabled on the IPSEC VPN Crypto Map, which is attached to the correct outside interface. But the XML profile download still fails.

Client logs show xml profile is marked to be downloaded, and vpndownloader is executing, but the process fails.
Packet capture on FTD shows traffic to port 443 from client to headend is dropped (due to ACL). The ACL allows port 443. I understand even though we use IKEv2, any updates are done via port 443 if client services are enabled, which it is.
Would anyone have any idea what could be wrong here also.

Many thanks

[tvotna]

Since downloader doesn't work for you, you can disable it on the client by editing Local Policy file AnyConnectLocalPolicy.xml (and distributing it via SCCM). The file should be in the C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client. Change false to true:

<BypassDownloader>true</BypassDownloader>

This way you won't need to change anything on the firewall side. Connection will succeed even if client profile is different from the headend profile.

I guess you're referring to "acl-drop" in the ASP drop capture for TCP/443, right? The "acl-drop" is a very generic drop code (catch-all). Most likely TCP/443 is dropped due to something else, but the drop code displayed is acl-drop. ACLs on ASA/FTD do not block to-the-box connections. Only control-plane ACLs do, do you have one? Hopefully TAC will help with this issue.

[NGJ]

Thanks for the response.  Thats a great idea regarding the bypassdownloader, didnt know by disabling it, then it would still allow the connection if xml was different.  Would sure save a lot of hassle.   I'll give that a test and provide an update.

Regarding the 443 traffic, I did a packet capture on the device, Phase 4 type Access-List states DROP. Reason (acl-drop) Flow is denied by configured rule.  

Hpoefully TAC get back soon to take a look.

Thanks

[MHM Cisco World]

DNS in profile with always use as boundaries of trust, 

DNS in Dhcp is use for name resolved. 

Can you share 

Debug aggragte-auth xml 255

MHM

[NGJ]

I set the bypassdownloader to true.  This still caused issues.  So my local XML was different to headend.  When I tried to connect got the message 'Automatic profile updates are disabled and the local VPN profile does not match the secure gateway VPN profile.'

I did read in the admin guide that is the expected outcome. 

When Bypass Downloader is selected, one of two things happens upon client connection to the Secure Firewall ASA:

• If the VPN client profile on the Secure Firewall ASA is different than the one on the client, the client aborts the connection attempt.

• If there is no VPN client profile on the Secure Firewall ASA, the client makes the VPN connection, but it uses its hard-coded VPN client profile settings.

So it seems to prevent the xml checking I do need to ensure there is no xml on the headend also

[tvotna]

Hmm.. I didn't know this. You can remove profile from FTD and test, but the client may revert to hard-coded default settings and ignore always-on and SBL configured in the profile.

If removing profile from FTD doesn't help, there is a new feature in 5.0, but configuring this custom attribute in the group-policy on FTD can be tricky.

Cisco Secure Client 5.0.02075 New Features

This maintenance release includes the following features and support updates and resolves the defects described in Cisco Secure Client 5.0.02075:

• UseLocalProfileAsAlternative Custom Attribute—If you want to distribute a profile out-of-band (using SCCM, MDM, SecureX Cloud Management, or the like) without configuring a Cisco Secure Client Profile (previously known as an AnyConnect profile) on the Secure Firewall ASA, you can use the UseLocalProfileAsAlternative custom attribute. When you configure this custom attribute, the client uses the local (on disk) Cisco Secure Client profile for its settings and preferences (rather than the usual defaults). Refer to Predeploying Cisco Secure Client in the administration guide for additional information. Additionally, refer to Configure Secure Client Custom Attributes in an Internal Group Policy for configuration procedures required in ASDM version 7.19 (or later). The Secure Client Custom Attributes section in the Cisco Secure Firewall ASA Series VPN ASDM Configuration Guide provides the type and named value for this custom attribute and others.

 ASDM doc:

• UseLocalProfileAsAlternative: If you want to distribute a profile out-of-band (using SCCM, MDM, SecureX Cloud Management, or the like) without configuring a Cisco Secure Client Profile (previously known as an AnyConnect profile) on the Secure Firewall ASA, you can use the UseLocalProfileAsAlternative custom attribute. When you configure this custom attribute, the client uses the local (on disk) Cisco Secure Client profile for its settings and preferences (rather than the usual defaults). Refer to Predeploying Cisco Secure Client in the administration guide for additional information.

  Establishing the session using the local profile only occurs when 1) UseLocalProfileAsAlternative is set to enabled, and 2) if an ASA group policy profile is not configured. If you configure this custom attribute and do not undo or remove the Cisco Secure Client profile from the Group Policy configuaration on the ASA, the Cisco Secure Client Profile configured on the Group Policy will be maintained and used for each connection, where the custom attribute setting will be ignored.

  Name—disabled/enabled

  Values—true/false

[NGJ]

I have TAC now onboard actively looking into the issues why clients can't download the xml.  

[MHM Cisco World]

"":Packet capture on FTD shows traffic to port 443 from client to headend is dropped (due to ACL)."" <- This can indeed issue here' 

If you fmc go to 

Device > device management > http > then allow VPN pool to connect to FTD 

After do this step 

Share

debug I ask before.

MHM

[Marvin Rhoads · Accepted solution]

You need to enable BOTH SSL/TLS and Client services for profile updates to work with a remote access VPN that otherwise uses IPsec for VPN transport.

I had a customer with this same issue just last month.

[NGJ]

Hi Marvin

I was actually reading a whitepaper you wrote regarding this

Whitepaper - Configuring IPsec IKEv2 Remote Access VPN with Cisco Secure Firewall

I was under the impression that although we are using IKEv2, we didn't need to enable SSL, just enable Client Services.  Thats not the case then, we still need to enable SSL.  I did test that on a call with TAC. 443 traffic was no longer dropped, but we got an error on the client side 'failed to get configuration because Cisco Secure Client cannot confirm it is connected to your secure gateway'.  I sent the DART file, and they are looking into this.

Additionally with SSL enabled we could browse to the headend and a logon screen was presented.  That was something we wanted to avoid also.  TAC did say that can be controlled via a keepout message option.

[MHM Cisco World]

Friend no need enable ssl you just need allow traffic from vpn pool to ftd http port, this allow RA VPN that use Ikev2 to access ftd and download the new updated xml.

Go to device management in fmc and select ftd and then http allow traffic. 

MHM

[NGJ]

When you say go to Device Management, select ftd...where do I enable http?  Do you mean on the Policy ACL?  or Platform settings http option?

[MHM Cisco World]

Platform setting friend 

MHM

[tvotna]

Friend no need enable ssl you just need allow traffic from vpn pool to ftd http port, this allow RA VPN that use Ikev2 to access ftd and download the new updated xml

I believe this is completely wrong advice.

[Marvin Rhoads]

@NGJ - it's on my list to update my 2021 whitepaper to reflect the information I just learned last month.

Thanks for the reminder.