Project

General

Profile

Usable Examples configurations » History » Version 37

Version 36 (Noel Kuntze, 06.12.2018 23:45) → Version 37/41 (Noel Kuntze, 10.01.2019 15:48)

h1. Usable Examples configurations

{{>toc}}

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.
* The configured proposals (ecp256,ecp521) in these examples require you to have the _openssl_ plugin loaded in strongSwan.

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
# secure cipher suits
ike=aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
esp=aes192gcm16-aes128gcm16-ecp256-modp3072,aes192-sha256-ecp256-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-l2tp
also=rw-base
# reduce to the most secure combination the client can support, if absolutely required.
ike=aes128-sha256-modp3072
esp=aes128-sha256-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-sha256-modp3072
esp=aes128-sha256-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

# IF you need to support several EAP methods at the same time, you need to use eap-dynamic
# and not use any other conn with eap settings. Add the settings for the eap-dynamic plugin to your strongswan.conf file.

conn ikev2-eap
also=rw-config
rightauth=eap-dynamic
eap_identity=%identity
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>
}}

{{collapse(swanctl.conf)
<pre>
connections {
ikev1-l2tp-chap-auth-in-l2tp {
version = 1
# reduce to the most secure combination the client can support, if absolutely required.
proposals = aes128-sha256-modp3072,default
rekey_time = 0s
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s
local-1 {
auth = psk
}
remote-1 {
auth = psk
}
children {
ikev1-l2tp-chap-auth-in-l2tp {
local_ts = dynamic[/1701]
# reduce to the most secure combination the client can support, if absolutely required.
esp_proposals = aes128-sha256-modp3072,default
mark = unique
mode = transport
rekey_time = 0s
dpd_action = clear
}
}
}

ikev1-l2tp-xauth-in-ike {
version = 1
proposals = aes128-sha256-modp3072,default
rekey_time = 0s
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s

local-1 {
auth = psk
}
remote-1 {
auth = psk
}
remote-2 {
auth = xauth
}
children {
ikev1-l2tp-xauth-in-ike {
local_ts = dynamic[/1701]
esp_proposals = aes128-sha256-modp3072,default
mark = unique
mode = transport
rekey_time = 0s
dpd_action = clear

}
}
}
ikev1-psk-xauth {
version = 1
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s
local-1 {
auth = psk
}
remote-1 {
auth = psk
}
remote-2 {
auth = xauth
}
children {
ikev1-psk-xauth {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
ikev1-pubkey {
version = 1
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
# defaults are fine.
}
children {
ikev1-pubkey {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}

ikev1-pubkey-xauth {
version = 1
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
# defaults are fine.
}
remote-2 {
auth = xauth
}
children {
ikev1-pubkey-xauth {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}

ikev1-hybrid {
version = 1
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
dpd_timeout = 90s
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
# defaults are fine.
}
children {
ikev1-hybrid {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}

ikev2-pubkey {
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
# dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
# defaults are fine.
}
children {
ikev2-pubkey {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}

ikev2-eap {
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
# dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
auth = eap-dynamic
# go ask the client for its eap identity.
eap_id = %any
}
children {
ikev2-eap {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}
ikev2-eap-tls-asymmetric {
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
# dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
auth = eap-tls
# go ask the client for its eap identity.
eap_id = %any
}
children {
ikev2-eap-tls-asymmetric {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}

ikev2-eap-tls-symmetric {
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
# dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
local-1 {
certs = mycert.pem
id = myid
auth = eap-tls
}
remote-1 {
auth = eap-tls
# go ask the client for its eap identity.
eap_id = %any
}
children {
ikev2-eap-tls-symmetric {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}
ikev2-eap-mschapv2 {
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = primary-pool-ipv4, primary-pool-ipv6
fragmentation = yes
dpd_delay = 30s
# dpd_timeout doesn't do anything for IKEv2. The general IKEv2 packet timeouts are used.
local-1 {
certs = mycert.pem
id = myid
}
remote-1 {
auth = eap-mschapv2
# go ask the client for its eap identity.
eap_id = %any
}
children {
ikev2-eap-mschapv2 {
local_ts = 0.0.0.0/0,::/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}
}

pools {
primary-pool-ipv4 {
addrs = 172.16.252.0/24
dns = 10.1.2.3, 8.8.8.8
split_exclude = 172.16.0.0/12
}
primary-pool-ipv6 {
addrs = yoursiteuniqueaddresspool goes here

}
}

secrets {
ike-one {
secret = "foobarblah"
}
private-second {
file = myprivatekey.pem
}
eap-carol {
id = carol
secret = "carolspassword"
}
}
}}

{{collapse(strongswan.conf)
<pre>
charon {

plugins {
eap_dynamic {
preferred = eap-mschapv2, eap-tls
}
}
}
</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>
}}

{{collapse(swanctl.conf)
<pre>
connections {
ikev1-psk-xauth {
dpd_delay = 30
dpd_timeout = 90
version = 1
remote_addrs = ResponderIPorQDNGoesHere
# 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.
# proposals = 3des-md5-modp1024
vips = 0.0.0.0,::
local-1 {
auth = psk
}
local-2 {
auth = xauth-generic
}
remote-1 {
auth = psk
# You might have to set this to the correct value, if the responder isn't configure correctly.
# id = foobar
}

children {
ikev1-psk-xauth {
remote_Ts = 0.0.0.0/0,::/0
# 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.
# esp_proposals = 3des-md5!
# Use this, if you want PFS with DH group 2.
# esp_proposals = 3des-md5-modp1024!
}
}
}

ikev1-psk-xauth-aggressive {
aggressive = yes
dpd_delay = 30
dpd_timeout = 90
version = 1
remote_addrs = ResponderIPorQDNGoesHere
# 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.
# proposals = 3des-md5-modp1024
vips = 0.0.0.0,::
local-1 {
auth = psk
}
local-2 {
auth = xauth-generic
}
remote-1 {
auth = psk
# You might have to set this to the correct value, if the responder isn't configure correctly.
# id = foobar
}

children {
ikev1-psk-xauth-aggressive {
remote_Ts = 0.0.0.0/0,::/0
# 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.
# esp_proposals = 3des-md5!
# Use this, if you want PFS with DH group 2.
# esp_proposals = 3des-md5-modp1024!
}
}
}
ikev1-rsa-xauth {
dpd_delay = 30
dpd_timeout = 90
version = 1
remote_addrs = ResponderIPorQDNGoesHere
# 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.
# proposals = 3des-md5-modp1024
vips = 0.0.0.0,::
local-1 {
certs = thisithepathtomycertificate.pem
}
local-2 {
auth = xauth-generic
}
remote-1 {
# You might have to set this to the correct value, if the responder isn't configure correctly.
# id = foobar
}

children {
ikev1-psk-xauth {
remote_Ts = 0.0.0.0/0,::/0
# 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.
# esp_proposals = 3des-md5!
# Use this, if you want PFS with DH group 2.
# esp_proposals = 3des-md5-modp1024!
}
}
}

ikev1-l2tp {
remote_addrs = ResponderIPorFQDNGoesHere
version = 1
local-1 {
auth = psk
}
remote-1 {
auth = psk
}

children {
ikev1-l2tp-xauth {
remote_ts = %dynamic[/1701]
mode = transport
start_action = none
}
}
}
ikev1-l2tp-xauth {
remote_addrs = ResponderIPorFQDNGoesHere
version = 1
local-1 {
auth = psk
}
local-2 {
auth = xauth
xauth_id = myusername
}
remote-1 {
auth = psk
}

children {
ikev1-l2tp-xauth {
remote_ts = %dynamic[/1701]
mode = transport
start_action = none
}
}
}

ikev2-eap-mschapv2 {
version = 2
remote_addrs = ResponderIPorFQDNGoesHere
vips = 0.0.0.0, ::
local-1 {
auth = eap-mschapv2
eap_id=myid
}
remote-1 {
# 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/swanctl.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
# certs = thisisthepathtothecertificate
# if the remote peer sends a wrong ID, set that wrong ID here or make them fix it.
# id = remoteIDGoesHere
}
children {
ikev2-eap-mschapv2 {
remote_ts = 0.0.0.0/0,::/0
}

}
}

ikev2-eap-tls-asymmetric {
version = 2
remote_addrs = ResponderIPorFQDNGoesHere
vips = 0.0.0.0, ::
local-1 {
auth = eap-tls
certs = mycert
}
remote-1 {
# 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/swanctl.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
# certs = thisisthepathtothecertificate
# if the remote peer sends a wrong ID, set that wrong ID here or make them fix it.
# id = remoteIDGoesHere
}
children {
ikev2-eap-tls-asymmetric {
remote_ts = 0.0.0.0/0,::/0
}

}
}

ikev2-eap-tls-symmetric {
version = 2
remote_addrs = ResponderIPorFQDNGoesHere
vips = 0.0.0.0, ::
local-1 {
auth = eap-tls
certs = mycert
}
remote-1 {
# 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/swanctl.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
# certs = thisisthepathtothecertificate
# if the remote peer sends a wrong ID, set that wrong ID here or make them fix it.
# id = remoteIDGoesHere
auth = eap-tls
}
children {
ikev2-eap-tls-symmetric {
remote_ts = 0.0.0.0/0,::/0
}

}
}

secrets {
ike-example {
id = RespondersIPorFQDNGoesHere
secret = "thisisthesharedpassword"
}
eap-username {
id = thisismyusername
secret = "thisismypassword"
}
private-mine {
file = myprivatekey
}
}
}
</pre>
}}

h2. Site-To-Site-Scenario

These configuration files are written under the presumption that both sides have public IPs and there is no NAT in between.
If you use NAT and the peers' IPs as IDs, you need to set them manually in leftid and rightid respectively (whereever the ID is not equal to the set address).
In some cases, the IDs other peers send are malformed or use an unusual type. If that is the case, you can force the sending of a specific ID or of a specific
type using a [[ConnSection#leftright-End-Parameters|special notation]] (see text about left|rightid).

{{collapse(ipsec.conf)
<pre>
conn sts-base
fragmentation=yes
dpdaction=restart
ike=aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
esp=aes192gcm16-aes128gcm16-ecp256-modp3072,aes192-sha256-ecp256-modp3072
keyingtries=%forever
leftid=foobar
leftcert=foobar.pem

# this conn is set up for a remote 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 remote 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>
}}

{{collapse(swanctl.conf)
<pre>
connections {

site-1-static-ip {
remote_addrs = 1.2.3.4
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
keyingtries = 0

local-1 {
certs = foobar.pem
}
remote-1 {
certs = 1.2.3.4.pem
}

children {
site-1-static-ip {
local_ts = 10.1.2.0/24,10.1.1.0/24
remote_ts = 10.1.3.0/24
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
dpd_action = restart
start_action = trap
}
}
}

site-2-dynamic-ip {
remote_addrs = example.com, 0.0.0.0/0
version = 2
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
keyingtries = 0
local-1 {
certs = foobar.pem
}
remote-1 {
certs = 1.2.3.4.pem
}

children {
site-2-dynamic-ip {
local_ts = 10.1.2.0/24,10.1.1.0/24
remote_ts = 10.1.3.0/24
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
dpd_action = restart
start_action = trap
}
}
}
site-3-legacy {
remote_addrs = example.com
version = 1
proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
local-1 {
auth = psk
id = mylocalsite
}
remote-1 {
# id field here is inferred from the remote address
auth = psk
}
children {
site-3-legacy-1 {
local_ts = 10.1.1.0/24
remote_ts = 10.1.5.0/24
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
start_action = trap
dpd_action = restart
}
site-3-legacy-2 {
local_ts = 10.1.2.0/24
remote_ts = 10.1.5.0/24
esp_proposals = aes192gcm16-aes128gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
start_action = trap
dpd_action = restart
}
}
}
}
secrets {
# PSK secret
ike-example.com {
id-1 = remote.com
secret = "example"
}
# generic private key, no specific type
private-foobar {
file = foobar.key
}

}
</pre>
}}

h2. Passthrough policy

h3. For a local LAN

This is a passthrough policy that works if the sender and recipient of the IP packets are in the 10.0.0.0/8 subnet.
@left@ is set to @127.0.0.1@ to prevent this conn from being considered in the conn lookup when a peer tries to connect.

{{collapse(ipsec.conf)
<pre>
conn passthrough-1
# makes sure those conns are excluded from every conn selection
left=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>
}}

{{collapse(swanctl.conf)
<pre>
connections {
passthrough-1 {
remote_addrs = 127.0.0.1
children {
passthrough-1 {
local_ts = 10.0.0.0/8
remote_ts = 10.0.0.0/8
mode = pass
start_action = trap
}
}
}
}
</pre>
}}

h3. For remote networks

This is a passthrough policy that applies to packets for which all of the section's conditions are true:
* For received packets:
** The recipient is in @192.168.0.0/16@
** The sender is in @10.0.0.0/8@
* For sent packets:
** The recipient is in @10.0.0.0/8@
** The sender is in @192.168.0.0/16@

Note that the conditions for received and sent packets are the inverse of each other.

@left@ is set to @127.0.0.1@ to prevent this conn from being considered in the conn lookup when a peer tries to connect and to prevent strongSwan from switching the sides of the conn (because @127.0.0.1@ is a local IP address).

{{collapse(ipsec.conf)
<pre>
conn passthrough-2
# makes sure those conns are excluded from every conn selection
left=127.0.0.1
# Those are just example values. Replace them with the apropriate ones!
leftsubnet=192.168.0.0/16
rightsubnet=10.0.0.0/8
# those two lines are critical.
type=passthrough
auto=route
</pre>
}}

For swanctl.conf style configurations, it is not an issue, so remote_addrs or local_addrs can be set to 127.0.0.1 to prevent strongSwan from considering the conn in the conn lookup when a peer tries to connect.
In this example, only remote_addrs is set to @127.0.0.1@. You are free to choose local_addrs, remote_addrs or both.

{{collapse(swanctl.conf)
<pre>
connections {
passthrough-2 {
remote_addrs = 127.0.0.1
children {
passthrough-2 {
local_ts = 192.168.0.0/16
remote_ts = 10.0.0.0/8
mode = pass
start_action = trap
}
}
}
}
</pre>
}}

If your goal is to exclude traffic into locally attached subnets from other tunnels and the locally attached subnets are dynamic, have a look at the [[bypass-lan]] plugin.

h3. For specific protocols or ports

The following configuration example is for traffic to the *local* SSH port.

{{collapse(ipsec.conf)
<pre>
conn passthrough-ssh
# makes sure those conns are excluded from every conn selection
left = 127.0.0.1
leftsubnet = %dynamic[tcp/22]
rightsubnet = 0.0.0.0/0
type = passthrough
auto = route
</pre>
}}

{{collapse(swanctl.conf)
<pre>
<pre>
connections {
passthrough-ssh {
remote_addrs = 127.0.0.1
children {
passthrough-ssh {
local_ts = dynamic[tcp/22]
remote_ts = 0.0.0.0/0
mode = pass
start_action = trap
}
}
}
}
</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>
}}
{{collapse(swanctl.conf)
<pre>
connections {
trap-any {
remote_addrs = %any
local {
auth = psk
}
remote {
auth = psk
}

children {
trap-any trap-yn {
remote_ts = 192.168.1.0/24
local_ts = 192.168.1.0/24
mode = transport
start_action = trap
}
}
}
}
</pre>
}}