strongSwan VPNs scalable and modularized! Andreas Steffen [email protected] Copyright © 2008 by Andreas Steffen Institute for Internet Technologies and Applications Hochschule für Technik Rapperswil, Switzerland The new strongSwan 4.2 IKEv2 release has been completely modularized. As an alternative to the classical ipsec.conf and ipsec.secrets configuration files, dynamical back end plugins now allow to load configuration data and user credentials from SQLite or MySQL databases. Together with a powerful XML- based web front end, thousands of IPsec tunnels can easily be managed, making strongSwan a truly scalable, industry-grade VPN solution. In addition to these new management features, all encryption and authentication algorithms have been implemented as pluggable modules, thus making it possible to integrate hardware-based crypto-accelerators, use the FIPS 140-2 certified OpenSSL library or attach smart card based secure authentication and storage modules. The strongSwan Mediation Manager is a FastCGI based web interface that writes configuration data and RSA public keys into an SQL database which in turn is accessible by the strongSwan Mediation Server. This leads to a user- friendly solution that makes it possible for two users hidden behind NAT routers each to establish a direct peer-to-peer IPsec tunnel, employing a coordinated UDP hole punching approach. What is strongSwan? strongSwan is a complete Open Source VPN solution for the Linux operating system. Released under the GNU General Public License (GPLv2) the source code can be freely downloaded from www.strongswan.org. The strongSwan software implements the IKEv1 (RFC 2409) and IKEv2 (RFC 4306) Internet Key Exchange protocols that are needed to set up secure IPsec tunnel connections in an automated way. Illustration 1 shows the the two main application areas: Reprint of LinuxTag2008 Paper 1 „Road Warrior“ VPN Client 10.3.0.2 10.1.0.5 10.2.0.3 55.66.x.x Internet VPN Tunnel Head Subsidiary Quarters VPN Tunnel 10.1.0.0/16 VPN Gateway VPN Gateway 10.2.0.0/16 11.22.33.44 55.66.77.88 Illustration 1: Site-to-site and remote-access VPNs ● Site-to-site VPNs that interconnect subnetworks at geographically disjoint locations via the public Internet. Typically the VPN gateways in front of the subnets have static IP addresses. ● Remote-access VPNs that allow “road warriors” to connect to their home network from any place on the globe. Typically road warriors have dynamically-allocated IP addresses, usually hide behind NAT routers and often make use of multi-homing network interfaces. Illustration 2: User-Mode-Linux based VPN testbed Reprint of LinuxTag2008 Paper 2 The strongSwan developers extensively use the User-Mode-Linux (UML) based virtual testbed shown in Illustration 2 for testing a broad range of VPN scenarios. Both site-to-site and remote-access setups can be simulated. The current test suite employed by our software regression tests comprises 84 IKEv1 and 62 IKEv2 examples based on IPv4 addresses and, due to the increasing deployment of IPv6 technology, a growing number of IPv6 scenarios. strongSwan Software Architecture The main focus of this paper is on the new modular software architecture introduced by the strongSwan 4.2 release. Since strongSwan has a long history going back to the famous FreeS/WAN project started in 1999 (see the FreeS/WAN family tree in Illustration 3), certain design constraints had to be obeyed in order to guarantee the full backward compatibility to previous strongSwan versions. The following two decisive milestones that occurred during the lifetime of the strongSwan project are worth mentioning: ● The strongSwan project was founded by the author in March 2004 as a fork from the FreeS/WAN project (www.freeswan.org) which was officially discontinued by its sponsor John Gilmore with the final freeswan-2.04 version released in April 2004. Both strongSwan and the second fork Openswan initially shared the same code basis including the author's X. 509 patch that added certificate and smartcard support to FreeS/WAN's basic IKEv1 capability. But whereas Openswan rather followed the VPN mainstream by supporting IKE Aggressive Mode, strongSwan focussed on strong certificate and smartcard based authentication mechanisms. 1999 FreeSFreeS/WAN/WAN 1.x 1.x 2000 X.509X.509 1.x 1.x Patch Patch FreeSFreeS/WAN/WAN 2.x 2.x 2004 SuperSuper FreeS FreeS/WAN/WAN 2003 X.509X.509 2.x 2.x Patch Patch OpenswanOpenswan1.x1.x 2004 OpenswanOpenswan2.x2.x strongSwanstrongSwan2.x2.x 2005 ITAITA IKEv2 IKEv2 Project Project 2006 OpenswanOpenswan3.x3.x strongSwanstrongSwan4.x4.x 2007 IKEv1 only IKEv1 & IKEv2 Illustration 3: The Frees/WAN genealogy Reprint of LinuxTag2008 Paper 3 ● The second milestone occurred in May 2006 when the strongSwan 4.x branch incorporating a first partial implementation of the IKEv2 protocol was presented at LinuxTag2006 in Wiesbaden. Whereas the IKEv1 pluto daemon inherited from the strongSwan 2.x branch was still heavily based on the original FreeS/WAN code, the IKEv2 charon daemon had been developed from scratch by applying modern object-oriented software design principles. In order to achieve full configuration compatibility between IKEv1 and IKEv2 connections, the architectural approach of Illustration 4 was chosen: The independent pluto and charon daemons are both controlled by the ipsec starter which parses the ipsec.conf configuration file and then transmits the connection information to the daemons via the whack and stroke socket interfaces, respectively. The whack and stroke record- based protocols are quite similar and are also spoken by the ipsec whack and ipsec stroke command line tools which are mainly used to send control and status commands directly to the keying daemons. Typical commands are up <conn>, down <conn>, statusall, listall, etc. The keying daemons communicate with the native IPsec stack of the Linux 2.6 kernel via a Netlink socket which speaks the XFRM protocol. IPsec SAs can be inserted and deleted and status information on the active tunnels can be retrieved from the kernel which does the actual ESP encryption and decryption work. Thus strongSwan is a pure userland application that interoperates with a standard IPsec-enabled Linux kernel. IKEv1 ipsec.confipsec.conf IKEv2 ipsecipsec ipsecipsec ipsecipsec whackwhack starterstarter strokestroke whack socket stroke socket plutopluto Netlink charoncharon XFRM socket Linux 2.6 kernel LSFLSF UDP/500UDP/500 nativenative rawraw socketsocket IPsecIPsec socketsocket Illustration 4: The strongSwan IKE daemons Reprint of LinuxTag2008 Paper 4 Software Architecture of the IKEv2 Daemon In the following we are going to concentrate on the IKEv2 charon daemon only, since no active development is taking place for the “old” IKEv1 pluto daemon any more. Fresh IKEv1 functionality might be integrated into charon at a future development stage. Illustration 5 shows a block diagram of charon's software architecture. Written completely in the C programming language, the IKEv2 daemon is fully multi-threaded. A total of 16 worker threads concurrently handle a broad set of different tasks. E.g. an IKE packet arriving at the UDP socket interface is assigned to an idle receiver thread which pre-parses the message and then queues a job with the scheduler for further processing. Reply packets are then sent by the sender thread to the socket interface. In addition to the UDP socket the following blocks are interfacing with the outside world: ● backends retrieve connection definitions ● credentials manage Pre-Shared Keys (PSKs), RSA private keys and fetch X.509 certificates and certificate revocation lists (CRLs). ● bus is responsible for the signalling of events among the threads and for logging to the syslog, the file system or a database. ● kernel interface communicates with the IPsec stack in the Linux 2.6 kernel via the Netlink socket interface using the XFRM protocol. At the core of the charon daemon is the IKE SA Manager which is responsible for the peer authentication based on the presented credentials and sets up IKE_SAs and dependent CHILD_SAs according to the connection definitions. credentialscredentials backendsbackends receiver CHILD SA receiver IKEIKE SA SA IKE CHILD SA schedulerscheduler IKE MM SASA aa CHILDCHILD SA SA socket nn socket a a CHILD SA gg IKEIKE CHILD SA processor ee SA processor r SA sendersender r busbus kernelkernelinterfaceinterface filefileloggerlogger syssysloggerlogger IPsecIPsecstackstack charon Illustration 5: Software architecture of the IKEv2 charon daemon Reprint of LinuxTag2008 Paper 5 Configuration and Control – the FreeS/WAN Way #ipsec.secrets for roadwarrior carol #ipsec.secrets for gateway moon [email protected] : \ : RSA moonKey.pem PSK "FpZAZqEN6Ti9sqt4ZP5EWcqx" [email protected] : \ #ipsec.conf for roadwarrior carol PSK "FpZAZqEN6Ti9sqt4ZP5EWcqx" conn home [email protected] : \ keyexchange=ikev2 PSK "jVzONCF02ncsgiSlmIXeqhGN" authby=psk left=%defaultroute #ipsec.conf for gateway moon leftsourceip=%config [email protected] conn rw leftfirewall=yes keyexchange=ikev2 right=192.168.0.1 authby=rsasig [email protected] left=%defaultroute rightsubnet=10.1.0.0/16 leftsubnet=10.1.0.0/16 auto=start leftcert=moonCert.pem [email protected] leftfirewall=yes right=%any rightsourceip=10.3.0.0/16 auto=add Illustration 6: IKEv2 Mixed PSK/RSA Authentication Illustration 6 shows a typical strongSwan connection definition using the classical configuration files ipsec.conf for connection and peer information and ipsec.secrets for credentials. Both file formats go a long way back to the original FreeS/WAN project and have been kept by the strongSwan project with only some extensions added. What is totally new, is the way the configuration files are used to set up an IKEv2 connection with a mixed PSK / RSA authentication plus the automatic assignment of virtual IP addresses for the road warrior clients from a common address pool. This goal is achieved with the following configuration parameters: ● keyexchange=ikev2 This parameter has always existed but had been used in the past with its default value “ike” that stood for “ikev1”.