In the last article, we began configuring the site-to-site VPN tunnel between a Cisco ASA and a system running Ubuntu to use digital certificates for authentication. We ended that article with both devices being enrolled with the CA. In this article, we will complete our VPN configuration so that it uses digital certificates for authentication instead of pre-shared keys.
Our lab setup remains as shown below:
The first thing we need to do is edit the ipsec.secrets file on the Ubuntu system to point to the RSA private key we want to use.
Note: Since we protected our private key with a passphrase, we need to specify that passphrase in quotes. If we don’t specify it in the secrets file, then we will need to enter it every time we want to bring up the tunnel.
Therefore, I will enter the following in my /etc/ipsec.secrets file:
: RSA UbuntuKey.pem "cisco123"
Hint: If you didn’t protect your private key with a passphrase, then your configuration will just be “: RSA ”
General note of warning: Be careful when copying quotation marks or apostrophes from this article into your Linux terminal because it may not interprete it correctly. If you get an error with a command that contains an apostrophe or a quotation mark, just delete the quotation mark/apostrophe and type it using your keyboard.
I don’t have to specify the full path of the RSA keys because I have placed the key file in the default destination that Openswan will check, i.e. /etc/ipsec.d/private/.
The next thing we will do is to edit our VPN configuration file itself, i.e. L2L_with_ASA.conf (please refer to first article). Instead of editing the previous connection profile, I will just create another one and comment out the previous one. There are a few things we need to change/add:
The authby option will now be “rsasig” instead of “secret”. In fact, we can leave out this option since authentication using RSA digital signatures is the default.
We need to add the leftrsasigkey option which specifies the RSA public key for the Ubuntu system. We will use a value of “%cert” for this option so that the public key is automatically loaded from the certificate we define using the leftcert option (covered next).
We need to add the leftcert option to define the digital certificate we want to use. I don’t have to specify the full path if the certificate is placed in the /etc/ipsec.d/certs folder.
There’s one more option that we need to specify but let’s go on for now. My new connection profile looks something like this:
conn L2L_with_ASA_RSA authby=rsasig auto=start left=192.0.2.1 leftsubnet=192.168.56.0/24 leftrsasigkey=%cert leftcert=UbuntuCert.pem right=192.0.2.2 rightsubnet=10.0.0.0/24 ike=aes192-sha1;modp1024 phase2alg=aes256-sha1 pfs=no
Now for the moment of truth – let’s test. I will restart the IPsec service while viewing the logs on the Cisco ASA:
As you can see from the log snippet on the Cisco ASA above, the ASA feels that IKE Phase 1 successfully completed but then it receives an “encrypted Oakley Information packet with invalid payloads” from the Ubuntu system. After this, the ASA just waits endlessly for IKE Phase 2.
It took me about 4 hours to figure out what the problem was. Let’s view the logs on the Ubuntu system stored in the file /var/log/auth.log. The last part of the file shows the following:
Jan 17 01:07:33 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=NG, O=example.com, CN=ASA, unstructuredName=ciscoasa.example.com' Jan 17 01:07:33 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: no crl from issuer "C=NG, O=example.com, CN=Cisco IOS CA" found (strict=no) Jan 17 01:07:33 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: we require peer to have ID '192.0.2.2', but peer declares 'C=NG, O=example.com, CN=ASA, unstructuredName=ciscoasa.example.com' Jan 17 01:07:33 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: sending encrypted notification INVALID_ID_INFORMATION to 192.0.2.2:500
Basically, it says that it expects the peer IKE ID to be “192.0.2.2” (i.e. the ASA’s IP address) but the IKE ID the ASA sent was “C=NG, O=example.com, CN=ASA, unstructuredName=ciscoasa.example.com”. The reason this is happening is that when the ASA is using digital certificates for authentication, it sends its Distinguished Name (DN) as the IKE ID by default.
We can change this setting on the ASA using the crypto isakmp identity command. However, if we configure the ASA to identify itself with its IP address (crypto isakmp identity address), the tunnel will still not come up and we will get a new error:
Jan 17 01:15:11 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: Main mode peer ID is ID_IPV4_ADDR: '192.0.2.2' Jan 17 01:15:11 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: no crl from issuer "C=NG, O=example.com, CN=Cisco IOS CA" found (strict=no) Jan 17 01:15:11 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: no RSA public key known for '192.0.2.2'; DNS search for KEY failed (failure querying DNS for KEY of 126.96.36.199.in-addr.arpa.: Host name lookup failure) Jan 17 01:15:11 adeolu-VirtualBox pluto: "L2L_with_ASA_RSA" #1: sending encrypted notification INVALID_KEY_INFORMATION to 192.0.2.2:500
The new error is that there is no public key for the IKE ID of “192.0.2.2”. There are two ways we can resolve this issue:
Configure the ASA to use its FQDN as the IKE ID since the ASA’s FQDN is part of the details in the digital certificate (it is in the subjectAltName field). We will also need to configure the rightid option in our configuration file on the Ubuntu system to reflect the change. In our example, it will be firstname.lastname@example.org. “@” must be used when specifying an FQDN.
Leave the default IKE ID on the ASA, i.e. DN for certificate-based authentication. Configure the rightid option in the Ubuntu IPsec configuration file to reflect the ASA’s DN. In our example, this will be rightid=”C=NG, O=example.com, CN=ASA, unstructuredName=ciscoasa.example.com”.
Whichever option you use, check that the VPN tunnel is formed and test that the PCs can ping themselves:
Note: If your ping doesn’t work, check that you have routing enabled on the Ubuntu system and that you have added the route to the 10.0.0.0/24 network. Refer to the beginning of the first article for more information.
This brings us to the end of this article where we have used digital certificates for the authentication of the site-to-site VPN tunnel between a Cisco ASA and a system running Ubuntu.
I hope you have found this article insightful.