Go to main content

man pages section 1M: System Administration Commands

Exit Print View

Updated: July 2017



in.ikev2d - daemon for Internet Key Exchange Version 2 (IKEv2)


/usr/lib/inet/in.ikev2d [-d] [
-f filename]
/usr/lib/inet/in.ikev2d -c [
-f filename]


The in.ikev2d daemon performs automated key management for IPsec using the Internet Key Exchange Version 2 (IKEv2) protocol as defined in RFC 5996.

in.ikev2d supports the following:

  • IKE authentication with either pre-shared keys, DSS signatures, RSA signatures, or Elliptic Curve Digital Signature Algorithm (ECDSA). Both self-signed and CA-signed certificates are supported.

  • Diffie-Hellman key derivation using MODP groups 1, 2, 5, 14, 15, 16, 22, 23, and 24 and ECP groups 19, 20, 21, 25, and 26 as defined in RFC 3526, RFC 5114, RFC 5903 and RFC 5996.

  • Secure IKEv2 exchange protection using authenticated encryption algorithms.

    Encryption algorithms: AES, 3DES.

    Authentication algorithms: HMAC-MD5, HMAC-MD5-128, HMAC-SHA-1, HMAC-SHA1-160, HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512.

  • Encryption in in.ikev2d is limited to the IKEv2 authentication and key exchange. See ipsecesp(7P) for information regarding IPsec protection choices.

  • Note that the algorithms defined above are used by in.ikev2d to protect its exchanges with a peer. The algorithms used to protect the actual IPsec traffic (ESP/AH) and the associated keys are negotiated as part of these IKEv2 exchanges. The actual algorithms chosen for IPsec are not defined in the in.ikev2d configuration files described in this man page because they are actually defined in the IPsec policy. The algorithms used by in.ikev2d and IPsec may be different. For more details on the IPsec policy, see ipsecconf(1M) and ipsecalgs(1M).

in.ikev2d is managed by the ikev2 instance of the ike smf(5) service:


This service is delivered disabled because the configuration file needs to be created before the service can be enabled. See ikev2.config(4) for the format of this file. In general, this service is used in conjunction with the svc:/network/ipsec/policy service, which must also be configured and enabled. See ipsecconf(1M) for details on that service.

See smf(5) for information on the Service Management Facility.

in.ikev2d sends and processes IKEv2 protocol exchanges with peer systems that use the IKEv2 protocol. This is done using a UDP socket on port 500 or 4500. in.ikev2d also processes requests for keying information that come from the IPsec module in the kernel. These messages are sent by means of a special socket described in pf_key(7P).

The PF_KEY interface is also used by in.ikev2d to add negotiated SAs into the kernels SADB, and to check that incoming requests match the local IPsec policy.

In the case of an already running in.iked(1M) IKEv1 daemon, the in.ikev2d daemon runs in coexistence mode. in.iked listens for IKEv1 and IKEv2 traffic and forwards any IKEv2 traffic on to in.ikev2d . in.ikev2d will detect if the IKEv1 daemon exits and will go back into standalone mode in that case. Coexistence mode is necessary since both daemons use the same UDP ports (500 and 4500) for network traffic.

in.ikev2d will manage all IKE exchanges using the IKEv2 protocol as defined by RFC 5996. It can coexist with in.iked(1M), which will manage IKE exchanges using the version of the IKE protocol defined by RFC 2409.

The configuration for in.iked(1M) is defined in ike.config(4). Configuration for in.ikev2d is defined in ikev2.config(4). Each daemon has its own set of configuration files.

If both daemons are enabled at the same time, care should be taken to avoid overlapping configuration rules; that is, rules that would allow both daemons to initiate sessions for the same pair of local and remote addresses. Particular caution is required when prefix or wildcard remote_addr/ local_addr values are used inside IKE(v2) rules in a mixed IKE/IKEv2 environment.

In order to satisfy the principle of least privilege, all administrative tasks for IKEv2 should be done under the Network IPsec Management rights profile. See rbac(5). Configuration files should be modified using pfedit(1M) in order to preserve proper file permissions and ownership.

For example:

$ pfedit /etc/inet/ike/ikev2.config

in.ikev2d runs as ikeuser and all of its configuration, logs, and key and certificate store are owned by this userid. It is imperative that the ownership and permissions stay this way or the running in.ikev2d daemon will not be able to read its configuration or keystore contents.

The ikeadm(1M) command can manage the running in.ikev2d daemon. See the ikeadm(1M) man page for details and examples.

pktool(1) is used to manage X.509 certificates and associated private keys for local certificates for users on Solaris. IKEv2 uses ikev2cert(1M) as its certificate management interface to the keystore for ikeuser, which is the user id for the running in.ikev2d daemon. ikev2cert(1M) is just a wrapper around pktool(1) that causes it to run as ikeuser and write to and access the IKEv2 keystore.

Certificate policy is controlled by the Solaris Key Management Framework (KMF). In order to change the default policy supplied for in.ikev2d, one must run kmfcfg(1) on the KMF configuration file for IKEv2 role. For example, to ignore unknown Extended Key Usage extensions in certificates, one would issue the following command:

$ pfexec kmfcfg modify \
dbfile=/etc/inet/ike/kmf-policy.xml policy=default \

See kmfcfg(1) for valid configuration options.

The in.ikev2d daemon may be notified of any changes to its configuration, including pre-shared keys and certificates, by issuing the following command:

# svcadm refresh network/ipsec/ike:ikev2

An alternative to the preceding command is to use one of the ikeadm(1M) commands, such as read rules or read preshared.

Service Management Facility

The IKE daemon (in.ikev2d) is managed by the service management facility, smf(5). The following group of services manage the components of IPsec:

The manual-key and ike services are delivered disabled because the system administrator must create configuration files for each service, as described in the respective man pages listed above.

The correct administrative procedure is to create the configuration file for the set of services relevant to the site's security policy, then enable each service using svcadm(1M).

The ike service has a dependency on the ipsecalgs and policy services. These services should be enabled before the ike service.

The section below describes a number of smf(5) properties that are used by in.ikev2d. These properties should rarely need to be changed from their default values. If any of these properties are changed, the ike:ikev2 service needs to be refreshed in order for the values updated in the smf(5) database.

Because the daemon in.ikev2d reads these properties only at startup time, the ike:ikev2 service will also need to be restarted after a property has been modified. For example:

example# svcadm refresh ike:ikev2
example# svcadm restart ike:ikev2

Please refer to the specific properties below for additional instructions.

Most common configuration changes can be applied to the running daemon by using ikeadm(1M).

Note that restarting the daemon will tear down any existing IKEv2 SAs along with their associated CHILD SAs. Delete notifications will be sent to each peer and SAs must all be reestablished.

The following properties are defined for the ikev2 instance of the ike service:


Defines the configuration file to use. The default value is /etc/inet/ike/ikev2.config. See ikev2.config(4) for the format of this file. This property has the same effect as the –f flag. See the description of –f in OPTIONS. Note that this file must be owned by the userid ikeuser.

To have the running daemon read an alternative file, see ikeadm(1M).


Defines the amount of debug output that is written to the debug_logfile file, described below. The default value for this is op or operator. This property controls the recording of information on events such as rereading the configuration file. Acceptable value for debug_level are listed in the ikeadm(1M) man page. The value verbose is suitable for general protocol troubleshooting.

For example:

example# svccfg -s ike:ikev2 setprop config/debug_level = verbose

Startup error messages are recorded by the smf(5) framework and recorded in a service-specific log file. Use the command svcs -xv ike:ikev2 to determine the name of the SMF startup log.

To change the debug level on the running daemon for debugging purposes, see ikeadm(1M).


Defines where debug output should be written. The messages written here are from debug code within in.ikev2d. It is important that this parameter is set to a directory owned by the user ikeuser or the daemon will fail to start. Use the following command to examine the logfile property:

example# svccfg -s ike:ikev2 listprop config/debug_logfile

Both the SMF log file and the debug log file should be inspected for errors.

To redirect the debugging output of the running daemon, see ikeadm(1M).


A boolean value that controls in.ikev2d's behavior should the configuration files have syntax errors, configuration errors, missing per-shared keys, missing certificates and the like. The default value is false, which causes in.ikev2d to enter maintenance mode if the configuration is invalid.

Setting this value to true causes the IKE service to stay online, but correct operation requires the administrator to configure the running daemon with ikeadm(1M).


Enforces a minimum number of threads for the daemon's dynamically sized thread pools. This value is set heuristically and should normally not need to be changed.


Limit the maximum number of threads in the daemon's dynamically sized thread pools. This value is set heuristically and should normally not need to be changed. A handful of threads in the in.ikev2d process are not counted against this limit, so it is possible that the total number of threads in the running daemon will exceed max_threads. The total number of concurrent outstanding CRL and OCSP retrieval operations is limited by max_threads. This should be given careful consideration before adjusting max_threads when these PKI features are in use.


Number of seconds for IKEv2 to wait for a response from the peer for any of its requests. This value should normally not have to be tuned. This value should not be viewed simply as a worst case value for network round-trip time, as the peer system may need to perform time consuming operations such as CRL retrieval in order to respond to a request.


Hardware token in PKCS#11 URI format, for example:

# svccfg -s ike:ikev2 setprop pkcs11_token/uri = \
'pkcs11:token=Hardware Token Name'

This value defaults to Metaslot, which means that keys and certificates will be stored in the softtoken keystore for the user ikeuser, protected by a pin. Change this value to specify a PKCS#11 hardware token. See pkcs11_softtoken(5) for details on the softtoken keystore.


The pin for the PKCS#11 softtoken keystore.

This pin must be set for unattended startup of in.ikev2d. Without this pin, in.ikev2d will not be able to access any private keys in its keystore. By default, the pin is unconfigured and the keystore uninitialized. The administrator must run ikev2cert(1M) to set the pin and initialize the keystore. For automated startup, the pin value must be stored in a special smf(5) property.

For soft token (the default):

# ikev2cert setpin

The current state of the token can be viewed with:

# ikev2cert tokens

For a hardware tokens, ikev2cert(1M) is not used because the hardware token is not part of a filesystem and does not have permissions or ownership. The pktool(1) can be used to manipulate the hardware directly:

# pktool setpin token=token_name

Then store the value of the pin in a special smf(5) property that requires special authorizations to read from or write to. See smf_security(5).

# svccfg -s ike:ikev2 editprop

In the editor:

setprop pkcs11_token/pin = pin_value

If security policy dictates that the pin cannot be stored in SMF, this property may be left blank and the administrator may run the following command to interactively unlock the softtoken in the running daemon:

# ikeadm -v2 token login "Sun Metaslot"

For a hardware token, substitute the token label name in the above command.

To retroactively log into the token with the daemon still running, use the following sequence:

  1. Initialize the token if you have not already done so. The default pin for the uninitialized token is changeme. Set this pin to a strong passphrase when prompted.

    # ikev2cert setpin
  2. Set the pin property using svccfg(1M).

    # svccfg -s ike:ikev2 editprop

    Pass the pin to the running daemon to unlock the token.

    # ikeadm -v2 token login "Sun Metaslot"

    See discussion of token login authorizations below.

These properties can be modified using svccfg(1M) by users who have been assigned the Network IPsec Management rights profile. See the prof_attr(4) man page.

Additional properties can be viewed using the svcprop(1) command. Their function is undefined and their modification unsupported.

PKCS#11 token objects can be unlocked or locked by using ikeadm token login and ikeadm token logout, respectively. The Network IPsec Management rights profile allows users to log into and out of PKCS#11 token objects. See the prof_attr(4) man page.

See auths(1), ikeadm(1M), user_attr(4), rbac(5), ikev2cert(1M).

The service needs to be refreshed using svcadm(1M) before a new property value is effective. General, non-modifiable properties can be viewed with the svcprop(1) command.

# svccfg -s ipsec/ike:ikev2 setprop config/config_file = \
       # svcadm refresh ike:ikev2

Administrative actions on this service, such as enabling, disabling, refreshing, and requesting restart can be performed using svcadm(1M). A user who has been assigned the Network IPsec Management rights profile can perform these actions.

The service's status can be queried using the svcs(1) command.

The in.ikev2d daemon is designed to be run under smf(5) management. While the in.ikev2d command can be run from the command line, this is discouraged. If the in.ikev2d command is to be run from the command line, the ike smf(5) service should be disabled first. See svcadm(1M).


The following options are supported:


Check the syntax of a configuration file.


Use debug mode. The process stays attached to the controlling terminal and produces large amounts of debugging output.

–f filename

Use filename instead of /etc/inet/ike/ikev2.config. See ikev2.config(4) for the format of this file.


This program has sensitive private keying information in its image. Care should be taken with any core dumps or system dumps of a running in.ikev2d daemon, as these files contain sensitive keying information. Use the coreadm(1M) command to limit any core files produced by the running in.ikev2d daemon.



Default configuration file.


Default IKEv2 pre-shared secrets file for IKE SA authentication.


Default IKEv2 KMF policy configuration file.


See attributes(5) for descriptions of the following attributes:

Interface Stability

See Also

auths(1), kmfcfg(1), pktool(1), svcprop(1), svcs(1), coreadm(1M), ikeadm(1M), ikev2cert(1M), in.iked(1M), ipsecalgs(1M), ipsecconf(1M), ipseckey(1M), pfedit(1M), svcadm(1M), svccfg(1M), ike.config(4), ikev2.config(4), ikev2.preshared(4), prof_attr(4), user_attr(4), attributes(5), pkcs11_softtoken(5), rbac(5), smf(5), smf_security(5), ipsecesp(7P), pf_key(7P)

Harkins, Dan and Carrel, Dave. RFC 2409, Internet Key Exchange (IKE). Network Working Group. November 1998.

Maughan, Douglas, Schertler, M., Schneider, M., Turner, J. RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP). Network Working Group. November 1998.

Piper, Derrell, RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. Network Working Group. November 1998.

Fu, D.; Solinos, J., RFC 4753, ECP Groups for IKE and IKEv2. Network Working Group. January 2007.

Lepinski, M.; Kent, S., RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards. Network Working Group. January 2008.

Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2). September 2010.