If
.B dh-group
is specified, CHILD_SA/Quick Mode setup and rekeying include a separate
-Diffie-Hellman exchange.
+Diffie-Hellman exchange (refer to the
+.B esp
+keyword for details).
.TP
.BR also " = <name>"
includes conn section
.BR hold ,
and
.B restart
-all activate DPD. If no activity is detected, all connections with a dead peer
-are stopped and unrouted
-.RB ( clear ),
-put in the hold state
-.RB ( hold )
-or restarted
-.RB ( restart ).
+all activate DPD and determine the action to perform on a timeout. With
+.B clear
+the connection is closed with no further actions taken.
+.B hold
+installs a trap policy, which will catch matching traffic and tries to
+re-negotiate the connection on demand.
+.B restart
+will immediately trigger an attempt to re-negotiation the connection.
The default is
.B none
which disables the active sending of DPD messages.
keyword may be used, AH+ESP bundles are not supported.
Defaults to
-.BR aes128-sha1,3des-sha1 .
+.BR aes128-sha256 .
The daemon adds its extensive default proposal to this default
or the configured value. To restrict it to the configured proposal an
exclamation mark
can be added at the end.
.BR Note :
-As a responder the daemon accepts the first supported proposal received from
-the peer. In order to restrict a responder to only accept specific cipher
-suites, the strict flag
+As a responder, the daemon defaults to selecting the first configured proposal
+that's also supported by the peer. This may be changed via
+.BR strongswan.conf (5)
+to selecting the first acceptable proposal sent by the peer instead. In order to
+restrict a responder to only accept specific cipher suites, the strict flag
.RB ( ! ,
exclamation mark) can be used, e.g: aes256-sha512-modp4096!
-.br
+
If
.B dh-group
-is specified, CHILD_SA/Quick Mode setup and rekeying include a separate
-Diffie-Hellman exchange. Valid values for
+is specified, CHILD_SA/Quick Mode rekeying and initial negotiation use a
+separate Diffie-Hellman exchange using the specified group. However, for IKEv2,
+the keys of the CHILD_SA created implicitly with the IKE_SA will always be
+derived from the IKE_SA's key material. So any DH group specified here will only
+apply when the CHILD_SA is later rekeyed or is created with a separate
+CREATE_CHILD_SA exchange. Therefore, a proposal mismatch might not immediately
+be noticed when the SA is established, but may later cause rekeying to fail.
+
+Valid values for
.B esnmode
-(IKEv2 only) are
+are
.B esn
and
.BR noesn .
This may help to surmount restrictive firewalls. In order to force the peer to
encapsulate packets, NAT detection payloads are faked.
.TP
-.BR fragmentation " = yes | force | " no
+.BR fragmentation " = " yes " | accept | force | no"
whether to use IKE fragmentation (proprietary IKEv1 extension or IKEv2
fragmentation as per RFC 7383). Acceptable values are
-.BR yes ,
+.B yes
+(the default),
+.BR accept ,
.B force
and
-.B no
-(the default). Fragmented IKE messages sent by a peer are always accepted
-irrespective of the value of this option. If set to
-.BR yes ,
-and the peer supports it, larger IKE messages will be sent in fragments.
+.BR no .
If set to
+.BR yes ,
+and the peer supports it, oversized IKE messages will be sent in fragments. If
+set to
+.BR accept ,
+support for fragmentation is announced to the peer but the daemon does not send
+its own messages in fragments. If set to
.B force
(only supported for IKEv1) the initial IKE message will already be fragmented
-if required.
+if required. Finally, setting the option to
+.B no
+will disable announcing support for this feature.
+
+Note that fragmented IKE messages sent by a peer are always accepted
+irrespective of the value of this option (even when set to
+.BR no ).
.TP
.BR ike " = <cipher suites>"
comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms
to be used, e.g.
-.BR aes128-sha1-modp2048 .
+.BR aes128-sha256-modp3072 .
The notation is
.BR encryption-integrity[-prf]-dhgroup .
If no PRF is given, the algorithms defined for integrity are used for the PRF.
.BR prfaesxcbc ).
.br
In IKEv2, multiple algorithms and proposals may be included, such as
-.BR aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024 .
+.BR aes128-aes256-sha1-modp3072-modp2048,3des-sha1-md5-modp1024 .
Defaults to
-.BR aes128-sha1-modp2048,3des-sha1-modp1536 .
+.BR aes128-sha256-modp3072 .
The daemon adds its extensive default proposal to this
default or the configured value. To restrict it to the configured proposal an
exclamation mark
means 'never give up'.
Relevant only locally, other end need not agree on it.
.TP
-.B keylife
-synonym for
-.BR lifetime .
-.TP
.BR left " = <ip address> | <fqdn> | " %any " | <range> | <subnet> "
The IP address of the left participant's public-network interface
or one of several magic values.
.B %any
is used for the remote endpoint it literally means any IP address.
+If an
+.B FQDN
+is assigned it is resolved every time a configuration lookup is done. If DNS
+resolution times out, the lookup is delayed for that time.
+
To limit the connection to a specific range of hosts, a range (
.BR 10.1.0.0-10.2.255.255
) or a subnet (
append hash algorithms to
.BR pubkey
or a key strength definition (for example
-.BR pubkey-sha1-sha256
+.BR pubkey-sha256-sha512 ,
+.BR rsa-2048-sha256-sha384-sha512 ,
or
-.BR rsa-2048-ecdsa-256-sha256-sha384-sha512 ).
+.BR rsa-2048-sha256-ecdsa-256-sha256-sha384 ).
Unless disabled in
-.BR strongswan.conf (5)
-such key types and hash algorithms are also applied as constraints against IKEv2
+.BR strongswan.conf (5),
+or explicit IKEv2 signature constraints are configured (see below), such key
+types and hash algorithms are also applied as constraints against IKEv2
signature authentication schemes used by the remote side.
If both peers support RFC 7427 ("Signature Authentication in IKEv2") specific
hash algorithms to be used during IKEv2 authentication may be configured.
-The syntax is the same as above. For example, with
-.B pubkey-sha384-sha256
+The syntax is the same as above, but with ike: prefix. For example, with
+.B ike:pubkey-sha384-sha256
a public key signature scheme with either SHA-384 or SHA-256 would get used for
authentication, in that order and depending on the hash algorithms supported by
the peer. If no specific hash algorithms are configured, the default is to
prefer an algorithm that matches or exceeds the strength of the signature key.
+If no constraints with ike: prefix are configured any signature scheme
+constraint (without ike: prefix) will also apply to IKEv2 authentication, unless
+this is disabled in
+.BR strongswan.conf (5).
+
+To use or require RSASSA-PSS signatures use rsa/pss instead of rsa as in e.g.
+.BR ike:rsa/pss-sha256 .
+If \fBpubkey\fR or \fBrsa\fR constraints are configured RSASSA-PSS signatures
+will only be used/accepted if enabled in
+.BR strongswan.conf (5).
For
.BR eap ,
implementations, make sure to configure identical subnets in such
configurations. IKEv2 supports multiple subnets separated by commas. IKEv1 only
interprets the first subnet of such a definition, unless the Cisco Unity
-extension plugin is enabled.
+extension plugin is enabled. This is due to a limitation of the IKEv1 protocol,
+which only allows a single pair of subnets per CHILD_SA. So to tunnel several
+subnets a conn entry has to be defined and brought up for each pair of subnets.
The optional part after each subnet enclosed in square brackets specifies a
protocol/port to restrict the selector for that subnet.
below.
.TP
.BR mark " = <value>[/<mask>]"
-sets an XFRM mark in the inbound and outbound
-IPsec SAs and policies. If the mask is missing then a default
+sets an XFRM mark on the inbound policy and outbound
+IPsec SA and policy. If the mask is missing then a default
mask of
.B 0xffffffff
is assumed. The special value
.B %unique
-assigns a unique value to each newly created IPsec SA.
+assigns a unique value to each newly created IPsec SA. To additionally
+make the mark unique for each IPsec SA direction (in/out) the special value
+.B %unique-dir
+may be used.
.TP
.BR mark_in " = <value>[/<mask>]"
-sets an XFRM mark in the inbound IPsec SA and
-policy. If the mask is missing then a default mask of
+sets an XFRM mark on the inbound policy (not on the SA). If the mask is missing
+then a default mask of
.B 0xffffffff
is assumed.
.TP
.BR mark_out " = <value>[/<mask>]"
-sets an XFRM mark in the outbound IPsec SA and
+sets an XFRM mark on the outbound IPsec SA and
policy. If the mask is missing then a default mask of
.B 0xffffffff
is assumed.
.B pull
(the default).
Push mode is currently not supported with IKEv2.
+The setting must be the same on both sides.
.TP
.BR reauth " = " yes " | no"
whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1,
Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY
below.
.TP
-.B rekeymargin
-synonym for
-.BR margintime .
-.TP
.BR replay_window " = " \-1 " | <number>"
The IPsec replay window size for this connection. With the default of \-1
the value configured with
.BR reqid " = <number>"
sets the reqid for a given connection to a pre-configured fixed value.
.TP
+.BR sha256_96 " = " no " | yes"
+HMAC-SHA-256 is used with 128-bit truncation with IPsec. For compatibility
+with implementations that incorrectly use 96-bit truncation this option may be
+enabled to configure the shorter truncation length in the kernel. This is not
+negotiated, so this only works with peers that use the incorrect truncation
+length (or have this option enabled).
+.TP
.BR tfc " = <value>"
number of bytes to pad ESP payload data to. Traffic Flow Confidentiality
is currently supported in IKEv2 and applies to outgoing packets only. The
projects / thirdparty / strongswan.git / blobdiff