User Tools

Site Tools


IPsec Road-Warrior Certificates

For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit 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.


Before continuing you should know the details of the basic and firewall guide. Additionally you will need some modifications in place.

Security aspects

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:

  • Certificate authority: Jumping on the certificate bandwagon we need our own root CA. This is required to sign the client certificates and the firewall certificate. This will ensure that nobody else will create certificates on his own.
  • Client certificates: Think of a client certificate as a machine authorisation. Of course it has something to do with the user behind the machine. But as in our last discussion we will verify users with XAuth. So users have to identify themselfes with passwords.
  • Certificate revocation list (CRL): In a normal setup this list will conatin all certificates that should no longer have VPN access (because they got lost). In our setup we will completely ignore CRLs. Not only they are complicate to manage but also there exists a very simple workaround. We will come back to that later.

Road Warrior Configuration

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:

  • We want to provide access to two different company networks. ACME LAN with addresses and ACME DMZ with
  • A laptop that connects to a VPN network is assigned a “secondary VPN inside IP” on a virtual VPN adapter. Our roadwarriors should get IP addresses from the range

Root CA

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.

config 'certificate' 'acme_root'

Router Certificate

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 "/"
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
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...'

Machine/User Certificates

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.

  • The certificate has to be signed by our root certificate
  • The sertificate alternate subject (asn1dn) has to be on a list of allowed certificates

Let us assume we create a new certificate for user Otto and set the subject to 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. 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 "/"
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
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' ''

OpenWrt Configuration

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' ''
  option 'local_subnet' ''
  option 'p2_proposal' 'g2_aes_sha1'

config 'sainfo' 'acme_dmz'
  option 'remote_subnet' ''
  option 'local_subnet' ''
  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'

Client Configuration

Put the otto.p12 on the road warrior laptop and configure the Shrew client as follows.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
docs/guide-user/services/vpn/ipsec/racoon/roadwarriorcertificates.txt · Last modified: 2019/08/26 16:00 by vgaetera