Defines the parameters of the IKE phase 2 (IPsec-SA establishment).
The
local_id and
remote_id strings are constructed like:
address address [
/ prefix] [[
port]]
ul_proto
or
subnet address [
/ prefix] [[
port]]
ul_proto
An id string should be expressed to match the exact value of an ID payload. This is not like a filter rule. For example, if you define 3ffe:501:4819::/48 as
local_id. 3ffe:501:4819:1000:/64 will not match. In the case of a longest prefix (selecting a single host),
address instructs to send ID type of ADDRESS while
subnet instructs to send ID type of SUBNET. Otherwise, these instructions are identical.
The
anonymous keyword can be used to match any id. The
clientaddr keyword can be used to match a remote id that is equal to either the peer ip address or the mode_cfg ip address (if assigned). This can be useful to restrict policy generation when racoon is acting as a client gateway for peers with dynamic ip addresses.
The
from keyword allows an sainfo to only match for peers that use a specific phase1 id value during authentication. The
group keyword allows an XAuth group membership check to be performed for this sainfo section. When the mode_cfg auth source is set to
system or
ldap, the XAuth user is verified to be a member of the specified group before allowing a matching SA to be negotiated.
pfs_group group;
define the group of Diffie-Hellman exponentiations. If you do not require PFS then you can omit this directive. Any proposal will be accepted if you do not specify one. group is one of following: modp768, modp1024, modp1536, modp2048, modp3072, modp4096, modp6144, modp8192. Or you can define 1, 2, 5, 14, 15, 16, 17, or 18 as the DH group number.
lifetime time number timeunit;
define how long an IPsec-SA will be used, in timeunits. Any proposal will be accepted, and no attribute(s) will be proposed to the peer if you do not specify it(them). See the proposal_check directive.
remoteid number;
Sainfos will only be used if their remoteid matches the ph1id of the remote section used for phase 1. Defaults to 0, which is also the default for ph1id.
racoon(8) does not have a list of security protocols to be negotiated. The list of security protocols are passed by SPD in the kernel. Therefore you have to define all of the potential algorithms in the phase 2 proposals even if there are algorithms which will not be used. These algorithms are define by using the following three directives, with a single comma as the separator. For algorithms that can take variable-length keys, algorithm names can be followed by a key length, like “
blowfish 448”.
racoon(8) will compute the actual phase 2 proposals by computing the permutation of the specified algorithms, and then combining them with the security protocol specified by the SPD. For example, if
des,
3des,
hmac_md5, and
hmac_sha1 are specified as algorithms, we have four combinations for use with ESP, and two for AH. Then, based on the SPD settings,
racoon(8) will construct the actual proposals. If the SPD entry asks for ESP only, there will be 4 proposals. If it asks for both AH and ESP, there will be 8 proposals. Note that the kernel may not support the algorithm you have specified.
encryption_algorithm algorithms;
des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea, cast128, blowfish, null_enc, twofish, rijndael, aes, camellia (used with ESP)
authentication_algorithm algorithms;
des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512, non_auth (used with ESP authentication and AH)
compression_algorithm algorithms;
deflate (used with IPComp)