|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.
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.
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.
root@SchengFui:/tmp# openssl genrsa -des3 -out ca.key 4096 Generating RSA private key, 4096 bit long modulus .....................................++ .....................++ e is 65537 (0x10001) Enter pass phrase for ca.key: <password> Verifying - Enter pass phrase for ca.key: <password> root@SchengFui:/tmp# ls -l -rw-r--r-- 1 root root 3311 Mar 30 06:06 ca.key
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.
#/etc/config/racoon ... config 'certificate' 'acme_root' option 'crt' '-----BEGIN CERTIFICATE-----MIIGADCCA+igAwIBAgIJAI6xsXSYVD9NMA0GCSqGSI...' ...
The important certificate that we still need is the router certificate itself. So we have to start with a key again.
root@SchengFui:/tmp# openssl genrsa -des3 -out openwrt_encrypted.key 4096 Generating RSA private key, 4096 bit long modulus .............++++++ ....................................................++++++ e is 65537 (0x10001) Enter pass phrase for openwrt_encrypted.key: <Password> Verifying - Enter pass phrase for openwrt_encrypted.key: <Password>
This key is encrypted with the password you provided. We have to decrypt it so that racoon can access it.
root@SchengFui:/tmp# openssl rsa -in openwrt_encrypted.key -out openwrt.key Enter pass phrase for openwrt_encrypted.key: <Password> writing RSA key
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.
root@SchengFui:/tmp# openssl req -new -key openwrt.key -out openwrt.csr -subj "/CNemail@example.com" root@SchengFui:/tmp# ls -al openwrt.csr -rw-r--r-- 1 root root 546 Oct 22 13:14 openwrt.csr
We can either send this signing request to the external certificate authority or use our just created root certificate. In the second case we have to use openssl once again.
root@SchengFui:/tmp# openssl x509 -req -days 3650 -in openwrt.csr \ -CA ca.crt -CAkey ca.key -set_serial 01 -out openwrt.crt Signature ok subject=/CNfirstname.lastname@example.org Getting CA Private Key Enter pass phrase for ca.key: <Password>
One thing left. Place the private key and the signed certificate in the /etc/config/racoon file into a new certificate section. Remove line feeds and use quotation marks this time too.
config 'certificate' 'openwrt' option 'key' '-----BEGIN RSA PRIVATE KEY-----IIJKAIBAAKCAgEAqMFzh...' option 'crt' '-----BEGIN CERTIFICATE-----IIE7DCCAtQCAQEwDQYJKoZIh...'
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.
#/etc/config/racoon ... config 'tunnel' 'acme' option 'enabled' '1' option 'remote' '220.127.116.11' option 'pre_shared_key' 'yourpasswordhere' option 'exchange_mode' 'aggressive' option 'certificate' 'openwrt' list 'p1_proposal' 'rsa_g2_aes_sha1' list 'sainfo' 'acme_dmz' list 'sainfo' 'acme_lan' config 'p1_proposal' 'rsa_g2_aes_sha1' option 'encryption_algorithm' 'aes 128' option 'hash_algorithm' 'sha1' option 'authentication_method' 'rsasig' option 'dh_group' '2' config 'sainfo' 'acme_lan' option 'local_subnet' '192.168.2.64/26' option 'remote_subnet' '10.1.2.0/24' option 'p2_proposal' 'g2_aes_sha1' config 'sainfo' 'acme_dmz' option 'local_subnet' '192.168.2.64/26' option 'remote_subnet' '18.104.22.168/26' option 'p2_proposal' 'g2_aes_sha1' config 'p2_proposal' 'g2_aes_sha1' option 'pfs_group' '2' option 'encryption_algorithm' 'aes 128' option 'authentication_algorithm' 'hmac_sha1' ...
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:
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.
Name resolution is just the same as in our site to site setup. Have a look over there for more details.
IPsec VPN tunnels with overlapping subnets on both ends of the tunnel.