User Tools

Site Tools


IPsec Road-Warrior Configuration

IPsec Road-Warrior Configuration: Android, Windows 7, BB10, PlayBook, Dtek mobile devices.

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

:!: This page is about strongswan. The old racoon documentation can be found here.

Most of the racoon information is relevant (sort-of).

The basic context of the “road warrior” configuration:

  1. Your OpenWrt router is the firewalled HOST or gateway that receives requests to connect from mobile users, or clients.
  2. The clients have a dynamically assigned (private) IP outside your private net which changes.
  3. The clients frequently move around.
  4. The clients require access to both internal and external resources (full tunnel support) through a “gateway”.

Examples would be a phone or laptop that wants to VPN into a private home network. Note that Strongswan's IKEv2 with MOBIKE lets you leave VPN up ALL the time on a phone with near zero battery drain or perceptible performance hit. The benefits of this cannot be overstated for the roadwarrior.

This configuration uses TWO authentication mechanisms: certificates and a username/password challenge (EAP) for an added layer of security. This is an IKEv2 setup. Everything else in my opinion is obsolete and should not be used. IKEv2 is built-in to Windows 7 and Blackberry. It's added to Android using the Strongswan client.


  • Supported version of OpenWrt (opkg will complain about kernel version if not).
  • Strongswan-Full
  • OpenSSL (to make the .p12 or PKCS#12 package you distribute to clients)
  • If OpenWRT-LEDE version is less than 17.0.5 then patch the \lib\ file line 161 to:

modprobe $m || :

Tested on OpenWrt Barrier Breaker r37092-r39879 through to the current (July 2017) Openwrt Designated Driver 50107 on WNDR3700v2.
Tested on LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-18.147.69097-36945b5) on D-Link DIR-885L

To make sure Strongswan runs, you can type /etc/init.d/ipsec start

For testing, you will want to run logread in a scrolling window as follows:

logread && logread -f

We're going to edit the following:

  • /etc/strongswan.conf: Strongswan configuration file
  • /etc/ipsec.conf: Tunnel definitions
  • /etc/ipsec.secrets: List of secrets and keys
  • /etc/ipsec.d: Folder for certificates
  • /etc/config/firewall: Firewall changes to allow VPN traffic


charon {
        dns1 =
        nbns1 =
        plugins {
                include strongswan.d/charon/*.conf
include strongswan.d/charon/*.conf

Note that in earlier versions of StrongSwan (5.1.1 or earlier), you may find that charon plugins are not loading dynamically. You can spot by changing charondebug in ipsec.conf to check. If you must use an older version, try explicitly telling charon which plugins you want by adding “load = …” to charon like this:

charon {
load = aes des sha1 sha2 md5 pem pkcs1 gmp random nonce x509 revocation hmac stroke kernel-netlink socket-default updown attr farp dhcp

The above issue seems to have been resolved in 5.1.2 according to the Wiki here. Replace the IP addresses with the appropriate values for your INTERNAL network. In this and other examples, I expect your private internal network to be “dns1” entry tells charon (the IKEv2 service) where to go for dns - typically the openwrt host. “nbns1” entry tells charon where to go for netbios name services if you want to use windows file sharing.


Note that this is a certificate-based configuration with an additional username/password challenge. It REQUIRES you to put certificates on the server and clients, as well as have clients supply username and password.

config setup

conn %default

conn roadwarrior

Explanation: The notion of “left” and “right” is explained in the strongswan documentation, but briefly, “left” here is the “Local” (Left = Local) or private net you want access to, and “right” is the “Remote” (Right = Remote) or client side.

  • The config setup block is needed but can be empty
  • The conn %default block provides default settings if you plan on adding more profiles.
  • conn roadwarrior is our roadwarrior configuration.
  • leftauth = pubkey tells the host to use certificates.
  • leftid = the FQDN you put in the cert as subjectAltName (see “–san” option when you make your certs below). Note that it could be anything as long as it matches what you set on the client. Use of dyndns (in example) is advised if your gateway is also assigned a dynamic address.
  • leftsubnet = the scope of VPN. is a full tunnel, meaning ALL traffic will go through the VPN. You can put if you want your client to use the VPN to reach ONLY those addresses and your private net is The full tunnel option is more secure because it prevents a client from acting as a bridge.
  • right = %any - lets any peer IP connect. (remote user)
  • rightsourceIP = The pool of internal addresses to use for the VPN clients. Note that if you have only ONE client connecting, you could use as an example, which means that only 1 host can connect and it will be given the address You may want to assign IPs from a subnet which doesn't overlap neither your home nor your guest's LAN. You may set this to %dhcp and configure /etc/strongswan.d/charon/dhcp.conf accordingly if you want client addresses to be released by DHCP.
  • rightcert = the cert the client needs
  • rightauth = pubkey Tells the client to use certificates.
  • rightauth2 = eap-mschapv2 tells the client to use a second challenge: username and password, but this is not supported on iOS and Windows native IKEv2 clients

If you want to issue personal certificates to your clients then you should verify the signing CA's identity instead of the client certificates itself. To achieve this, use the rightca=“C=US, O=yyy, CN=xxxx” directive instead of rightcert, where yyy and xxxx are what you choose in the next steps at Making Keys. More information on this: strongSwan documentation With the above configuration, you will need to also install caCert.pem on your clients in addition to the client cert - see 'Making Keys' section below.


This configures the second authentication round done via eap-mschapv2 with user/password credentials. You can skip this if you don't use it.

: RSA serverKey.pem
remoteusername : EAP "secretpassword"

The first line defines the key to use and the second line is for the username/password challenge (EAP). Replace remoteusername and secretpassword with the values you want.

Making Keys

To make keys, run this script:

ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "C=US, O=yyy, CN=xxxx" --ca --outform pem > caCert.pem
ipsec pki --gen --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=US, O=yyy," --san="" --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem
ipsec pki --gen --outform pem > clientKey.pem
ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=US, O=yyy, CN=myvpnclient" --san="myvpnclient" --outform pem > clientCert.pem
openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "myvpnclient" -certfile caCert.pem -caname "xxxx" -out clientCert.p12

# where to put them...
mv caCert.pem /etc/ipsec.d/cacerts/
mv caKey.pem /etc/ipsec.d/private/
mv serverCert.pem /etc/ipsec.d/certs/
mv serverKey.pem /etc/ipsec.d/private/
mv clientCert.pem /etc/ipsec.d/certs/
mv clientKey.pem /etc/ipsec.d/private/

Now install clientCert.p12 and caCert.pem on the clients. Note that caCert.pem has been included already in the clientCert.p12 if you used the above commands, however depending on the client platform you may be required to install the CA certificate separately.


Add the following to your firewall configuration. You can use Luci for this.

config rule 'ipsec_esp'
	option src 'wan'
	option name 'IPSec ESP'
	option proto 'esp'
	option target 'ACCEPT'

config rule 'ipsec_ike'
	option src 'wan'
	option name 'IPSec IKE'
	option proto 'udp'
	option dest_port '500'
	option target 'ACCEPT'

config rule 'ipsec_nat_traversal'
	option src 'wan'
	option name 'IPSec NAT-T'
	option proto 'udp'
	option dest_port '4500'
	option target 'ACCEPT'

config rule 'ipsec_auth_header'
	option src 'wan'
	option name 'Auth Header'
	option proto 'ah'
	option target 'ACCEPT'

Explanation: Basically you're opening up the ports/protocols on the WAN zone that strongswan needs to accept traffic from a client. You can also create a custom zone called “VPN” if you want to get fancy.

You will also need additional forwarding rules in /etc/firewall.user. Note that strongswan mentions the leftfirewall=yes setting in ipsec.conf which used to add the iptables entries using the _updown script in /usr/libexec/ipsec/_updown but this has been deprecated and doesn't do anything.


iptables -I INPUT  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir out --pol ipsec --proto esp -j ACCEPT
iptables -I OUTPUT   -m policy --dir out --pol ipsec --proto esp -j ACCEPT


For testing, I used a Blackberry Z10 with NATIVE Ikev2 support (LOVE your Blackberry), an android phone with the StrongSwan Client, Windows 7 and 10 machines using native IKEv2, and a Blackberry DTek running Android with Dtek.

You can email clientCert.p12 and caCert.pem to the mobile clients.

For BlackBerry Clients

BlackBerry allows you to specify Perfect Forward Secrecy. You will want/need this. This should be standard. If you have problems, try adding the following lines to the ipsec.conf file in the conn roadwarrior section:


What this does is specify what cipher suites to use, including the Diffie Hellman Groups; you can read about these settings in the strongswan IKEv2 cipher suite documentation. Previously (before Strongswan 5.x), you'd use the pfs=yes statement. This has been deprecated.

Import your certificates into the Berry first, then add a VPN profile with the following settings:

  • Your gateway type will be “Generic IKEv2 VPN Server”,
  • Authentication Type = PKI,
  • Authentication ID Type= Identity Certificate Distinguished Name
  • Client Certificate = The name of your client cert (“myvpnclient” in the above example)
  • Gateway Auth Type = PKI
  • Gateway Auth ID Type = Identify Certificate Distinguished Name
  • Gateway CA Certificate = your server Certificate name (“xxxx” in the above example)
  • Perfect Forward Secrecy = On (VERY IMPORTANT)
  • Automatically determine IP = ON
  • Automatically determine DNS = ON
  • Automatically determine algorithm = ON

The rest can be left to defaults.

If you receive Authentication Error you can try to use distuingished name (DN) of your server's certificate instead of the FQDN for the leftid property. It is “C=US, O=yyy,” in the example above, but you can find out yours using the command below and looking for the “Subject” field

openssl x509 -in /etc/ipsec.d/certs/serverCert.pem -text -noout

For Windows 7+ Clients

In windows, import your client and CA certificates into Local Machine storage, not Current User. If you followed this tutorial the CA certificate is already in bundle with the client cert into the clientCert.p12 package, just take care of importing, again, into Local Machine and keep selected the option to automatically choose appropriate certificate store. At the end of the export you should have the CA into “Trusted Root Certification Authorities\Certificates” store and the client cert into “My\Certificates” store.

Follow these instructions to setup the Windows VPN connection:

For Android Clients

In Android, go to “Settings > Security” to import.

In the Strongswan client, specify “IKEv2 Certificate” (“+ EAP” if you enabled second round auth) as the type of VPN, pick “myvpnclient” for your certificate you just imported, and eventually specify the username/password combo you added to /etc/ipsec.secrets for second round auth. Keep an eye on the logfile (see above) during initial login to spot any issues.

If you get a proposal error in your log, such as: received NO_PROPOSAL_CHOSEN you need to specify an encryption proposal in your StrongSwan VPN Profile.

To do that, click Edit on the Profile, and scroll to the bottom to Advanced settings. At the bottom you will find a section called Algorithms.

Under IKEv2 Algorithms, enter: aes256-sha256-modp1024 or whatever IKEv2 Algorithm you are using.
Under IPsec/ESP Algorithms, enter: aes256-sha256 or whatever IPsec/ESP Algorithm you are using.
Save, and then try to connect again.

For iPhones/iOS Clients

Versions of iOS prior to iOS 9, like Android, only support IKEv1. This setup is not recommended. For versions of iOS prior to iOS 9, you will need to use an app to use IKEv2. Cisco's Anyconnect may work, but has not been tested.

Beginning with iOS 9, IKEv2 connections are natively supported. However, iOS9 only supports the use of certificates or username/password, but not both. Therefore, the native IKEv2 implementation in iOS 9 will not work with second round auth enabled. If you wish to use both certificates and username/passwords together for iOS 9 clients of your IPsec VPN, you will have to use a third-party application like Cisco's Anyconnect, but has not been tested.

To use the native IKEv2 support:

You must install the CA certificate (caCert.pem) and the personal certificate (clientCert.p12) onto the device, such as by access through iCloud drive or an email attachment. You do not need to set the CA certificate to be trusted for web sites.

iOS 12 client requires an additional directive leftsendcert=always in the ipsec.conf connection profile example above.

Sample iOS configuration, from Settings→VPN→Add Configuration…

Type: IKEv2
Description: <your choice>
Server: <domain name of VPN server:>
Remote ID: <same as Server>
Local ID: <CN from client certificate: myvpnclient>
User Authentication: None
Use Cerificiate: enabled
Certificate: select the certificate imported from clientCert.p12
docs/guide-user/services/vpn/ipsec/strongswan/roadwarrior.txt · Last modified: 2019/06/25 23:47 by lukepicci