Project

General

Profile

History

strongSwan User Documentation »

Usable Examples configurations » History » Version 9

« Previous - Version 9/41 (diff) - Next » - Current version
Noel Kuntze, 26.10.2016 22:43
fixed xauth configs (xauth=server was missing).

Sane Example 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 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.

Roadwarrior scenario

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

Site-To-Site-Scenario

passthrough policy

host-to-host opportunistic 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).