ASA IKEv2 L2L VPN Cert Auth failing

[christopher.wallace]

Hi guys,

How does an ASA verify/validate the certificate used for authentication of the remote end of an IKEv2 tunnel?

I'm having some problems with setting up a. L2L IKEv2 VPN using certificate auth. The VPN is between 2 ASAs, but I only control 1 side.

When I send 'interesting traffic', my ASA initiates IKE and the IKEv2 settings get passed, agreed and then auth is attempted. The only message I am getting back is:

IKEv2-PROTO-5: Parse Notify Payload: AUTHENTICATION_FAILED NOTIFY(AUTHENTICATION_FAILED)  Next payload: NONE, reserved: 0x0, length: 8
    Security protocol id: IKE, spi size: 0, type: AUTHENTICATION_FAILED

What could be the cause of this? I presume the other end doesn't like my cert. The question is why?

I've created a trustpoint on my end with my cert and my publishing CAs intermediate CA certificate. The identity cert I have is a general usage certificate, but the subject of my identity cert is a hostname, not my IP address and is not in the SAN of the certificate. I know that both ends are using the same CA, so the intermediate CA at my end should be OK to validate the remote end.

Should that be OK or do I need a cert with my IP address.

Thanks.

[Rahul Govindan]

If you have not changed the ISAKMP identity on your ASA, the ID that you will send to authenticate the cert is your cert DN. If you send the DN as ID, the remote ASA may not be able to validate the peer ID. There are 2 things you can do:

1) Disable peer-id validate on the remote ASA. Command is "peer-id-validate nocheck" in the tunnel-group ipsec attributes

2) Set your isakmp identity to address so that remote ASA uses that ID to validate and match the tunnel-group. Command is "crypto isakmp identity address". This is a global command and uses ip address as ID for all tunnels. PSK based tunnels use ID as address anyway so its ok.

More details on this here:

http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/117337-config-asa-router-00.html#anc9

[christopher.wallace]

Thanks for the reply. The link has some very useful info about peer authentication, but this leaves me with some challenges.

By policy, we cannot disable peer validation. I can probably enable this for testing purposes, but cannot leave this in place.

We use CSM to manage our ASAs and have a large number of site to site VPNs. The current VPNs are all using PSK, so from my understanding, if I change the "crypto isakmp identity" command from address to auto, the PSK VPNs will still work and it will try to validate certificate based VPNs using the DN from the cert. Is this correct?

Thanks.

[Rahul Govindan]

When set to auto, the identity is:

* Address for PSK based connections

* DN for cert based connection

Changing identity to address changes both to address.

Also understand that peer validation happens at both ends, so if the peer has set the isakmp identity to auto, they will send the DN as identity which will fail validation at your end. So the change would have to be made on both sides if you want to validate peer ID.

[christopher.wallace]

Hi guys,

So a little further info. It looks like my end is being authenticated at the remote end, but I suspect they have disabled peer authentication.

My trustpoint has both my identity certificate and the issuing CAs intermediate certificate.

The remote end is using the same CA.

I can start the VPN from my end and I can see IKEv2 starting. Once it gets to the authentication stage, the only message I am getting back is:

CRYPTO_PKI: No Tunnel Group Match for peer certificate.

How do I get this certificate to match the tunnel group? I know it uses the DN of the cert to identify the tunnel group, but the certificate only has an FQDN in it. Is there a way of using this for authentication?

We are trying to match a policy that says we have to use certificate based authentication, must verify the certificate and must check it against the CRL.

[Rahul Govindan · Accepted solution]

ASA uses the IKE ID to match the tunnel-groups. So, if your peer is sending the DN as the IKE ID, you would have to create a tunnel-group with that DN to match it automatically.

You can also use tunnel-group-map to match based on certificate attributes, like CN or issuer CN. This is a more recommended approach when you have dynamic tunnels using cert authentication. This would work well in your case too as you know the cert parameters before hand. Some more info on how to configure tunnel-group-map is here:

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113573-sol-tunnels-groups.html

[christopher.wallace]

Just so you know, I am using Cisco Security Manager to configure the ASA.

So, I've managed to get this to work using a certificate map, but I would like to check something.

When configuring the crypto map, you specify the peers IP address using the IP address. If you then have the tunnel group configured using the DN of the cert, how does the crypto map tie with the tunnel group?

Reading the command references, I see that the tunnel group name can be anything. From what you have been saying the tunnel group name should be the DN of the certificate. From what I have read, the tunnel group name can't have any spaces. The DN of the certificate currently has a number of spaces in it. eg. 'cn=<FQDN>,ou=Domain Control Validated'

In CSM, when creating the VPN topology, there is nowhere to enter the certificate DN, only the ability to specify the trustpoint used for IKEv2 authentication. The peers address can only be an IP address, not an FQDN.

Unfortunately, the only way exposed in the interface to create a certificate to tunnel group mapping is for remote access VPNs, so I have had to create a flex config to create the mapping.

[Rahul Govindan]

I think this might be a limitation on the way CSM handles VPN topologies. Majority of the Site to Site VPN's use IP address as IKE ID. The use of cert maps and non-ip address IKE ID's is more prevalent in Remote access use cases where you want to push users to different groups based on their cert parameters. I would recommend opening a case with Cisco to see if there is some sort of enhancement request for this already. Glad to hear that it is working for you with the cert map settings.