strongSwan

h1. Sane Example configurations

Preliminary obligatory notes:

* These examples follow the [[SecurityRecommendations|Security Recommendations]]. Follow them. They are there

  for a reason.

* You can have several conn sections in your @ipsec.conf@ file

* In scenarios where the remote peer authenticates itself with a client certificate,

  charon requires all certificates that are in the trust path of the client's certificate

  to be present, readable and valid for authentication

  to be successful. charon implicitely trusts all CA certificates that it loads

  via local files or that are loaded via the VICI API.

* In scenarios where charon authenticates itself with a certificate, it needs to have

  all certificates in the trust path. 

* charon only reads the first certificate in a file.

* Your responder (the proper word for "server" in ipsec talk) needs to identify

  and authenticate itself to the initiator (the proper word for "client" in ipsec talk)

  with the apropriate identity. If your initiator wants to talk to "foo.bar.com",

  your responder needs to identify and authenticate itself as _foo.bar.com_.

* Credentials are bound to identities. You can not successfully authenticate yourself

  as the identitiy _foo.bar.com_ with a certificate if that certificate is not issued for that

  identity. The identities that a certificate provide are its complete DN and the SAN fields.

* The used cipher suite must be supported by both sides. Some implementations

  only support weak crypto. Do not make concessions, unless necessary for interoperability.

* XAUTH credentials are handled internally as EAP credentials. Both are valid for

  XAUTH, EAP-GTC, EAP-MSCHAPv2 and whatever other cleartext or digest based

  authentication might be implemented in the future.

* The cipher settings are deliberately ordered by performance.

  Faster, but secure ciphers appear in the beginning of the cipher list.

  That should make charon choose faster, but secure ones first.  

* Do not use MD5, DES or 3DES. They are broken.

* The algorithm your certificate uses and they algorithm the key exchange uses

  do not have anything to do with each other.

* strongSwan does not implement L2TP.

* Read the documentation and use "the search function":https://wiki.strongswan.org/projects/strongswan/search.

h2. Roadwarrior scenario

This is an example configuration that provides support for several clients

with several authentication styles.

{{collapse(ipsec.conf)

<pre>

conn rw-base

    # enables IKE fragmentation 

    fragmentation=yes

    dpdaction=clear

    # dpdtimeout is not honored for ikev2. For IKEv2, every message is used

    # to determine the timeout, so the generic timeout value for IKEv2 messages

    # is used. 

    dpdtimeout=90s

    dpddelay=30s

# this is used in every conn in which the client is assigned a "virtual" IP or

# one or several DNS servers    

# the cipher suits require the openssl plugin.

conn rw-config

    also=rw-base

    rightsourceip=172.16.252.0/24

    # set this to a local DNS server that the clients can reach with their assigned IPs.

    # Think about routing.

    rightdns=

    leftsubnet=0.0.0.0/0

    leftid=whatevertheclientusestoconnect

    leftcert=mycertificate.pem

    # not possible with asymmetric authentication

    reauth=no

    rekey=no

    # sane cipher suits

    ike=aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072

    esp=aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072#

    leftsendcert=always

    rightca="C=This, O=Is, OU=My, CN=CA"

# this conn is set up for l2tp support where the user authentication is happening

# in the l2tp control connection. With L2TP, clients are usually not assigned

# a virtual IP in IKE.

# Charon is not an l2tp server. You need to install xl2tp for that and configure it correctly.

# mark=%unique requires the connmark plugin.

conn ikev1-l2tp-chap-auth-in-xl2tpd

    also=rw-base

    # reduce to the most secure combination the client can support, if absolutely required.

    ike=aes128-sha1-modp3072

    esp=aes128-sha1-modp3073

    leftsubnet=%dynamic[/1701]

    rightsubnet=%dynamic[/1701]

    mark=%unique

    leftauth=psk

    rightauth=psk

    type=transport

    auto=add

# this conn is set up for l2tp support where the user authentication is happening

# during the IKEv1 authentication. With L2TP, clients are usually not assigned

# a virtual IP in IKE.

# mark=%unique requires the connmark plugin.

# this requires the xauth-generic plugin.

conn ikev1-l2tp-xauth-in-ike

    also=rw-base

    # reduce to the most secure combination the client can support, if absolutely required.

    ike=aes128-sha1-modp3072

    esp=aes128-sha1-modp3073

    leftsubnet=%dynamic[/1701]

    rightsubnet=%dynamic[/1701]

    mark=%unique

    leftauth=psk

    rightauth=psk

    rightauth2=xauth-generic

    # not possible with asymmetric authentication

    reauth=no

    rekey=no

    type=transport

    auto=add

# this requires the xauth-generic plugin.

conn ikev1-psk-xauth

    also=rw-config

    leftauth=psk

    rightauth=psk

    rightauth2=xauth-generic

    auto=add

# leftauth and rightauth default to "pubkey", so no change necessary.

conn ikev1-pubkey

    also=rw-config

    auto=add

# this requires the xauth-generic plugin.

conn ikev1-pubkey-xauth

    also=rw-config

    rightauth2=xauth-generic

    auto=add

# this requires the xauth-generic plugin.

conn ikev1-hybrid

    also=rw-config

    rightauth=xauth-generic

conn ikev2-pubkey

    also=rw-config

    auto=add

# this requires the eap-tls plugin.

conn ikev2-eap-tls

    also=rw-base

    rightauth=eap-tls

    eap_identity=%identity

    auto=add

# this requires the eap-mschapv2 plugin.

conn ikev2-eap-mschapv2

    also=rw-config

    rightauth=eap-mschapv2

    eap_identity=%identity

    auto=add

</pre>

}}

{{collapse(ipsec.secrets)

<pre>

: PSK "foobarblah"

: RSA myprivatekey.pem

carol : EAP "carolspassword"

</pre>

}}

h2. Site-To-Site-Scenario

{{collapse(ipsec.conf)

<pre>

conn sts-base

    fragmentation=yes

    dpdaction=restart

    ike=aes192gcm16-aes128gcm16-aes192-prfsha256-ecp256-ecp521,aes192-sha256-modp3072

    esp=aes192gcm16-aes128gcm16-aes192-ecp256,aes192-sha256-modp3072#

    keyingtries=%forever

    leftcert=foobar.pem

# this conn is set up for a host with a static IP

conn site-1-static-ip

    also=sts-base

    keyexchange=ikev2

    leftsubnet=10.1.2.0/24,10.1.1.0/24

    rightsubnet=10.1.3.0/24

    right=1.2.3.4

    rightcert=1.2.3.4.pem

    auto=route

# this conn is set up for a host with a dynamic IP

conn site-2-dynamic-ip

    also=sts-base

    keyexchange=ikev2

    leftsubnet=10.1.2.0/24,10.1.1.0/24

    rightsubnet=10.1.4.0/24

    # for this to work, DNS must be usable and working.

    right=%example.com

    rightcert=example.com.pem

    auto=route

# this conn is set up for IKEv1 compatibility. It shows how to define several subnets

# with IKEv1. site-3-legacy-1 and site-3-legacy-2 keep the data for the CHILD_SA.

# The same can be accomplished with implicit merging by specifying the same IKE_SA

# configuration in two different conns. This set up is cleaner, though.

# If you put "auto=route" into the "site-3-legacy-base conn", charon will route the

# conn with the ts being the local IP that is used to communicate with the remote

# peer and the remote's peer. If such a CHILD_SA is not configured on the peer, ICMP

# error messages from the remote peer to the local peer will not be able to be transmitted.

# So don't do that, unless your remote peer is configured for that.

# This is an IKEv1 connection with PSK authentication. That means, that you need to know

# the other side's IP.

conn site-3-legacy-base

    also=sts-base

    keyexchange=ikev1

    # IKE and ESP cipher settings are reconfigured, because in IKEv1 every 

    # single cipher suite needs to be enumerated.

    # It is not possible to define all supported ciphers in one suite.

    # select apropriate and strong ciphers for your scenario.

    ike=aes192gcm16-prfsha256-ecp256,aes128gcm16-prfsha256-ecp256,aes128gcm16-prfsha256-ecp521,aes192-sha256-modp3072

    esp=aes192gcm16-ecp256,aes192-sha256-modp3072

    rightsubnet=10.1.5.0/24

    # for this to work, DNS must be usable and working.

    right=example.com

    leftauth=psk

    rightauth=psk

conn site-3-legacy-1

    leftsubnet=10.1.1.0/24

    also=site-3-legacy-base

    auto=route

conn site-3-legacy-2

    leftsubnet=10.1.2.0/24

    also=site-3-legacy-base

    auto=route

</pre>

}}

{{collapse(ipsec.secrets)

<pre>

: RSA foobar.key

remote.com : EAP "example"

</pre>

}}

h2. passthrough policy

{{collapse(ipsec.conf)

<pre>

conn passthrough-1

    # makes sure those conns are excluded from every conn selection

    left=127.0.0.1

    right=127.0.0.1

    # Those are just example values. Replace them with the apropriate ones!

    leftsubnet=10.0.0.0/8

    rightsubnet=10.0.0.0/8

    # those two lines are critical.

    type=passthrough

    auto=route

</pre>

}}

h2. host-to-host opportunistic transport mode

Based on "the trap-any test scenario":https://www.strongswan.org/testing/testresults/ikev2/trap-any/.

The hosts involved are in the 192.168.1.0/24 subnet.

{{collapse(ipsec.conf)

<pre>conn host-to-host

	ikelifetime=60m

	keylife=20m

	rekeymargin=3m

	keyingtries=1

conn trap-any

    also=host-to-host

	right=%any

	leftsubnet=192.168.1.0/24

	rightsubnet=192.168.1.0/24

	type=transport

	authby=psk

	auto=route

</pre>

}}