Configuring, Verifying, and Troubleshooting a Point-to-Point FlexVPN with PKI Authentication

In this post I want to demo/breakdown configuring a point-to-point FlexVPN that uses certificate authentication. This lab demo will use PKI VPN authentication between two directly connected peers by utilizing an IOS PKI that has been referenced in other blogs. We will also explore ways to verify it. Lastly, I will share how to understand some valuable debugs.

I wont be covering IOS PKI in this post so to see more about understanding/configuring IOS PKI see: Configuring, Verifying, & Troubleshooting IOS PKI

As mentioned in other posts, there are 4 main building blocks when configuring an IOS device to support PKI. These blocks include your rsa/ec keypair creation, pki trustpoint, authenticating the trustpoint, and finally enrolling with the trustpoint to obtain an identity certificate.

Quick recap of PKI config on CSR1, which acts as our CA:

crypto pki trustpoint Cifelli-Lab
 revocation-check crl
 rsakeypair Cifelli-Lab

crypto pki server Cifelli-Lab
 database level names
 no database archive
 issuer-name CN=Cifelli-Lab,O=cifelli.lab.net
 grant auto
 hash sha512
 lifetime certificate 6000
 lifetime ca-certificate 7305

Note to change the IOS local storage location:

#crypto pki certificate storage flash:/certs

Note: to change your trustpoint to use an Elliptic Curve (EC) keypair:

(ca-trustpoint)#eckeypair <name>

Best practice would be to rely on using an EC keypair. Note: if using EC make sure in your IKEv2 profile you change the authentication type to ecsda-sig:

(config-ikev2-profile)#authentication <local/remote> ecdsa-sig

Now that our CA is staged, let's focus on building a P2P FlexVPN using certificates for authentication. Starting with CSR3 configs:

For the sake of this lab I disabled CRL verification so we can simply understand the config & verification process of authenticating the peers with PKI certs. Note that this is not best practice and in an enterprise scenario you want to validate certificates via OCSP/CRLs.

Let's configure our trustpoint container for the certificates that will be used for VPN authentication. In our example we disable revocation checks, assign the rsa keypair we will use, as well as other relevant/necessary configs for authenticating & enrolling with the CA.

crypto pki trustpoint Cifelli-Lab
 enrollment url http://192.168.4.1:8080
 fqdn csr3.cifelli.lab.net
 subject-name CN=csr3.cifelli.lab.net
 subject-alt-name csr3.cifelli.lab.net
 revocation-check none
 rsakeypair csr3.cifelli.lab.net 

Assuming we have successfully authenticated, & enrolled with our CA, let's proceed to setting up our IKEv2 items that will be used to negotiate and establish our IKEv2 SA. First we create a certmap that we will later assign to our IKEv2 profile. In our cert map we are specifying that the subject-name of the certificate contains cifelli.lab.net.

crypto pki certificate map Cifelli-Lab 10
 subject-name co cifelli.lab.net

For this example we use some of the smart defaults to make the configuration easier. Let's bind our certmap & create our IKEv2 profile of nonnegotiable parameters to be used for negotiation. We map/bind our cert map, set local identity to our fqdn to use as IKE identity in negotiation to avoid pki identity warnings, set local/remote auth to rsa-sig, & lastly specify our trustpoint to use for PKI verification.

crypto ikev2 profile Cifelli-Lab
 match certificate Cifelli-Lab
 identity local fqdn csr3.cifelli.lab.net
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint Cifelli-Lab 

Now let's map our IKEv2 profile to our IPsec profile that we will use for tunnel protection. Note that we use the default IPsec transform set.

crypto ipsec profile CSR3-IPSEC-PROF
 set ikev2-profile Cifelli-Lab

Next we configure a static virtual tunnel-interface (SVTI) so that we can establish our overlay. In the tunnel config we specify the underlay tunnel source/dest., IPsec profile to use for protection, & our P2P tunnel IP.

interface Tunnel0
 ip address 10.0.0.13 255.255.255.252
 tunnel source 192.168.3.3
 tunnel destination 192.168.4.4
 tunnel protection ipsec profile CSR3-IPSEC-PROF  

We initiate traffic to our remote destination to bring up our FlexVPN with certificate authentication between peers by pinging the remote side.

Peer CSR relevant config:

crypto pki trustpoint Cifelli-Lab
 enrollment url http://192.168.4.1:8080
 fqdn csr4.cifelli.lab.net
 subject-name CN=csr4.cifelli.lab.net
 subject-alt-name csr4.cifelli.lab.net,csr4.cifelli.lab.net,csr1.cifelli.lab.net
 revocation-check none
!                 
!         
crypto pki certificate map Cifelli-Lab 10
 subject-name co cifelli.lab.net
!

crypto ikev2 profile Cifelli-Lab
 match certificate Cifelli-Lab
 identity local fqdn csr4.cifelli.lab.net
 authentication remote rsa-sig
 authentication local rsa-sig
 pki trustpoint Cifelli-Lab
!    
crypto ipsec profile CSR4-IPSEC-CIFELLI
 set ikev2-profile Cifelli-Lab
!
interface Tunnel0
 ip address 10.0.0.14 255.255.255.252
 tunnel source 192.168.4.4
 tunnel destination 192.168.3.3
 tunnel protection ipsec profile CSR4-IPSEC-CIFELLI     

Now let's perform some verification:

Verifying our authentication method:

Verifying IPsec transform set defaults in use:

#show crypto ipsec sa

Debugging successful FlexVPN certificate authentication:

You can see in the debugs that our host is searching for the IKEv2 policy based on peer fqdn. It matches to our Cifelli-Lab IKEv2 profile we created earlier. From here the host continues to verify the cert chain of the received cert. The debugs also state that our auth method is via RSA signatures as we configured, and that the verification of the signed auth data has been successfully verified:

Some important debugs to understand to aide in troubleshooting config errors:

• %CRYPTO-6-IKMP_NO_ID_CERT_ADDR_MATCH = fqdn, the fully qualified domain name, provided by the vpn peer doesn't match the one stated on the digital certificate.

• %CRYPTO-6-IKMP_NO_ID_CERT_ADDR_MATCH: (NOT ERROR BUT WARNING ONLY)ID of 192.168.3.3 (type 1) and certificate addr with = setting local identity to fqdn or DN eliminates this identity cert mismatch error. Or adding the device IP address in sub alt name eliminates this identity warning error.

• %PKI-3-CERTIFICATE_INVALID_NOT_YET_VALID: Certificate chain validation has failed = Check system clock/ntp config

IKEv2 debugs when Certificate authentication fails:

Remember that best practice is to perform certificate verification, and to use elliptic curve cryptopgraphy. Thanks for reading. Cheers!