https://wiki.strongswan.org/projects/strongswan/wiki/UsableExamples

Usable Examples configurations

Preliminary obligatory notes:

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

Roadwarrior scenario

Responder

This is an example configuration that provides support for several clients
with several authentication styles.

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

ipsec.secrets

: PSK "foobarblah" 
: RSA myprivatekey.pem
carol : EAP "carolspassword"

swanctl.conf

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

strongswan.conf

charon {

    plugins {
        eap_dynamic {
            preferred = eap-mschapv2, eap-tls
        }
    }
}

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 plugin list and the test scenarios
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.

ipsec.conf

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

ipsec.secrets

RespondersIPorFQDNGoesHere : PSK "thisisthesharedpassword" 
thisismyusername : EAP "thisismypassword" 
: RSA myprivatekey

swanctl.conf

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

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 special notation (see text about left|rightid).

ipsec.conf

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

ipsec.secrets

: RSA foobar.key
remote.com : PSK "example"

swanctl.conf

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
    }

}

Passthrough policy

For a local LAN

To automatically install passthrough policies for locally connected subnets, the Bypass-lan" style="color: rgb(138, 0, 32); text-decoration-line: none; overflow-wrap: break-word; font-weight: bold;">bypass-lan plugin may be used.

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.

ipsec.conf

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

swanctl.conf

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

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).

ipsec.conf

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

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.

swanctl.conf

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

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.

For specific protocols or ports

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

ipsec.conf

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

swanctl.conf

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

Host-To-Host transport mode

Based on the trap-any test scenario.

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).

ipsec.conf

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

swanctl.conf

connections {
    trap-any {
        remote_addrs = %any
        local {
            auth = psk
        }
        remote {
            auth = psk
        }

        children {
            trap-any {
                remote_ts = 192.168.1.0/24
                local_ts = 192.168.1.0/24
                mode = transport
                start_action = trap
            }
        }
    }
}

打赏