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-Labcrypto 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 7305Note to change the IOS local storage location:
#crypto pki certificate storage flash:/certsNote: 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-sigNow 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.netFor 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-LabNext 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!