Table of Contents

IPsec With Certificates

For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit vpn.overview

This page is about racoon. The new strongwang documentation can be found here.

Certificates are another approach for establishing IPsec VPN tunnels. This article describes everything that is required. Before you continue make sure you have everything in place from the basic and firewall configuation.

Background

Usually not only the preshared key but although the definition of the tunnel endpoint IP addresses gives a quite attack proof setup for an IPsec VPN tunnel. Security maniacs may argue that preshared keys are not really secure due to the fact that two different parties know the same secret. So if you think that you only want to go with certificates we should make clear how it works. A small picture will give a good overview.

Both sides that want to build a certificate based tunnel need a private key and a certificate that is generated from that key. During phase 1 (while establishing the tunnel) each side sends it public certificate to the remote end. The partner verifies that this certificate was signed by a certificate authorithy that he trusts. If both sides accept the foreign certificate the phase 1 can continue. They encrypt the data stream with their private keys and the remote end uses the sent certificate to decrypt it again. If the tunnel is up the security policies (phase 2) are handled as usual.

Just for the curious: More details can be found in this article. Important for our case: Two different encrpytion/decrpytion concepts exist. Symmetric and asymmetriy. Symmetric cryptography uses a common key to encrypt and decrypt data. Well known algorithm are 3DES or AES. Asymmetric encryption uses different keys for encryption and decryption. It is realized with a private/public key pair. Besides from that symmetric cryptography is much faster. Therefore IPsec only realizes phase 1 with certificates while the normal data transfer afterwards is processed with the same symmetric algorithms. So you will be slower and safer during tunnel creation but your transmission speed will not suffer from the changed setup.

Root CA

The major culprit with certificate based IPsec tunnels is the root certificate authority. You need not only two private keys and certificates for each side but someone who signs them an that will not be for cheap if done offically. If you connect your OpenWrt device to your company maybe they can sign your self generated certificate for you. If you are not in this lucky position, we have to create a root CA ourselfes. Attention! This will break any security concept. Nevertheless it simply works.

With this key we can generate our root certificate. To reduce further maintenance overhead, we will build it with a lifetime of 10 years (3650 days). And because we are working for ACME Inc. we will fill some helpful information inside.

root@SchengFui:/tmp# openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Enter pass phrase for ca.key: <password>
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:California
Locality Name (eg, city) []:LA
Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:ACME Inc.
Email Address []:
root@SchengFui:/tmp# ls -l ca*
-rw-r--r-- 1 root root 2114 Mar 30 06:10 ca.crt
-rw-r--r-- 1 root root 3311 Mar 30 06:06 ca.key

If your are interested in getting this certificate into the root CA list of Mozilla Firefox you can find a decent application template here. It will be much easier and for our setup absolutely necessary to save it in your OpenWrt router. Just create a new certificate section with a unique name in /etc/config/racoon ('acme_root' in our case). Remove all line feeds from the certificate before you paste it as a one-liner and do not forget to surround it by quotation marks.

For this key we generate a certificate signing request - remember that it has to be 'officially' signed by our trusted root certificate. To ensure, that the certificate has a friendly common name (CN) we choose a mail address. Everything else would be allowed too.

Configuration

With all certificates implemented the rest of the configuration is very easy. We will repeat the setup from the site to site guide. Just make a configuration that is similar to our preshared key version. For documentation purposes some explanations for the changed parameters.

option certificate: Tells racoon which certificate to use for authentication (openwrt in this case). The root CA does not need to be included at all. It will be choosen automatically by racoon.

option authentication_method: Has been set to rsasig. This is required to ensure that phase 1 is handled with certificates.

Central Side Gateway

It is always useful to see the setup from the other side. Here a peek at the ACME Juniper firewall on the remote end. Only phase 1 settings have been adapted to support certificate authentication. Most important are:

Remote identifier: Has to match the certificate subject name of the OpenWrt router.

Proposal: Changed from preshared key to certificate.

Local certificate: Local certificate of the firewall

Peer CA: The root CA that signed the OpenWrt router certificate.

Connection

The /etc/init.d/racoon start script will parametrize and start racoon so that it will work with certificates. Just start the process, configure the firewall and you should be able to reach the subnets on the other side of the tunnel.

DNS

Name resolution is just the same as in our site to site setup. Have a look over there for more details.