Project

General

Profile

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.

Roadwarrior scenario

Responder

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

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.

Site-To-Site-Scenario

Passthrough policy

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