| For an overview over all existing Virtual private network (VPN)-related articles in the OpenWrt wiki, please visit [[doc/​howto/​vpn.overview]] |

-

:!: This page is about strongswan. The old racoon documentation can be found [[vpn.ipsec.basics.racoon|here]].

+

A quick starters quide based on OpenWrt Barrier Breaker 14.07. Maybe it will save you and me time if one has to setup an IPsec VPN in the future. Hopefully it will ecourage other people to use Openwrt as an IPsec VPN router. We cannot provide a graphical user interface at the moment but at least it is a solid alternative to commercial IPsec appliances.

-

A quick starters quide based on Backfire 12.09. Maybe it will save you and me time if one has to setup an IPsec VPN in the future. Hopefully it will ecourage other people to use Openwrt as an IPsec VPN router. We cannot provide a graphical user interface at the moment but at least it is a solid alternative to commercial IPsec appliances. If you came here for informations about [[http://​www.openswan.org|Openswan]] on OpenWrt you may be disappointed. This guide is only about strongswan.

===== Packages =====

===== Packages =====

-

If not already installed on your router you need the at least those packages. **Ensure that you use strongswan 5.0.1 or higher**. Several severe bugs have been fixed in Charon that nowadays handles IKEv1 connections.

+

If not already installed on your router you need the at least those packages. ​

The major challenge is handling all of those files automatically with a clean integration into the OpenWrt configuration concept. To solve this we will use a hierarchical configuration process. That involves

-

* **/​etc/​init.d/​ipsec**:​ The Strongswan start script. It will generate the required configuration files for racoon

In the times of broadband internet connections encryption and decryption speed of routers can limit throughput of VPN tunnels. CPU utilization maxes out at 100 percent and impacts other services of the device like a web server. If you really want to go with a self made IPsec VPN on a cheap router you should consider some facts

-

* Older firewall devices with hardware accelerated VPN are sold for a few bucks on Ebay. Juniper Netscreen 5GT for example can easily reach a VPN throughput of 20 MBit/sec. Downside is that firmware updates are only possible with a Juniper support contract. So check twice for a bargain.

-

* Firewall devices are build to support IPsec out of the box. A convenient web interface helps the administrator to build a tunnel in a few seconds. OpenWrt still lacks a standard LuCI config panel. If you only go with 1-5 VPN tunnels this should be no concern to you.

-

To find the right OpenWrt hardware for your VPN you should have a look at the following benchmark table. It is build on a simple test without any claim of perfection. Nevertheless the numbers are quite close to what you can expect from an AES 128/256 bit encrypted IPsec Tunnel connection with standard kernel modules. You may notice that those numbers differ from what is written on the [[inbox:​benchmark.openssl|OpenSSL wiki page]]. But simply remember: **The tests over there do not include network traffic**. If you want to add a new device onto the list check the encrpytion throughput using the following prerequisites

If you use a default OpenWrt installation you will discover that using the SHA1 hashing function will hit VPN performance. If you go for raw throughput MD5 can be a helpful alternative. One may remark that MD5 is [[http://​en.wikipedia.org/​wiki/​Md5#​Security|not very secure]] but for IPsec connections it should be enough as we are talking about hash values of encrypted data with a key that is changed [[doc:​uci:​racoon#​p2_proposal|every hour]] according to phase 2 proposals. A good tradeoff could be to choose AES256/SHA1 for phase 1 and AES128/MD5 for phase 2. ​

-

-

Read on if you have some time and want to enhance your VPN speed. The kernel IPsec architecture relies on different crypto providers. E.g. if you build a tunnel with SHA1 checksums you must hava a module that can calculate those values. A look at /​proc/​crypto will reveal what modules are loaded and which algorithms they provide. The standard Linux Kernel modules are far from being optimized. At least with kernel 3.2 someone has taken care of [[http://​git.kernel.org/?​p=linux/​kernel/​git/​torvalds/​linux.git;​a=commit;​h=1eb19a12bd2214cdcad5273d472b062a4ba97fa1|SHA1]]. Those of you that are on **MIPS big endian** machines can replace the default aes_generic.ko,​ sha_generic.ko,​ cbc.ko and md5.ko modules with a single assembler optimized [[https://​sourceforge.net/​projects/​mcespi/​files/​|mcespi.ko]]. Besides of being faster it has some nice characteristcs:​

-

-

* SHA1 calculation works on registers only

-

* A lot of memcpy operations have been removed from MD5 and AES.

-

* AES memory footprint is lowered from 16K to 8,2K

-

* Avoid little endian byte swapping in AES

-

* 21K module size in contrast to 4 modules with 45K

-

-

If you are on AR7161 you should ensure that you already have [[https://​dev.openwrt.org/​browser/​trunk/​target/​linux/​ar71xx/​patches-2.6.39/​910-unaligned_access_hacks.patch|unaligned access patch 1]] from trunk and the not yet implemented [[http://​patchwork.openwrt.org/​patch/​1721/​|unaligned access patch 2]]. It will free CPU from handling unaligned access expections so that you can reach these results:

The module is in early alpha development an the easyiest way to install it includes a few steps.

-

-

* create a buildroot environment

-

* compile an image for your router once

-

* put the mcespi.c into the the folder build_dir/​linux-<​arch>/​linux-<​X.Y.Z>/​crypto

-

* Include the line **obj-$(CONFIG_CRYPTO_MD5) += mcespi.o** into build_dir/​linux-<​arch>/​linux-<​X.Y.Z>/​crypto/​Makefile

-

* compile the image once again.

-

* Afterwards you will find build_dir/​linux-<​arch>/​linux-<​X.Y.Z>/​crypto/​mcespi.ko

-

* Put mcespi.ko to your router into /​lib/​modules/<​X.Y.Z>​

-

* Load the module with insmod ​

-

* For automatic loading create a new /​etc/​modules.d/​09-crypto-mcespi with corresponding content.

-

-

If you are not on MIPS big endian but you have at least kernel 2.6.39 you can head for SHA1 performance optimization. Download [[http://​wiki.openwrt.org/​_media/​doc/​howto/​sha1-optimized.c|sha_optimized.c]] and build it as a module. FIXME Ticket [[https://​dev.openwrt.org/​ticket/​10637|#​10637]] tries to implement that patch into trunk. At least on Atheros AR7161 platform and current trunk this leads to an oops. If you can help and find out why just put your feedback here or over there. ​ Note: On current trunk the default kernel is 3.3 and sha_optimized.c does not have to be backported anymore.