|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.
You think a roadwarrior configuration with preshared keys is not secure? You have found the right place. This article should give the last bit of information to cover any IPsec related setup with OpenWrt.
With site to site tunnels we have the choice between preshared keys and certificates. Both of them provide similar security levels. But sharing one key between several roadwarriors may be a huge security risk. If only one of them looses the configuration file with the preshared key the administrator has to redistribute a new key to all clients. When managing 10 or more laptops this can be a pain. The use of certificates will help us to keep maintenance moderate and to increase the security by an order of magnitude. So what to we have to think about:
We will repeat the setup of our last article. Just to avoid jumping between both pages we will repeat it here once again. The aspects are:
Manual creation of root certificates may be a security risk with site to site tunnels but not for road warrior configurations. This time both VPN tunnel ends are company owned machines so also the certificates should be controlled by the company. If not already done we will repeat the steps from our last certificate based setup.
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
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...' ...
Now we need 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 To ensure, that the certificate has a friendly common name (CN) we choose a mail address.
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
Now take our root certificate to sign the router certificate.
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>
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...'
So what is it all about? Why don't we need CRLs? As we already have learned ceartificates are an alternative to phase 1 handshakes with preshared keys. Messages are encrypted with the public certificates and the key owner can decrypt it with the private key. In our site to site setup we did not take special care about certificates and their subjects. This time we have to be more careful because every computer in the internet can drive an attack against our router. Therefore two criteria have to match before a road warrior certificate is allowed to connect.
Let us assume we create a new certificate for user Otto and set the subject to CNemail@example.com. We hand that certificate and its private key over to the users laptop and put the subject into the racoon white list. Afterwards Otto can pass IPsec phase 1 and is asked for his XAuth user password afterwards. If this matches too access is granted.
But what if Otto looses is laptop and his certificate. This is not critical as long as nobody else gets hold of Ottos password. But just to be sure we want to revoke the certificate long before it will expire. Nothing easyier than that. Simply remove it from the whitelist, generate a new one with another number (e.g. CNfirstname.lastname@example.org) and let Otto connect with it. Life can be soo easy.
Conclusion: Always generate certificates with unique subject names.
Repeat the following steps for each user that you want to give VPN access. First of all create a private key for our VPN user. Remove the password afterwards.
root@FungKu:/tmp# openssl genrsa -des3 -out otto.key.crypt 4096 Generating RSA private key, 4096 bit long modulus .........+++ ...........................+++ e is 65537 (0x10001) Enter pass phrase for otto.key.crypt: Verifying - Enter pass phrase for otto.key.crypt: root@FungKu:/tmp# openssl rsa -in otto.key.crypt -out otto.key Enter pass phrase for otto.key.crypt: writing RSA key
Create a certificate signing request for the key an place a unique subject name into it.
root@FungKu:/tmp# openssl req -new -key otto.key -out otto.csr -subj "/CNemail@example.com" root@FungKu:/tmp# ls -al otto.csr -rw-r--r-- 1 root root 903 Nov 29 13:54 otto.csr
Sign the certificate with the root certificate. If you like you can set an automatic expiration time. In our case we take 730 days or 2 years.
root@FungKu:/tmp# openssl x509 -req -days 730 -in otto.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out otto.crt Signature ok subject=/CNfirstname.lastname@example.org Getting CA Private Key Enter pass phrase for ca.key:
To establish a VPN connection we need three objects on the road warrior site. The root certificate, the user/machine certificate and the user/machine private key. To reduce errors wen distributing those files we will pack them together into one.
root@FungKu:/tmp# openssl pkcs12 -inkey otto.key -in otto.crt -certfile ca.crt -export -out otto.p12 -passout pass:
Beware! The file otto.p12 is not encrypted. Put it directly onto the road warrior laptop afterwards.
We already learned how to create users that are allowed to connect to the device in /etc/config/users. We will repeat the step but this time we add the certificate subject into the users section. This subject has to match the above created user/machine certificate
config 'user' option 'enabled' '1' option 'name' 'otto' option 'password' 'this_is_ottos_password' option 'xauth' '1' option 'crt_subject' 'CNemail@example.com'
Once again this is a repetition of our original PSK road warrior setup. The main difference is phase 1 authentication method xauth_rsa_server.
... config 'tunnel' 'roadwarrior' option 'enabled' '1' option 'remote' 'anonymous' option 'exchange_mode' 'aggressive' option 'pre_shared_key' 'a_very_secret_key' list 'p1_proposal' 'pre_g2_3des_sha1_xauth' list 'sainfo' 'acme_dmz' list 'sainfo' 'acme_lan' config 'sainfo' 'acme_lan' option 'remote_subnet' '192.0.2.0/24' option 'local_subnet' '10.1.2.0/24' option 'p2_proposal' 'g2_aes_sha1' config 'sainfo' 'acme_dmz' option 'remote_subnet' '192.0.2.0/24' option 'local_subnet' '184.108.40.206/26' option 'p2_proposal' 'g2_aes_sha1' config 'p1_proposal' 'pre_g2_3des_sha1_xauth' option 'lifetime' '28800' option 'encryption_algorithm' '3des' option 'hash_algorithm' 'sha1' option 'authentication_method' 'xauth_rsa_server' option 'dh_group' '2' config 'p2_proposal' 'g2_aes_sha1' option 'pfs_group' '2' option 'lifetime' '3600' option 'encryption_algorithm' 'aes' option 'authentication_algorithm' 'hmac_sha1' ...