December 23, 2011

StrongSwan Configuration Guide

Recently I got a chance to study strongswan and its configurations. This document intends to record the findings, in the hope to help myself in the future and to help others too.

Strongswan is open-source IPSec/VPN software. It was based on FreeSwan, whose development is now stopped. Another descendent of FreeSwan is “OpenSwan”. I have no experience with OpenSwan, and therefore will be focusing on StrongSwan in this document.

By the way, I found the authors of StrongSwan (Andrea and Martini) very much helpful. The know strongswan inside out and was able to explain things really well in many of the mailinglist posts and also in the wiki documentation. This is a great strength of strongswan.

StrongSwan’s core VPN behavior is largely controlled by the configuration file /etc/ipsec.conf. There are many possible lines there you can put in this file. Some lines are extremely important, and a good understanding of what they mean is critical to the successful establishment of the VPN tunnels.

There are a few types of VPN Connections:

  1. Host to Host
  2. Net to Net
  3. Host to Net

Host to Host is fairly rare, and many of the things discussed here also apply to apply to it. So I will focus on “net-net” and “host-net”.

The following settings are tested with StrongSwan 4.5.3 and 4.6.1.

1.      Common Configuration

Common configuration lines in /etc/ipsec.conf

config setup
        strictcrlpolicy=no
        charonstart=yes
        plutostart=no
conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2
        esp=aes256gcm16,aes128gcm16!
        mobike=yes
        leftikeport=4500
        rightikeport=4500

Explanations:

“strictcrlpolicy” indicates whether CRL is mandatory or not. If CRL is not mandatory, put no. Otherwise, put yes.

“Charon” is the IKEv2 daemon, and “Pluto” is the IKEv1 daemon. In this document, we are only using “IKEv2” and will focus on IKEv2 options only.

“Mobike” stands for Mobile IKE. This is for the case where the public IP of the device may change. If Mobike is enabled, strongswan may float its communication port from UDP port 500 to UDP port 4500 and start telling the Linux kernel to use UDP encapsulation for ESP packets.  It is a good thing to enable if there is a chance that your device’s public IP may change.

“leftikepor” and “rightikeport” tells strongswan to always use UDP port 4500, from the very beginning of IKEv2 message exchange.


2.      Net to Net

2.1   VPN Server

A working net-net VPN SERVER configuration file

Conn myvpn
    left=%defaultroute
    leftcert=/etc/certs/vpn.cert
    leftsubnet=192.168.17.0/24
    leftfirewall=yes
    right=%any
    rightsubnet=0.0.0.0/0
auto=add

Left means “my side”. Right means “my peer’s side”.  You could switch it the other way, but this is how most people use it and is a common convention. Unless one really wants to be different and asking for troubles, it is strongly suggested that this common convention be followed.

“left” is your IP address. This can be set to “%defaultroute” where the system will figure out the value based on the “right” IP address.

“leftcert” is the certificate file of the left. The file path can be an absolute path (starting with /) or a relative path, in which case, the system will look for certs under /etc/ipsec.d/certs/

“leftsubnet”: This is “the” critical line that tells strongswan you want a subnet tunnel instead of a host tunnel. Without this line, the strongswan will try to make a host-only tunnel.  This is the subnet on “your” device’s side. Your peers will only be able to talk to IPs in this subnet.

“leftfirewall”: optional. Tells strongswan to automatically insert firewall rules (iptables rules) when a connection is up or down.

“right” is the peer’s address. For server, this can be “%any”.

“rightsubnet”: similar to “leftsubnet”, this line is critical to indicating that you want to connect to a “subnet”, not just a remote host. Unless “leftsubnet”, you can put “0.0.0.0/0” indicating that you just accept the subnet that the peer defines.

“auto=add” means when you run “ipsec start”, the ipsec daemon just listens, not initiate a connection. “auto=start” means that when you run “ipsec start”, the ipsec daemon will actually try to initiate a call. So “auto=add” is good for servers, and “auto=start” is good for clients. “auto=start” is equivalent to “auto=add” plus “ipsec up MYCONNECTION”

We skipped “leftid=”. leftid by default is derived from the leftcert certificate file, using the Distinguished Name, in the format of “C=XX, O=XXX, CN=XXX, …”. There are any forms of ID that can be used by the leftid/rightid field, but in this document we chose to use this format. See the end of this document for more detailed description of leftid/rightid field.

A working net-net VPN CLIENT configuration file

Net-net is pretty much symmetrical. You can run the above same configuration file on client side and it will work. I chose to one more configuration line:

rightid="C=CH, O=strongSwan, CN=server"

This tells the client to check the server’s certificate ID and make sure it matches this ID. This is just to be safe so that I know I did not connect to some other server. Keep this mind this is after the server certificate is being authenticated by the CA certificate.


3.      Host to Net

3.1   VPN Server

A working host-net VPN SERVER configuration file
conn server
leftcert=server.cert
leftfirewall=yes
right=%any
rightsourceip=192.168.22.0/24
auto=add

Notice that we simply removed “leftsubnet” and “rightsubnet” from the net-net VPN SERVER configuration, and here we have a host-net VPN SERVER.

We added one more line “rightsourceip”. This enables the server to “automatically assign a virtual IP address to the connecting peer”.

Note that in IKEv1 (Pluto) "rightsourceip" can be used to specify the internal side IP address. For IKEv2 (Charon) this is done automatically by the charon daemon and rightsourceip takes up the new meaning of requesting a virtual IP address. If the server does not have "rightsourceip" configured but client has "leftsourceip=x.x.x.x" configured, the tunnel establishment will fail because the server is rejecting the request for a virtual IP address.


3.2  VPN Client

A working host-net VPN CLIENT configuration file

left=%defaultroute
leftcert=client.cert
leftsourceip=%config
leftfirewall=yes
right=192.168.5.1
rightid="C=CH, O=strongSwan, CN=server"
auto=start

The only special line here is “leftsourceip”, which tells the client to obtain a virtual IP address from the VPN Server.


4.       leftid and rightid, what to use?

The ID by which a peer is identifying itself during IKE main mode can by any of the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first three ID types is used, then the accompanying X.509 certificate of the peer must contain a matching subjectAltName field of the type ipAddress (IP:), dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type DER_ASN1_DN, the identifier must completely match the subject field of the peer's certificate. One of the two possible representations of a Distinguished Name (DN) is the LDAP-type format
     rightid="C=CH,O=Linux strongSwan, CN=sun.strongswan.org"

Additional whitespace can be added everywhere as desired since it will be automatically eliminated by the X.509 parser. An exception is the single whitespace between individual words , like e.g. in Linux strongSwan, which is preserved by the parser.

The Relative Distinguished Names (RDNs) can alternatively be separated by a slash ( '/')  instead of a comma (',')

rightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org"

This is the representation extracted from the certificate by the OpenSSL command line option

openssl x509 -in sunCert.pem -noout –subject

The following X.501 RDNs are supported by strongSwan
 DC
 Domain Component
 C
 Country
 ST
 State or province
 L
 Locality or town
 O
 Organisation
 OU
 Organisational Unit
 CN
 Common Name
 ND
 Name Distinguisher, used with CN
 N
 Name
 G
 Given name
 S
 Surname
 I
 Initials
 T
 Personal title
 E
 E-mail
 Email
 E-mail
  emailAddress
 E-mail
 SN
 Serial number
  serialNumber
 Serial number
 D
 Description
 UID
 User ID
 ID
 X.500 Unique Identifier
 TCGID
 [Siemens] Trust Center Global ID
 unstructuredName
 Unstructured Name
 UN
 Unstructured Name
 employeeNumber
 Employee Number
 EN
 Employee Number

5.      Recommended Documentation
  1. http://www.strongswan.org/docs/readme.htm I’ve found this readme file very helpful, although it may be a little old. Information presented here still applies.  It is a good starting point, and gives you a good base understanding of everything. This should be the first read, and then you can move on to other documentation such as the wiki.
  2. Strong Swan WiKi, which contains “lots of” information. Here is a guide to get you started:
    1. IpsecConf http://wiki.strongswan.org/projects/strongswan/wiki/IpsecConf
    2. ConnSection http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
    3. ConfigurationExamples: http://wiki.strongswan.org/projects/strongswan/wiki/UserDocumentation#Configuration-Examples

6 comments:

  1. Yes its really useful :)

    ReplyDelete
  2. Finally, a document we human beings CAN understand! Thank you!

    ReplyDelete
  3. Thanks this was really helpful :)

    ReplyDelete
  4. Excellent overview and good references, thank you.

    ReplyDelete
  5. Dear Sir,
    I want to set up IPSec connection between IPV4 only host to IPV6 only host using Strongswan.. I tried to do..but i m finding dificulty.Please help me..

    ReplyDelete