Key Exchange version 2 (IKEv2) daemon
is an Internet Key Exchange (IKEv2) daemon
which performs mutual authentication and which establishes and maintains IPsec
flows and security associations (SAs) between the two peers.
The IKEv2 protocol is defined in RFC 5996, which combines and updates the
previous standards: ISAKMP/Oakley (RFC 2408), IKE (RFC 2409), and the Internet
DOI (RFC 2407). iked
only supports the IKEv2
protocol; support for ISAKMP/Oakley and IKEv1 is provided by
supports mutual authentication using RSA or
ECDSA public keys and X.509 certificates. See the
section below and PKI AND CERTIFICATE AUTHORITY COMMANDS in
for more information
about creating and maintaining the public key infrastructure.
The options are as follows:
- Disable automatic blocking of IPv6 traffic. By default,
iked blocks any IPv6 traffic unless a flow
for this address family has been negotiated. This option is used to
prevent VPN traffic leakages on dual stack hosts.
- Define macro to be set to
value on the command line. Overrides the
definition of macro in the configuration
- Do not daemonize and log to
- Use file as the
configuration file, instead of the default
- Configtest mode. Only check the configuration file for
- Start iked in passive mode.
See the set passive option in
iked.conf(5) for more
- Disable NAT-Traversal and do not propose NAT-Traversal
support to the peers.
- Enforce NAT-Traversal and only listen to NAT-Traversal
messages. This option is only recommended for testing; the default is to
negotiate NAT-Traversal with the peers.
- Produce more verbose output.
It is possible to store trusted public keys to make them directly usable by
, bypassing the need to use certificates. The
keys should be saved in PEM format (see
) and named and
stored as follows:
- For IPv4 identities:
- For IPv6 identities:
- For FQDN identities:
- For UFQDN identities:
Depending on the srcid
, keys may be
named after their IPv4 address, IPv6 address, fully qualified domain name
(FQDN) or user fully qualified domain name (UFQDN).
For example, iked
can authenticate using the
pre-generated keys if the local public key, by default
, is copied to the remote
and the remote gateway's public key is copied to the local gateway as
Of course, new keys may also be generated (the user is not required to use the
pre-generated keys). In this example, srcid
would also have to be set to the specified
addresses in iked.conf(5)
- The default iked configuration
- The directory where CA certificates are kept.
- The directory where IKE certificates are kept, both the
local certificate(s) and those of the peers, if a choice to have them kept
permanently has been made.
- The directory where CRLs are kept.
- The directory where local private keys used for public key
authentication are kept. The file local.key
is used to store the local private key.
- The directory in which trusted public keys are kept. The
keys must be named in the fashion described above.
- The default iked control
P. Hoffman, Y. Nir, and
P. Eronen, Internet Key Exchange
Protocol Version 2 (IKEv2), RFC 5996,
program first appeared in
program was written by