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