Chapter 4
Older versions of Openswan had a workaround for this that disabled the rcookie verification code, and blindly accepted all rcookies. This workaround was enabled by defining APPLY_CRISCO in programs/pluto/dpd.c before compiling Pluto. As of Openswan 2.3.1, this define is removed and the code is always enabled. It has been extended to work around a different, but similar, bug in the Clavister VPN client. Accepting these bad cookies is strangely enough also what the RFC dictates as the correct behavior towards these broken packets.
Ciphers and Algorithms
Normally Openswan proposes all the ciphers and algorithms it supports, using a hardcoded preference. You can force which ciphers and algorithms to propose, and in which order to propose them, per connection. This can be useful for various reasons. The remote could have a buggy cipher implementation that would be otherwise selected. The remote could be a low-CPU appliance, and you wish to reduce the crypto strength. Some remotes do not respond at all after the first proposal, and you need to send the exact proposal for the remote as the first suggestion. Depending on the ciphers and algorithms that your version of Openswan and kernel support, you can define them using ike= and esp= lines. Ciphers and algorithms can either come from the KLIPS code or from the Linux CryptoAPI code. If a cipher or algorithm is available from KLIPS, it will be used instead of the CryptoAPI version.
You can use the following command to see what ciphers and algorithms are supported and loaded:
# ipsec auto --status
Using ike= to Specify Phase 1 Parameters
The ike= option is used to tune the IKE negotiation. This is sometimes called Phase 1 encryption on other devices. The esp= option is used to tune the ESP parameters for the kernel. This is sometimes called Phase 2 encryption on other devices. For example:
ike="3des-sha1-96,aes-md5-96"
In this example, Openswan will first propose 3DES encryption with the SHA1 hashing algorithm of 96 bits. Then it will propose AES encryption with the MD5 hashing algorithm using 96 bits. No other proposals will be sent, or accepted. Sub-options can be specified using underscores, such as
3des_cbc.
Older versions only accepted sha and not sha1. Since sha2 will become a standard in the near future, Openswan now uses sha1 everywhere, and any occurrence of sha is treated
as sha1.
You can also force a Diffie-Hellman key size (dhgroup):
ike="aes128-sha1-modp1536"
Openswan does not support using DH group names such as dh2 or dh5. If you need to translate the DH group name to MODP syntax, use the following table, which shows DH groups according to RFC 3526:
101
Configuring IPsec
DH group |
MODP |
remark |
|
|
|
1 |
768 |
No longer supported in Openswan 2 unless compiled with USE_WEAKSTUFF=true |
2 |
1024 |
|
5 |
1536 |
|
14 |
2048 |
Not yet supported by Openswan 2 |
16 |
4096 |
Not yet supported by Openswan 2 |
18 |
8192 |
Not yet supported by Openswan 2 |
|
|
|
If you are just interested in forcing the cipher, but not any of the algorithms, you can leave those out. For example to just allow AES, for instance because the device has limited CPU power, you can use:
ike="aes"
Any proposal with 3DES would no longer be accepted.
Not specifying an ike= line, as we have done throughout the book until now, is the same as allowing all combinations of acceptable ciphers, secure hashes and DH groups. Currently this means AES128 or 3DES as cipher, and MD5 or SHA1 as secure hash, and DH group 2 or 5.
Older versions of Openswan supported the pfsgroup= option. This option is obsolete. Use the appropriate ike= and esp= options instead.
Using esp= to Specify Phase 2 Parameters
To tune the kernel ciphers, also called Phase 2 encryption, you can use the esp= option:
esp=aes256-sha1,aes128-sha1,3des-sha1
Currently, you cannot specify MODP groups in Phase 2. The DH group from Phase 1 will be automatically used for Phase 2 as well.
Defaults and Strictness
Not defining an ike= or esp= line, as we have done up to know, means we offer and accept all supported ciphers and algorithms. Currently this means AES and 3DES in different modes, MD5 and SHA1, and DH groups 2 and 5.
As soon as you specify an ike= or esp= option, that option becomes an exclusive list, and no other options are proposed or accepted. Older versions used an exclamation mark (!) syntax at the end of the line to signify strictness. This is no longer necessary nor allowed.
102