Usable Examples configurations¶
- Usable Examples configurations
- These examples follow the Security Recommendations. Follow them. They are there
for a reason.
- You can have several conn sections in your
- 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.
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).
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).