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 "",
    your responder needs to identify and authenticate itself as
  • Credentials are bound to identities. You can not successfully authenticate yourself
    as the identitiy 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


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


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.


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

Passthrough policy

For a local LAN

To automatically install passthrough policies for locally connected subnets, the 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 subnet.
left is set to to prevent this conn from being considered in the conn lookup when a peer tries to connect.

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
    • The sender is in
  • For sent packets:
    • The recipient is in
    • The sender is in

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

left is set to 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 is a local IP address).

For swanctl.conf style configurations, it is not an issue, so remote_addrs or local_addrs can be set to 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 You are free to choose local_addrs, remote_addrs or both.

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.

Host-To-Host transport mode

Based on the trap-any test scenario.

The hosts involved are in the subnet.
The notes from Tobias' comment in issue #196 apply:

The hosts can be limited by specifying rightsubnet (e.g. rightsubnet=,, It is even possible to limit this to a specific protocol/port (for any remote host use %dynamic[<proto>/<port>], not[...]). 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> and rightid=*<group> in ipsec.conf and *@<group> : PSK "..." in ipsec.secrets).