This page is optional and only documentation for the speed freak.
In the times of broadband internet connections encryption and decryption speed of SOME low-end routers can limit throughput of VPN tunnels. CPU utilization can max out at 100 percent and impacts other services of the device like a web server. FOR REFERENCE: Strongswan will run just FINE on a WNDR3700 (MIPS 680 Mhz, 64 Mb RAM). If your router is underpowered, here are some other options:
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 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
ssh -2 -c aes128-cbc root@<router> time dd if=/dev/zero bs=500000 count=200 > /dev/null ssh -2 -c aes256-cbc root@<router> time dd if=/dev/zero bs=500000 count=200 > /dev/null
You can have a look at the realtime traffic graph in a dry run afterwards to verify the speed. But do not open it during your test because it invalidates the results.
If you use a default OpenWrt installation you will discover that working with the most secure AES256/SHA256 tunnel options will hit VPN performance. If you go for raw throughput going down the less secure AES128, SHA1 & MD5 functions can be a helpful alternative. One may remark that MD5 is 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 every hour according to phase 2 proposals. A good tradeoff could be to choose AES256/SHA256 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 have 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. If you opted for a cheap router there won't be any hardware crpyto device.
Users of a TP-Link WDR4900 might enjoy the benefits of some recent module developments.
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 mcespi.ko. The module is quite some years old and a first experience with crypto modules. Nevertheless it will work quite fine but needs manual compiling. The easyiest way to install it includes a few steps.
Basic setup and performance ok? So continue with the firewall modifications.