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

[NGJ · Accepted solution]

Thought I would provide an update what worked for us to get this issue resolved.

SSL and client services had to be enabled on the Access Interface to allow the XML profile to be downloaded, as pointed out in previous comments.
We did not enable SSL VPN on the RA Group Policy, as we wanted to use IKEv2 only.

Still we had an issue and the profile wasnt being downloaded.
Cisco TAC analysed the DART file and discovered further issues related to the Certificate.

The Secure Clients DART logs showed various errors, i.e.
EKU not found in certificate: 1.3.6.1.5.5.7.3.1
Extended key usage verification failed
CERTIFICATE_ERROR_VERIFY_ENHKEYUSAGE_FAILED:The certificate did not contain the required Extended Key Usages

We had pointed the SSL settings on the access interface to use the same certificate as we used for IKEv2.
However this certificate didnt include the extended key usage (EKU) of Server Authentication.

We use microsoft CA services.
So we generated a seperate cert to be used for SSL, that included the EKU of Server Authentication in its template on the CA.

Process now works as expected.
Secure client connects, does a check against local XML and whats on the headend.
If it detects a difference, the headend XML now get downloaded to the client

Thanks

[MHM Cisco World]

So in end both SSL and IPsec need to enable to male xml download?

Can you confirm 

Thanks 

MHM

[NGJ]

Yes, IPsec used for the tunnel, SSL for the XML profile to be downloaded (along with client services enabled in the crypto map).

Prior to discovering the certificate issue, we did also ensure that https access using port 443 was disabled in platform settings.  We use FMC to configure the FTDs anyway.  TAC suggested this be done also.

[MHM Cisco World]

Thanks alot for update me

""we did also ensure that https access using port 443 was disabled in platform settings.""

I.e. TAC suggest disable https access to ftd (via platform settings)?

MHM

[NGJ]

Yes as part of the initial troubleshooting.  FMC uses different ports to manage the FTDs, so no need for us to have https enabled in platform settings.   We wanted to ensure nothing else was listening on 443 that may have been causing an issue with the profile download. 

Not sure if it was ultimately required to disable https for our setup, but thought I would mention as could be a potential issue also. In fact the help page states https and SSL VPN cannot be enabled on same interface for same TCP port, so that could impact some scenarios.

Thanks

[Marvin Rhoads]

@NGJ I updated my article to note the required SSL/TLS and client services options for profile downloads.

I believe the platform settings should only affect the FTD device being able to serve troubleshooting and such files up from /ngfw/var/common via the management interface. It does not affect remote access VPN or other services on the dataplane interfaces.

[NGJ]

Ok thanks.  I've now got your updated Whitepaper also.