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 3DES, CAST, DES or MD5. 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.

* Multiple pools can be used at the same time.

* The [[IpsecPool|ipsec pools]] tool with the [[attrsql]] plugin can be used to assign different DNS and NBNS servers,

  as well as different arbitrary attributes to remote peers.

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

h2. Roadwarrior scenario

h3. Responder

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-modp3072

    leftsubnet=%dynamic[/1701]

    rightsubnet=%dynamic

    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-modp3072

    leftsubnet=%dynamic[/1701]

    rightsubnet=%dynamic

    mark=%unique

    leftauth=psk

    rightauth=psk

    rightauth2=xauth-generic

    xauth=server

    # 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

    xauth=server

    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

    xauth=server

    auto=add

# this requires the xauth-generic plugin.

conn ikev1-hybrid

    also=rw-config

    rightauth=xauth-generic

    xauth=server

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>

}}

h3. Initiator

These configuration files provide valid and usable configurations as use

as a roadwarrior client against arbitrary IKE responders that are configured correctly.

*You need to replace the marked values with the correct values*

Remove conns that you do not require for your scenario. Some values

might need to be changed, depending on the brokeness of the responder.

*Read the comments in the files and read _ipsec.conf_ as well as _ipsec.secrets_.*

The configurations shown here are not exclusive. There are a lot more possible.

Check out the [[PluginList|plugin list]] and the "test scenarios":https://strongswan.org/uml/testresults5/

to see how they can be configured, but beware, those are just test scenarios

and the configurations there are not usable in production as a whole. They need

to be combined with the examples here to produce usable scenarios.

{{collapse(ipsec.conf)

<pre>

conn rw-base

    dpdaction=restart

    dpddelay=30

    dpdtimeout=90

    fragmentation=yes

conn vip-base

    also=rw-base

    leftsourceip=%config

conn ikev1-psk-xauth

# uncomment if the responder only supports crappy crypto. But seriously,

# every single one of those algorithms is broken. Better spend some $$$

# on a better solution.

# 

#   ike=3des-md5-modp1024!

#   esp=3des-md5!

# Use this, if you want PFS with DH group 2.

#   esp=3des-md5-modp1024!

    also=vip-base

    keyexchange=ikev1

    leftauth=psk

    leftauth2=xauth

    right=RespondersIPorFQDNGoesHere

# You might have to set this to the correct value, if the responder isn't configure correctly.

#   rightid=foobar

    rightauth=psk

# this tunnels all the traffic. You might maybe want to also define a passthrough policy

# for the local LAN traffic (or use the bypass-lan plugin when it's gone into the master branch)

# Choose a smaller subnet, if required.

# this config supports CISCO UNITY. 

# Remove the ::/0, if you don't require IPv6.

    rightsubnet=0.0.0.0/0,::/0

    auto=add

# aggressive mode is incredibly insecure.

conn ikev1-psk-xauth-aggressive

    aggressive=yes

    also=ikev1-psk-xauth

    auto=add

conn ikev1-rsa-xauth

    also=vip-base

    keyexchange=ikev1

    leftauth=pubkey

    leftauth2=xauth-generic

    leftcert=thisithepathtomycertificate.pem

    xauth_identity=thisismyusername

    right=RespondersIPorFQDNGoesHere

# You might require this if the responder sends a wrong ID.

#   rightid=somethingsomething

    rightauth=pubkey

# The following settings depend on if you've got the CA that issued the

# responder's certificate or just the certificate.

# if you've got the CA certificate, put it into /etc/ipsec.d/cacerts/. Also

# read the notes in the beginning of the page about certificates.

#   rightca="This is the DN of the CA's certificate"

# if you've only got the responder's certificate

#   rightcert=thisisthepathtothecertificate

    auto=add

conn ikev1-l2tp

    also=rw-base

    keyexchange=ikev1

    type=transport

    right=RespondersIPorFQDNGoesHere

    rightsubnet=%dynamic[/1701]

    leftauth=psk

    rightauth=psk

# if your responder uses aggressive mode, add

# aggressive=yes in the conn

# user authentication happens in IKE using xauth

conn ikev1-l2tp-ipsec-userauth-in-ike

    also=ikev1-l2tp

    leftauth2=xauth-generic

    auto=add

# if your responder uses aggressive mode, add

# aggressive=yes in the conn

# user authentication happens in L2TP

conn ikev1-l2tp-ipsec-userauth-in-l2tp

    also=ikev1-l2tp

    auto=add

# Authentication with EAP-MSCHAPv2 is asymmetric. The responder

# has to authenticate itself against the initiator with an X.509 certificate.

conn ikev2-eap-mschapv2

    also=vip-base

    keyexchange=ikev2

    leftauth=eap-mschapv2

    rightauth=pubkey

    right=RespondersIPorFQDNGoesHere

# The following settings depend on if you've got the CA that issued the

# responder's certificate or just the certificate.

# if you've got the CA certificate, put it into /etc/ipsec.d/cacerts/. Also

# read the notes in the beginning of the page about certificates.

#   rightca="This is the DN of the CA's certificate"

# if you've only got the responder's certificate

#   rightcert=thisisthepathtothecertificate

# You might have to set this to the correct value, if the responder isn't configure correctly.

#   rightid=foobar

# Remove the ::/0, if you don't require IPv6.

    rightsubnet=0.0.0.0/0,::/0

    auto=add

# asymmetric authentication using eap-tls and pubkey auth

conn ikev2-eap-tls-asymmetric

    also=vip-base

    keyexchange=ikev2

    leftcert=mycert

    leftauth=eap-tls

    rightauth=pubkey

# The following settings depend on if you've got the CA that issued the

# responder's certificate or just the certificate.

# if you've got the CA certificate, put it into /etc/ipsec.d/cacerts/. Also

# read the notes in the beginning of the page about certificates.

#   rightca="This is the DN of the CA's certificate"

# if you've only got the responder's certificate

#   rightcert=thisisthepathtothecertificate

    right=RespondersIPorFQDNGoesHere

# You might have to set this to the correct value, if the responder isn't configure correctly.

#   rightid=foobar

# Remove the ::/0, if you don't require IPv6.

    rightsubnet=0.0.0.0/0,::/0

    auto=add

# symmetric authentication using just eap-tls

conn ikev2-eap-tls-symmetric

    also=vip-base

    keyexchange=ikev2

    leftcert=mycert

    leftauth=eap-tls

    rightauth=eap-tls

# The following settings depend on if you've got the CA that issued the

# responder's certificate or just the certificate.

# if you've got the CA certificate, put it into /etc/ipsec.d/cacerts/. Also

# read the notes in the beginning of the page about certificates.

#   rightca="This is the DN of the CA's certificate"

# if you've only got the responder's certificate

#   rightcert=thisisthepathtothecertificate

    right=RespondersIPorFQDNGoesHere

# You might have to set this to the correct value, if the responder isn't configure correctly.

#   rightid=foobar

# Remove the ::/0, if you don't require IPv6.

    rightsubnet=0.0.0.0/0,::/0

    auto=add

</pre>

}}

{{collapse(ipsec.secrets)

<pre>

RespondersIPorFQDNGoesHere : PSK "thisisthesharedpassword"

thisismyusername : EAP "thisismypassword"

: RSA myprivatekey

</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 : PSK "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 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.

The notes from Tobias' comment in issue #196 apply:

> The hosts can be limited by specifying rightsubnet (e.g. rightsubnet=192.168.1.0/24,192.168.2.0/30,10.0.2.2/32). It is even possible to limit this to a specific protocol/port (for any remote host use %dynamic[<proto>/<port>], not 0.0.0.0/0[...]). A new test scenario (ikev2/trap-any, bb1d9e45) provides some examples.

> 

> Authentication can easily be done via certificates, but using PSKs is also possible. However, because there is no pattern/subnet matching for IP-based identities you need to either use a single secret for all hosts or use identities appropriately if you want to use different PSKs for different groups of hosts (e.g. use leftid=<host>@<group>.example.com and rightid=*@<group>.example.com in ipsec.conf and *@<group>.example.com : PSK "..." in ipsec.secrets).

{{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>

}}