# Custom rules for ipsec.conf.5; manpages.mk should be updated to
# mimic this behaviour.
-$(builddir)/ipsec.conf.5.man: $(srcdir)/ipsec.conf.5.xml $(srcdir)/d.ipsec.conf/*.xml
+
+
+$(builddir)/ipsec.conf.5.man: $(srcdir)/ipsec.conf.5.xml
+$(builddir)/ipsec.conf.5.man: $(srcdir)/d.ipsec.conf/*/*.xml
$(builddir)/ipsec.conf.5.man: $(builddir)/ipsec.conf.5.ok
-$(builddir)/ipsec.conf.5.ok: $(srcdir)/d.ipsec.conf/*.xml
: do all d.ipsec.conf/*.xml files appear in ipsec.conf.5.xml?
- for x in d.ipsec.conf/*.xml ; do \
+ for x in d.ipsec.conf/*/*.xml ; do \
+ d=$$(basename $$(dirname $${x})) ; \
b=$$(basename $${x} .xml) ; \
if ! grep '"'$${x}'"' ipsec.conf.5.xml > /dev/null ; then \
- echo '"'$${x}'"' missing ; \
+ echo 'ENTITY ... "'$${x}'"' missing ; \
exit 1 ; \
fi ; \
- if ! grep '&'$${b}';' ipsec.conf.5.xml > /dev/null ; then \
- echo $${b} missing ; \
+ if ! grep '&'$${d}.$${b}';' ipsec.conf.5.xml > /dev/null ; then \
+ echo '&'$${d}.$${b}';' missing ; \
exit 1 ; \
fi ; \
done
+++ /dev/null
-<varlistentry>
- <term>
- <option>accept-redirect-to</option>
- </term>
- <listitem>
- <para>
- Specify the comma separated list of addresses we accept being
- redirected to. Both IPv4 and IPv6 addresses are supported as
- well the FQDNs. The value <option>%any</option>, as well as not
- specifying any address, signifes that we will redirect to any
- address gateway sends us in REDIRECT notify payload.
- </para>
- <para>
- The value of this option is not considered at all if
- accept-redirect is set to no.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>accept-redirect</option>
- </term>
- <listitem>
- <para>
- Whether requests of the remote peer to redirect IKE/IPsec SA's
- are accepted. Valid options are <option>no</option> (the
- default) and <option>yes</option>. See also
- <option>accept-redirect-to</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftaddresspool=&ip_pool;,...</option>
- </term>
- <term>
- <option>rightaddresspool=&ip_pool;...</option>
- </term>
- <listitem>
- <para>
- Comma separated list of address pools from where the IKEv1 (IPv4
- Mode Config server) and IKEv2 (IPv4 and IPv6 configuration
- payload server) can assign IP addresses to clients. At most one
- one IPv4 and one IPv6 pool may be specified. The
- <option>leftaddresspool=</option> option can not be combined
- with with either the <option>leftsubnet=</option> or
- <option>leftsubnets=</option> options.
- </para>
- <para>
- A pool is specified using either an address range (for instance,
- <option>leftaddresspool=192.168.1.100-192.168.1.200</option> or
- CIDR (for instance,
- <option>leftaddresspool=2001:db8:0:3:1::/97)</option> syntax.
- For IPv6, the CIDR syntax has been extended to also allow the
- specification of a subnet, for instance
- <option>leftaddresspool=2001:db8:0:3:1::/60/64</option> will
- allocate <option>/64</option> leases. While address pools are
- grown as required and leases are reclaimed, the size of an
- address pool should be reasonable. For instance, the pool
- <option>leftaddresspool=10.0.0.0-11.0.0.0</option> will
- eventually result in an in-memory structure containing 16
- million leases.
- </para>
- <para>
- Address pools specifying the exact same range are shared between
- connections. Different addresspools cannot partially overlap.
- </para>
- <para>
- For IKEv1, when <option>right</option> is configured as a server
- using <option>rightxauthserver=yes</option>, this option
- specifies the address pool from which IP addresses are taken to
- assign the <option>left</option> clients during the Mode Config
- exchange. Generally, the <option>leftaddresspool=</option>
- option will be accompanied by
- <option>leftxauthclient=yes</option>,
- <option>rightxauthserver=yes</option> and
- <option>rightsubnet=0.0.0.0/0</option> option.
- </para>
- <para>
- History: &Libreswan; version 3.30 added support for IPv6
- addresses, and replaced a static table with dynamic O(1)
- structures; &Libreswan; 5.0 added support for combined IPv4 and
- IPv6 address pools; &Libreswan; 5.4 added support for IPv6
- subnets. &Libreswan; should allow the combination of
- <option>addresspool</option> and <option>subnet</option>,
- patches would be welcome.
- </para>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>aggressive</option>
- </term>
- <listitem>
-
- <para>
- Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This
- option has no effect when IKEv2 is used. Acceptable values are
- <option>no</option> (the default) or <option>yes</option>.
- When this option is enabled, IKEv1 Main Mode will no longer be
- allowed for this connection. The old name of this option was
- <option>aggrmode</option>.
- </para>
-
- <para>
- Aggressive Mode is less secure, and more vulnerable to Denial Of
- Service attacks. It is also vulnerable to brute force attacks
- with software such as <option>ikecrack</option>.
- It should not be used, and it should especially not be used with
- XAUTH and group secrets (PSK). If the remote system administrator
- insists on staying irresponsible, enable this option.
- </para>
-
- <para>
- Aggressive Mode is further limited to only proposals with one DH
- group as there is no room to negotiate the DH group. Therefore
- it is mandatory for Aggressive Mode connections that both
- <option>ike=</option> and <option>esp=</option> options
- are specified with only one fully specified proposal using one DH group.
- </para>
-
- <para>
- The KE payload is created in the first exchange packet when
- using aggressive mode. The KE payload depends on the DH group
- used. This is why there cannot be multiple DH groups in IKEv1
- aggressive mode. In IKEv2, which uses a similar method to IKEv1
- Aggressive Mode, there is an INVALID_KE response payload that
- can inform the initiator of the responder's desired DH group and
- so an IKEv2 connection can actually recover from picking the
- wrong DH group by restarting its negotiation.
- </para>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ah</option>
- </term>
- <listitem>
- <para>
- A comma separated list of AH algorithms that will be
- offered/accepted when negotiating the Child SA. The general
- syntax is:
- </para>
- <para>
- <simplelist columns='1'>
- <member>AH = PROPOSAL[,PROPOSAL...]</member>
- <member>PROPOSAL = INTEG_ALGS[-DH_ALGS]</member>
- <member>INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]</member>
- <member>DH_ALGS = DH_ALG[+DH_ALG...]</member>
- </simplelist>
- </para>
- <para>
- During startup, &ipsec-pluto.8; will log all supported AH
- algorithms.
- </para>
- <para>
- Specifying the DH algorithms explicitly is
- <option>not</option> recommended. When PFS is enabled, and
- the DH algorithms are omitted, each PROPOSAL will automatically
- include the DH algorithm negotiated during the IKE exchange.
- </para>
- <para>
- The default is not to use AH. If for some (invalid) reason you
- still think you need AH, please use esp with the null encryption
- cipher instead.
- </para>
- <para>
- For instance:
- </para>
- <para>
- <simplelist columns='1'>
- <member><computeroutput>ah=sha2_256+sha2_512</computeroutput></member>
- <member><computeroutput>ah=sha2_256+sha2_512-dh14+dh19</computeroutput></member>
- </simplelist>
- </para>
- <para>
- If not specified, a secure set of defaults will be used. The
- command <command>ipsec algparse ah=...</command> can be used to
- query these defaults.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>audit-log</option>=&Yn_options;
- </term>
- <listitem>
- <para>
- Whether pluto should produce Linux Auditing System log messages.
- If enabled, pluto will log <option>start</option>,
- <command>stop</command> and <option>fail</option> for the
- negotiation of IKE and IPsec SA's. The kernel will also log
- success and failures for actually adding and removing IPsec SA's
- from the kernel's SADB. Valid options are
- <option>yes</option>(the default) and <option>no</option>. On
- non-Linux systems, this option is ignored. If enabled but the
- kernel is lacking audit support, audit messages are not sent.
- If the kernel has audit support and using it fails, pluto will
- abort. Note that for compliance reasons, audit log messages
- contain the relevant IP addresses, even if
- <option>logip=no</option>.
- </para>
- <para>
- Prior to &Libreswan; version 5.3, when <command>pluto</command>
- was invoked directly and without a configuration file, this
- option was set to <option>no</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftauth</option>
- </term>
- <term>
- <option>rightauth</option>
- </term>
- <listitem>
- <para>
- How the security gateways will authenticate to the other side in
- the case of asymmetric authentication; acceptable values are
- <option>rsasig</option> or <option>rsa</option>
- for RSA Authentication with SHA-1, <option>rsa-sha2</option>
- for RSA-PSS digital signatures based authentication with SHA2-256,
- <option>rsa-sha2_384</option> for RSA-PSS digital signatures
- based authentication with SHA2-384, <option>rsa-sha2_512</option>
- for RSA-PSS digital signatures based authentication with SHA2-512,
- <option>ecdsa</option> for ECDSA digital signatures based
- authentication, <option>secret</option> for shared
- secrets (PSK) authentication and <option>null</option> for
- null-authentication. There is no default value - if unset, the
- symmetrical <option>authby=</option> keyword is used to
- determine the authentication policy of the connection.
- </para>
-
- <para>
- Asymmetric authentication is only supported with IKEv2. If symmetric
- authentication is required, use <option>authby=</option> instead
- of leftauth and rightauth. If leftauth is set, rightauth must also be set and
- authby= must not be set. Asymmetric authentication cannot use secret (psk) on one
- side and null on the other side - use psk on both ends instead.
- </para>
- <para>
- When using EAPONLY authentication, which omits the regular IKEv2
- AUTH payload, leftauth= (or rightauth=) should be set to
- <option>eaponly</option>.
- </para>
- <para>
- Be aware that the symmetric keyword is <option>authby=</option>
- but the asymmetric keyword is <option>leftauth</option> and
- <option>rightauth</option> (without the "by").
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>authby=</option>
- </term>
- <listitem>
-
- <para>
- How the two security gateways should authenticate each other. A
- comma separated list of one or more of the following:
- </para>
-
- <variablelist>
-
- <varlistentry>
- <term>
- <option>ecdsa</option>
- </term>
- <term>
- <option>ecdsa-sha2</option>
- </term>
- <listitem>
- <para>
- ECDSA digital signature based authentication with any of
- the hash algorithms SHA2_256, SHA2_384, or SHA2_512.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>ecdsa-sha2_256</option>
- </term>
- <term>
- <option>ecdsa-sha2_384</option>
- </term>
- <term>
- <option>ecdsa-sha2_512</option>
- </term>
- <listitem>
- <para>
- ECDSA digital signature based authentication with the
- specified SHA2_256, SHA2_384, or SHA2_512 hash algorithm.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>eddsa</option>
- </term>
- <listitem>
- <para>
- EDDSA digital signature based authentication on curve on
- curve 25519.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>rsa</option>
- </term>
- <term>
- <option>rsasig</option>
- </term>
- <listitem>
- <para>
- RSA-PKCSv1.5 digital signature based authentication with
- SHA1; and, when IKEv2, RSASSA-PSS digital signature
- authentication with either SHA2_256, SHA2_384, or
- SHA2_512.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>rsa-sha1</option>
- </term>
- <listitem>
- <para>
- RSA-PKCSv1.5 digital signature based authentication with
- SHA1
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>rsa-sha2</option>
- </term>
- <listitem>
- <para>
- RSASSA-PSS digital signature based authentication with any
- of the hash algorithms SHA2_256, SHA2_384, or SHA2_512.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>rsa-sha2_256</option>
- </term>
- <term>
- <option>rsa-sha2_384</option>
- </term>
- <term>
- <option>rsa-sha2_512</option>
- </term>
- <listitem>
- <para>
- RSASSA-PSS digital signature based authentication with
- the specified SHA2_256, SHA2_384, or SHA2_512 hash
- algorithm.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>secret</option>
- </term>
- <listitem>
- <para>
- Shared secrets (PSK) authentication; cannot be combined
- with other authentication methods.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>never</option>
- </term>
- <listitem>
- <para>
- Negotiation is never to be attempted or accepted; cannot
- be combined with other authentication methods.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>null</option>
- </term>
- <listitem>
- <para>
- NULL-authentication; cannot be combined with other
- authentication methods.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- For IKEv1, SHA2 based signatures are not defined and ECDSA is
- not implemented, so the default <option>authby</option> value is
- <option>rsa-sha1</option>. Using <option>authby=rsasig</option>
- results in only <option>rsa-sha1</option> as well.
- </para>
-
- <para>
- For IKEv2, <option>rsasig,ecdsa</option> which allows ECDSA with
- SHA-2 and RSA with SHA2 or SHA1. Using
- <option>authby=rsasig</option> means using
- <option>rsa-sha2_512</option>, <option>rsa-sha2_384</option>,
- <option>rsa-sha2_256</option> and <option>rsa-sha1</option>,
- where <option>rsa-sha1</option> will used only if RFC 7427 is
- not supported by the peer.
- </para>
-
- <para>
- Note that <option>authby</option> cannot be used for asymmetric
- authentication. Instead, IKEv2 must be enabled and the options
- <option>leftauth</option> and <option>rightauth</option> used.
- </para>
-
- <para>
- As per RFC 8221, <option>authby=rsa-sha1</option> is only
- supported in the old style, meaning RSA-PKCSv1.5. The SHA2
- variants are only supported for the new style of RFC 7427, so
- <option>authby=rsa-sha2</option> will use the new style. The
- default <option>authby=</option> will remove
- <option>rsa-sha1</option> in the near future. It is strongly
- recommended that when certificates are used, the certificates
- and the <option>authby=</option> signature methods used are the
- same, as it increases interoperability and keeps the
- authentication of everything within one digital signature
- system.
- </para>
-
- <para>
- Digital signatures are superior in every way to shared secrets.
- Especially IKEv1 in Aggressive Mode is vulnerable to offline
- dictionary attacks and is performed routinely by at least the
- NSA on monitored internet traffic globally. The never option is
- only used for connections that do not actually start an IKE
- negotiation, such as type=passthrough connections. The auth
- method null is used for "anonymous opportunistic IPsec" and
- should not be used for regular pre-configured IPsec VPNs.
- </para>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftautheap</option>
- </term>
- <term>
- <option>rightautheap</option>
- </term>
- <listitem>
- <para>
- Whether the security gateways will authenticate uing an EAP
- method. Acceptable values are <option>none</option>
- (the default) and <option>tls</option> for EAPTLS. If EAP
- is the only authentication method, set <option>leftauth=none</option>
- in addition to <option>leftautheap=tls=</option>.
- </para>
-
- <para>
- The EAP authentication mechanisms are only available for IKEv2
- based connections.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='author'>
- <title>AUTHOR</title>
- <para>
- <author><personname><firstname>Paul</firstname><surname>Wouters</surname></personname></author>
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>auto=</option>
- </term>
- <listitem>
- <para>
- what operation, if any, should be done automatically at IPsec
- startup; currently-accepted values are:
- </para>
- <variablelist>
- <varlistentry>
- <term>
- <option>auto=add</option>
- </term>
- <listitem>
- <para>
- equivalent to:
- <simplelist>
- <member>
- <command>ipsec add <replaceable>connection</replaceable></command>
- </member>
- </simplelist>
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>auto=ondemand</option>
- </term>
- <listitem>
- <para>
- equivalent to:
- <simplelist>
- <member>
- <command>ipsec add <replaceable>connection</replaceable></command>
- </member>
- <member>
- <command>ipsec route <replaceable>connection</replaceable></command>
- </member>
- </simplelist>
- (<option>auto=route</option> is an alias)
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>auto=up</option>
- </term>
- <term>
- <option>auto=start</option>
- </term>
- <listitem>
- <para>
- equivalent to:
- <simplelist>
- <member>
- <command>ipsec add <replaceable>connection</replaceable></command>
- </member>
- <member>
- <command>ipsec up <replaceable>connection</replaceable></command>
- </member>
- </simplelist>
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>auto=ignore</option>
- </term>
- <listitem>
- <para>
- signifying no automatic operation when
- &Libreswan; is starting (also the
- default)
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>auto=keep</option>
- </term>
- <listitem>
- <para>
- signifying an add plus an attempt to keep the connection
- up once the remote peer brought it up
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- Relevant only locally, other end need not agree on it (but in
- general, for an intended-to-be-permanent connection, both ends
- should use <option>auto=up</option> to ensure that any reboot
- causes immediate renegotiation).
- </para>
- <para>
- See the <option>config setup</option> discussion below.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='bugs'>
- <title>
- BUGS
- </title>
- <para>
- Before reporting new bugs, please ensure you are using the latest
- version of Libreswan.
- </para>
-
- <para>
- When <option>type</option> or <option>failureshunt</option> is set
- to <option>drop</option> or <option>reject,</option> &Libreswan;
- blocks outbound packets using eroutes, but assumes inbound
- blocking is handled by the firewall. &Libreswan; offers firewall
- hooks via an “updown” script. However, the default
- <command>ipsec _updown</command> provides no help in controlling a
- modern firewall.
- </para>
-
- <para>
- Including attributes of the keying channel (authentication
- methods, <option>ikelifetime</option>, etc.) as an
- attribute of a connection, rather than of a participant pair, is
- dubious and incurs limitations.
- </para>
-
- <para>
- The use of <option>%any</option> with the <option>protoport=</option>
- option is ambiguous. Should the SA permits any port through or should
- the SA negotiate any single port through? The first is a basic conn with
- a wildcard. The second is a template. The second is the current behaviour,
- and it's wrong for quite a number of uses involving TCP. The keyword
- <option>%one</option> may be introduced in the
- future to separate these two cases.
- </para>
-
- <para>
- It would be good to have a line-continuation syntax, especially
- for the very long lines involved in RSA signature keys.
- </para>
-
- <para>
- The ability to specify different identities, <option>authby</option>,
- and public keys for different automatic-keyed connections between
- the same participants is misleading; this doesn't work dependably
- because the identity of the participants is not known early enough.
- This is especially awkward for the “Road Warrior” case,
- where the remote IP address is specified as <literal>0.0.0.0</literal>,
- and that is considered to be the “participant” for such
- connections.
- </para>
-
- <para>
- If conns are to be added before DNS is available, <option>left=</option>
- <option>FQDN</option>, <option>leftnextop=</option><option>FQDN</option>,
- and <option>leftrsasigkey=%dnsonload</option> will fail.
- &ipsec-pluto.8;
- does not actually use the public key for our side of a conn but it
- isn't generally known at a add-time which side is ours (Road
- Warrior and Opportunistic conns are currently exceptions).
- </para>
-
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftca</option>
- </term>
- <term>
- <option>rightca</option>
- </term>
- <listitem>
- <para>
- Specifies the Distinguished Name of the authorized Certificate
- Authority (CA) that signed the certificate of the peer. When
- unspecified, it defaults to the CA that signed the certificate
- specified in <option>leftcert</option>.
- </para>
- <para>
- The special
- <option>rightca=%same</option> is implied when not specifying a
- <option>rightca</option> and means that only peers with
- certificates signed by the same CA as the leftca will be
- allowed. This option is only useful in complex multi CA
- certificate situations. When using a single CA, it can be safely
- omitted for both left and right.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftcat</option>
- </term>
- <term>
- <option>rightcat</option>
- </term>
- <listitem>
- <para>
- Whether to perform Client Address Translation ("CAT") when using
- Opportunistic IPsec behind NAT. Accepted values are <option>no</option>
- (the default) and <option>yes</option>. This option should
- only be enabled on the special Opportunistic IPsec connections,
- usually called "private" and "private-or-clear". When set, this
- option causes the given addresspool IP from the remote peer to be
- NATed with nftables or iptables. It will also install an additional
- IPsec SA policy to cover the pre-NAT IP. See the Opportunistic IPsec
- information on the libreswan website for more information and examples.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftcert</option>
- </term>
- <term>
- <option>rightcert</option>
- </term>
- <listitem>
- <para>
- If you are using <option>leftrsasigkey=%cert</option>
- this defines the certificate nickname of your certificate in the NSS
- database. This can be on software or hardware security device.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='choosing_a_connection'>
- <title>
- CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE
- </title>
- <para>
- When choosing a connection to apply to an outbound packet caught
- with a <option>%trap,</option> the system prefers
- the one with the most specific eroute that includes the packet's
- source and destination IP addresses. Source subnets are examined
- before destination subnets. For initiating, only routed
- connections are considered. For responding, unrouted but added
- connections are considered.
- </para>
- <para>
- When choosing a connection to use to respond to a negotiation
- that doesn't match an ordinary conn, an opportunistic connection may
- be instantiated. Eventually, its instance will be /32 -> /32, but
- for earlier stages of the negotiation, there will not be enough
- information about the client subnets to complete the
- instantiation.
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>cisco-split</option>=&yN_options;
- </term>
- <listitem>
- <para>
- Use the IKEv1 MODE_CFG CISCO_SPLIT_INCLUDE payload to transfer
- the server's <option>subnet=</option> list to the client.
- During the Quick Mode exchange, the client and server will then
- install kernel policy that includes all the subnets. Acceptable
- values are: <option>no</option> (the default) and
- <option>yes</option>.
- </para>
- <para>
- The <option>cisco-split</option> option was added in &Libreswan;
- version 5.3.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>cisco-unity</option>
- </term>
- <listitem>
- <para>
- whether to send a CISCO_UNITY payload to the peer. Acceptable
- values are: <option>no</option> (the default) and
- <option>yes</option>.
- </para>
- <para>
- It is recommended to leave this option unset, unless the remote
- peer (Cisco client or server) requires it. This option does not
- modify local behaviour. It can be needed to connect as a client
- to a Cisco server. It can also be needed to act as a server for
- a Cisco client, which otherwise might send back an error
- DEL_REASON_NON_UNITY_PEER.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftckaid</option>
- </term>
- <term>
- <option>rightckaid</option>
- </term>
- <listitem>
- <para>
- The CKAID of the X.509 certificate or host key.
- </para>
- <para>
- For X.509 certificates, the CKAID is either the certificate's
- SubjectKeyIdentifier or the public key's SHA1 fingerprint (when
- the SubjectKeyIdentifier isn't specified). For host keys the
- CKAID is the SHA1 fingerprint of the public key.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>clientaddrfamily={ipv4,ipv6}</option>
- </term>
- <listitem>
- <para>
- This option was removed in &Libreswan; version 5.3.
- </para>
- <para>
- Since &Libreswan; version 5.0, <option>subnet=</option>
- <option>subnets=</option> have allowed a mixture of IKEv1 and
- IKEv2 addresses, making <option>clientaddrfamily=</option>
- redundant.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term><option>compress</option></term>
- <listitem>
- <para>
- whether IPComp compression of content is proposed on the
- connection (link-level compression does not work on encrypted
- data, so to be effective, compression must be done
- <option>before</option> encryption); acceptable values are
- <option>yes</option> and <option>no</option> (the default).
- </para>
- <para>
- For IKEv1, compress settings on both peers must match. For
- IKEv2, compression can only be suggested and a mismatched
- compress setting results in connection without compression.
- </para>
- <para>
- When set to yes, compression is negotiated for the DEFLATE
- compression algorithm.
- </para>
- </listitem>
-</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>accept-redirect-to</option>
+ </term>
+ <listitem>
+ <para>
+ Specify the comma separated list of addresses we accept being
+ redirected to. Both IPv4 and IPv6 addresses are supported as
+ well the FQDNs. The value <option>%any</option>, as well as not
+ specifying any address, signifes that we will redirect to any
+ address gateway sends us in REDIRECT notify payload.
+ </para>
+ <para>
+ The value of this option is not considered at all if
+ accept-redirect is set to no.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>accept-redirect</option>
+ </term>
+ <listitem>
+ <para>
+ Whether requests of the remote peer to redirect IKE/IPsec SA's
+ are accepted. Valid options are <option>no</option> (the
+ default) and <option>yes</option>. See also
+ <option>accept-redirect-to</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftaddresspool=&ip_pool;,...</option>
+ </term>
+ <term>
+ <option>rightaddresspool=&ip_pool;...</option>
+ </term>
+ <listitem>
+ <para>
+ Comma separated list of address pools from where the IKEv1 (IPv4
+ Mode Config server) and IKEv2 (IPv4 and IPv6 configuration
+ payload server) can assign IP addresses to clients. At most one
+ one IPv4 and one IPv6 pool may be specified. The
+ <option>leftaddresspool=</option> option can not be combined
+ with with either the <option>leftsubnet=</option> or
+ <option>leftsubnets=</option> options.
+ </para>
+ <para>
+ A pool is specified using either an address range (for instance,
+ <option>leftaddresspool=192.168.1.100-192.168.1.200</option> or
+ CIDR (for instance,
+ <option>leftaddresspool=2001:db8:0:3:1::/97)</option> syntax.
+ For IPv6, the CIDR syntax has been extended to also allow the
+ specification of a subnet, for instance
+ <option>leftaddresspool=2001:db8:0:3:1::/60/64</option> will
+ allocate <option>/64</option> leases. While address pools are
+ grown as required and leases are reclaimed, the size of an
+ address pool should be reasonable. For instance, the pool
+ <option>leftaddresspool=10.0.0.0-11.0.0.0</option> will
+ eventually result in an in-memory structure containing 16
+ million leases.
+ </para>
+ <para>
+ Address pools specifying the exact same range are shared between
+ connections. Different addresspools cannot partially overlap.
+ </para>
+ <para>
+ For IKEv1, when <option>right</option> is configured as a server
+ using <option>rightxauthserver=yes</option>, this option
+ specifies the address pool from which IP addresses are taken to
+ assign the <option>left</option> clients during the Mode Config
+ exchange. Generally, the <option>leftaddresspool=</option>
+ option will be accompanied by
+ <option>leftxauthclient=yes</option>,
+ <option>rightxauthserver=yes</option> and
+ <option>rightsubnet=0.0.0.0/0</option> option.
+ </para>
+ <para>
+ History: &Libreswan; version 3.30 added support for IPv6
+ addresses, and replaced a static table with dynamic O(1)
+ structures; &Libreswan; 5.0 added support for combined IPv4 and
+ IPv6 address pools; &Libreswan; 5.4 added support for IPv6
+ subnets. &Libreswan; should allow the combination of
+ <option>addresspool</option> and <option>subnet</option>,
+ patches would be welcome.
+ </para>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>aggressive</option>
+ </term>
+ <listitem>
+
+ <para>
+ Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This
+ option has no effect when IKEv2 is used. Acceptable values are
+ <option>no</option> (the default) or <option>yes</option>.
+ When this option is enabled, IKEv1 Main Mode will no longer be
+ allowed for this connection. The old name of this option was
+ <option>aggrmode</option>.
+ </para>
+
+ <para>
+ Aggressive Mode is less secure, and more vulnerable to Denial Of
+ Service attacks. It is also vulnerable to brute force attacks
+ with software such as <option>ikecrack</option>.
+ It should not be used, and it should especially not be used with
+ XAUTH and group secrets (PSK). If the remote system administrator
+ insists on staying irresponsible, enable this option.
+ </para>
+
+ <para>
+ Aggressive Mode is further limited to only proposals with one DH
+ group as there is no room to negotiate the DH group. Therefore
+ it is mandatory for Aggressive Mode connections that both
+ <option>ike=</option> and <option>esp=</option> options
+ are specified with only one fully specified proposal using one DH group.
+ </para>
+
+ <para>
+ The KE payload is created in the first exchange packet when
+ using aggressive mode. The KE payload depends on the DH group
+ used. This is why there cannot be multiple DH groups in IKEv1
+ aggressive mode. In IKEv2, which uses a similar method to IKEv1
+ Aggressive Mode, there is an INVALID_KE response payload that
+ can inform the initiator of the responder's desired DH group and
+ so an IKEv2 connection can actually recover from picking the
+ wrong DH group by restarting its negotiation.
+ </para>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ah</option>
+ </term>
+ <listitem>
+ <para>
+ A comma separated list of AH algorithms that will be
+ offered/accepted when negotiating the Child SA. The general
+ syntax is:
+ </para>
+ <para>
+ <simplelist columns='1'>
+ <member>AH = PROPOSAL[,PROPOSAL...]</member>
+ <member>PROPOSAL = INTEG_ALGS[-DH_ALGS]</member>
+ <member>INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]</member>
+ <member>DH_ALGS = DH_ALG[+DH_ALG...]</member>
+ </simplelist>
+ </para>
+ <para>
+ During startup, &ipsec-pluto.8; will log all supported AH
+ algorithms.
+ </para>
+ <para>
+ Specifying the DH algorithms explicitly is
+ <option>not</option> recommended. When PFS is enabled, and
+ the DH algorithms are omitted, each PROPOSAL will automatically
+ include the DH algorithm negotiated during the IKE exchange.
+ </para>
+ <para>
+ The default is not to use AH. If for some (invalid) reason you
+ still think you need AH, please use esp with the null encryption
+ cipher instead.
+ </para>
+ <para>
+ For instance:
+ </para>
+ <para>
+ <simplelist columns='1'>
+ <member><computeroutput>ah=sha2_256+sha2_512</computeroutput></member>
+ <member><computeroutput>ah=sha2_256+sha2_512-dh14+dh19</computeroutput></member>
+ </simplelist>
+ </para>
+ <para>
+ If not specified, a secure set of defaults will be used. The
+ command <command>ipsec algparse ah=...</command> can be used to
+ query these defaults.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftauth</option>
+ </term>
+ <term>
+ <option>rightauth</option>
+ </term>
+ <listitem>
+ <para>
+ How the security gateways will authenticate to the other side in
+ the case of asymmetric authentication; acceptable values are
+ <option>rsasig</option> or <option>rsa</option>
+ for RSA Authentication with SHA-1, <option>rsa-sha2</option>
+ for RSA-PSS digital signatures based authentication with SHA2-256,
+ <option>rsa-sha2_384</option> for RSA-PSS digital signatures
+ based authentication with SHA2-384, <option>rsa-sha2_512</option>
+ for RSA-PSS digital signatures based authentication with SHA2-512,
+ <option>ecdsa</option> for ECDSA digital signatures based
+ authentication, <option>secret</option> for shared
+ secrets (PSK) authentication and <option>null</option> for
+ null-authentication. There is no default value - if unset, the
+ symmetrical <option>authby=</option> keyword is used to
+ determine the authentication policy of the connection.
+ </para>
+
+ <para>
+ Asymmetric authentication is only supported with IKEv2. If symmetric
+ authentication is required, use <option>authby=</option> instead
+ of leftauth and rightauth. If leftauth is set, rightauth must also be set and
+ authby= must not be set. Asymmetric authentication cannot use secret (psk) on one
+ side and null on the other side - use psk on both ends instead.
+ </para>
+ <para>
+ When using EAPONLY authentication, which omits the regular IKEv2
+ AUTH payload, leftauth= (or rightauth=) should be set to
+ <option>eaponly</option>.
+ </para>
+ <para>
+ Be aware that the symmetric keyword is <option>authby=</option>
+ but the asymmetric keyword is <option>leftauth</option> and
+ <option>rightauth</option> (without the "by").
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>authby=</option>
+ </term>
+ <listitem>
+
+ <para>
+ How the two security gateways should authenticate each other. A
+ comma separated list of one or more of the following:
+ </para>
+
+ <variablelist>
+
+ <varlistentry>
+ <term>
+ <option>ecdsa</option>
+ </term>
+ <term>
+ <option>ecdsa-sha2</option>
+ </term>
+ <listitem>
+ <para>
+ ECDSA digital signature based authentication with any of
+ the hash algorithms SHA2_256, SHA2_384, or SHA2_512.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>ecdsa-sha2_256</option>
+ </term>
+ <term>
+ <option>ecdsa-sha2_384</option>
+ </term>
+ <term>
+ <option>ecdsa-sha2_512</option>
+ </term>
+ <listitem>
+ <para>
+ ECDSA digital signature based authentication with the
+ specified SHA2_256, SHA2_384, or SHA2_512 hash algorithm.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>eddsa</option>
+ </term>
+ <listitem>
+ <para>
+ EDDSA digital signature based authentication on curve on
+ curve 25519.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>rsa</option>
+ </term>
+ <term>
+ <option>rsasig</option>
+ </term>
+ <listitem>
+ <para>
+ RSA-PKCSv1.5 digital signature based authentication with
+ SHA1; and, when IKEv2, RSASSA-PSS digital signature
+ authentication with either SHA2_256, SHA2_384, or
+ SHA2_512.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>rsa-sha1</option>
+ </term>
+ <listitem>
+ <para>
+ RSA-PKCSv1.5 digital signature based authentication with
+ SHA1
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>rsa-sha2</option>
+ </term>
+ <listitem>
+ <para>
+ RSASSA-PSS digital signature based authentication with any
+ of the hash algorithms SHA2_256, SHA2_384, or SHA2_512.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>rsa-sha2_256</option>
+ </term>
+ <term>
+ <option>rsa-sha2_384</option>
+ </term>
+ <term>
+ <option>rsa-sha2_512</option>
+ </term>
+ <listitem>
+ <para>
+ RSASSA-PSS digital signature based authentication with
+ the specified SHA2_256, SHA2_384, or SHA2_512 hash
+ algorithm.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>secret</option>
+ </term>
+ <listitem>
+ <para>
+ Shared secrets (PSK) authentication; cannot be combined
+ with other authentication methods.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>never</option>
+ </term>
+ <listitem>
+ <para>
+ Negotiation is never to be attempted or accepted; cannot
+ be combined with other authentication methods.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>null</option>
+ </term>
+ <listitem>
+ <para>
+ NULL-authentication; cannot be combined with other
+ authentication methods.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ For IKEv1, SHA2 based signatures are not defined and ECDSA is
+ not implemented, so the default <option>authby</option> value is
+ <option>rsa-sha1</option>. Using <option>authby=rsasig</option>
+ results in only <option>rsa-sha1</option> as well.
+ </para>
+
+ <para>
+ For IKEv2, <option>rsasig,ecdsa</option> which allows ECDSA with
+ SHA-2 and RSA with SHA2 or SHA1. Using
+ <option>authby=rsasig</option> means using
+ <option>rsa-sha2_512</option>, <option>rsa-sha2_384</option>,
+ <option>rsa-sha2_256</option> and <option>rsa-sha1</option>,
+ where <option>rsa-sha1</option> will used only if RFC 7427 is
+ not supported by the peer.
+ </para>
+
+ <para>
+ Note that <option>authby</option> cannot be used for asymmetric
+ authentication. Instead, IKEv2 must be enabled and the options
+ <option>leftauth</option> and <option>rightauth</option> used.
+ </para>
+
+ <para>
+ As per RFC 8221, <option>authby=rsa-sha1</option> is only
+ supported in the old style, meaning RSA-PKCSv1.5. The SHA2
+ variants are only supported for the new style of RFC 7427, so
+ <option>authby=rsa-sha2</option> will use the new style. The
+ default <option>authby=</option> will remove
+ <option>rsa-sha1</option> in the near future. It is strongly
+ recommended that when certificates are used, the certificates
+ and the <option>authby=</option> signature methods used are the
+ same, as it increases interoperability and keeps the
+ authentication of everything within one digital signature
+ system.
+ </para>
+
+ <para>
+ Digital signatures are superior in every way to shared secrets.
+ Especially IKEv1 in Aggressive Mode is vulnerable to offline
+ dictionary attacks and is performed routinely by at least the
+ NSA on monitored internet traffic globally. The never option is
+ only used for connections that do not actually start an IKE
+ negotiation, such as type=passthrough connections. The auth
+ method null is used for "anonymous opportunistic IPsec" and
+ should not be used for regular pre-configured IPsec VPNs.
+ </para>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftautheap</option>
+ </term>
+ <term>
+ <option>rightautheap</option>
+ </term>
+ <listitem>
+ <para>
+ Whether the security gateways will authenticate uing an EAP
+ method. Acceptable values are <option>none</option>
+ (the default) and <option>tls</option> for EAPTLS. If EAP
+ is the only authentication method, set <option>leftauth=none</option>
+ in addition to <option>leftautheap=tls=</option>.
+ </para>
+
+ <para>
+ The EAP authentication mechanisms are only available for IKEv2
+ based connections.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>auto=</option>
+ </term>
+ <listitem>
+ <para>
+ what operation, if any, should be done automatically at IPsec
+ startup; currently-accepted values are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <option>auto=add</option>
+ </term>
+ <listitem>
+ <para>
+ equivalent to:
+ <simplelist>
+ <member>
+ <command>ipsec add <replaceable>connection</replaceable></command>
+ </member>
+ </simplelist>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>auto=ondemand</option>
+ </term>
+ <listitem>
+ <para>
+ equivalent to:
+ <simplelist>
+ <member>
+ <command>ipsec add <replaceable>connection</replaceable></command>
+ </member>
+ <member>
+ <command>ipsec route <replaceable>connection</replaceable></command>
+ </member>
+ </simplelist>
+ (<option>auto=route</option> is an alias)
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>auto=up</option>
+ </term>
+ <term>
+ <option>auto=start</option>
+ </term>
+ <listitem>
+ <para>
+ equivalent to:
+ <simplelist>
+ <member>
+ <command>ipsec add <replaceable>connection</replaceable></command>
+ </member>
+ <member>
+ <command>ipsec up <replaceable>connection</replaceable></command>
+ </member>
+ </simplelist>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>auto=ignore</option>
+ </term>
+ <listitem>
+ <para>
+ signifying no automatic operation when
+ &Libreswan; is starting (also the
+ default)
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>auto=keep</option>
+ </term>
+ <listitem>
+ <para>
+ signifying an add plus an attempt to keep the connection
+ up once the remote peer brought it up
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ Relevant only locally, other end need not agree on it (but in
+ general, for an intended-to-be-permanent connection, both ends
+ should use <option>auto=up</option> to ensure that any reboot
+ causes immediate renegotiation).
+ </para>
+ <para>
+ See the <option>config setup</option> discussion below.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftca</option>
+ </term>
+ <term>
+ <option>rightca</option>
+ </term>
+ <listitem>
+ <para>
+ Specifies the Distinguished Name of the authorized Certificate
+ Authority (CA) that signed the certificate of the peer. When
+ unspecified, it defaults to the CA that signed the certificate
+ specified in <option>leftcert</option>.
+ </para>
+ <para>
+ The special
+ <option>rightca=%same</option> is implied when not specifying a
+ <option>rightca</option> and means that only peers with
+ certificates signed by the same CA as the leftca will be
+ allowed. This option is only useful in complex multi CA
+ certificate situations. When using a single CA, it can be safely
+ omitted for both left and right.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftcat</option>
+ </term>
+ <term>
+ <option>rightcat</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to perform Client Address Translation ("CAT") when using
+ Opportunistic IPsec behind NAT. Accepted values are <option>no</option>
+ (the default) and <option>yes</option>. This option should
+ only be enabled on the special Opportunistic IPsec connections,
+ usually called "private" and "private-or-clear". When set, this
+ option causes the given addresspool IP from the remote peer to be
+ NATed with nftables or iptables. It will also install an additional
+ IPsec SA policy to cover the pre-NAT IP. See the Opportunistic IPsec
+ information on the libreswan website for more information and examples.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftcert</option>
+ </term>
+ <term>
+ <option>rightcert</option>
+ </term>
+ <listitem>
+ <para>
+ If you are using <option>leftrsasigkey=%cert</option>
+ this defines the certificate nickname of your certificate in the NSS
+ database. This can be on software or hardware security device.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>cisco-split</option>=&yN_options;
+ </term>
+ <listitem>
+ <para>
+ Use the IKEv1 MODE_CFG CISCO_SPLIT_INCLUDE payload to transfer
+ the server's <option>subnet=</option> list to the client.
+ During the Quick Mode exchange, the client and server will then
+ install kernel policy that includes all the subnets. Acceptable
+ values are: <option>no</option> (the default) and
+ <option>yes</option>.
+ </para>
+ <para>
+ The <option>cisco-split</option> option was added in &Libreswan;
+ version 5.3.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>cisco-unity</option>
+ </term>
+ <listitem>
+ <para>
+ whether to send a CISCO_UNITY payload to the peer. Acceptable
+ values are: <option>no</option> (the default) and
+ <option>yes</option>.
+ </para>
+ <para>
+ It is recommended to leave this option unset, unless the remote
+ peer (Cisco client or server) requires it. This option does not
+ modify local behaviour. It can be needed to connect as a client
+ to a Cisco server. It can also be needed to act as a server for
+ a Cisco client, which otherwise might send back an error
+ DEL_REASON_NON_UNITY_PEER.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftckaid</option>
+ </term>
+ <term>
+ <option>rightckaid</option>
+ </term>
+ <listitem>
+ <para>
+ The CKAID of the X.509 certificate or host key.
+ </para>
+ <para>
+ For X.509 certificates, the CKAID is either the certificate's
+ SubjectKeyIdentifier or the public key's SHA1 fingerprint (when
+ the SubjectKeyIdentifier isn't specified). For host keys the
+ CKAID is the SHA1 fingerprint of the public key.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>clientaddrfamily={ipv4,ipv6}</option>
+ </term>
+ <listitem>
+ <para>
+ This option was removed in &Libreswan; version 5.3.
+ </para>
+ <para>
+ Since &Libreswan; version 5.0, <option>subnet=</option>
+ <option>subnets=</option> have allowed a mixture of IKEv1 and
+ IKEv2 addresses, making <option>clientaddrfamily=</option>
+ redundant.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term><option>compress</option></term>
+ <listitem>
+ <para>
+ whether IPComp compression of content is proposed on the
+ connection (link-level compression does not work on encrypted
+ data, so to be effective, compression must be done
+ <option>before</option> encryption); acceptable values are
+ <option>yes</option> and <option>no</option> (the default).
+ </para>
+ <para>
+ For IKEv1, compress settings on both peers must match. For
+ IKEv2, compression can only be suggested and a mismatched
+ compress setting results in connection without compression.
+ </para>
+ <para>
+ When set to yes, compression is negotiated for the DEFLATE
+ compression algorithm.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>debug=<replaceable>option</replaceable></option>
+ </term>
+ <listitem>
+ <para>
+ A comma separated list of options that enable internal debug
+ logs of the connection. For more information see the global
+ <option>plutodebug=</option> option.
+ </para>
+ <note>
+ <para>
+ This feature is used by &Libreswan;
+ developers. The default logs should provide sufficient
+ information to diagnose configuration and connection problems.
+ </para>
+ </note>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>decap-dscp</option>
+ </term>
+ <listitem>
+ <para>
+ Enable decapsulating the Differentiated Services Code Point
+ (DSCP, formerly known as Terms Of Service (TOS)) bits. If these
+ bits are set on the inner (encrypted) IP packets, these bits are
+ set on the decrypted IP packets. Acceptable values are
+ <option>no</option> (the default) or <option>yes</option>.
+ Currently this feature is only implemented for the Linux XFRM stack.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dns-match-id</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to perform an additional DNS lookup and confirm the
+ remote ID payload with the DNS name in the reverse DNS PTR
+ record. Accepted values are <option>no</option> (the default) or
+ <option>yes</option>. This check should be enabled when
+ Opportunistic IPsec is enabled in a mode that is based on packet
+ triggers (on-demand) using IPSECKEY records in DNS. Since in
+ that case the IKE daemon pluto does not know the remote ID, it
+ only knows the remote IP address, this option forces it to
+ confirm the peer's proposed ID (and thus its public/private key)
+ with its actual IP address as listed in the DNS. This prevents
+ attacks where mail.example.com's IP address is taken over by a
+ neighbour machine with a valid web.example.com setup. This check
+ is not needed for certificate based Opportunistic IPsec, as
+ "mail.example.com"s certificate does not have an entry for
+ "web.example.com". It is also not needed for DNS server
+ triggered Opportunistic IPsec, as in that case the IKE daemon
+ pluto is informed of both the IP address, and the
+ hostname/public key.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dpddelay</option>
+ </term>
+ <listitem>
+ <para>
+ Set the delay (in time units, defaults to seconds) between Dead
+ Peer Detection (IKEv1 RFC 3706) or IKEv2 Liveness keepalives
+ that are sent for this connection (default <literal>0</literal>
+ seconds). Set to enable checking.
+ </para>
+ <para>
+ If dpddelay is set, you might need to adjust
+ <option>retransmit-timeout</option> for IKEv2
+ and you must set <option>dpdtimeout</option> for IKEv1.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dpdtimeout</option>
+ </term>
+ <listitem>
+ <para>
+ Set the length of time (in time units, defaults to seconds) that
+ pluto will idle without hearing back from the peer. After this
+ period has elapsed with no response and no traffic, pluto will
+ declare the peer dead, and remove the SA (default
+ <literal>0</literal> meaning disabled). Set value bigger than
+ dpddelay to enable. If dpdtimeout is set, dpddelay also needs to
+ be set.
+ </para>
+ <para>
+ This option is only valid for IKEv1. For IKEv2, this value is
+ always the same as the retransmit-timeout, as IKEv2 is blocked
+ from sending further IKE messages if an answer is not
+ received.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>enable-tcp</option>
+ </term>
+ <listitem>
+ <para>
+ Normally, IKE negotiation and ESP encapsulation happens over
+ UDP. This option enables support for IKE and ESP over TCP as per
+ RFC 8229. Acceptable values are <option>no</option>(the default),
+ <option>yes</option> meaning only TCP will be used, or
+ <option>fallback</option> meaning that TCP will be
+ attempted only after negotiation over UDP failed. Since
+ performance over TCP is much less, and TCP sessions are
+ vulnerable to simply RST resets and MITM attacks causing the TCP
+ connection to close, this option should really only be used in
+ fallback mode. If used in fallback mode, it is recommend to
+ reduce the <option>retransmit-timeout</option>
+ from the default 60s to a much shorter value such as 10s, so
+ that one does not have to wait a minute for the TCP fallback to
+ be attempted. To receive incoming TCP connections, the
+ <option>config setup</option> option <option>listen-tcp</option>
+ needs to be enabled.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>encap-dscp</option>
+ </term>
+ <listitem>
+ <para>
+ Enable encapsulating the Differentiated Services Code Point
+ (DSCP, formerly known as Terms Of Service (TOS)) bits. The extra
+ xfrm flag "dont-encap-dscp" prevents these bits from being
+ copied from the unencrypted IP packets to the encrypted IP
+ packets. Acceptable values are <option>yes</option>
+ (the default) or <option>no</option>.
+ Currently this feature is only implemented for the Linux XFRM stack.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>encapsulation</option>
+ </term>
+ <listitem>
+ <para>
+ In some cases, for example when ESP packets are filtered or when
+ a broken IPsec peer does not properly recognise NAT, it can be
+ useful to force RFC-3948 encapsulation. In other cases, where
+ IKE is NAT'ed but ESP packets can or should flow without
+ encapsulation, it can be useful to ignore the NAT-Traversal
+ auto-detection.
+ <option>encapsulation=yes</option> forces the NAT detection
+ code to lie and tell the remote peer that RFC-3948 encapsulation
+ (ESP in port 4500 packets) is required.
+ <option>encapsulation=no</option> ignores the NAT detection
+ causing ESP packets to send send without encapsulation. The
+ default value of <option>encapsulation=auto</option> follows
+ the regular outcome of the NAT auto-detection code performed in IKE.
+ This option replaced the obsoleted forceencaps option.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>esn</option>
+ </term>
+ <listitem>
+ <para>
+ Whether or not to enable Extended Sequence Number (ESN) for the
+ IPsec SA. This option is only implemented for IKEv2. ESN is
+ typically used for very high-speed links (10Gbps or faster)
+ where the standard 32 bit sequence number is exhausted too
+ quickly, causing IPsec SA's rekeys to happen too often. Accepted
+ values are <option>either</option> (the default),
+ <option>yes</option> and <option>no</option>.
+ If <option>either</option> is specified as an initiator,
+ the responder will make the choice. As a responder,
+ if <option>either</option> is received,
+ <option>yes</option> is picked.
+ </para>
+ <para>
+ If replay-window is set to 0, ESN is disabled as some (most?)
+ IPsec stacks won't support ESN in such a configuration.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>esp</option>
+ </term>
+ <listitem>
+ <para>
+ Specifies the algorithms that will be offered/accepted when
+ negotiating a Child SA with ESP encapsulation. The general
+ syntax is:
+ </para>
+ <para>
+ <!-- should use EBNF -->
+ <simplelist columns='1'>
+ <member>ESP = PROPOSAL[,PROPOSAL...]</member>
+ <member>PROPOSAL = ENCRYPT_ALGS[-INTEG_ALGS[-DH_ALGS]]</member>
+ <member>ENCRYPT_ALGS = ENCRYPT_ALG[+ENCRYPT_ALG...]</member>
+ <member>INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]</member>
+ <member>DH_ALGS = DH_ALG[+DH_ALG...]</member>
+ </simplelist>
+ </para>
+ <para>
+ During startup, &ipsec-pluto.8; will log all supported ESP
+ algorithms.
+ </para>
+ <para>
+ Specifying the DH algorithms explicitly is <option>not</option>
+ recommended. When PFS is enabled, and the DH algorithms are
+ omitted, each PROPOSAL will automatically include the DH
+ algorithm negotiated during the IKE exchange.
+ </para>
+ <para>
+ AEAD algorithms such as AES_GCM and AES_CCM do not not require a
+ separate integrity algorithm. For example
+ <option>esp=aes_gcm256</option> or <option>esp=aes_ccm</option>.
+ </para>
+ <para>
+ Note that AES_GCM and AES_CCM for ESP come in 8, 12 and 16 byte
+ ICV versions. RFC 8221 only requires AES_GCM with 16 byte ICV
+ and AES_CCM with 8 byte ICV to be implemented, and "aes_gcm" and
+ "aes_ccm" refer to these variants. The other variants can be
+ specified using an _a (8), _b(12) or _c(16) postfix, eg
+ esp=aes_gcm_a for the 8 byte ICV and esp=aes_gcm_b for the 12
+ byte ICV.
+ </para>
+ <para>
+ For instance:
+ </para>
+ <para>
+ <simplelist columns='1'>
+ <member><computeroutput>esp=aes_gcm;aes128+aes256-sha2_512+sha2_256</computeroutput></member>
+ <member><computeroutput>esp=aes128-sha2_512;dh19</computeroutput></member>
+ </simplelist>
+ </para>
+ <para>
+ If not specified, a secure set of defaults will be used. The
+ program <command>ipsec algparse</command> can be used to query
+ these defaults for instance: <command>ipsec algparse
+ esp=</command> (see &ipsec-algparse.8;).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>failureshunt</option>
+ </term>
+ <listitem>
+ <para>
+ what to do with packets when negotiation fails. The default is
+ <option>none</option>: no shunt; <option>pass</option>,
+ <option>drop</option>, and <option>reject</option> have the
+ obvious meanings.</para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>fake-strongswan</option>=&yN_options;
+ </term>
+ <listitem>
+ <para>
+ whether to send a STRONGSWAN Vendor ID payload to the peer.
+ Acceptable values are: <option>no</option> (the
+ default) and <option>yes</option>. Strongswan enables some
+ non-standard features and private algorithms only when it detects
+ the strongswan Vendor ID. The exact capabilities depend on the
+ strongswan version. At the time of writing this entry this option
+ can enable negotiation of BEET mode (until the IETF assigns a
+ code point), enable some private algorithms (eg some experimental
+ post-quantum algorithms) and eanbles forwarding RADIUS attributes
+ (which should not have any affects with the current EAP support
+ in libreswan). Note that experimental algorithms on strongswan
+ can also be enabled using charon.accept_private_algs and then this
+ option is not needed.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftfirewall</option>
+ </term>
+ <term>
+ <option>rightirewall</option>
+ </term>
+ <listitem>
+ <para>
+ This option is obsolete and should not used anymore.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>fragmentation</option>
+ </term>
+ <listitem>
+ <para>
+ Whether or not to allow IKE fragmentation. Valid values are
+ <option>yes</option> (the default) and <option>no</option>.
+ In addition IKEv1 allows <option>force</option>.
+ </para>
+ <para>
+ IKEv2 fragmentation support is implemented using RFC 7383.
+ </para>
+ <para>
+ IKEv1 fragmentation capabilities are negotiated via a well-known
+ private <option>vendor id</option>. If pluto does
+ not receive the fragmentation payload, no IKE fragments will be
+ sent, regardless of the <option>fragmentation=</option> setting.
+ When set to <option>yes</option>, IKE fragmentation will be
+ attempted on the first re-transmit of an IKE packet of a size
+ larger then 576 bytes for IPv4 and 1280 bytes for IPv6. If
+ fragmentation is set to force, IKE fragmentation is used on
+ initial transmits of such sized packets as well. When we have
+ received IKE fragments for a connection, pluto behaves as if in
+ force mode.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>left</option>
+ </term>
+ <term>
+ <option>right</option>
+ </term>
+ <listitem>
+ <para>
+ (required) the IP address or DNS hostname of the left
+ participant's public-network interface, Currently, IPv4 and IPv6
+ IP addresses are supported. If a DNS hostname is used, it will
+ be resolved to an IP address on load time, and whenever a
+ connection is rekeying or restarting (such as when restarted via
+ a DPD failure detection). This allows one to use a DNS hostname
+ when the endpoint is on a dynamic IP address.
+ </para>
+ <para>
+ There are several magic values. If it is
+ <option>%defaultroute</option>, <option>left</option> will be
+ filled in automatically with the local address of the
+ default-route interface (as determined at IPsec startup time);
+ this also overrides any value supplied for
+ <option>leftnexthop</option>. (Either <option>left</option> or
+ <option>right</option> may be <option>%defaultroute</option>,
+ but not both.) The value <option>%any</option> signifies an
+ address to be filled in (by automatic keying) during
+ negotiation. The value <option>%opportunistic</option>
+ signifies that both <option>left</option> and
+ <option>leftnexthop</option> are to be filled in (by automatic
+ keying) from DNS data for <option>left</option>'s client. The
+ value can also contain the interface name, which will then later
+ be used to obtain the IP address from to fill in. For example
+ <option>%ppp0</option>.
+ </para>
+ <para>
+ The values <option>%group</option> and
+ <option>%opportunisticgroup</option> makes this a policy group
+ conn: one that will be instantiated into a regular or
+ opportunistic conn for each CIDR block listed in the policy
+ group file with the same name as the conn.
+ </para>
+ <para>
+ If using IP addresses in combination with NAT, always use the
+ actual local machine's (NATed) IP address, and if the remote (eg
+ right=) is NATed as well, the remote's public
+ (<option>not</option> NATed) IP address. Note that this makes
+ the configuration no longer symmetrical on both sides, so you
+ cannot use an identical configuration file on both hosts.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>hostaddrfamily</option>
+ </term>
+ <listitem>
+ <para>
+ the address family of the hosts; currently the accepted values
+ are <option>ipv4</option> and <option>ipv6</option>.
+ The default is to detect this based on the IP addresses specified
+ or the IP addresses resolved, so this option is not needed, unless
+ you specify hostnames that resolve to both IPv4 and IPv6.
+ </para>
+ <para>
+ This option used to be named connaddrfamily but its use was broken
+ so it was obsoleted in favour or using the new hostaddrfamily and
+ clientaddrfamily.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftid</option>
+ </term>
+ <term>
+ <option>rightid</option>
+ </term>
+ <listitem>
+ <para>
+ how the left participant should be identified for
+ authentication; defaults to <option>left</option>.
+ Can be an IP address or a fully-qualified domain name which will
+ be resolved. If preceded by <option>@</option>,
+ the value is used as a literal string and will not be resolved.
+
+ To support opaque identifiers (usually of type ID_KEY_ID, such
+ as used by Cisco to specify Group Name, use square brackets, eg
+ <option>rightid=@[GroupName]</option>.
+
+ The magic value <option>%fromcert</option> causes
+ the ID to be set to a DN taken from a certificate that is
+ loaded. Prior to 2.5.16, this was the default if a certificate
+ was specified.
+
+ The magic value <option>%none</option> sets the ID
+ to no ID. This is included for completeness, as the ID may have
+ been set in the default conn, and one wishes for it to default
+ instead of being explicitly set.
+ </para>
+ <para>
+ When using certificate based ID's, one need to specify the full
+ RDN, optionally using wildcard matching (eg CN='*'). If the RDN
+ contains a comma, this can be masked using a backslash (eg
+ OU='Foo\, Bar and associates')
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ignore-peer-dns</option>
+ </term>
+ <listitem>
+ <para>
+ whether to ignore received DNS configuration. Acceptable values
+ are: <option>no</option> (the default) and
+ <option>yes</option>. Normally, when a
+ roadwarrior connects to a remote VPN, the remote VPN server
+ sends a list of DNS domains and DNS nameserver IP addresses that
+ the roadwarrior can use to reach internal only resources through
+ the VPN. This option allows the roadwarrior to ignore the
+ server's suggestion. The roadwarrior will normally use this
+ information to update the DNS resolving process. What is changed
+ depends on the detected DNS configuration. It can modify
+ /etc/resolv.conf directly, or reconfigure a locally running DNS
+ server (unbound, knot, stubby or systemd-resolved) or inform
+ NetworkManager.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term><option>ike</option></term>
+ <listitem>
+ <para>
+ IKE encryption/authentication algorithm to be used for the
+ connection (phase 1 aka ISAKMP SA or IKE SA). If this option is
+ not set, the builtin defaults will be used. This is the
+ preferred method, and allows for gradual automatic updates using
+ the same configuration. Some distributions, such as Fedora and
+ RHEL/CentOS, use a System Wide Crypto Policy that sets the
+ default ike= (and esp=) lines. Specifying your own ike= line
+ means overriding all these system or software recommended
+ defaults, but can be necessary at times. Note that libreswan
+ does not support using a PRF algorithm that is different from
+ the INTEGRITY (hash) algorithm by design.
+ </para>
+ <para>
+ The format is <option>"cipher-hash-modpgroup,
+ cipher-hash-modpgroup, ..."</option> Any omitited option will
+ be filled in with <option>all</option> allowed
+ default values. Multiple proposals are separated by a comma. If
+ an <option>ike=</option> line is specified, no
+ other received proposals will be accepted than those specified
+ on the IKE line. Some examples are <option>ike=3des-sha1,aes-sha1</option>,
+ <option>ike=aes</option>,
+ <option>ike=aes_ctr</option>,
+ <option>ike=aes_gcm256;sha2_256</option>,
+ <option>ike=aes128-sha1;modp2048</option>,
+ <option>ike=aes256-sha2;dh19</option>,
+ <option>ike=aes128-sha1;dh22</option>,
+ <option>ike=3des-md5;modp1024,aes-sha1;modp1536</option>.
+ </para><para> IKEv2 allows combining elements into a single
+ proposal. These can be specified by using the + symbol. An
+ example is:
+ <option>ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14</option>.
+ Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305)
+ and non-AEAD algorithms (aes, 3des) cannot be combined into a
+ single proposal. To support aes and aes_gcm, two proposals
+ separated by a comma must be used.
+ </para>
+ <para>
+ The default IKE proposal depends on the version of libreswan
+ used. It follow the recommendations of RFC4306, RFC7321 and as
+ of this writing their successor draft documents RFC4306bis and
+ RFC7321bis. As for libreswan 3.32, SHA1 and MODP1536(dh5) are
+ still allowed per default for backwards compatibility, but 3DES
+ and MODP1024(dh2) are not allowed per default. As of libreswan
+ 4.x, modp1024(dh2) support is no longer compiled in at all. For
+ IKEv2, the defaults include AES, AES-GCM, DH14 and stronger, and
+ SHA2. The default key size is 256 bits. The default AES_GCM ICV
+ is 16 bytes.
+ </para>
+ <para>
+ Note that AES-GCM is an AEAD algorithm, meaning that it performs
+ encryption+authentication in one step. This means that AES-GCM
+ must not specify an authentication algorithm. However, for IKE
+ it does require a PRF function, so the second argument to an
+ AEAD algorithm denotes the PRF. So ike=aes_gcm-sha2_256 means
+ propose AES_GCM with SHA2_256 as the prf. Note that for
+ esp, there is no prf, so AES-GCM is specified for ESP as
+ esp=aes_gcm. The AES-GCM and AES-CCM algorithms support 8,12 and
+ 16 byte ICV's. These can be specified using a postfix, for
+ example aes_gcm_a (for 8), aes_gcm_b (for 12) and aes_gcm_c (for
+ 16). The default (aes_gcm without postfix) refers to the 16
+ byte ICV version. RFC 8247 only mandates the 16 byte ICV version
+ is implemented, so it is recommended to NOT use the 8 or 12 byte
+ versions of GCM or CCM. These versions are NOT included in the
+ default proposal list and will be removed in a future version.
+ </para>
+ <para>
+ Weak algorithms are regularly removed from libreswan. Currently,
+ 1DES and modp768(DH1) have been removed and modp1024(DH2) has
+ been disabled at compile time. Additionally, MD5 and SHA1 will
+ be removed within the next few years. Null encryption is
+ available, and should only be used for testing or benchmarking
+ purposes. Please do not request for insecure algorithms to be
+ re-added to libreswan. IKEv1 has been disabled per default, and
+ will soon no longer be compiled in by default.
+ </para>
+ <para>
+ For all Diffie-Hellman groups, the "dh" keyword can be used
+ instead of the "modp" keyword. For example
+ <option>ike=3des-sha1-dh19</option>. Diffie-Hellman groups
+ 19,20 and 21 from RFC-5903 are supported. Curve25519 from
+ RFC-8031 is supported as "dh31". Curve448 and GOST DH groups are
+ not yet supported in libreswan because these are not supported
+ yet in the NSS crypto library.
+ </para>
+ <para>
+ Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are
+ implemented but not compiled in by default. These DH groups are
+ extremely controversial and MUST NOT be used unless forced
+ (administratively) by the other party. This is further
+ documented in RFC 8247, but the summary is that it cannot be
+ proven that these DH groups do not contain a cryptographic
+ trapdoor (a backdoor by the USG who provided these primes
+ without revealing the seeds and generation process used).
+ </para>
+ <para>
+ The modp syntax will be removed in favour of the dh syntax in
+ the future
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ikelifetime</option>
+ </term>
+ <listitem>
+ <para>
+ how long the keying channel of a connection (buzzphrase:
+ “IKE SA” or “ISAKMP SA”) should last
+ before being renegotiated; acceptable values as for
+ <option>salifetime</option>. The default as of version 4.2
+ is <option>8h</option>, before that it was 1h. The
+ maximum is <option>24h</option>. The
+ two-ends-disagree case is similar to that of
+ <option>salifetime</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ikepad=</option>
+ </term>
+ <listitem>
+ <para>
+ Work around IKEv1 padding issues when inter-operating with other
+ IKE daemons.
+ </para>
+ <para>
+ By default, &Libreswan; pads messages
+ to a minimum of 4-bytes. While this is allowed it may cause
+ interoperability issues. To remove this padding, specify
+ <option>ikepad=no</option> (note that this does not affect
+ messages encrypted using a block-mode cipher where padding is
+ always added).
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.2, some MODECFG payloads were
+ incorrectly padded to 4-bytes which caused interoperability
+ issues. To restore this behaviour, specify
+ <option>ikepad=yes</option>.
+ </para>
+ <para>
+ In IKEv2, this option is ignored.
+ </para>
+ <sidebar>
+ <title>
+ Background
+ </title>
+ <para>
+ It was thought that padding messages by 4-bytes was causing
+ interoperability issues with
+ &Checkpoint;
+ (<option>ikepad=no</option> was added as a workaround).
+ However, it's since been determined that &Racoon; also had
+ interoperability issues and the cause was the padding of some
+ XAUTH and MODECFG payloads. Setting
+ <option>ikepad=no</option> fixed interoperability because it
+ was also disabling that padding. The padding of XAUTH and
+ MODECFG was removed in &Libreswan; version 5.2.
+ </para>
+ <para>
+ Further details can be found in the RFCs, see: RFC-2409
+ section 5.3, Phase 1 Authenticated With a Revised Mode of
+ Public Key Encryption, <quote>the last byte of the padding
+ contains the number of padding bytes</quote> and <quote>there
+ will always be padding</quote>; RFC-2408 section 3.5, Proposal
+ Payload, <quote>there is no padding applied to the payload,
+ however, it can be applied at the end of the message</quote>;
+ RFC-2408 section 3.6, Transform Payload, <quote>then
+ subsequent payloads will not be aligned and any padding will
+ be added at the end of the message to make the message 4-octet
+ aligned</quote>.
+ </para>
+ </sidebar>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftikeport</option>
+ </term>
+ <term>
+ <option>rightikeport</option>
+ </term>
+ <listitem>
+ <para>
+ The UDP IKE port to listen on or send data to. This port cannot
+ be 0 or 500. For TCP, see <option>tcp-remoteport=</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>initial-contact</option>
+ </term>
+ <listitem>
+ <para>
+ whether to send an INITIAL_CONTACT payload to the peer we are
+ initiating to, if we currently have no IPsec SAs up with that
+ peer. Acceptable values are: <option>yes</option>
+ (the default) and <option>no</option>. It is
+ recommended to leave this option set, unless multiple clients
+ with the same identity are expected to connect using the same
+ subnets and should operate at the same time. Or if a
+ reconnecting client should not delete its old instance (eg
+ perhaps it is still running). This is unlikely to be true.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftinterface-ip=&ip_cidr;</option>
+ </term>
+ <term>
+ <option>rightinterface-ip=&ip_cidr;</option>
+ </term>
+ <listitem>
+ <para>
+ The IP address and netmask to configure on a virtual device (eg
+ <filename>ipsec<replaceable>N</replaceable></filename>). This
+ is often used when building Routing based IPsec tunnels using
+ transport mode and GRE, but can also be useful in other
+ scenarios. Currently requires
+ <option>ipsec-interface=</option>.
+ </para>
+ <para>
+ See also <option>leftvti=</option> for configuring IP addresses
+ when using deprecated VTI.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>intermediate</option>
+ </term>
+ <listitem>
+ <para>
+ EXPERIMENTAL: Whether to enable the INTERMEDIATE exchange in
+ IKEv2 (RFC 9242). Currently the accepted values are
+ <option>yes</option>, signifying we propose to use the
+ INTERMEDIATE exchange for this connection;
+ <option>no</option> (the default), signifying we will not
+ use the INTERMEDIATE exchange for this connection.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ipsec-interface</option>
+ </term>
+ <listitem>
+ <para>
+ Specify the IPsec Interface for "Routing based IPsec VPNs" (as
+ opposed to "Policy based VPNs"). The IPsec Interface is used to
+ route outbound traffic that needs to be encrypted, and will
+ decrypt inbound traffic that arrives on this interface. All
+ traffic that is routed to this interface will be automatically
+ encrypted providing the IPsec SA policy covers this traffic.
+ Traffic not matching the IPsec SA will be dropped. Tools such
+ as <command>tcpdump</command>, <command>iptables</command>,
+ <command>ifconfig</command> and tools that need traffic counters
+ can be used on all cleartext pre-encrypt and post-decrypt
+ traffic on the device. When <option>leftsubnet=</option> is
+ equal to <option>rightsubnet=</option>, the routing needs to be
+ managed by an external routing daemon or manually by the
+ administrator.
+ </para>
+ <para>
+ By default, &Libreswan; is configured in managed mode. In
+ managed mode, &Libreswan; will create, configure
+ <option>up</option>, <option>down</option>, and delete the IPsec
+ Interface device (on &Linux;, &FreeBSD;, and &NetBSD; that
+ device is named <option>ipsec</option>; &OpenBSD; it is named
+ <option>sec</option>). To specify the IP address to configure
+ when creating the device also specify
+ <option>interface-ip=</option>.
+ </para>
+ <para>
+ Alternatively, &Libreswan; can be configured in unmanaged mode.
+ In unmanaged mode, &Libreswan; does not manipulate the IPsec
+ Interface Device directly. Instead &Libreswan; will assume the
+ IPsec Interface device already exists, manipulating it directly
+ using the low-level kernel ID (on &Linux; that is the XFRMi
+ if_id). A typical use is with namespaces where the IPsec
+ Interface Device and &Libreswan; are in separate namespace.
+ </para>
+ <para>
+ </para>
+ <para>
+ </para>
+ <para>
+ Possible values are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <option>no</option> (default)
+ </term>
+ <listitem>
+ <para>
+ Do not use "Routing based IPsec VPN".
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>yes</option>
+ </term>
+ <listitem>
+ <para>
+ Enable "Routing based IPsec VPNs". In managed mode, use
+ IPsec Interface device 1 (for instance,
+ <option>ipsec1</option>). In unmanaged mode, use the
+ kernel device 1.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option><replaceable>number</replaceable></option>
+ </term>
+ <listitem>
+ <para>
+ Enable "Routing based IPsec VPNs" using the device
+ <replaceable>number</replaceable>. For instance,
+ <option>ipsec-interface=5</option> will use
+ <option>ipsec5</option> in managed mode, and kernel xfrm interface
+ with if_id <option>5</option> in unmanaged mode.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ Kernel Support:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ &Linux; (since 4.19)
+ </term>
+ <listitem>
+ <para>
+ This option is currently only supported on Linux kernels
+ when compiled with XFRMi support
+ (<option>CONFIG_XFRM_INTERFACE</option>). The number of
+ the ipsecX device corresponds with the <option>XFRM
+ IF_ID</option> policy option of the IPsec SA in the Linux
+ kernel. On Linux, XFRMi interfaces can be managed by
+ &Libreswan; automatically or can be preconfigured on the
+ system using the existing init system or via networking
+ tools such as systemd-networkd and NetworkManager. The
+ _updown script handles certain Linux specific interfaces
+ settings required for proper functioning, such as
+ forwarding and routing rules for IPsec traffic.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ &NetBSD; (since 8.0)
+ </term>
+ <term>
+ &OpenBSD; (since 7.4)
+ </term>
+ <term>
+ &FreeBSD; (since 11.0)
+ </term>
+ <listitem>
+ <para>
+ Supported since &Libreswan; 5.2.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ipsec-max-bytes</option>
+ </term>
+ <listitem>
+ <para>
+ how many bytes can be sent, or how many bytes can be received on
+ an IPsec SA instance for a connection; acceptable values are an
+ integer optionally followed by
+
+ <option>KiB</option>,
+ <option>MiB</option>,
+ <option>GiB</option>,
+ <option>TiB</option>,
+ <option>PiB</option> or
+ <option>EiB</option>
+
+ to signify kilobytes, megabytes, gigabytes, terabytes, petabytes
+ or exabytes.
+
+ </para>
+ <para>
+ An IPsec SA contains two keys, one for inbound and one for
+ outbound traffic. The
+ <replaceable>ipsec-max-bytes</replaceable> sets two limits on
+ each of these keys: the hard limit which is the total number of
+ bytes that a given key can encrypt, and the soft limit which is
+ the number of bytes that can be encrypted before a renegotiation
+ of the IPsec SA is initiated. Normally the renegotiation (via
+ the IKE SA) is completed before the
+ <replaceable>ipsec-max-bytes</replaceable> value is reached.
+ </para>
+ <para>
+ Pluto sets the the original initiator's soft limit to 25% of
+ <replaceable>ipsec-max-bytes</replaceable> (with 12% fuzz) and
+ on the original responder's soft limit to 50% of
+ <replaceable>ipsec-max-bytes</replaceable> (with 12% fuzz).
+ This way the original initiator hopefully is the one initiating
+ the renegotiation of the IPsec SA.
+ </para>
+ <para>
+ This option is not negotiated between IKE peers. Each end of
+ the IPsec SA sets their own limits independently.
+ </para>
+ <para>
+ The default (hard limit) is 2^63 bytes. The original
+ initiator's soft limit is 2^61 bytes (approx.) and the original
+ responder's soft limit is 2^62 bytes (approx.).
+ </para>
+ <para>
+ When using Linux with <option>nic-offload=packet</option> set,
+ Linux 6.7 or later is required.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ipsec-max-packets</option>
+ </term>
+ <listitem>
+ <para>
+ How many packets can be sent/received on a particular instance
+ of a connection (a set of encryption/authentication keys for
+ user packets) , from successful negotiation to expiry.
+ </para>
+ <para>
+ Default values and caveats are the same as for
+ <option>ipsec-max-bytes</option>. This option uses a prefix
+ without "B" for bytes.
+ </para>
+ <para>
+ When using Linux with <option>nic-offload=packet</option> set,
+ Linux 6.7 or later is required.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>iptfs</option>
+ </term>
+ <listitem>
+ <para>
+ Enable "Aggregation and Fragmentation Mode for Encapsulating
+ Security Payload (ESP) and its use for IP Traffic Flow Security
+ (IP-TFS) as defined in RFC 9347. Currently, this is only
+ supported for the Linux XFRM stack and will likely be merged
+ into Linux 6.7 or 6.8. Valid options are <option>no</option>
+ (the default) or <option>yes</option>. IP-TFS allow the kernel
+ to combine multiple small packets into one ESP packet, which
+ should cause a performance gain when many small packets (eg
+ iperf packets) are sent. It also allows the kernel to fragment
+ the outgoing packet stream so that the ESP packets have a fixed
+ size that can be set manually or fit the path MTU. This should
+ avoid common MTU issues with IPsec. IP-TFS can only be used
+ with tunnel mode and ESP. It cannot be combined with
+ <option>type=transport</option>, <option>phase2=ah</option>,
+ <option>compress=yes</option> or <option>tfc=yes</option>. A
+ number of IP-TFS options can be tuned.
+ </para>
+ </listitem>
+</varlistentry>
+<varlistentry>
+ <term>
+ <option>iptfs-fragmentation={yes,no}</option>
+ </term>
+ <listitem>
+ <para>
+ Whether or not to fragment IP-TFS.
+ </para>
+ <para>
+ On &Linux; and
+ <option>iptfs-fragmentation=no</option>, this passes
+ <option>XFRMA_IPTFS_DONT_FRAG</option> to the kernel. (Unclear
+ to at least one author if this means regular ICMP Dont Fragment
+ sending, or whether it stops IP-TFS from fragmenting).
+ </para>
+ <para>
+ Default is <option>iptfs-fragmentation=yes</option>
+ </para>
+ </listitem>
+</varlistentry>
+<varlistentry>
+ <term><option>iptfs-max-queue-size</option></term>
+ <listitem>
+ <para>
+ The default IP-TFS max output queue size in octets. The output
+ queue is where received packets destined for output over an
+ IP-TFS tunnel are stored prior to being output in
+ aggregated/fragmented form over the IP-TFS tunnel.
+ </para>
+ <para>
+ Default 1000000.
+ </para>
+ </listitem>
+</varlistentry>
+<varlistentry>
+ <term><option>iptfs-drop-time=<replaceable>duration</replaceable></option></term>
+ <listitem>
+ <para>
+ The amount of time before a missing out-of-order IP-TFS tunnel
+ packet is considered lost. See also
+ <option>iptfs-reorder-window</option>.
+ </para>
+ <para>
+ The default is 1s. The default time unit is seconds (see
+ <replaceable>duration</replaceable>).
+ </para>
+ </listitem>
+</varlistentry>
+<varlistentry>
+ <term><option>iptfs-init-delay=<replaceable>duration</replaceable></option></term>
+ <listitem>
+ <para>
+ The amount of time prior to servicing the output queue after
+ queueing the first packet on said queue.
+ </para>
+ <para>
+ The default is 0s. The default time unit is seconds (see
+ <replaceable>duration</replaceable>).
+ </para>
+ </listitem>
+</varlistentry>
+<varlistentry>
+ <term><option>iptfs-reorder-window</option></term>
+ <listitem>
+ <para>
+ The default IP-TFS reorder window size. The reorder window size
+ dictates the maximum number of IP-TFS tunnel packets in a
+ sequence that may arrive out of order.
+ </para>
+ <para>
+ Default 3.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>keyexchange</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to use IKEv2 (RFC 7296) or IKEv1 (RFC 4301). Currently the
+ accepted values are <option>ikev2</option> (the default) and
+ <option>ikev1</option>.
+ </para>
+ <para>
+ This option replaces ikev2=yes|no. Old values yes, propose and instist
+ all map to keyexchange=ikev2. Values no and permit are map to
+ keyexchange=ikev1.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>mark-in</option>
+ </term>
+ <listitem>
+ <para>
+ The same as <option>mark</option>, but mark-in only applies to
+ the inbound half of the IPsec SA. It overrides any mark=
+ setting.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>mark-out</option>
+ </term>
+ <listitem>
+ <para>
+ The same as <option>mark</option>, but mark-out only applies to
+ the outbound half of the IPsec SA. It overrides any mark=
+ setting.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>mark</option>
+ </term>
+ <listitem>
+ <para>
+ If set, the MARK to set for the IPsec SA of this connection. The
+ format of a CONNMARK is <option>mark/mask</option>. If the mask
+ is left out, a default mask of 0xffffffff is used. A mark value
+ of -1 means to assign a new global unique mark number for each
+ instance of the connection. Global marks start at 1001. This
+ option is only available on linux XFRM kernels. It can be used
+ with iptables to create custom iptables rules using CONNMARK. It
+ can also be used with Virtual Tunnel Interfaces ("VTI") to
+ direct marked traffic to specific vtiXX devices.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>metric</option>
+ </term>
+ <listitem>
+ <para>
+ Set the metric for added routes. This value is passed to the
+ <command>ipsec _updown</command> scripts as
+ <envar>PLUTO_METRIC</envar> (see &ipsec-updown.8;).
+ </para>
+ <para>
+ Acceptable values are positive numbers, with the default being
+ <option>1</option>.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>mobike</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to allow MOBIKE (RFC 4555) to enable a connection to
+ migrate its endpoint without needing to restart the connection
+ from scratch. This is used on mobile devices that switch between
+ wired, wireless or mobile data connections. Current values are
+ <option>no</option> (the default) or <option>yes</option>, Only
+ connection acting as modecfgclient will allow the initiator to
+ migrate using mobike. Only connections acting as modecfgserver
+ will allow clients to migrate.
+ </para>
+ <para>
+ VTI and MOBIKE might not work well when used together.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftmodecfgclient</option>
+ </term>
+ <term>
+ <option>rightmodecfgclient</option>
+ </term>
+ <listitem>
+ <para>Left is a Mode Config client. It can receive network
+ configuration from the server. Acceptable values are
+ <option>yes</option> or <option>no</option> (the
+ default).</para>
+ </listitem>
+</varlistentry>
+
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>modecfgdns</option>
+ </term>
+ <term>
+ <option>modecfgdomains</option>
+ </term>
+ <term>
+ <option>modecfgbanner</option>
+ </term>
+ <listitem>
+ <para>
+ When configured as IKEv1 ModeCFG or IKEv2 server, specifying any
+ of these options will cause those options and values to be sent
+ to the connecting client. &Libreswan; as a client will use
+ these received options to either update /etc/resolv.conf or the
+ running unbound DNS server. When the connection is brought down,
+ the previous DNS resolving state is restored.
+ </para>
+ <para>
+ The modecfgdns option takes a comma or space separated list of
+ IP addresses that can be used for DNS resolution. The
+ modecfgdomains option takes a comma or space separated list of
+ internal domain names that are reachable via the supplied
+ modecfgdns DNS servers.
+ </para>
+ <para>
+ The IKEv1 split tunnel directive will be sent automatically if
+ the xauth server side has configured a network other than
+ 0.0.0.0/0. For IKEv2, this is automated via narrowing.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>modecfgpull</option>
+ </term>
+ <listitem>
+ <para>
+ Pull the Mode Config network information from the server.
+ Both server and client must use same setting.
+ Acceptable values are <option>yes</option> or
+ <option>no</option> (the default).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftmodecfgserver</option>
+ </term>
+ <term>
+ <option>rightmodecfgserver</option>
+ </term>
+ <listitem>
+ <para>
+ Left is a Mode Config server. It can push network configuration
+ to the client. Acceptable values are <option>yes</option>
+ or <option>no</option> (the default).
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term><option>ms-dh-downgrade</option></term>
+ <listitem>
+ <para>
+ Whether to allow a downgrade of Diffie-Hellman group during
+ rekey (using CREATE_CHILD_SA).
+ </para>
+ <para>
+ Microsoft Windows (at the time of writing, Feb 2018) defaults to
+ using the very weak modp1024 (DH2). This can be changed using a
+ Windows registry setting to use modp2048 (DH14). However, at
+ rekey times, it will shamelessly use modp1024 again and the
+ connection might fail. Setting <option>ms-dh-downgrade=yes</option>
+ (and adding modp1024 proposals to the ike line) will allow this
+ downgrade attack to happen. This should only be used to support
+ Windows that feature this bug.
+ </para>
+ <para>
+ The accepted values are <option>no</option>, (the
+ default) or <option>yes</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>mtu</option>
+ </term>
+ <listitem>
+ <para>
+ Set the MTU for the route(s) to the remote endpoint and/or
+ subnets. This is sometimes required when the overhead of the
+ IPsec encapsulation would cause the packet the become too big
+ for a router on the path. Since IPsec cannot trust any
+ unauthenticated ICMP messages, PATH MTU discovery does not
+ work. This can also be needed when using "6to4" IPV6
+ deployments, which adds another header on the packet size.
+ </para>
+ <para>
+ Acceptable values are positive numbers. There is no default.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>narrowing</option>
+ </term>
+ <listitem>
+ <para>
+ IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options.
+ Currently the accepted values are <option>no</option>, (the
+ default) signifying no narrowing will be proposed or accepted,
+ or <option>yes</option>, signifying IKEv2 negotiation may allow
+ establishing an IPsec connection with narrowed down traffic
+ selectors. This option is ignored for IKEv1.
+ </para>
+ <para>
+ There are security implications in allowing narrowing down the
+ proposal. For one, what should be done with packets that we
+ hoped to tunnel, but cannot. Should these be dropped or send in
+ the clear? Second, this could cause thousands of narrowed down
+ Child SAs to be created if the conn has a broad policy (eg 0/0
+ to 0/0). One possible good use case scenario is that a remote
+ end (that you fully trust) allows you to define a 0/0 to them,
+ while adjusting what traffic you route via them, and what
+ traffic remains outside the tunnel. However, it is always
+ preferred to setup the exact tunnel policy you want, as this
+ will be much clearer to the user.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nat-ikev1-method</option>
+ </term>
+ <listitem>
+ <para>
+ NAT Traversal in IKEv1 is negotiated via Vendor ID options as
+ specified in RFC 3947. However, many implementations only
+ support the draft version of the RFC. &Libreswan; sends both the
+ RFC and the most common draft versions (02, 02_n and 03) to
+ maximize interoperability. Unfortunately, there are known
+ broken implementations of RFC 3947, notably Cisco routers that
+ have not been updated to the latest firmware. As the NAT-T
+ payload is sent in the very first packet of the initiator, there
+ is no method to auto-detect this problem and initiate a
+ workaround.
+ </para>
+ <para>
+ This option allows fine tuning which of the NAT-T payloads to
+ consider for sending and processing. Currently the accepted
+ values are <option>drafts</option>, <option>rfc</option>,
+ <option>both</option> (the default) and
+ <option>none</option>. To interoperate with known broken
+ devices, use nat-ikev1-method=drafts. To prevent the other end
+ from triggering IKEv1 NAT-T encapsulation, set this to
+ none. This will omit the NAT-T payloads used to determine NAT,
+ forcing the other end not to use encapsulation.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nat-keepalive</option>
+ </term>
+ <listitem>
+ <para>
+ whether to send any NAT-T keep-alives. These one byte packets
+ prevent the NAT router from closing its port when there is not
+ enough traffic on the IPsec connection. Acceptable values are:
+ <option>yes</option> (the default) and <option>no</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>negotiationshunt</option>
+ </term>
+ <listitem>
+ <para>
+ What to do with packets during the IKE negotiation. Valid
+ options are <option>hold</option> (the default) or
+ <option>pass</option>. This should almost always be left to the
+ default <option>hold</option> value to avoid cleartext packet
+ leaking. The only reason to set this to <option>pass</option> is
+ if plaintext service availability is more important than service
+ security or privacy, a scenario that also implies
+ <option>failureshunt=pass</option> and most likely
+ <option>authby=%null</option> using Opportunistic Encryption.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftnexthop</option>
+ </term>
+ <term>
+ <option>rightnexthop</option>
+ </term>
+ <listitem>
+ <para>
+ next-hop gateway IP address for the left participant's
+ connection to the public network; defaults to <option>%direct</option>
+ (meaning <option>right</option>). If the value is to be overridden
+ by the <option>left=%defaultroute</option> method
+ (see above), an explicit value must <option>not</option> be given.
+ If that method is not being used, but <option>leftnexthop</option> is
+ <option>%defaultroute</option>, the next-hop
+ gateway address of the default-route interface will be used.
+ The magic value <option>%direct</option> signifies
+ a value to be filled in (by automatic keying) with the peer's
+ address. Relevant only locally, other end need not agree on
+ it.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nflog-group</option>
+ </term>
+ <listitem>
+ <para>
+ If set, the NFLOG group number to log this connection's
+ pre-crypt and post-decrypt traffic to. The default value of
+ <option>0</option> means no logging at all. This option is only
+ available on linux kernel 2.6.14 and later. It allows common
+ network utilities such as tcpdump, wireshark and dumpcap, to use
+ nflog:XXX pseudo interfaces where XXX is the nflog group
+ number. During the updown phase of a connection, iptables will
+ be used to add and remove the source/destination pair to the
+ nflog group specified. The rules are setup with the
+ nflog-prefix matching the connection name. See also the global
+ <option>nflog-all</option> option.
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3, this option was called
+ <option>nflog</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nic-offload</option>
+ </term>
+ <listitem>
+ <para>
+ Set the method of Network Interface Controller (NIC) hardware
+ offload for ESP/AH packet processing. Acceptable values are
+ <option>no</option> (the default),
+ <option>crypto</option> or <option>packet</option>. The
+ value <option>yes</option> is a backwards compatible value
+ for <option>crypto</option>. The nic-offload option is
+ separate from any CPU hardware offload available. When set to
+ <option>crypto</option>, only cryptographic operations are
+ offloaded to the NIC card. When set to
+ <option>packet</option>, the entire packet processing
+ including the encryption/decryption is offloaded to the NIC
+ card.
+ </para>
+ <para>
+ Crypto nic-offload is available starting Linux 4.13 using the
+ XFRM IPsec stack. Packet nic-offload is available starting
+ Linux 6.3. Both require that the Linux kernel is compiled with
+ the options CONFIG_XFRM_OFFLOAD, CONFIG_INET_ESP_OFFLOAD and
+ CONFIG_INET6_ESP_OFFLOAD. Network card support can be seen by
+ the presence of the <option>esp-hw-offload</option>
+ capability using the <option>ethtool -S</option> command.
+ The Linux kernel attempts to fall back from crypto hardware
+ offload to software, but only for some algorithms (AEADs only?).
+ There is no fallback from packet offload to crypto offload. At
+ the time of libreswan 5.0, we are only aware of the
+ Nvidia/Mellanox ConnectX-7 (and to some extend ConnectX-6) cards
+ supporting packet offload.
+ </para>
+ <para>
+ In general, it makes no sense to try to offload older (non-AEAD)
+ cryptographic algorithms such as AES-CBC or 3DES, as these
+ algorithms are so much slower than AEAD algorithms (such as
+ AES-GCM) that one would gain more performance by switching the
+ algorithm to AEAD than by offloading. As such, AES-CBC tends to
+ not be implemented in offload hardware. This option has also no
+ effect on IKE packets, which are never offloaded, although IKE
+ encryption does use supported CPU hardware instructions, such as
+ AESNI.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nm-configured</option>
+ </term>
+ <listitem>
+ <para>
+ Mark this connection as controlled by Network Manager.
+ Acceptable values are <option>yes</option> or
+ <option>no</option> (the default). Currently, setting this to
+ yes will cause libreswan to skip reconfiguring resolv.conf when
+ used with XAUTH and ModeConfig.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nopmtudisc</option>
+ </term>
+ <listitem>
+ <para>
+ Disable Path MTU discovery for the IPsec SA. Acceptable values
+ are <option>no</option> (the default) or <option>yes</option>.
+ Currently this feature is only implemented for the Linux XFRM
+ stack.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>overlapip</option>
+ </term>
+ <listitem>
+ <para>
+ a boolean (yes/no) that determines, when
+ (left|right)subnet=vhost: is used, if the virtual IP claimed by
+ this states created from this connection can with states created
+ from other connections.
+ </para>
+ <para>
+ Note that connection instances created by the Opportunistic
+ Encryption or PKIX (x.509) instantiation system are distinct
+ internally. They will inherit this policy bit.
+ </para>
+ <para>
+ The default is no.
+ </para>
+ <para>
+ This feature is only available with kernel drivers that support
+ SAs to overlapping conns. At present only the (klips) mast
+ protocol stack supports this feature.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>pam-authorize</option>
+ </term>
+ <listitem>
+ <para>
+ IKEv2 does not support receiving a plaintext username and
+ password. &Libreswan; does not yet support EAP authentication
+ methods for IKE. The pam-authorize=yes option performs an
+ authorization call via PAM, but only includes the remote ID (not
+ username or password). This allows for backends to disallow an
+ ID based on non-password situations, such as "user disabled" or
+ "user over quota".
+ </para>
+ <para>
+ See also the IKEv1 option <option>xauthby=pam</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>pfs</option>
+ </term>
+ <listitem>
+ <para>
+ whether Perfect Forward Secrecy of keys is desired on the
+ connection's keying channel (with PFS, penetration of the
+ key-exchange protocol does not compromise keys negotiated
+ earlier); Acceptable values are <option>yes</option> (the
+ default) and <option>no</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>phase2</option>
+ </term>
+ <listitem>
+ <para>
+ Sets the type of SA that will be produced. Valid options are:
+ <option>esp</option> for encryption (the default),
+ <option>ah</option> for authentication only.
+ </para>
+ <para>
+ The very first IPsec designs called for use of AH plus ESP to
+ offer authentication, integrity and confidentiality. That dual
+ protocol use was a significant burden, so ESP was extended to
+ offer all three services, and AH remained as an auth/integ. The
+ old mode of <option>ah+esp</option> is no longer supported in
+ compliance with RFC 8221 Section 4. Additionally, AH does not
+ play well with NATs, so it is strongly recommended to use ESP
+ with the null cipher if you require unencrypted authenticated
+ transport.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>policy-label</option>
+ </term>
+ <listitem>
+ <para>
+ The string representation of an access control security label
+ that is interpreted by the Linux Security Module (e.g. SELinux)
+ for use with Labeled IPsec.
+ </para>
+ <para>
+ For example, <option>policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023</option>
+ </para>
+ <para>
+ Labeled IPsec support is IKEv2 only.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ppk-ids</option>
+ </term>
+ <listitem>
+ <para>
+ EXPERIMENTAL: Specify which PPK_ID's to look for in .secrets
+ file. The value must be a string (enclosed in quotes)
+ containing a comma-separated list with PPK_ID's. Whitespaces
+ cannot be a part of PPK_ID, i.e., they will be seen as a
+ delimiter. If some PPK_ID's are specified and PPK feature is
+ enabled (<option>ppk=</option>), one of the PPK secrets must
+ have an ID matching one of the specified PPK_ID's. If this
+ option is not set and the PPK feature is enabled, any matching
+ PPK secret will be used.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ppk</option>
+ </term>
+ <listitem>
+ <para>
+ EXPERIMENTAL: Post-quantum preshared keys (PPKs) to be
+ used. Currently the accepted values are <option>propose</option>
+ or <option>yes</option> (the default), signifying we propose to
+ use PPK for this connection; <option>insist</option>, signifying
+ we allow communication only if PPK is used for key derivation;
+ <option>never</option> or <option>no</option>, signifying that
+ PPK should not be used for key derivation. PPKs can be used in
+ connections that allow only IKEv2. In libreswan that would mean
+ that ikev2 option must have value <option>insist</option>. This
+ feature is based on RFC 8784.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>priority</option>
+ </term>
+ <listitem>
+ <para>
+ The priority in the kernel SPD/SAD database, when matching up
+ packets. Each kernel (XFRM, OSX, etc) has its own mechanism
+ for setting the priority. Setting this option to non-zero
+ passes the priority to the kernel stack unmodified. The
+ maximum value depends on the stack. It is recommended not to
+ exceed 65536
+ </para>
+ <para>
+ XFRM use a priority system based on "most specific match
+ first". It uses an internal algorithm to calculate these based
+ on network prefix length, protocol and port selectors. A lower
+ value means a higher priority.
+ </para>
+ <para>
+ Typical values are about the 2000 range. These can be seen on
+ the XFRM stack using <option>ip xfrm policy</option> when the
+ connection is up. For "anonymous IPsec" or Opportunistic
+ Encryption based connections, a much lower priority (65535) is
+ used to ensure administrator configured IPsec always takes
+ precedence over opportunistic IPsec.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftprotoport=&ip_protoport;</option>
+ </term>
+ <term>
+ <option>rightprotoport=&ip_protoport;</option>
+ </term>
+ <listitem>
+ <para>
+ allowed protocols and ports over connection, also called Port
+ Selectors. The argument is in the form <option>protocol</option>,
+ which can be a number or a name
+ that will be looked up in <option>/etc/protocols</option>,
+ such as <option>leftprotoport=icmp</option>, or in the form of
+ <option>protocol/port</option>, such as <option>tcp/smtp</option>.
+ Ports can be defined as a number
+ (eg. 25) or as a name (eg smtp) which will be looked up in
+ <option>/etc/services</option>. A special keyword
+ <option>%any</option> can be used to allow all
+ ports of a certain protocol. The most common use of this option
+ is for L2TP connections to only allow l2tp packets (UDP port
+ 1701), eg: <option>leftprotoport=17/1701</option>.
+ </para>
+
+ <para>
+ To filter on specific icmp type and code, use the higher 8 bits
+ for type and the lower 8 bits for port. For example, to allow
+ icmp echo packets (type 8, code 0) the 'port' would be 0x0800,
+ or 2048 in decimal, so you configure
+ <option>leftprotoport=icmp/2048</option>. Similarly, to
+ allow ipv6-icmp Neighbour Discovery which has type 136 (0x88)
+ and code 0(0x00) this becomes 0x8800 or in decimal 34816
+ resulting in <option>leftprotoport=ipv6-icmp/34816</option>.
+ </para>
+
+ <para>
+ Some clients, notably older Windows XP and some Mac OSX clients,
+ use a random high port as source port. In those cases
+ <option>rightprotoport=17/%any</option> can be used to allow all
+ UDP traffic on the connection. Note that this option is part of
+ the proposal, so it cannot be arbitrarily left out if one end
+ does not care about the traffic selection over this connection -
+ both peers have to agree. The Port Selectors show up in the
+ output of <command>ipsec status</command> eg:<option>"l2tp":
+ 193.110.157.131[@aivd.libreswan.org]:7/1701...%any:17/1701</option>.
+ This option only filters outbound traffic. Inbound traffic
+ selection must still be based on firewall rules activated by an
+ updown script. The environment variables
+ <envar>PLUTO_MY_PROTOCOL</envar>,
+ <envar>PLUTO_PEER_PROTOCOL</envar>,
+ <envar>PLUTO_MY_PORT</envar>, and <envar>PLUTO_PEER_PORT</envar>
+ are available for use in <command>ipsec _updown</command>
+ scripts (see &ipsec-updown.8;). Older workarounds for bugs
+ involved a setting of <option>17/0</option> to denote
+ <option>any single UDP port</option> (not UDP port 0). Some
+ clients, most notably OSX, uses a random high port, instead of
+ port 1701 for L2TP.
+ </para>
+
+ <important>
+ <title>
+ Use with <option>leftsubnet=</option>.
+ </title>
+ <para>
+ With IKEv2, the <option>leftsubnet=</option> specification can
+ include the protocol and port. Combining that syntax with
+ <option>protoport=</option> is not supported.
+ </para>
+ </important>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>redirect-to</option>
+ </term>
+ <listitem>
+ <para>
+ Where to send remote peers to via the
+ <option>send-redirect</option> option. This can be an IP address
+ or hostname (FQDN).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>reject-simultaneous-ike-auth</option>
+ </term>
+ <listitem>
+
+ <para>
+ When libreswan receives IKE_AUTH request from the peer while having
+ an outstanding IKE_AUTH request for the same connection, reject with
+ AUTHENTICATION_FAILED to avoid potential SA mismatch issues. This only
+ applies to permanent IKEv2 connections so that the revival mechanism
+ ensures connection retry.
+ </para>
+
+ <para>
+ The accepted values are <option>yes</option> (the default) or
+ <option>no</option>.
+ </para>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>rekey</option>
+ </term>
+ <listitem>
+ <para>
+ whether a connection should be renegotiated when it is about to
+ expire; acceptable values are <option>yes</option> (the default)
+ and <option>no</option>. The two ends need not agree, but while
+ a value of <option>no</option> prevents Pluto from requesting
+ renegotiation, it does not prevent responding to renegotiation
+ requested from the other end, so <option>no</option> will be
+ largely ineffective unless both ends agree on it.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>rekeyfuzz</option>
+ </term>
+ <listitem>
+ <para>
+ maximum percentage by which <option>rekeymargin</option> should
+ be randomly increased to randomize rekeying intervals (important
+ for hosts with many connections); acceptable values are an
+ integer, which may exceed 100, followed by a `%' (default set by
+ &ipsec-pluto.8;,
+ currently <option>100%</option>). The value of
+ <option>rekeymargin</option>, after this random increase, must
+ not exceed <option>salifetime</option>. The value
+ <option>0%</option> will suppress time randomization. Relevant
+ only locally, other end need not agree on it.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>rekeymargin</option>
+ </term>
+ <listitem>
+ <para>
+ how long before connection expiry or keying-channel expiry
+ should attempts to negotiate a replacement begin; acceptable
+ values as for <option>salifetime</option> (default
+ <option>9m</option>). Relevant only locally, other end need not
+ agree on it.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>remote-peer-type</option>
+ </term>
+ <listitem>
+ <para>
+ Set the remote peer type. This can enable additional processing
+ during the IKEv1 negotiation. Acceptable values are
+ <option>cisco</option> or <option>ietf</option> (the
+ default). When set to cisco, support for Cisco IPsec gateway
+ redirection and Cisco obtained DNS and domainname are
+ enabled. This includes automatically updating (and restoring)
+ /etc/resolv.conf. These options require that XAUTH is also
+ enabled on this connection.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>replay-window</option>
+ </term>
+ <listitem>
+ <para>
+ The size of the IPsec SA replay window protection in packets.
+ Kernels (Linux, and most BSDs) support a window size of at least
+ 2040 packets. The default replay window size is 128 packets.
+ </para>
+ <para>
+ A value of 0 disables replay protection. Disabling of replay
+ protection is sometimes used on a pair of IPsec servers in a
+ High Availability setup, or on servers with very unpredictable
+ latency, such as mobile networks, which can cause an excessive
+ amount of out of order packets.
+ </para>
+ <para>
+ Disabling replay protection will also disable Extended Sequence
+ Numbers (esn=no), as advise from RFC 4303 caused some stacks to
+ not support ESN without a replay-window.
+ </para>
+ <para>
+ Note: on Linux, sequence errors can be seen in
+ /proc/net/xfrm_stat.
+ </para>
+ <para>
+ Note: the BSD <option>setkey</option> utility displays the
+ replay window size in bytes (8 packets per byte) and not
+ packets.
+ </para>
+ <para>
+ Technically, at least the Linux kernel can install IPsec SA's
+ with an IPsec SA Sequence Number, but this is currently not
+ supported by libreswan.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>reqid</option>
+ </term>
+ <listitem>
+ <para>
+ a unique identifier used to match IPsec SAs using iptables with
+ XFRM. This identifier is normally automatically allocated in
+ groups of 4. It is exported to the _updown script as REQID. On
+ Linux, reqids are supported with IP Connection Tracking and NAT
+ (iptables). Automatically generated values use the range 16380
+ and higher. Manually specified reqid values therefore must be
+ between 1 and 16379.
+ </para>
+ <para>
+ Automatically generated reqids use a range of 0-3 (eg 16380-16383 for the
+ first reqid). These are used depending on the exact policy (AH, AH+ESP,
+ IPCOMP, etc).
+ </para>
+ <para>
+ WARNING: Manually assigned reqids are all
+ identical. Instantiations of connections (those using %any
+ wildcards) will all use the same reqid. If you use manual
+ assigning you should make sure your connections only match
+ single road warrior only or you break multiple road warriors
+ behind same NAT router because this feature requires unique
+ reqids to work.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>require-id-on-certificate</option>
+ </term>
+ <listitem>
+ <para>
+ When using certificates, check whether the IKE peer ID is
+ present as a subjectAltName (SAN) on the peer
+ certificate. Accepted values are <option>yes</option> (the
+ default) or <option>no</option>. This check should only be
+ disabled when intentionally using certificates that do not have
+ their peer ID specified as a SAN on the certificate. These
+ certificates violate RFC 4945 Section 3.1 and are normally
+ rejected to prevent a compromised host from assuming the IKE
+ identity of another host. The SAN limits the IDs that the peer
+ is able to assume.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>retransmit-interval</option>
+ </term>
+ <listitem>
+ <para>
+ the initial interval time period, specified in msecs, that pluto
+ waits before retransmitting an IKE packet. This interval is
+ doubled for each attempt (exponential back-off). The default
+ set by
+ &ipsec-pluto.8;,
+ currently is <option>500</option>.
+ </para>
+ <para>
+ See also: <option>retransmit-timeout</option> and
+ <option>rekey</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>retransmit-timeout</option>
+ </term>
+ <listitem>
+ <para>
+ how long a single packet, including retransmits of that packet,
+ may take before the IKE attempt is aborted. If rekeying is
+ enabled, a new IKE attempt is started. The default set by
+ &ipsec-pluto.8;, currently is <option>60s</option>.
+ </para>
+ <para>
+ See also: <option>retransmit-interval</option> and
+ <option>rekey</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftrsasigkey</option>
+ </term>
+ <term>
+ <option>rightrsasigkey</option>
+ </term>
+ <listitem>
+ <para>
+ the left participant's public key for RSA signature
+ authentication, in base-64 encoded RFC 2537 format (with 0s
+ prepended), or one of the following:
+ <variablelist>
+ <varlistentry>
+ <term>
+ <option>%none</option>
+ </term>
+ <listitem>
+ <para>
+ the same as not specifying a value (useful to override a
+ default)
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>%dnsondemand</option>
+ </term>
+ <listitem>
+ <para>
+ (the default) the key is to be fetched from DNS at the
+ time it is needed.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>%dnsonload</option>
+ </term>
+ <listitem>
+ <para>
+ the key is to be fetched from DNS at the time the
+ connection description is read from
+ <option>ipsec.conf</option>; currently this will be
+ treated as <option>%none</option> if
+ <option>right=%any</option> or
+ <option>right=%opportunistic</option>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>%dns</option>
+ </term>
+ <listitem>
+ <para>
+ currently treated as <option>%dnsonload</option> but
+ will change to <option>%dnsondemand</option> in the
+ future. The identity used for the left participant must
+ be a specific host, not <option>%any</option> or
+ another magic value.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>%cert</option>
+ </term>
+ <listitem>
+ <para>
+ the information required from a certificate defined in
+ <option>%leftcert</option> and automatically define
+ leftid for you
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ <caution>
+ <para>
+ If two connection descriptions specify different public keys
+ for the same <option>leftid</option>, confusion and
+ madness will ensue.
+ </para>
+ </caution>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>salifetime</option>
+ </term>
+ <listitem>
+ <para>
+ how long a particular instance of a connection (a set of
+ encryption/authentication keys for user packets) should last,
+ from successful negotiation to expiry; acceptable values are an
+ integer optionally followed by <option>s</option> (a time in
+ seconds) or a decimal number followed by <option>m</option>,
+ <option>h</option>, or <option>d</option> (a time in minutes,
+ hours, or days respectively) (default <option>8h</option>,
+ maximum <option>24h</option>). Normally, the connection is
+ renegotiated (via the keying channel) before it expires. The
+ two ends need not exactly agree on <option>salifetime</option>,
+ although if they do not, there will be some clutter of
+ superseded connections on the end which thinks the lifetime is
+ longer.
+ </para>
+ <para>
+ The keywords "keylife" and "lifetime" are obsoleted aliases for
+ "salifetime." Change your configs to use "salifetime" instead.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term><option>send-no-esp-tfc</option></term>
+ <listitem>
+ <para>
+ Whether or not to tell the remote peer that we do not support Traffic Flow Confidentiality ("TFC")
+ (RFC-4303). Possible values are <option>no</option> (the default) which allows the
+ peer to use TFC or <option>yes</option> which prevents to peer from using TFC.
+ This does not affect whether this endpoint uses TFC, which only depends on the
+ local <option>tfc</option> setting. This option is only valid for IKEv2.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>send-redirect</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to send requests for the remote peer to redirect
+ IKE/IPsec SA's during IKE_AUTH. Valid options are
+ <option>no</option> (the default) and <option>yes</option>. If
+ set, the option <option>redirect-to=</option> must also be set
+ to indicate where to redirect peers to. For redirection during
+ IKE_SA_INIT exchange, see the <option>global-redirect=</option>
+ and <option>global-redirect-to=</option> options. Runtime
+ redirects can be triggered via the <command>ipsec
+ redirect</command> command.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>send-vendorid</option>&yN_options;
+ </term>
+ <listitem>
+ <para>
+ whether to send our Vendor ID during IKE. Acceptable values
+ are: <option>no</option> (the default) and
+ <option>yes</option>. The vendor id sent can be configured using
+ the "config setup" option <option>myvendorid=</option>. It
+ defaults to OE-Libreswan-VERSION.
+ </para>
+ <para>
+ Vendor ID's can be useful in tracking interoperability
+ problems. However, specific vendor identification and software
+ versions can be useful to an attacker when there are known
+ vulnerabilities to a specific vendor/version.
+ </para>
+ <para>
+ The prefix OE stands for "Opportunistic Encryption". This prefix
+ was historically used by The FreeS/WAN Project and The Openswan
+ Project (openswan up to version 2.6.38) and in one Xeleranized
+ openswan versions (2.6.39). Further Xeleranized openswan's use
+ the prefix OSW.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>sendca</option>
+ </term>
+ <listitem>
+ <para>
+ How many of the available X.509 intermediate CA certificates to
+ send with the End certificate (root CA's are never sent).
+ Specifying <option>none</option> sends no intermediate
+ certificates, <option>issuer</option> sends the End
+ certificate's issuing intermediate CA, and <option>all</option>
+ sends all intermediate CAs (the default).
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3, the default was
+ <option>none</option> (that is, no intermediate CAs were sent).
+ &Libreswan; never sends intermediate certificates when
+ establishing a connection using IKEv1's Agressive Mode.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftsendcert</option>
+ </term>
+ <term>
+ <option>rightsendcert</option>
+ </term>
+ <listitem>
+ <para>
+ This option configures when &Libreswan; will send &X.509;
+ certificates to the remote host. Acceptable values are:
+
+ <variablelist spacing="compact">
+
+ <varlistentry>
+ <term><option>yes</option></term>
+ <term><option>always</option></term>
+ <listitem><para>always send a certificate</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>sendifasked</option></term>
+ <listitem><para>send a certificate when the peer asks for it
+ (for instance by sending a CERTREQ
+ payload)</para></listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><option>no</option></term>
+ <term><option>never</option></term>
+ <listitem><para>never send a certificate</para></listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ The default for this option is <option>always</option>. Note
+ that while <option>always</option> is suboptimal, setting this
+ to <option>sendifasked</option> may break compatibility with
+ other vendor's IPsec implementations, such as &Cisco;. If you
+ find that you are getting errors about no ID/Key found, you
+ likely need to revert this option to <option>always</option>.
+ </para>
+
+ <para>
+ This option was added in &Libreswan; 2.5.14; in &Libreswan;
+ 2.28, the default was changed from <option>sendifasked</option>
+ to <option>always</option>; and in &Libreswan; 3.0, the related
+ and obsolete global option <option>nocrsend=</option> was
+ removed.
+ </para>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>sha2-truncbug</option>
+ </term>
+ <listitem>
+ <para>
+ The default ESP hash truncation for sha2_256 is 128 bits. Some
+ IPsec implementations (Linux before 2.6.33, some Cisco (2811?)
+ routers) implement the draft version which stated 96 bits. If a
+ draft implementation communicates with an RFC implementation,
+ both ends will reject encrypted packets from each other.
+ </para>
+ <para>
+ This option enables using the draft 96 bits version to interop
+ with those implementations. Currently the accepted values are
+ <option>no</option>, (the default) signifying default RFC
+ truncation of 128 bits, or <option>yes</option>, signifying the
+ draft 96 bits truncation.
+ </para>
+ <para>
+ Another workaround is to switch from sha2_256 to sha2_128 or
+ sha2_512.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>share-lease</option>
+ </term>
+ <listitem>
+ <para>
+ Whether multiple outoging IKEv1 connections that are not
+ specifying a local subnet should use the lease IP given by
+ the server of the first connection. The default and expected
+ behaviour (of emulating a Cisco client) is <option>yes</option>.
+ It can be disabled by setting it to <option>no</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftsourceip</option>
+ </term>
+ <term>
+ <option>rightsourceip</option>
+ </term>
+ <listitem>
+ <para>
+ the IP address for this host to use when transmitting a packet
+ to the other side of this link. Relevant only locally, the
+ other end need not agree. This option is used to make the
+ gateway itself use its internal IP, which is part of the
+ leftsubnet, to communicate to the rightsubnet or
+ right. Otherwise, it will use its <option>nearest</option> IP
+ address, which is its public IP address. This option is mostly
+ used when defining subnet-subnet connections, so that the
+ gateways can talk to each other and the subnet at the other end,
+ without the need to build additional host-subnet, subnet-host
+ and host-host tunnels. Both IPv4 and IPv6 addresses are
+ supported.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftsubnet=&ip_selector;[,...]</option>
+ </term>
+ <term>
+ <option>rightsubnet=&ip_selector;[,...]</option>
+ </term>
+ <listitem>
+ <para>
+ A comma separated list of traffic selectors behind the
+ <option>left</option> or <option>right</option> participant.
+ </para>
+ <para>
+ Each traffic selector expressed as: <systemitem
+ class="ipaddress"> <replaceable>network-prefix</replaceable> /
+ <replaceable>netmask</replaceable>/
+ <replaceable>protocol</replaceable>/
+ <replaceable>port</replaceable> </systemitem> where trailing
+ elements may be omitted. For instance:
+ <code>leftsubnet=1.2.3.0/24,1:2::/64</code>,
+ <code>leftsubnet=1.2.3.4/32/tcp,1:2::/128/tcp</code>,
+ <code>leftsubnet=1.2.3.4/31/tcp/22,1:2::/128/tcp/22</code>.
+ </para>
+ <para>
+ If both <code>leftsubnet=</code> and <code>rightsubnet=</code>
+ are specified, all combinations will be established as a single
+ IPsec tunnel.
+ </para>
+ <para>
+ When omitted, essentially assumed to be <code>left</code>,
+ signifying that the left end of the connection goes to the left
+ participant only.
+ </para>
+
+ <note>
+ <para>
+ Support for specifying multiple selectors and the protocol and
+ port was added in &Libreswan; version 5.
+ </para>
+ </note>
+
+ <important>
+ <title>
+ IKEv1
+ </title>
+ <para>
+ In IKEv1 only a single selector is allowed and it is limited
+ to specifying a subnet as in: <code>
+ <replaceable>network</replaceable> /
+ <replaceable>netmask</replaceable> </code>
+ </para>
+ </important>
+
+ <important>
+ <title>
+ IKEv1
+ </title>
+ <para>
+ IKEv1 supports two magic shorthands <code>vhost:</code> and
+ <code>vnet:</code>, which can list subnets in the same syntax
+ as <replaceable>virtual-private</replaceable>. The value
+ <code>%priv</code> expands to the networks specified in
+ <code>virtual-private</code>. The value <code>%no</code>
+ means no subnet. A common use for allowing roadwarriors to
+ come in on public IPs or via accepted NATed networks from
+ RFC1918 is to use <code>leftsubnet=vhost:%no,%priv</code>. The
+ <code>vnet:</code> option can be used to allow RFC1918 subnets
+ without hardcoding them. When using vnet the connection will
+ instantiate, allowing for multiple tunnels with different
+ subnets.
+ </para>
+ </important>
+
+ <important>
+ <title>
+ Use with <code>leftprotport</code> and
+ <code>leftsubnets</code>
+ </title>
+ <para>
+ Compatible with libreswan version 4, a simple
+ <code>leftsubnet</code> (specifying a single network prefix
+ and netmask) may be combined with <code>leftprotoport</code>
+ and <code>leftsubnets</code>. Anything more complicated
+ should be converted to use the selector syntax.
+ </para>
+ </important>
+
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftsubnets=&ip_subnet;[,...]</option>
+ </term>
+ <term>
+ <option>rightsubnets=&ip_subnet;[,...]</option>
+ </term>
+ <listitem>
+ <para>
+ Specify multiple private subnets behind the participant,
+ expressed as
+ <option>networkA</option><option>/</option><option>netmaskA</option>,<option>networkB</option><option>/</option><option>netmaskB</option><option>[,...]</option>.
+ If both a <option>leftsubnets=</option> and
+ <option>rightsubnets=</option> are defined, all combinations of
+ subnet tunnels will be established as separate IPsec tunnels.
+ You cannot use <option>leftsubnet=</option> and
+ <option>leftsubnets=</option> together. For examples see
+ <option>testing/pluto/multinet-*</option>. Be aware that when
+ using spaces as separator, that the entire option value needs to
+ be in double quotes.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>tcp-remoteport</option>
+ </term>
+ <listitem>
+ <para>
+ Which remote TCP port to use when IKE over TCP is attempted. The
+ default value is to use the NAT-T IKE port (4500). This value is
+ not negotiated and should be configured properly on all
+ endpoints. When opening a TCP socket to the remote host in this
+ port, a regular ephemeral source port is obtained from the
+ OS. For changing the UDP ports, see
+ <option>leftikeport=</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term><option>tfc</option></term>
+ <listitem>
+ <para>
+ Enable Traffic Flow Confidentiality ("TFC") (RFC-4303) for outgoing ESP
+ packets in Tunnel Mode. When enabled, ESP packets are padded to the
+ specified size (up to the PMTU size) to prevent leaking information based
+ on ESP packet size. This option is ignored for AH and for ESP in Transport
+ Mode as those always leak traffic characteristics and applying TFC will
+ not do anything. Acceptable values are positive numbers. The value 0 means
+ TFC padding is not performed. Currently this feature is only implemented
+ for the Linux XFRM stack. In IKEv2, when the notify payload
+ ESP_TFC_PADDING_NOT_SUPPORTED is received, TFC padding is disabled. The
+ default is not to do any TFC padding, but this might change in the near
+ future.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>type</option>
+ </term>
+ <listitem>
+ <para>
+ the type of the connection; currently the accepted values are
+ <option>tunnel</option> (the default) signifying a host-to-host,
+ host-to-subnet, or subnet-to-subnet tunnel;
+ <option>transport</option>, signifying host-to-host transport
+ mode; <option>passthrough</option>, signifying that no IPsec
+ processing should be done at all; <option>drop</option>,
+ signifying that packets should be discarded.
+ </para>
+ <para>
+ Historic Note: &KLIPS; supported the option
+ <option>reject</option> signifying that packets should be
+ discarded and a diagnostic ICMP returned. Support for &KLIPS;,
+ and this option, have been removed.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftupdown</option>
+ </term>
+ <term>
+ <option>rightupdown</option>
+ </term>
+ <listitem>
+ <para>
+ The script to run to adjust routing and/or firewalling when the
+ status of the connection changes (default <command>ipsec
+ _updown</command>). May include positional parameters separated
+ by white space (although this requires enclosing the whole
+ string in quotes); including shell metacharacters is unwise. An
+ example to enable routing when using the XFRM stack, one can
+ use:
+ </para>
+ <para>
+ <simplelist columns='1'>
+ <member><computeroutput>updown="ipsec _updown --route yes"</computeroutput></member>
+ </simplelist>
+ </para>
+ <para>
+ To disable calling an updown script, set it to the empty string,
+ eg leftupdown="" or leftupdown="%disabled".
+ </para>
+ <para>
+ Connections with <option>type=</option> set to
+ <option>passthrough</option>, <option>reject</option> or
+ <option>drop</option> never run <command>ipsec _updown</command>.
+ </para>
+ <para>
+ See &libreswan.7; for details.
+ </para>
+ <para>
+ Relevant only locally, other end need not agree on it.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftusername</option>
+ </term>
+ <term>
+ <option>rightusername</option>
+ </term>
+ <listitem>
+ <para>
+ The username associated with this connection. The username can
+ be the IKEv2 XAUTH username, a GSSAPI username or IKEv2 CP
+ username. For the XAUTH username, the XAUTH password can be
+ configured in the <option>ipsec.secrets</option> file. This
+ option was previously called leftxauthusername.</para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>vti-interface</option>
+ </term>
+ <listitem>
+ <para>
+ This option is deprecated. See <option>ipsec-interface</option>
+ instead.
+ </para>
+ <para>
+ This option is used to create "Routing based VPNs"
+ (as opposed to "Policy based VPNs"). It will create a new interface
+ that can be used to route traffic in for encryption/decryption. The Virtual
+ Tunnel Interface ("VTI") interface name is used to for all IPsec SA's created by
+ this connection. This requires that the connection also enables either
+ the <option>mark=</option> or <option>mark-in= /
+ mark-out-</option> option(s). All traffic marked with the proper MARKs
+ will be automatically encrypted if there is an IPsec SA policy covering the
+ source/destination traffic. Tools such as tcpdump and iptables can be
+ used on all cleartext pre-encrypt and post-decrypt traffic on the device.
+ See the libreswan wiki for example configurations that use VTI.
+ </para>
+ <para>
+ VTI interfaces are currently only supported on Linux with
+ XFRM. The _updown script handles certain Linux specific
+ interfaces settings required for proper functioning
+ (disable_policy, rp_filter, forwarding, etc). Interface names
+ are limited to 16 characters and may not allow all characters to
+ be used. If marking and <option>vti-routing=yes</option> is
+ used, no manual iptables should be required. However,
+ administrators can use the iptables mangle table to mark traffic
+ manually if desired.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>vti-routing</option>
+ </term>
+ <listitem>
+ <para>
+ Whether or not to add network rules or routes for IPsec
+ SA's to the respective VTI devices. Valid values are
+ <option>yes</option> (the default) or <option>no</option>.
+ When using "routing based VPNs" with a subnets policy of 0.0.0.0/0,
+ this setting needs to set to <option>no</option> to prevent
+ imploding the tunnel, and the administrator is expected to manually
+ add ip rules and ip routes to configure what traffic must be encrypted.
+ When set to <option>yes</option>, the _updown script will
+ automatically route the leftsubnet/rightsubnet traffic into the
+ VTI device specified with <option>vti-interface</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>vti-shared</option>
+ </term>
+ <listitem>
+ <para>
+ Whether or not the VTI device is shared amongst connections.
+ Valid values are <option>no</option> (the default) or
+ <option>yes</option>. When set to no, the VTI device is
+ automatically deleted if the connection is a single
+ non-instantiated connection. If a connection instantiates (eg
+ right=%any) then this option has no effect, as the VTI device is
+ not removed as it is shared with multiple roadwarriors.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftvti</option>
+ </term>
+ <term>
+ <option>rightvti</option>
+ </term>
+ <listitem>
+ <para>
+ the address/mask to configure on the VTI interface when
+ <option>vti-interface</option> is set. It takes the form of
+ <option>network</option><option>/</option><option>netmask</option>
+ Currently, IPv4 and IPv6 addresses with cidr netmask are
+ supported. This option is often used in combination with routed
+ based VPNs.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>xauthby</option>
+ </term>
+ <listitem>
+ <para>
+ When IKEv1 XAUTH support is available, set the method used by
+ XAUTH to authenticate the user with IKEv1. The currently
+ supported values are <option>file</option> (the default),
+ <option>pam</option> or <option>alwaysok</option>. The password
+ file is located at <option>/etc/ipsec.d/passwd</option>, and
+ follows a syntax similar to the Apache htpasswd file, except an
+ additional connection name argument (and optional static IP
+ address) are also present:
+ </para>
+ <para>
+ <option>username:password:conname:ipaddress</option>
+ </para>
+ <para>
+ For supported password hashing methods, see &crypt.3;. If pluto
+ is running in FIPS mode, some hash methods, such as MD5, might
+ not be available. Threads are used to launch an xauth
+ authentication helper for file as well as PAM methods.
+ </para>
+ <para>
+ The <option>alwaysok</option> should only be used if the XAUTH
+ user authentication is not really used, but is required for
+ interoperability, as it defeats the whole point of XAUTH which
+ is to rely on a secret only known by a human. See also
+ <option>pam-authorize=yes</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftxauthclient</option>
+ </term>
+ <term>
+ <option>rightxauthclient</option>
+ </term>
+ <listitem>
+ <para>
+ Left is an XAUTH client. The xauth connection will have to be
+ started interactively and cannot be configured using
+ <option>auto=start</option>. Instead, it has to be started from
+ the commandline using <command>ipsec up
+ <replaceable>connection</replaceable></command>. You will then
+ be prompted for the username and password. To setup an XAUTH
+ connection non-interactively, which defeats the whole purpose of
+ XAUTH, but is regularly requested by users, it is possible to
+ use a whack command - <command>ipsec whack --name baduser
+ --ipsecgroup-xauth --xauthname badusername --xauthpass password
+ --initiate</command> The other side of the connection should be
+ configured as <option>rightxauthserver</option>. Acceptable
+ values are <option>yes</option> or <option>no</option> (the
+ default).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>xauthfail</option>
+ </term>
+ <listitem>
+ <para>
+ When XAUTH support is available, set the failure method desired
+ when authentication has failed. The currently supported values
+ are <option>hard</option> (the default) and
+ <option>soft</option>. A soft failure means the IPsec SA is
+ allowed to be established, as if authentication had passed
+ successfully, but the XAUTH_FAILED environment variable will be
+ set to 1 for the updown script, which can then be used to
+ redirect the user into a walled garden, for example a payment
+ portal.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>leftxauthserver</option>
+ </term>
+ <term>
+ <option>rightxauthserver</option>
+ </term>
+ <listitem>
+ <para>
+ Left is an XAUTH server. This can use PAM for authentication or
+ md5 passwords in <option>/etc/ipsec.d/passwd</option>. These are
+ additional credentials to verify the user identity, and should
+ not be confused with the XAUTH <option>group secret</option>,
+ which is just a regular PSK defined in
+ <option>ipsec.secrets</option>. The other side of the
+ connection should be configured as
+ <option>rightxauthclient</option>. XAUTH connections cannot
+ rekey, so <option>rekey=no</option> should be specified in this
+ conn. For further details on how to compile and use XAUTH, see
+ README.XAUTH. Acceptable values are <option>yes</option> or
+ <option>no</option> (the default).
+ </para>
+ </listitem>
+</varlistentry>
+++ /dev/null
-<refsect1 id='description'>
-
- <title>
- DESCRIPTION
- </title>
-
- <para>
- The <filename>ipsec.conf</filename> file specifies most
- configuration and control information for the &Libreswan; IPsec
- subsystem (the major exception is secrets for authentication; see
- &ipsec.secrets.5;). &Libreswan; reads this file during start up
- (technically, if &Libreswan;'s daemon &ipsec-pluto.8; is invoked
- directly then the file <filename>ipsec.conf</filename> is not
- needed; however, this is not recommended). Configurations can be
- added using eithe this configuration file or by using
- <command>ipsec whack</command> directly.
- </para>
-
- <para>
- <filename>ipsec.conf</filename> is a text file, consisting of one
- or more <option>sections</option>.
- </para>
-
- <para>
- Within the file, white space followed by <option>#</option>
- followed by anything to the end of the line is a comment and is
- ignored, as are empty lines that are not within a section.
- </para>
-
- <para>
- A line that contains <option>include</option> and a file name,
- separated by white space, is replaced by the contents of that
- file. If the file name is not a full pathname, it is considered
- to be relative to the directory that contains the including file.
- Such inclusions can be nested. Only a single filename may be
- supplied, and it may not contain white space, but it may include
- shell wildcards (see &glob.3;); for example:
- </para>
-
- <para>
- <option>include</option> <filename>/etc/ipsec.d/*.conf</filename>
- </para>
-
- <para>
- The intention of the include facility is mostly to permit keeping
- information on connections, or sets of connections, separate from
- the main configuration file. This permits such connection
- descriptions to be changed, copied to the other security gateways
- involved, etc., without having to constantly extract them from the
- configuration file and then insert them back into it. Note also
- the <option>also</option> parameters (described below) which
- permit splitting a single logical section (e.g. a connection
- description) into several distinct sections.
- </para>
-
- <para>
- The first significant line of the file may specify a version of
- this specification for backwards compatibility with freeswan and
- openswan. It is ignored and unused. For compatibility with
- openswan, specify:
- </para>
-
- <para>
- <option>version 2</option>
- </para>
-
- <para>
- A section begins with a line of the form:
- </para>
-
- <para>
- <replaceable>type</replaceable> <replaceable>name</replaceable>
- </para>
-
- <para>
- where <replaceable>type</replaceable> indicates what type of
- section follows, and <replaceable>name</replaceable> is an
- arbitrary name that distinguishes the section from others of the
- same type. Names must start with a letter and may contain only
- letters, digits, periods, underscores, and hyphens. All
- subsequent non-empty lines that begin with white space are part of
- the section; comments within a section must begin with white space
- too. There may be only one section of a given type with a given
- name.
- </para>
-
- <para>
- There are two types of section: a <option>config</option>
- section specifies general configuration information for
- &Libreswan;, and a
- <option>conn</option> section specifies an IPsec connection.
- </para>
-
- <para>
- Lines within the section are generally of the form
- </para>
-
- <para>
- <replaceable>parameter</replaceable>=<replaceable>value</replaceable>
- </para>
-
- <para>
- (note the mandatory preceding white space). There can be white
- space on either side of the <option>=</option>. Parameter
- names follow the same syntax as section names, and are specific to
- a section type. Unless otherwise explicitly specified, no
- parameter name may appear more than once in a section.
- </para>
-
- <para>
- An empty <replaceable>value</replaceable> stands for the empty
- string. A non-empty <replaceable>value</replaceable> may contain
- white space only if the entire <replaceable>value</replaceable> is
- enclosed in double quotes (<option>"</option>); a
- <replaceable>value</replaceable> cannot itself contain a double
- quote, nor may it be continued across more than one line.
- </para>
-
- <para>
- Numeric values are specified to be either an integer (a sequence
- of digits) or a decimal number (sequence of digits optionally
- followed by `.' and another sequence of digits).
- </para>
-
- <para>
- There is currently one parameter that is available in any type of
- section:
- </para>
-
- <variablelist>
- <varlistentry>
- <term><option>also=<replaceable>value</replaceable></option></term>
- <listitem>
- <para>
- The <replaceable>value</replaceable> is a section name. The
- parameters of that section are inserted, in place, into this
- section (i.e., as if they had been written as part of and at
- that point in the section's definition). The specified
- section must exist, and must have the same section type.
- Multiple and nested <option>also</option> are permitted
- (duplicate insertions of the same section are ignored).
- When the same <option>parameter</option> appears in
- multiple sections, the first definition encountered is used.
- This allows, for example, keeping the encryption keys for a
- connection in a separate file from the rest of the
- description, by using both an <option>also</option> parameter
- and an <option>include</option> line.
- </para>
- <para>
- Putting <option>also</option> at the end of the section after
- any <option>parameter</option> definitions is
- recommended. This way, the section's
- <option>parameter</option>
- <replaceable>value</replaceable> overrides
- <option>also</option> sections.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- A section with name <option>%default</option> specifies
- defaults for sections of the same type. For each parameter in it,
- any section of that type that does not have a parameter of the
- same name gets a copy of the one from the
- <option>%default</option> section. There may be multiple
- <option>%default</option> sections of a given type and
- multiple default values for a given parameter (the last
- <option>value</option> is used).
- <option>%default</option> sections may not contain any
- <option>also</option> parameters.
- </para>
-
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>crl-strict=</option>
- </term>
- <listitem>
- <para>
- if not set, pluto is tolerant about missing or expired X.509
- Certificate Revocation Lists (CRL's), and will allow peer
- certificates as long as they do not appear on an expired CRL.
- When this option is enabled, all connections with an expired or
- missing CRL will be denied. Active connections will be
- terminated at rekey time. This setup is more secure, but
- vulnerable to downtime if the CRL expires. Acceptable values
- are <option>yes</option> or <option>no</option> (the default).
- </para>
- <para>
- This option used to be called <option>strictcrlpolicy</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term><option>crl-timeout</option></term>
- <listitem>
- <para>
- The timeout for used when fetching CRLs. The default is 5s.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>crlcheckinterval</option>
- </term>
- <listitem>
- <para>
- interval expressed in second units, for example
- crlcheckinterval=8h for 8 hours, after which pluto will fetch
- new Certificate Revocation List (CRL) from crl distribution
- points. List of used CRL distribution points are collected from
- CA certificates and end certificates. Loaded X.509 CRL's are
- verified to be valid and updates are imported to NSS database.
- If set to <option>0</option>, which is also the
- default value if this option is not specified, CRL updating is
- disabled.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>curl-iface</option>
- </term>
- <listitem>
- <para>
- The name of the interface that is used for CURL lookups. This is
- needed on rare situations where the interface needs to be forced
- to be different from the default interface used based on the
- routing table.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ddos-ike-threshold</option>
- </term>
- <listitem>
- <para>
- The number of half-open IKE SAs before the pluto IKE daemon will
- be placed in busy mode. When in busy mode, pluto activates
- anti-DDoS counter measures. The default is 25000. See also
- <option>ddos-mode</option> and <command>ipsec whack
- --ddos-XXX</command>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ddos-mode</option>
- </term>
- <listitem>
- <para>
- The startup mode of the DDoS defense mechanism. Acceptable
- values are <option>busy</option>, <option>unlimited</option>
- or <option>auto</option> (the default). This option can also be
- given to the IKE daemon while running, for example by issuing
- <command>ipsec whack --ddos--busy</command>. When
- in busy mode, pluto activates anti-DDoS counter
- measures. Currently, counter measures consist of requiring IKEv2
- anti-DDoS cookies on new incoming IKE requests, and a more
- aggressive cleanup of partially established or AUTH_NULL
- connections.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>debug=<replaceable>option</replaceable></option>
- </term>
- <listitem>
- <para>
- A comma separated list of options that enable internal debug
- logs of the connection. For more information see the global
- <option>plutodebug=</option> option.
- </para>
- <note>
- <para>
- This feature is used by &Libreswan;
- developers. The default logs should provide sufficient
- information to diagnose configuration and connection problems.
- </para>
- </note>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>decap-dscp</option>
- </term>
- <listitem>
- <para>
- Enable decapsulating the Differentiated Services Code Point
- (DSCP, formerly known as Terms Of Service (TOS)) bits. If these
- bits are set on the inner (encrypted) IP packets, these bits are
- set on the decrypted IP packets. Acceptable values are
- <option>no</option> (the default) or <option>yes</option>.
- Currently this feature is only implemented for the Linux XFRM stack.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='default_policy_groups'>
- <title>
- DEFAULT POLICY GROUPS
- </title>
- <para>
- The standard &Libreswan; install includes several policy groups
- which provide a way of classifying possible peers into IPsec
- security classes: <option>private</option> (talk encrypted only),
- <option>private-or-clear</option> (prefer encryption),
- <option>clear-or-private</option> (respond to requests for
- encryption), <option>clear</option> and <option>block</option>.
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dns-match-id</option>
- </term>
- <listitem>
- <para>
- Whether to perform an additional DNS lookup and confirm the
- remote ID payload with the DNS name in the reverse DNS PTR
- record. Accepted values are <option>no</option> (the default) or
- <option>yes</option>. This check should be enabled when
- Opportunistic IPsec is enabled in a mode that is based on packet
- triggers (on-demand) using IPSECKEY records in DNS. Since in
- that case the IKE daemon pluto does not know the remote ID, it
- only knows the remote IP address, this option forces it to
- confirm the peer's proposed ID (and thus its public/private key)
- with its actual IP address as listed in the DNS. This prevents
- attacks where mail.example.com's IP address is taken over by a
- neighbour machine with a valid web.example.com setup. This check
- is not needed for certificate based Opportunistic IPsec, as
- "mail.example.com"s certificate does not have an entry for
- "web.example.com". It is also not needed for DNS server
- triggered Opportunistic IPsec, as in that case the IKE daemon
- pluto is informed of both the IP address, and the
- hostname/public key.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dns-resolver=</option>
- </term>
- <listitem>
- <para>
- The DNS resolver to be configured by &ipsec-updown.8;. Both
- <parameter>file</parameter>
- (<filename>/etc/resolve.conf</filename>)
- <parameter>systemd</parameter>
- (<command>systemd-resolved</command> are recognized. The
- configured value is passed to &ipsec-updown.8; in the
- environment variable <envar>PLUTO_DNS_RESOLVER</envar>.
- </para>
- <para>
- The default is <parameter>file</parameter>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dnssec-anchors=<filename>file</filename></option>
- </term>
- <listitem>
- <para>
- The location of a file containing additional DNSSEC Trust
- Anchors. This can be used when a network is using split-DNS and
- the internal hierarchy is using DNSSEC trust anchors.
- </para>
- <para>
- There is no default value.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dnssec-enable</option>
- </term>
- <listitem>
- <para>
- Whether pluto should perform dnssec validation using libunbound,
- provided libreswan was compiled with USE_DNSSEC. A value of
- <option>yes</option> (the default) means pluto
- should perform DNSSEC validation. Note that pluto reads the file
- <option>/etc/resolv.conf</option> to determine
- which nameservers to use.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dnssec-rootkey-file=<filename>rootkey</filename></option>
- </term>
- <listitem>
- <para>
- The location of the DNSSEC root zone public key file.
- </para>
- <para>
- The default is <option>@@DEFAULT_DNSSEC_ROOTKEY_FILE@@</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dpddelay</option>
- </term>
- <listitem>
- <para>
- Set the delay (in time units, defaults to seconds) between Dead
- Peer Detection (IKEv1 RFC 3706) or IKEv2 Liveness keepalives
- that are sent for this connection (default <literal>0</literal>
- seconds). Set to enable checking.
- </para>
- <para>
- If dpddelay is set, you might need to adjust
- <option>retransmit-timeout</option> for IKEv2
- and you must set <option>dpdtimeout</option> for IKEv1.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dpdtimeout</option>
- </term>
- <listitem>
- <para>
- Set the length of time (in time units, defaults to seconds) that
- pluto will idle without hearing back from the peer. After this
- period has elapsed with no response and no traffic, pluto will
- declare the peer dead, and remove the SA (default
- <literal>0</literal> meaning disabled). Set value bigger than
- dpddelay to enable. If dpdtimeout is set, dpddelay also needs to
- be set.
- </para>
- <para>
- This option is only valid for IKEv1. For IKEv2, this value is
- always the same as the retransmit-timeout, as IKEv2 is blocked
- from sending further IKE messages if an answer is not
- received.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>dumpdir=<filename><replaceable>directory</replaceable></filename></option>
- </term>
- <listitem>
- <para>
- in what directory should things started by
- <option>setup</option> (notably the Pluto daemon) be allowed to
- dump core? The default value is <filename>@@RUNDIR@@</filename>.
- When SELinux runs in enforced mode, changing this requires a
- similar change in the SELinux policy for the pluto daemon.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>enable-tcp</option>
- </term>
- <listitem>
- <para>
- Normally, IKE negotiation and ESP encapsulation happens over
- UDP. This option enables support for IKE and ESP over TCP as per
- RFC 8229. Acceptable values are <option>no</option>(the default),
- <option>yes</option> meaning only TCP will be used, or
- <option>fallback</option> meaning that TCP will be
- attempted only after negotiation over UDP failed. Since
- performance over TCP is much less, and TCP sessions are
- vulnerable to simply RST resets and MITM attacks causing the TCP
- connection to close, this option should really only be used in
- fallback mode. If used in fallback mode, it is recommend to
- reduce the <option>retransmit-timeout</option>
- from the default 60s to a much shorter value such as 10s, so
- that one does not have to wait a minute for the TCP fallback to
- be attempted. To receive incoming TCP connections, the
- <option>config setup</option> option <option>listen-tcp</option>
- needs to be enabled.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>encap-dscp</option>
- </term>
- <listitem>
- <para>
- Enable encapsulating the Differentiated Services Code Point
- (DSCP, formerly known as Terms Of Service (TOS)) bits. The extra
- xfrm flag "dont-encap-dscp" prevents these bits from being
- copied from the unencrypted IP packets to the encrypted IP
- packets. Acceptable values are <option>yes</option>
- (the default) or <option>no</option>.
- Currently this feature is only implemented for the Linux XFRM stack.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>encapsulation</option>
- </term>
- <listitem>
- <para>
- In some cases, for example when ESP packets are filtered or when
- a broken IPsec peer does not properly recognise NAT, it can be
- useful to force RFC-3948 encapsulation. In other cases, where
- IKE is NAT'ed but ESP packets can or should flow without
- encapsulation, it can be useful to ignore the NAT-Traversal
- auto-detection.
- <option>encapsulation=yes</option> forces the NAT detection
- code to lie and tell the remote peer that RFC-3948 encapsulation
- (ESP in port 4500 packets) is required.
- <option>encapsulation=no</option> ignores the NAT detection
- causing ESP packets to send send without encapsulation. The
- default value of <option>encapsulation=auto</option> follows
- the regular outcome of the NAT auto-detection code performed in IKE.
- This option replaced the obsoleted forceencaps option.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>esn</option>
- </term>
- <listitem>
- <para>
- Whether or not to enable Extended Sequence Number (ESN) for the
- IPsec SA. This option is only implemented for IKEv2. ESN is
- typically used for very high-speed links (10Gbps or faster)
- where the standard 32 bit sequence number is exhausted too
- quickly, causing IPsec SA's rekeys to happen too often. Accepted
- values are <option>either</option> (the default),
- <option>yes</option> and <option>no</option>.
- If <option>either</option> is specified as an initiator,
- the responder will make the choice. As a responder,
- if <option>either</option> is received,
- <option>yes</option> is picked.
- </para>
- <para>
- If replay-window is set to 0, ESN is disabled as some (most?)
- IPsec stacks won't support ESN in such a configuration.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>esp</option>
- </term>
- <listitem>
- <para>
- Specifies the algorithms that will be offered/accepted when
- negotiating a Child SA with ESP encapsulation. The general
- syntax is:
- </para>
- <para>
- <!-- should use EBNF -->
- <simplelist columns='1'>
- <member>ESP = PROPOSAL[,PROPOSAL...]</member>
- <member>PROPOSAL = ENCRYPT_ALGS[-INTEG_ALGS[-DH_ALGS]]</member>
- <member>ENCRYPT_ALGS = ENCRYPT_ALG[+ENCRYPT_ALG...]</member>
- <member>INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]</member>
- <member>DH_ALGS = DH_ALG[+DH_ALG...]</member>
- </simplelist>
- </para>
- <para>
- During startup, &ipsec-pluto.8; will log all supported ESP
- algorithms.
- </para>
- <para>
- Specifying the DH algorithms explicitly is <option>not</option>
- recommended. When PFS is enabled, and the DH algorithms are
- omitted, each PROPOSAL will automatically include the DH
- algorithm negotiated during the IKE exchange.
- </para>
- <para>
- AEAD algorithms such as AES_GCM and AES_CCM do not not require a
- separate integrity algorithm. For example
- <option>esp=aes_gcm256</option> or <option>esp=aes_ccm</option>.
- </para>
- <para>
- Note that AES_GCM and AES_CCM for ESP come in 8, 12 and 16 byte
- ICV versions. RFC 8221 only requires AES_GCM with 16 byte ICV
- and AES_CCM with 8 byte ICV to be implemented, and "aes_gcm" and
- "aes_ccm" refer to these variants. The other variants can be
- specified using an _a (8), _b(12) or _c(16) postfix, eg
- esp=aes_gcm_a for the 8 byte ICV and esp=aes_gcm_b for the 12
- byte ICV.
- </para>
- <para>
- For instance:
- </para>
- <para>
- <simplelist columns='1'>
- <member><computeroutput>esp=aes_gcm;aes128+aes256-sha2_512+sha2_256</computeroutput></member>
- <member><computeroutput>esp=aes128-sha2_512;dh19</computeroutput></member>
- </simplelist>
- </para>
- <para>
- If not specified, a secure set of defaults will be used. The
- program <command>ipsec algparse</command> can be used to query
- these defaults for instance: <command>ipsec algparse
- esp=</command> (see &ipsec-algparse.8;).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-
- <title>CONN SECTIONS</title>
- <para>
- A <option>conn</option> section contains a <option>connection
- specification</option>, defining a network connection to be made
- using IPsec. The name given is arbitrary, and is used to identify
- the connection to &ipsec.8; sub-commands. Here's a simple
- example:
- </para>
-
- <programlisting><xi:include href="d.ipsec.conf/exampleleftright.example" parse="text"
- xmlns:xi="http://www.w3.org/2001/XInclude"/></programlisting>
-
- <para>
- A note on terminology... In automatic keying, there are two
- kinds of communications going on: transmission of user IP packets, and
- gateway-to-gateway negotiations for keying, rekeying, and general
- control. The data path (a set of “Child SAs”) used for
- user packets is herein referred to as the “connection”;
- the path used for negotiations (built with “IKE SAs”)
- is referred to as the “keying channel”.
- </para>
-
- <para>
- To avoid trivial editing of the configuration file to suit it to each system
- involved in a connection,
- connection specifications are written in terms of
- <option>left</option>
- and
- <option>right</option>
- participants,
- rather than in terms of local and remote.
- Which participant is considered
- <option>left</option>
- or
- <option>right</option>
- is arbitrary;
- IPsec figures out which one it is being run on based on internal information.
- This permits using identical connection specifications on both ends.
- There are cases where there is no symmetry; a good convention is to
- use
- <option>left</option>
- for the local side and
- <option>right</option>
- for the remote side (the first letters are a good mnemonic).
- </para>
-
- <para>
- Many of the parameters relate to one participant or the other;
- only the ones for
- <option>left</option>
- are listed here, but every parameter whose name begins with
- <option>left</option>
- has a
- <option>right</option>
- counterpart,
- whose description is the same but with
- <option>left</option>
- and
- <option>right</option>
- reversed.
- </para>
-
- <para>
- Parameters are optional unless marked “(required)”
- </para>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>expire-lifetime</option>
- </term>
- <listitem>
- <para>
- The time in seconds until the acquire kernel state times out.
- On &Linux;, the default value, determined by
- <filename>/proc/sys/net/core/xfrm_acq_expires</filename> is 30
- seconds. On BSD, this option is ignored.
- </para>
- <para>
- On-demand connections (such as Opportunistic,
- <option>auto=ondemand</option>, or <command>ipsec
- route</command>) have an IPsec trap policy installed in the
- kernel. If an outgoing (or inbound) packet matches this policy,
- a state is created in the kernel and then the kernel sends an
- ACQUIRE message to the IKE daemon pluto. While this state is in
- place, no new acquires will come in for this connection. The
- default should be fine for most people. One use case of
- shortening these is if opportunistc encryption is used towards
- cloud instances that can quickly re-use IP addresses.
- </para>
- <para>
- See also <option>failureshunt</option> and
- <option>negotiationshunt</option>
- </para>
- <para>
- Prior to &Libreswan; version 5.3 this option was called
- <option>xfrmlifetime</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>expire-shunt-interval=<replaceable>seconds</replaceable></option>
- </term>
- <listitem>
- <para>
- How often to scan for Opportunistic Encryption failure shunts
- (kernel policies) that have expired and should be removed.
- </para>
- <para>
- When an Opportuistic Encryption negotiation fails, a failure
- shunt is installed to either block (<option>drop</option>) or
- allows(<option>pass</option>) traffic to the peer. These shunts
- are given a lifetime of 15 minutes (see
- <option>shuntlifetime</option>) after which time they expire and
- should be removed. The option
- <option>expire-shunt-interval</option> determines how frequently
- these shunts are checked. The default interval is 20 seconds.
- </para>
- <para>
- Note: because these shunts (kernel policies) are not
- bound to a connection instance they are refered to as bare.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>failureshunt</option>
- </term>
- <listitem>
- <para>
- what to do with packets when negotiation fails. The default is
- <option>none</option>: no shunt; <option>pass</option>,
- <option>drop</option>, and <option>reject</option> have the
- obvious meanings.</para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>fake-strongswan</option>=&yN_options;
- </term>
- <listitem>
- <para>
- whether to send a STRONGSWAN Vendor ID payload to the peer.
- Acceptable values are: <option>no</option> (the
- default) and <option>yes</option>. Strongswan enables some
- non-standard features and private algorithms only when it detects
- the strongswan Vendor ID. The exact capabilities depend on the
- strongswan version. At the time of writing this entry this option
- can enable negotiation of BEET mode (until the IETF assigns a
- code point), enable some private algorithms (eg some experimental
- post-quantum algorithms) and eanbles forwarding RADIUS attributes
- (which should not have any affects with the current EAP support
- in libreswan). Note that experimental algorithms on strongswan
- can also be enabled using charon.accept_private_algs and then this
- option is not needed.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='files'>
- <title>
- FILES
- </title>
- <para>
- <filename>/etc/ipsec.conf</filename>
- <filename>/etc/ipsec.d/policies/clear</filename>
- <filename>/etc/ipsec.d/policies/clear-or-private</filename>
- <filename>/etc/ipsec.d/policies/private-or-clear</filename>
- <filename>/etc/ipsec.d/policies/private</filename>
- <filename>/etc/ipsec.d/policies/block</filename>
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftfirewall</option>
- </term>
- <term>
- <option>rightirewall</option>
- </term>
- <listitem>
- <para>
- This option is obsolete and should not used anymore.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>fragmentation</option>
- </term>
- <listitem>
- <para>
- Whether or not to allow IKE fragmentation. Valid values are
- <option>yes</option> (the default) and <option>no</option>.
- In addition IKEv1 allows <option>force</option>.
- </para>
- <para>
- IKEv2 fragmentation support is implemented using RFC 7383.
- </para>
- <para>
- IKEv1 fragmentation capabilities are negotiated via a well-known
- private <option>vendor id</option>. If pluto does
- not receive the fragmentation payload, no IKE fragments will be
- sent, regardless of the <option>fragmentation=</option> setting.
- When set to <option>yes</option>, IKE fragmentation will be
- attempted on the first re-transmit of an IKE packet of a size
- larger then 576 bytes for IPv4 and 1280 bytes for IPv6. If
- fragmentation is set to force, IKE fragmentation is used on
- initial transmits of such sized packets as well. When we have
- received IKE fragments for a connection, pluto behaves as if in
- force mode.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>global-redirect-to</option>
- </term>
- <listitem>
- <para>
- Where to send remote peers to via the <option>global-redirect</option>
- option. This can be a list, or a single entry, of IP addresses or hostnames
- (FQDNs). If there is a list of entries, they must be separated with
- comma's. One specified entry means all peers will be redirected
- to it, while multiple specified entries means peers will be
- evenly distributed across the specified servers. This
- configuration can be changed at runtime via the
- <command>ipsec whack --global-redirect-to</command> command.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>global-redirect</option>
- </term>
- <listitem>
- <para>
- Whether to send requests for the remote peer to redirect
- IKE/IPsec SA's during IKE_SA_INIT. Valid options are
- <option>no</option> (the default),
- <option>yes</option> and <option>auto</option>,
- where auto means that the requests will be sent if DDoS mode
- is active (see <option>ddos-mode</option>). If set,
- the option <option>global-redirect-to=</option> must also be
- set to indicate where to redirect peers to. For specific connection
- redirection after IKE SA authentication, see the
- <option>send-redirect=</option> and <option>redirect-to=</option>
- options. This configuration can be changed at runtime via the
- <command>ipsec whack --global-redirect</command> command.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='history'>
- <title>
- HISTORY
- </title>
- <para>
- Designed for the FreeS/WAN project <<ulink
- url='https://www.freeswan.org'>https://www.freeswan.org</ulink>>
- by Henry Spencer.
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>left</option>
- </term>
- <term>
- <option>right</option>
- </term>
- <listitem>
- <para>
- (required) the IP address or DNS hostname of the left
- participant's public-network interface, Currently, IPv4 and IPv6
- IP addresses are supported. If a DNS hostname is used, it will
- be resolved to an IP address on load time, and whenever a
- connection is rekeying or restarting (such as when restarted via
- a DPD failure detection). This allows one to use a DNS hostname
- when the endpoint is on a dynamic IP address.
- </para>
- <para>
- There are several magic values. If it is
- <option>%defaultroute</option>, <option>left</option> will be
- filled in automatically with the local address of the
- default-route interface (as determined at IPsec startup time);
- this also overrides any value supplied for
- <option>leftnexthop</option>. (Either <option>left</option> or
- <option>right</option> may be <option>%defaultroute</option>,
- but not both.) The value <option>%any</option> signifies an
- address to be filled in (by automatic keying) during
- negotiation. The value <option>%opportunistic</option>
- signifies that both <option>left</option> and
- <option>leftnexthop</option> are to be filled in (by automatic
- keying) from DNS data for <option>left</option>'s client. The
- value can also contain the interface name, which will then later
- be used to obtain the IP address from to fill in. For example
- <option>%ppp0</option>.
- </para>
- <para>
- The values <option>%group</option> and
- <option>%opportunisticgroup</option> makes this a policy group
- conn: one that will be instantiated into a regular or
- opportunistic conn for each CIDR block listed in the policy
- group file with the same name as the conn.
- </para>
- <para>
- If using IP addresses in combination with NAT, always use the
- actual local machine's (NATed) IP address, and if the remote (eg
- right=) is NATed as well, the remote's public
- (<option>not</option> NATed) IP address. Note that this makes
- the configuration no longer symmetrical on both sides, so you
- cannot use an identical configuration file on both hosts.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>hostaddrfamily</option>
- </term>
- <listitem>
- <para>
- the address family of the hosts; currently the accepted values
- are <option>ipv4</option> and <option>ipv6</option>.
- The default is to detect this based on the IP addresses specified
- or the IP addresses resolved, so this option is not needed, unless
- you specify hostnames that resolve to both IPv4 and IPv6.
- </para>
- <para>
- This option used to be named connaddrfamily but its use was broken
- so it was obsoleted in favour or using the new hostaddrfamily and
- clientaddrfamily.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftid</option>
- </term>
- <term>
- <option>rightid</option>
- </term>
- <listitem>
- <para>
- how the left participant should be identified for
- authentication; defaults to <option>left</option>.
- Can be an IP address or a fully-qualified domain name which will
- be resolved. If preceded by <option>@</option>,
- the value is used as a literal string and will not be resolved.
-
- To support opaque identifiers (usually of type ID_KEY_ID, such
- as used by Cisco to specify Group Name, use square brackets, eg
- <option>rightid=@[GroupName]</option>.
-
- The magic value <option>%fromcert</option> causes
- the ID to be set to a DN taken from a certificate that is
- loaded. Prior to 2.5.16, this was the default if a certificate
- was specified.
-
- The magic value <option>%none</option> sets the ID
- to no ID. This is included for completeness, as the ID may have
- been set in the default conn, and one wishes for it to default
- instead of being explicitly set.
- </para>
- <para>
- When using certificate based ID's, one need to specify the full
- RDN, optionally using wildcard matching (eg CN='*'). If the RDN
- contains a comma, this can be masked using a backslash (eg
- OU='Foo\, Bar and associates')
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ignore-peer-dns</option>
- </term>
- <listitem>
- <para>
- whether to ignore received DNS configuration. Acceptable values
- are: <option>no</option> (the default) and
- <option>yes</option>. Normally, when a
- roadwarrior connects to a remote VPN, the remote VPN server
- sends a list of DNS domains and DNS nameserver IP addresses that
- the roadwarrior can use to reach internal only resources through
- the VPN. This option allows the roadwarrior to ignore the
- server's suggestion. The roadwarrior will normally use this
- information to update the DNS resolving process. What is changed
- depends on the detected DNS configuration. It can modify
- /etc/resolv.conf directly, or reconfigure a locally running DNS
- server (unbound, knot, stubby or systemd-resolved) or inform
- NetworkManager.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ike-socket-bufsize</option>
- </term>
- <listitem>
- <para>
- Set the IKE socket buffer size. Default size is determined by
- the OS (as of writing, this seems to be set to 212992. On Linux
- this is visible via /proc/sys/net/core/rmem_default and
- /proc/sys/net/core/wmem_default. On Linux, this option uses
- SO_RCVBUFFORCE and SO_SNDBUFFORCE so that it can override
- rmem_max/wmem_max values of the OS. This requires CAP_NET_ADMIN
- (which is also required for other tasks). This option can also
- be toggled on a running system using <option>ipsec
- whack --ike-socket-bufsize bufsize</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ike-socket-errqueue</option>
- </term>
- <listitem>
- <para>
- Whether to enable or disable receiving socket errors via
- IP_RECVERR. The default is enabled. This will cause the socket
- to receive, process and log socket errors, such as ICMP
- unreachable messages or Connection Refused messages. Disabling
- this only makes sense on very busy servers, and even then it
- might not make much of a difference. This option can also be
- toggled on a running system using <option>ipsec
- whack --ike-socket-errqueue-toggle</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term><option>ike</option></term>
- <listitem>
- <para>
- IKE encryption/authentication algorithm to be used for the
- connection (phase 1 aka ISAKMP SA or IKE SA). If this option is
- not set, the builtin defaults will be used. This is the
- preferred method, and allows for gradual automatic updates using
- the same configuration. Some distributions, such as Fedora and
- RHEL/CentOS, use a System Wide Crypto Policy that sets the
- default ike= (and esp=) lines. Specifying your own ike= line
- means overriding all these system or software recommended
- defaults, but can be necessary at times. Note that libreswan
- does not support using a PRF algorithm that is different from
- the INTEGRITY (hash) algorithm by design.
- </para>
- <para>
- The format is <option>"cipher-hash-modpgroup,
- cipher-hash-modpgroup, ..."</option> Any omitited option will
- be filled in with <option>all</option> allowed
- default values. Multiple proposals are separated by a comma. If
- an <option>ike=</option> line is specified, no
- other received proposals will be accepted than those specified
- on the IKE line. Some examples are <option>ike=3des-sha1,aes-sha1</option>,
- <option>ike=aes</option>,
- <option>ike=aes_ctr</option>,
- <option>ike=aes_gcm256;sha2_256</option>,
- <option>ike=aes128-sha1;modp2048</option>,
- <option>ike=aes256-sha2;dh19</option>,
- <option>ike=aes128-sha1;dh22</option>,
- <option>ike=3des-md5;modp1024,aes-sha1;modp1536</option>.
- </para><para> IKEv2 allows combining elements into a single
- proposal. These can be specified by using the + symbol. An
- example is:
- <option>ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14</option>.
- Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305)
- and non-AEAD algorithms (aes, 3des) cannot be combined into a
- single proposal. To support aes and aes_gcm, two proposals
- separated by a comma must be used.
- </para>
- <para>
- The default IKE proposal depends on the version of libreswan
- used. It follow the recommendations of RFC4306, RFC7321 and as
- of this writing their successor draft documents RFC4306bis and
- RFC7321bis. As for libreswan 3.32, SHA1 and MODP1536(dh5) are
- still allowed per default for backwards compatibility, but 3DES
- and MODP1024(dh2) are not allowed per default. As of libreswan
- 4.x, modp1024(dh2) support is no longer compiled in at all. For
- IKEv2, the defaults include AES, AES-GCM, DH14 and stronger, and
- SHA2. The default key size is 256 bits. The default AES_GCM ICV
- is 16 bytes.
- </para>
- <para>
- Note that AES-GCM is an AEAD algorithm, meaning that it performs
- encryption+authentication in one step. This means that AES-GCM
- must not specify an authentication algorithm. However, for IKE
- it does require a PRF function, so the second argument to an
- AEAD algorithm denotes the PRF. So ike=aes_gcm-sha2_256 means
- propose AES_GCM with SHA2_256 as the prf. Note that for
- esp, there is no prf, so AES-GCM is specified for ESP as
- esp=aes_gcm. The AES-GCM and AES-CCM algorithms support 8,12 and
- 16 byte ICV's. These can be specified using a postfix, for
- example aes_gcm_a (for 8), aes_gcm_b (for 12) and aes_gcm_c (for
- 16). The default (aes_gcm without postfix) refers to the 16
- byte ICV version. RFC 8247 only mandates the 16 byte ICV version
- is implemented, so it is recommended to NOT use the 8 or 12 byte
- versions of GCM or CCM. These versions are NOT included in the
- default proposal list and will be removed in a future version.
- </para>
- <para>
- Weak algorithms are regularly removed from libreswan. Currently,
- 1DES and modp768(DH1) have been removed and modp1024(DH2) has
- been disabled at compile time. Additionally, MD5 and SHA1 will
- be removed within the next few years. Null encryption is
- available, and should only be used for testing or benchmarking
- purposes. Please do not request for insecure algorithms to be
- re-added to libreswan. IKEv1 has been disabled per default, and
- will soon no longer be compiled in by default.
- </para>
- <para>
- For all Diffie-Hellman groups, the "dh" keyword can be used
- instead of the "modp" keyword. For example
- <option>ike=3des-sha1-dh19</option>. Diffie-Hellman groups
- 19,20 and 21 from RFC-5903 are supported. Curve25519 from
- RFC-8031 is supported as "dh31". Curve448 and GOST DH groups are
- not yet supported in libreswan because these are not supported
- yet in the NSS crypto library.
- </para>
- <para>
- Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are
- implemented but not compiled in by default. These DH groups are
- extremely controversial and MUST NOT be used unless forced
- (administratively) by the other party. This is further
- documented in RFC 8247, but the summary is that it cannot be
- proven that these DH groups do not contain a cryptographic
- trapdoor (a backdoor by the USG who provided these primes
- without revealing the seeds and generation process used).
- </para>
- <para>
- The modp syntax will be removed in favour of the dh syntax in
- the future
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>ikelifetime</option>
- </term>
- <listitem>
- <para>
- how long the keying channel of a connection (buzzphrase:
- “IKE SA” or “ISAKMP SA”) should last
- before being renegotiated; acceptable values as for
- <option>salifetime</option>. The default as of version 4.2
- is <option>8h</option>, before that it was 1h. The
- maximum is <option>24h</option>. The
- two-ends-disagree case is similar to that of
- <option>salifetime</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ikepad=</option>
- </term>
- <listitem>
- <para>
- Work around IKEv1 padding issues when inter-operating with other
- IKE daemons.
- </para>
- <para>
- By default, &Libreswan; pads messages
- to a minimum of 4-bytes. While this is allowed it may cause
- interoperability issues. To remove this padding, specify
- <option>ikepad=no</option> (note that this does not affect
- messages encrypted using a block-mode cipher where padding is
- always added).
- </para>
- <para>
- Prior to &Libreswan; version 5.2, some MODECFG payloads were
- incorrectly padded to 4-bytes which caused interoperability
- issues. To restore this behaviour, specify
- <option>ikepad=yes</option>.
- </para>
- <para>
- In IKEv2, this option is ignored.
- </para>
- <sidebar>
- <title>
- Background
- </title>
- <para>
- It was thought that padding messages by 4-bytes was causing
- interoperability issues with
- &Checkpoint;
- (<option>ikepad=no</option> was added as a workaround).
- However, it's since been determined that &Racoon; also had
- interoperability issues and the cause was the padding of some
- XAUTH and MODECFG payloads. Setting
- <option>ikepad=no</option> fixed interoperability because it
- was also disabling that padding. The padding of XAUTH and
- MODECFG was removed in &Libreswan; version 5.2.
- </para>
- <para>
- Further details can be found in the RFCs, see: RFC-2409
- section 5.3, Phase 1 Authenticated With a Revised Mode of
- Public Key Encryption, <quote>the last byte of the padding
- contains the number of padding bytes</quote> and <quote>there
- will always be padding</quote>; RFC-2408 section 3.5, Proposal
- Payload, <quote>there is no padding applied to the payload,
- however, it can be applied at the end of the message</quote>;
- RFC-2408 section 3.6, Transform Payload, <quote>then
- subsequent payloads will not be aligned and any padding will
- be added at the end of the message to make the message 4-octet
- aligned</quote>.
- </para>
- </sidebar>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftikeport</option>
- </term>
- <term>
- <option>rightikeport</option>
- </term>
- <listitem>
- <para>
- The UDP IKE port to listen on or send data to. This port cannot
- be 0 or 500. For TCP, see <option>tcp-remoteport=</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ikev1-policy</option>
- </term>
- <listitem>
- <para>
- What to do with received IKEv1 packets. Valid options are
- <option>drop</option> (default) which will
- silently drop any received IKEv1 packet, <option>accept</option>,
- and <option>reject</option> which will reply with an error. If
- this option is set to drop or reject, an attempt to load an
- IKEv1 connection will fail, as these connections would never be
- able to receive a packet for processing.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>initial-contact</option>
- </term>
- <listitem>
- <para>
- whether to send an INITIAL_CONTACT payload to the peer we are
- initiating to, if we currently have no IPsec SAs up with that
- peer. Acceptable values are: <option>yes</option>
- (the default) and <option>no</option>. It is
- recommended to leave this option set, unless multiple clients
- with the same identity are expected to connect using the same
- subnets and should operate at the same time. Or if a
- reconnecting client should not delete its old instance (eg
- perhaps it is still running). This is unlikely to be true.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftinterface-ip=&ip_cidr;</option>
- </term>
- <term>
- <option>rightinterface-ip=&ip_cidr;</option>
- </term>
- <listitem>
- <para>
- The IP address and netmask to configure on a virtual device (eg
- <filename>ipsec<replaceable>N</replaceable></filename>). This
- is often used when building Routing based IPsec tunnels using
- transport mode and GRE, but can also be useful in other
- scenarios. Currently requires
- <option>ipsec-interface=</option>.
- </para>
- <para>
- See also <option>leftvti=</option> for configuring IP addresses
- when using deprecated VTI.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>intermediate</option>
- </term>
- <listitem>
- <para>
- EXPERIMENTAL: Whether to enable the INTERMEDIATE exchange in
- IKEv2 (RFC 9242). Currently the accepted values are
- <option>yes</option>, signifying we propose to use the
- INTERMEDIATE exchange for this connection;
- <option>no</option> (the default), signifying we will not
- use the INTERMEDIATE exchange for this connection.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ipsec-interface-managed</option>
- </term>
- <listitem>
- <para>
- Specify whether the IPsec Interface specified by
- <option>ipsec-interface</option> managed by
- &Libreswan;. Possible values are:
- </para>
- <variablelist>
- <varlistentry>
- <term>
- <option>yes</option> (default)
- </term>
- <listitem>
- <para>
- &Libreswan; is responsible for managing the IPsec
- Interface. For instance, creating it when needed, adding
- the address specified by <option>interface-ip</option>,
- installing any kernel policy or state, and marking it
- <option>up</option> and <option>down</option>.
- </para>
- <para>
- In this mode <option>ipsec-interface</option> identifies
- the IPsec interface network device. For instance,
- <option>ipsec-interface=1</option> specifies the network
- device <option>ipsec1</option>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>no</option>
- </term>
- <listitem>
- <para>
- &Libreswan; assumes that the IPsec interface specified by
- <option>ipsec-interface</option> exists and &Libreswan; is
- only responsible for managing kernel policy and state.
- </para>
- <para>
- In this mode <option>ipsec-interface</option> identifies
- the low level kernel ID. For instance, on &Linux;,
- <option>ipsec-interface=1</option> identifies the device
- with the XFRM if_id 1.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ipsec-interface</option>
- </term>
- <listitem>
- <para>
- Specify the IPsec Interface for "Routing based IPsec VPNs" (as
- opposed to "Policy based VPNs"). The IPsec Interface is used to
- route outbound traffic that needs to be encrypted, and will
- decrypt inbound traffic that arrives on this interface. All
- traffic that is routed to this interface will be automatically
- encrypted providing the IPsec SA policy covers this traffic.
- Traffic not matching the IPsec SA will be dropped. Tools such
- as <command>tcpdump</command>, <command>iptables</command>,
- <command>ifconfig</command> and tools that need traffic counters
- can be used on all cleartext pre-encrypt and post-decrypt
- traffic on the device. When <option>leftsubnet=</option> is
- equal to <option>rightsubnet=</option>, the routing needs to be
- managed by an external routing daemon or manually by the
- administrator.
- </para>
- <para>
- By default, &Libreswan; is configured in managed mode. In
- managed mode, &Libreswan; will create, configure
- <option>up</option>, <option>down</option>, and delete the IPsec
- Interface device (on &Linux;, &FreeBSD;, and &NetBSD; that
- device is named <option>ipsec</option>; &OpenBSD; it is named
- <option>sec</option>). To specify the IP address to configure
- when creating the device also specify
- <option>interface-ip=</option>.
- </para>
- <para>
- Alternatively, &Libreswan; can be configured in unmanaged mode.
- In unmanaged mode, &Libreswan; does not manipulate the IPsec
- Interface Device directly. Instead &Libreswan; will assume the
- IPsec Interface device already exists, manipulating it directly
- using the low-level kernel ID (on &Linux; that is the XFRMi
- if_id). A typical use is with namespaces where the IPsec
- Interface Device and &Libreswan; are in separate namespace.
- </para>
- <para>
- </para>
- <para>
- </para>
- <para>
- Possible values are:
- </para>
- <variablelist>
- <varlistentry>
- <term>
- <option>no</option> (default)
- </term>
- <listitem>
- <para>
- Do not use "Routing based IPsec VPN".
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>yes</option>
- </term>
- <listitem>
- <para>
- Enable "Routing based IPsec VPNs". In managed mode, use
- IPsec Interface device 1 (for instance,
- <option>ipsec1</option>). In unmanaged mode, use the
- kernel device 1.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option><replaceable>number</replaceable></option>
- </term>
- <listitem>
- <para>
- Enable "Routing based IPsec VPNs" using the device
- <replaceable>number</replaceable>. For instance,
- <option>ipsec-interface=5</option> will use
- <option>ipsec5</option> in managed mode, and kernel xfrm interface
- with if_id <option>5</option> in unmanaged mode.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- Kernel Support:
- </para>
- <variablelist>
- <varlistentry>
- <term>
- &Linux; (since 4.19)
- </term>
- <listitem>
- <para>
- This option is currently only supported on Linux kernels
- when compiled with XFRMi support
- (<option>CONFIG_XFRM_INTERFACE</option>). The number of
- the ipsecX device corresponds with the <option>XFRM
- IF_ID</option> policy option of the IPsec SA in the Linux
- kernel. On Linux, XFRMi interfaces can be managed by
- &Libreswan; automatically or can be preconfigured on the
- system using the existing init system or via networking
- tools such as systemd-networkd and NetworkManager. The
- _updown script handles certain Linux specific interfaces
- settings required for proper functioning, such as
- forwarding and routing rules for IPsec traffic.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- &NetBSD; (since 8.0)
- </term>
- <term>
- &OpenBSD; (since 7.4)
- </term>
- <term>
- &FreeBSD; (since 11.0)
- </term>
- <listitem>
- <para>
- Supported since &Libreswan; 5.2.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ipsec-max-bytes</option>
- </term>
- <listitem>
- <para>
- how many bytes can be sent, or how many bytes can be received on
- an IPsec SA instance for a connection; acceptable values are an
- integer optionally followed by
-
- <option>KiB</option>,
- <option>MiB</option>,
- <option>GiB</option>,
- <option>TiB</option>,
- <option>PiB</option> or
- <option>EiB</option>
-
- to signify kilobytes, megabytes, gigabytes, terabytes, petabytes
- or exabytes.
-
- </para>
- <para>
- An IPsec SA contains two keys, one for inbound and one for
- outbound traffic. The
- <replaceable>ipsec-max-bytes</replaceable> sets two limits on
- each of these keys: the hard limit which is the total number of
- bytes that a given key can encrypt, and the soft limit which is
- the number of bytes that can be encrypted before a renegotiation
- of the IPsec SA is initiated. Normally the renegotiation (via
- the IKE SA) is completed before the
- <replaceable>ipsec-max-bytes</replaceable> value is reached.
- </para>
- <para>
- Pluto sets the the original initiator's soft limit to 25% of
- <replaceable>ipsec-max-bytes</replaceable> (with 12% fuzz) and
- on the original responder's soft limit to 50% of
- <replaceable>ipsec-max-bytes</replaceable> (with 12% fuzz).
- This way the original initiator hopefully is the one initiating
- the renegotiation of the IPsec SA.
- </para>
- <para>
- This option is not negotiated between IKE peers. Each end of
- the IPsec SA sets their own limits independently.
- </para>
- <para>
- The default (hard limit) is 2^63 bytes. The original
- initiator's soft limit is 2^61 bytes (approx.) and the original
- responder's soft limit is 2^62 bytes (approx.).
- </para>
- <para>
- When using Linux with <option>nic-offload=packet</option> set,
- Linux 6.7 or later is required.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ipsec-max-packets</option>
- </term>
- <listitem>
- <para>
- How many packets can be sent/received on a particular instance
- of a connection (a set of encryption/authentication keys for
- user packets) , from successful negotiation to expiry.
- </para>
- <para>
- Default values and caveats are the same as for
- <option>ipsec-max-bytes</option>. This option uses a prefix
- without "B" for bytes.
- </para>
- <para>
- When using Linux with <option>nic-offload=packet</option> set,
- Linux 6.7 or later is required.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ipsecdir</option>
- </term>
- <listitem>
- <para>
- Specifies a directory for administrator-controlled configuration
- files and directories. The default value is
- <option>@@IPSEC_CONFDDIR@@</option>. It may contain the following
- files and directories:
- </para>
- <variablelist>
- <varlistentry>
- <term>
- passwd
- </term>
- <listitem>
- <para>
- (optional) for IKEv1 XAUTH support if not using PAM (this file
- should not be world-readable). See README.XAUTH for more
- information.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- nsspassword
- </term>
- <listitem>
- <para>
- (optional) passwords needed to unlock the NSS database in
- <filename>@@IPSEC_NSSDIR@@</filename> (this file should
- not be world-readable). See README.nss for more
- information.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- policies/
- </term>
- <listitem>
- <para>
- a directory containing policy group configuration
- information. See <option>POLICY GROUP
- FILES</option> in this document for more information.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- <para>
- When SELinux runs in enforced mode, changing this requires a
- similar change in the SELinux policy for the pluto daemon.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>iptfs</option>
- </term>
- <listitem>
- <para>
- Enable "Aggregation and Fragmentation Mode for Encapsulating
- Security Payload (ESP) and its use for IP Traffic Flow Security
- (IP-TFS) as defined in RFC 9347. Currently, this is only
- supported for the Linux XFRM stack and will likely be merged
- into Linux 6.7 or 6.8. Valid options are <option>no</option>
- (the default) or <option>yes</option>. IP-TFS allow the kernel
- to combine multiple small packets into one ESP packet, which
- should cause a performance gain when many small packets (eg
- iperf packets) are sent. It also allows the kernel to fragment
- the outgoing packet stream so that the ESP packets have a fixed
- size that can be set manually or fit the path MTU. This should
- avoid common MTU issues with IPsec. IP-TFS can only be used
- with tunnel mode and ESP. It cannot be combined with
- <option>type=transport</option>, <option>phase2=ah</option>,
- <option>compress=yes</option> or <option>tfc=yes</option>. A
- number of IP-TFS options can be tuned.
- </para>
- </listitem>
-</varlistentry>
-<varlistentry>
- <term>
- <option>iptfs-fragmentation={yes,no}</option>
- </term>
- <listitem>
- <para>
- Whether or not to fragment IP-TFS.
- </para>
- <para>
- On &Linux; and
- <option>iptfs-fragmentation=no</option>, this passes
- <option>XFRMA_IPTFS_DONT_FRAG</option> to the kernel. (Unclear
- to at least one author if this means regular ICMP Dont Fragment
- sending, or whether it stops IP-TFS from fragmenting).
- </para>
- <para>
- Default is <option>iptfs-fragmentation=yes</option>
- </para>
- </listitem>
-</varlistentry>
-<varlistentry>
- <term><option>iptfs-max-queue-size</option></term>
- <listitem>
- <para>
- The default IP-TFS max output queue size in octets. The output
- queue is where received packets destined for output over an
- IP-TFS tunnel are stored prior to being output in
- aggregated/fragmented form over the IP-TFS tunnel.
- </para>
- <para>
- Default 1000000.
- </para>
- </listitem>
-</varlistentry>
-<varlistentry>
- <term><option>iptfs-drop-time=<replaceable>duration</replaceable></option></term>
- <listitem>
- <para>
- The amount of time before a missing out-of-order IP-TFS tunnel
- packet is considered lost. See also
- <option>iptfs-reorder-window</option>.
- </para>
- <para>
- The default is 1s. The default time unit is seconds (see
- <replaceable>duration</replaceable>).
- </para>
- </listitem>
-</varlistentry>
-<varlistentry>
- <term><option>iptfs-init-delay=<replaceable>duration</replaceable></option></term>
- <listitem>
- <para>
- The amount of time prior to servicing the output queue after
- queueing the first packet on said queue.
- </para>
- <para>
- The default is 0s. The default time unit is seconds (see
- <replaceable>duration</replaceable>).
- </para>
- </listitem>
-</varlistentry>
-<varlistentry>
- <term><option>iptfs-reorder-window</option></term>
- <listitem>
- <para>
- The default IP-TFS reorder window size. The reorder window size
- dictates the maximum number of IP-TFS tunnel packets in a
- sequence that may arrive out of order.
- </para>
- <para>
- Default 3.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>keep-alive</option>
- </term>
- <listitem>
- <para>
- The delay (in seconds) for NAT-T keep-alive packets, if these
- are enabled using <option>nat-keepalive</option>
- This parameter may eventually become per-connection.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>keyexchange</option>
- </term>
- <listitem>
- <para>
- Whether to use IKEv2 (RFC 7296) or IKEv1 (RFC 4301). Currently the
- accepted values are <option>ikev2</option> (the default) and
- <option>ikev1</option>.
- </para>
- <para>
- This option replaces ikev2=yes|no. Old values yes, propose and instist
- all map to keyexchange=ikev2. Values no and permit are map to
- keyexchange=ikev1.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>listen-tcp</option>
- </term>
- <listitem>
- <para>
- Whether the pluto IKE daemon should listen on the (pseudo)
- standard TCP port <option>4500</option>. The default is
- "no". The TCP usage complies to RFC 9329 for IKE and ESP over
- TCP support. Connections can specify their own non-standard TCP
- port using <option>leftikeport=</option> and
- <option>tcp-remoteport=</option> for a non-standard peer TCP
- port.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>listen-udp</option>
- </term>
- <listitem>
- <para>
- Whether the pluto IKE daemon should listen on the standard UDP
- ports of <option>500</option> and <option>4500</option>. The
- value "yes" means to listen on these ports, and is the default.
- This should almost never be disabled. In the rare case where it
- is known that only ever TCP or non-standard UDP ports will be
- used, this option can disable the standard UDP
- ports. Connections can specify their own non-standard port using
- leftikeport=.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>listen</option>
- </term>
- <listitem>
- <para>
- IP address to listen on, defaults to ANY. Currently only
- accepts one IP address.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>logappend</option>=&Yn_options;
- </term>
- <listitem>
- <para>
- If pluto is instructed to log to a file using
- <option>logfile=</option>, this option determines whether the
- log file should be appended to or overwritten. Valid options
- are <option>yes</option> (the default) to append and
- <option>no</option> to overwrite. Since on modern systems,
- pluto is restarted by other daemons, such as systemd, this
- option should be left at its default <option>yes</option> value
- to preserve the log entries of previous runs of pluto. This
- option is mainly of use for running the test suite, which needs
- to create new log files from scratch.
- </para>
- <para>
- Prior to &Libreswan; version 5.3 <command>pluto</command>, when
- invoked without a config file, had this option disabled.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>logfile</option>
- </term>
- <listitem>
- <para>
- do not use syslog, but rather log to stderr, and direct stderr
- to the argument file. This option used to be called
- plutostderrlog=
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>logip</option>
- </term>
- <listitem>
- <para>
- If pluto is instructed to log the IP address of incoming
- connections. Valid options are <option>yes</option> (the
- default) and <option>no</option>. Note that this only affects
- regular logging. Any enabled debugging via
- <option>plutodebug=</option> will still contain IP addresses of
- peers. This option is mostly meant for servers that want to
- avoid logging IP addresses of incoming clients. Other
- identifiable information might still be logged, such as ID
- payloads and X.509 certificate details. When using ID of type
- IP address, this option will not hide the actual IP address as
- part of the ID. Most deployments will not want to change this
- from the default. If logging of IP addresses is unwanted,
- <option>audit-log=no</option> should also be set.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>logtime</option>
- </term>
- <listitem>
- <para>
- When pluto is directed to log to a file using
- <option>logfile=</option>, this option determines whether or not
- to log the current timestamp as prefix. Values are
- <option>yes</option> (the default) or <option>no</option>. The
- no value can be used to create logs without ephemeral
- timestamps, such as those created when running the test suite.
- This option used to be called plutostderrlogtime=
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>mark-in</option>
- </term>
- <listitem>
- <para>
- The same as <option>mark</option>, but mark-in only applies to
- the inbound half of the IPsec SA. It overrides any mark=
- setting.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>mark-out</option>
- </term>
- <listitem>
- <para>
- The same as <option>mark</option>, but mark-out only applies to
- the outbound half of the IPsec SA. It overrides any mark=
- setting.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>mark</option>
- </term>
- <listitem>
- <para>
- If set, the MARK to set for the IPsec SA of this connection. The
- format of a CONNMARK is <option>mark/mask</option>. If the mask
- is left out, a default mask of 0xffffffff is used. A mark value
- of -1 means to assign a new global unique mark number for each
- instance of the connection. Global marks start at 1001. This
- option is only available on linux XFRM kernels. It can be used
- with iptables to create custom iptables rules using CONNMARK. It
- can also be used with Virtual Tunnel Interfaces ("VTI") to
- direct marked traffic to specific vtiXX devices.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>max-halfopen-ike</option>
- </term>
- <listitem>
- <para>
- The number of half-open IKE SAs before the IKE daemon starts
- refusing all new IKE attempts. Established IKE peers are not
- affected. The default value is 50000.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>metric</option>
- </term>
- <listitem>
- <para>
- Set the metric for added routes. This value is passed to the
- <command>ipsec _updown</command> scripts as
- <envar>PLUTO_METRIC</envar> (see &ipsec-updown.8;).
- </para>
- <para>
- Acceptable values are positive numbers, with the default being
- <option>1</option>.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>mobike</option>
- </term>
- <listitem>
- <para>
- Whether to allow MOBIKE (RFC 4555) to enable a connection to
- migrate its endpoint without needing to restart the connection
- from scratch. This is used on mobile devices that switch between
- wired, wireless or mobile data connections. Current values are
- <option>no</option> (the default) or <option>yes</option>, Only
- connection acting as modecfgclient will allow the initiator to
- migrate using mobike. Only connections acting as modecfgserver
- will allow clients to migrate.
- </para>
- <para>
- VTI and MOBIKE might not work well when used together.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftmodecfgclient</option>
- </term>
- <term>
- <option>rightmodecfgclient</option>
- </term>
- <listitem>
- <para>Left is a Mode Config client. It can receive network
- configuration from the server. Acceptable values are
- <option>yes</option> or <option>no</option> (the
- default).</para>
- </listitem>
-</varlistentry>
-
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>modecfgdns</option>
- </term>
- <term>
- <option>modecfgdomains</option>
- </term>
- <term>
- <option>modecfgbanner</option>
- </term>
- <listitem>
- <para>
- When configured as IKEv1 ModeCFG or IKEv2 server, specifying any
- of these options will cause those options and values to be sent
- to the connecting client. &Libreswan; as a client will use
- these received options to either update /etc/resolv.conf or the
- running unbound DNS server. When the connection is brought down,
- the previous DNS resolving state is restored.
- </para>
- <para>
- The modecfgdns option takes a comma or space separated list of
- IP addresses that can be used for DNS resolution. The
- modecfgdomains option takes a comma or space separated list of
- internal domain names that are reachable via the supplied
- modecfgdns DNS servers.
- </para>
- <para>
- The IKEv1 split tunnel directive will be sent automatically if
- the xauth server side has configured a network other than
- 0.0.0.0/0. For IKEv2, this is automated via narrowing.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>modecfgpull</option>
- </term>
- <listitem>
- <para>
- Pull the Mode Config network information from the server.
- Both server and client must use same setting.
- Acceptable values are <option>yes</option> or
- <option>no</option> (the default).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftmodecfgserver</option>
- </term>
- <term>
- <option>rightmodecfgserver</option>
- </term>
- <listitem>
- <para>
- Left is a Mode Config server. It can push network configuration
- to the client. Acceptable values are <option>yes</option>
- or <option>no</option> (the default).
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term><option>ms-dh-downgrade</option></term>
- <listitem>
- <para>
- Whether to allow a downgrade of Diffie-Hellman group during
- rekey (using CREATE_CHILD_SA).
- </para>
- <para>
- Microsoft Windows (at the time of writing, Feb 2018) defaults to
- using the very weak modp1024 (DH2). This can be changed using a
- Windows registry setting to use modp2048 (DH14). However, at
- rekey times, it will shamelessly use modp1024 again and the
- connection might fail. Setting <option>ms-dh-downgrade=yes</option>
- (and adding modp1024 proposals to the ike line) will allow this
- downgrade attack to happen. This should only be used to support
- Windows that feature this bug.
- </para>
- <para>
- The accepted values are <option>no</option>, (the
- default) or <option>yes</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>mtu</option>
- </term>
- <listitem>
- <para>
- Set the MTU for the route(s) to the remote endpoint and/or
- subnets. This is sometimes required when the overhead of the
- IPsec encapsulation would cause the packet the become too big
- for a router on the path. Since IPsec cannot trust any
- unauthenticated ICMP messages, PATH MTU discovery does not
- work. This can also be needed when using "6to4" IPV6
- deployments, which adds another header on the packet size.
- </para>
- <para>
- Acceptable values are positive numbers. There is no default.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>myvendorid</option>
- </term>
- <listitem>
- <para>
- The string to use as our vendor id (VID) when
- send-vendorid=yes. The default is OE-Libreswan-VERSION.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>narrowing</option>
- </term>
- <listitem>
- <para>
- IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options.
- Currently the accepted values are <option>no</option>, (the
- default) signifying no narrowing will be proposed or accepted,
- or <option>yes</option>, signifying IKEv2 negotiation may allow
- establishing an IPsec connection with narrowed down traffic
- selectors. This option is ignored for IKEv1.
- </para>
- <para>
- There are security implications in allowing narrowing down the
- proposal. For one, what should be done with packets that we
- hoped to tunnel, but cannot. Should these be dropped or send in
- the clear? Second, this could cause thousands of narrowed down
- Child SAs to be created if the conn has a broad policy (eg 0/0
- to 0/0). One possible good use case scenario is that a remote
- end (that you fully trust) allows you to define a 0/0 to them,
- while adjusting what traffic you route via them, and what
- traffic remains outside the tunnel. However, it is always
- preferred to setup the exact tunnel policy you want, as this
- will be much clearer to the user.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nat-ikev1-method</option>
- </term>
- <listitem>
- <para>
- NAT Traversal in IKEv1 is negotiated via Vendor ID options as
- specified in RFC 3947. However, many implementations only
- support the draft version of the RFC. &Libreswan; sends both the
- RFC and the most common draft versions (02, 02_n and 03) to
- maximize interoperability. Unfortunately, there are known
- broken implementations of RFC 3947, notably Cisco routers that
- have not been updated to the latest firmware. As the NAT-T
- payload is sent in the very first packet of the initiator, there
- is no method to auto-detect this problem and initiate a
- workaround.
- </para>
- <para>
- This option allows fine tuning which of the NAT-T payloads to
- consider for sending and processing. Currently the accepted
- values are <option>drafts</option>, <option>rfc</option>,
- <option>both</option> (the default) and
- <option>none</option>. To interoperate with known broken
- devices, use nat-ikev1-method=drafts. To prevent the other end
- from triggering IKEv1 NAT-T encapsulation, set this to
- none. This will omit the NAT-T payloads used to determine NAT,
- forcing the other end not to use encapsulation.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nat-keepalive</option>
- </term>
- <listitem>
- <para>
- whether to send any NAT-T keep-alives. These one byte packets
- prevent the NAT router from closing its port when there is not
- enough traffic on the IPsec connection. Acceptable values are:
- <option>yes</option> (the default) and <option>no</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>negotiationshunt</option>
- </term>
- <listitem>
- <para>
- What to do with packets during the IKE negotiation. Valid
- options are <option>hold</option> (the default) or
- <option>pass</option>. This should almost always be left to the
- default <option>hold</option> value to avoid cleartext packet
- leaking. The only reason to set this to <option>pass</option> is
- if plaintext service availability is more important than service
- security or privacy, a scenario that also implies
- <option>failureshunt=pass</option> and most likely
- <option>authby=%null</option> using Opportunistic Encryption.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftnexthop</option>
- </term>
- <term>
- <option>rightnexthop</option>
- </term>
- <listitem>
- <para>
- next-hop gateway IP address for the left participant's
- connection to the public network; defaults to <option>%direct</option>
- (meaning <option>right</option>). If the value is to be overridden
- by the <option>left=%defaultroute</option> method
- (see above), an explicit value must <option>not</option> be given.
- If that method is not being used, but <option>leftnexthop</option> is
- <option>%defaultroute</option>, the next-hop
- gateway address of the default-route interface will be used.
- The magic value <option>%direct</option> signifies
- a value to be filled in (by automatic keying) with the peer's
- address. Relevant only locally, other end need not agree on
- it.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nflog-all</option>
- </term>
- <listitem>
- <para>
- If set, the NFLOG group number to log <option>all</option>
- pre-crypt and post-decrypt traffic to. The default value of
- <option>0</option> means no logging at all. This option is only
- available on linux kernel 2.6.14 and later. It allows common
- network utilities such as tcpdump, wireshark and dumpcap, to use
- nflog:XXX pseudo interfaces where XXX is the nflog group
- number. During startup and shutdown of the IPsec service,
- iptables commands will be used to add or remove the global NFLOG
- table rules. The rules are setup with the nflog-prefix
- <option>all-ipsec</option>. See also the per-connection
- <option>nflog</option> option.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nflog-group</option>
- </term>
- <listitem>
- <para>
- If set, the NFLOG group number to log this connection's
- pre-crypt and post-decrypt traffic to. The default value of
- <option>0</option> means no logging at all. This option is only
- available on linux kernel 2.6.14 and later. It allows common
- network utilities such as tcpdump, wireshark and dumpcap, to use
- nflog:XXX pseudo interfaces where XXX is the nflog group
- number. During the updown phase of a connection, iptables will
- be used to add and remove the source/destination pair to the
- nflog group specified. The rules are setup with the
- nflog-prefix matching the connection name. See also the global
- <option>nflog-all</option> option.
- </para>
- <para>
- Prior to &Libreswan; version 5.3, this option was called
- <option>nflog</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nhelpers</option>
- </term>
- <listitem>
- <para>
- how many <option>pluto helpers</option> are started to help with
- cryptographic operations. Pluto will start as many helpers as
- the number of CPU's, minus 1 to dedicate to the main thread.
- For machines with less than 4 CPU's, an equal number of helpers
- to CPU's are started. A value of 0 forces pluto to do all
- operations inline using the main process. A value of -1 tells
- pluto to perform the above calculation. Any other value forces
- the number to that amount.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nic-offload</option>
- </term>
- <listitem>
- <para>
- Set the method of Network Interface Controller (NIC) hardware
- offload for ESP/AH packet processing. Acceptable values are
- <option>no</option> (the default),
- <option>crypto</option> or <option>packet</option>. The
- value <option>yes</option> is a backwards compatible value
- for <option>crypto</option>. The nic-offload option is
- separate from any CPU hardware offload available. When set to
- <option>crypto</option>, only cryptographic operations are
- offloaded to the NIC card. When set to
- <option>packet</option>, the entire packet processing
- including the encryption/decryption is offloaded to the NIC
- card.
- </para>
- <para>
- Crypto nic-offload is available starting Linux 4.13 using the
- XFRM IPsec stack. Packet nic-offload is available starting
- Linux 6.3. Both require that the Linux kernel is compiled with
- the options CONFIG_XFRM_OFFLOAD, CONFIG_INET_ESP_OFFLOAD and
- CONFIG_INET6_ESP_OFFLOAD. Network card support can be seen by
- the presence of the <option>esp-hw-offload</option>
- capability using the <option>ethtool -S</option> command.
- The Linux kernel attempts to fall back from crypto hardware
- offload to software, but only for some algorithms (AEADs only?).
- There is no fallback from packet offload to crypto offload. At
- the time of libreswan 5.0, we are only aware of the
- Nvidia/Mellanox ConnectX-7 (and to some extend ConnectX-6) cards
- supporting packet offload.
- </para>
- <para>
- In general, it makes no sense to try to offload older (non-AEAD)
- cryptographic algorithms such as AES-CBC or 3DES, as these
- algorithms are so much slower than AEAD algorithms (such as
- AES-GCM) that one would gain more performance by switching the
- algorithm to AEAD than by offloading. As such, AES-CBC tends to
- not be implemented in offload hardware. This option has also no
- effect on IKE packets, which are never offloaded, although IKE
- encryption does use supported CPU hardware instructions, such as
- AESNI.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nm-configured</option>
- </term>
- <listitem>
- <para>
- Mark this connection as controlled by Network Manager.
- Acceptable values are <option>yes</option> or
- <option>no</option> (the default). Currently, setting this to
- yes will cause libreswan to skip reconfiguring resolv.conf when
- used with XAUTH and ModeConfig.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nopmtudisc</option>
- </term>
- <listitem>
- <para>
- Disable Path MTU discovery for the IPsec SA. Acceptable values
- are <option>no</option> (the default) or <option>yes</option>.
- Currently this feature is only implemented for the Linux XFRM
- stack.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>nssdir</option>
- </term>
- <listitem>
- <para>
- Specifies a directory for NSS database files. The default value
- is <option>@@IPSEC_NSSDIR@@</option>. It may contain the
- following files:
- </para>
- <variablelist>
- <varlistentry>
- <term>pkcs11.txt</term>
- <listitem><para>
- Detailed info about NSS database creation parameters.
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>cert9.db</term>
- <listitem><para>
- NSS Certificate database.
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>key4.db</term>
- <listitem><para>
- NSS Key database.
- </para></listitem>
- </varlistentry>
- </variablelist>
- <para>
- When SELinux runs in enforced mode, changing this requires a similar
- change in the SELinux policy for the pluto daemon.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-cache-max-age</option>
- </term>
- <listitem>
- <para>
- The maximum age (in seconds) before a new fetch will be
- attempted. The default is 1 day.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-cache-min-age</option>
- </term>
- <listitem>
- <para>
- The minimum age (in seconds) before a new fetch will be
- attempted. The default is 1 hour.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-cache-size</option>
- </term>
- <listitem>
- <para>
- The maximum size (in number of certificates) of OCSP responses
- that will be kept in the cache. The default is 1000. Setting
- this value to 0 means the cache is disabled.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-enable</option>
- </term>
- <listitem>
- <para>
- Whether to perform Online Certificate Store Protocol ("OCSP")
- checks on those certificates that have an OCSP URI
- defined. Acceptable values are <option>yes</option> or
- <option>no</option> (the default).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-method</option>
- </term>
- <listitem>
- <para>
- The HTTP methods used for fetching OCSP data. Valid options are
- <option>get</option> (the default) and
- <option>post</option>. Note that this behaviour depends on the
- NSS crypto library that is actually performing the
- fetching. When set to the get method, post is attempted only as
- fallback in case of failure. When set to post, only the post
- method is ever used.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-strict</option>
- </term>
- <listitem>
- <para>
- if set to no, pluto is tolerant about failing to obtain an OCSP
- responses and a certificate is not rejected when the OCSP
- request fails, only when the OCSP request succeeds and lists the
- certificate as revoked. If set to yes, any failure on obtaining
- an OCSP status for a certificate will be fatal and the
- certificate will be rejected. Acceptable values are
- <option>yes</option> or <option>no</option> (the default).
- </para>
- <para>
- The strict mode refers to the NSS
- ocspMode_FailureIsVerificationFailure mode, while non-strict
- mode refers to the NSS ocspMode_FailureIsNotAVerificationFailure
- mode.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-timeout</option>
- </term>
- <listitem>
- <para>
- The time until an OCSP request is aborted and considered
- failed. The default value is 2 seconds.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-trustname</option>
- </term>
- <listitem>
- <para>
- The nickname of the certificate that has been imported into the
- NSS database of the server handling the OCSP requests. This
- requires the ocsp-uri option to be set as well. This option and
- the previous options sets the OCSP <option>default
- responder</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ocsp-uri</option>
- </term>
- <listitem>
- <para>
- The URI to use for OCSP requests instead of the default OCSP URI
- listed in the CA certificate. This requires the ocsp-trustname
- option to be set to the nick (friendly name) of the OCSP server
- certificate, which needs to be present in the NSS
- database. These option combined with the next option sets the
- OCSP <option>default responder</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='oe_conns'>
- <title>
- OPPORTUNISTIC CONNS
- </title>
- <para>
- For Opportunistic connections, the system requires creating
- special named conns that are used to implement the default policy
- groups. Currently, these names cannot be changed.
- </para>
- <programlisting><xi:include href="d.ipsec.conf/oe_conns.example" parse="text"
- xmlns:xi="http://www.w3.org/2001/XInclude"/></programlisting>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>overlapip</option>
- </term>
- <listitem>
- <para>
- a boolean (yes/no) that determines, when
- (left|right)subnet=vhost: is used, if the virtual IP claimed by
- this states created from this connection can with states created
- from other connections.
- </para>
- <para>
- Note that connection instances created by the Opportunistic
- Encryption or PKIX (x.509) instantiation system are distinct
- internally. They will inherit this policy bit.
- </para>
- <para>
- The default is no.
- </para>
- <para>
- This feature is only available with kernel drivers that support
- SAs to overlapping conns. At present only the (klips) mast
- protocol stack supports this feature.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>pam-authorize</option>
- </term>
- <listitem>
- <para>
- IKEv2 does not support receiving a plaintext username and
- password. &Libreswan; does not yet support EAP authentication
- methods for IKE. The pam-authorize=yes option performs an
- authorization call via PAM, but only includes the remote ID (not
- username or password). This allows for backends to disallow an
- ID based on non-password situations, such as "user disabled" or
- "user over quota".
- </para>
- <para>
- See also the IKEv1 option <option>xauthby=pam</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>pfs</option>
- </term>
- <listitem>
- <para>
- whether Perfect Forward Secrecy of keys is desired on the
- connection's keying channel (with PFS, penetration of the
- key-exchange protocol does not compromise keys negotiated
- earlier); Acceptable values are <option>yes</option> (the
- default) and <option>no</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>phase2</option>
- </term>
- <listitem>
- <para>
- Sets the type of SA that will be produced. Valid options are:
- <option>esp</option> for encryption (the default),
- <option>ah</option> for authentication only.
- </para>
- <para>
- The very first IPsec designs called for use of AH plus ESP to
- offer authentication, integrity and confidentiality. That dual
- protocol use was a significant burden, so ESP was extended to
- offer all three services, and AH remained as an auth/integ. The
- old mode of <option>ah+esp</option> is no longer supported in
- compliance with RFC 8221 Section 4. Additionally, AH does not
- play well with NATs, so it is strongly recommended to use ESP
- with the null cipher if you require unencrypted authenticated
- transport.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>plutodebug=<replaceable>option</replaceable></option>
- </term>
- <listitem>
- <para>
- A comma separated list of options that globally enable internal
- debug logs. For debug logs of a single connection, see
- <option>debug=</option>.
- </para>
- <note>
- <para>
- This feature is used by &Libreswan; developers when debugging
- libreswan internals. The default logs should provide
- sufficient information to diagnose most configuration and
- connection problems.
- </para>
- </note>
- <para>
-
- Below is a select list of debug options (for a complete list
- <command>ipsec whack --debug help</command>):
-
- <variablelist>
-
- <varlistentry>
- <term>
- <option>updown</option>
- </term>
- <listitem>
- <para>
- Run the &ipsec-updown.8; scripts with <command>set -v
- -x</command>. Helpful when &ipsec-updown.8; isn't
- behaving as expected.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>routing</option>
- </term>
- <listitem>
- <para>
- Dump connection changes (for instance, routed, up,
- negotiating, ...) and how they interact with the kernel.
- Helpful when debugging connection transitions, and
- corresponding updates to kernel state/policy.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>base</option>
- </term>
- <listitem>
- <para>
- In addition to <option>routing</option>, include general
- debug messages.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>cpu-usage</option>
- </term>
- <listitem>
- <para>
- Dump the CPU time consumed as an event is processed.
- Only recommended when diagnosing performance problems.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>refcnt</option>
- </term>
- <listitem>
- <para>
- Dump all changes to all reference counters. Only
- recommended when tracking down a memory leak.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>all</option>
- </term>
- <listitem>
- <para>
- Equivalent to <option>routing/</option>,
- <option>base</option>, <option>cpu-usage</option>, and
- <option>refcnt</option>. Recommend using either
- <option>routing</option>, or <option>base</option>
- instead.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>crypt</option>
- </term>
- <listitem>
- <para>
- Dump changes to reference counters. Only recommended
- when debugging code making calls into the &NSS; library.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>private</option>
- </term>
- <listitem>
- <para>
- Dump the cryptographic material used by the IKE and
- Child SAs. The format is similar to that expected by
- <command>tcpdump</command> and
- <command>wireshark</command>.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
- <option>tmi</option>
- </term>
- <listitem>
- <para>
- It stands for Too Much Information. Need we say more?
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-
- All lines of debugging output are prefixed with "|" to
- distinguish them from normal diagnostic messages (the the
- command <command>grep -v -e '|' pluto.log</command> can be used
- to filter out the debug logs).
-
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>policy-label</option>
- </term>
- <listitem>
- <para>
- The string representation of an access control security label
- that is interpreted by the Linux Security Module (e.g. SELinux)
- for use with Labeled IPsec.
- </para>
- <para>
- For example, <option>policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023</option>
- </para>
- <para>
- Labeled IPsec support is IKEv2 only.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1 id='policy_group_files'>
- <title>
- POLICY GROUP FILES
- </title>
- <para>
- The optional files under
- <filename>@@IPSEC_CONFDDIR@@/policies</filename>,
- including
- </para>
- <para>
- <filename>@@IPSEC_CONFDDIR@@/policies/clear</filename>
- <filename>@@IPSEC_CONFDDIR@@/policies/clear-or-private</filename>
- <filename>@@IPSEC_CONFDDIR@@/policies/private-or-clear</filename>
- <filename>@@IPSEC_CONFDDIR@@/policies/private</filename>
- <filename>@@IPSEC_CONFDDIR@@/policies/block</filename>
- </para>
- <para>
- may contain policy group configuration information to supplement
- <option>ipsec.conf</option>. Their contents are not
- security-sensitive.
- </para>
- <para>
- These files are text files. Each consists of a list of CIDR
- blocks, one per line. White space followed by # followed by
- anything to the end of the line is a comment and is ignored, as
- are empty lines.
- </para>
- <para>
- A connection in <filename>ipsec.conf</filename> that has
- <option>right=%group</option> or
- <option>right=%opportunisticgroup</option> is a policy group
- connection. When a policy group file of the same name is loaded at
- system start, the connection is instantiated such that each CIDR
- block serves as an instance's <option>right</option> value. The
- system treats the resulting instances as normal connections.
- </para>
- <para>
- For example, given a suitable connection definition
- <option>private</option>, and the file
- <filename>@@IPSEC_CONFDDIR@@/policies/private</filename> with an
- entry 192.0.2.3, the system creates a connection instance
- <option>private#192.0.2.3.</option> This connection inherits all
- details from <option>private</option>, except that its right
- client is 192.0.2.3.
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ppk-ids</option>
- </term>
- <listitem>
- <para>
- EXPERIMENTAL: Specify which PPK_ID's to look for in .secrets
- file. The value must be a string (enclosed in quotes)
- containing a comma-separated list with PPK_ID's. Whitespaces
- cannot be a part of PPK_ID, i.e., they will be seen as a
- delimiter. If some PPK_ID's are specified and PPK feature is
- enabled (<option>ppk=</option>), one of the PPK secrets must
- have an ID matching one of the specified PPK_ID's. If this
- option is not set and the PPK feature is enabled, any matching
- PPK secret will be used.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>ppk</option>
- </term>
- <listitem>
- <para>
- EXPERIMENTAL: Post-quantum preshared keys (PPKs) to be
- used. Currently the accepted values are <option>propose</option>
- or <option>yes</option> (the default), signifying we propose to
- use PPK for this connection; <option>insist</option>, signifying
- we allow communication only if PPK is used for key derivation;
- <option>never</option> or <option>no</option>, signifying that
- PPK should not be used for key derivation. PPKs can be used in
- connections that allow only IKEv2. In libreswan that would mean
- that ikev2 option must have value <option>insist</option>. This
- feature is based on RFC 8784.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>priority</option>
- </term>
- <listitem>
- <para>
- The priority in the kernel SPD/SAD database, when matching up
- packets. Each kernel (XFRM, OSX, etc) has its own mechanism
- for setting the priority. Setting this option to non-zero
- passes the priority to the kernel stack unmodified. The
- maximum value depends on the stack. It is recommended not to
- exceed 65536
- </para>
- <para>
- XFRM use a priority system based on "most specific match
- first". It uses an internal algorithm to calculate these based
- on network prefix length, protocol and port selectors. A lower
- value means a higher priority.
- </para>
- <para>
- Typical values are about the 2000 range. These can be seen on
- the XFRM stack using <option>ip xfrm policy</option> when the
- connection is up. For "anonymous IPsec" or Opportunistic
- Encryption based connections, a much lower priority (65535) is
- used to ensure administrator configured IPsec always takes
- precedence over opportunistic IPsec.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftprotoport=&ip_protoport;</option>
- </term>
- <term>
- <option>rightprotoport=&ip_protoport;</option>
- </term>
- <listitem>
- <para>
- allowed protocols and ports over connection, also called Port
- Selectors. The argument is in the form <option>protocol</option>,
- which can be a number or a name
- that will be looked up in <option>/etc/protocols</option>,
- such as <option>leftprotoport=icmp</option>, or in the form of
- <option>protocol/port</option>, such as <option>tcp/smtp</option>.
- Ports can be defined as a number
- (eg. 25) or as a name (eg smtp) which will be looked up in
- <option>/etc/services</option>. A special keyword
- <option>%any</option> can be used to allow all
- ports of a certain protocol. The most common use of this option
- is for L2TP connections to only allow l2tp packets (UDP port
- 1701), eg: <option>leftprotoport=17/1701</option>.
- </para>
-
- <para>
- To filter on specific icmp type and code, use the higher 8 bits
- for type and the lower 8 bits for port. For example, to allow
- icmp echo packets (type 8, code 0) the 'port' would be 0x0800,
- or 2048 in decimal, so you configure
- <option>leftprotoport=icmp/2048</option>. Similarly, to
- allow ipv6-icmp Neighbour Discovery which has type 136 (0x88)
- and code 0(0x00) this becomes 0x8800 or in decimal 34816
- resulting in <option>leftprotoport=ipv6-icmp/34816</option>.
- </para>
-
- <para>
- Some clients, notably older Windows XP and some Mac OSX clients,
- use a random high port as source port. In those cases
- <option>rightprotoport=17/%any</option> can be used to allow all
- UDP traffic on the connection. Note that this option is part of
- the proposal, so it cannot be arbitrarily left out if one end
- does not care about the traffic selection over this connection -
- both peers have to agree. The Port Selectors show up in the
- output of <command>ipsec status</command> eg:<option>"l2tp":
- 193.110.157.131[@aivd.libreswan.org]:7/1701...%any:17/1701</option>.
- This option only filters outbound traffic. Inbound traffic
- selection must still be based on firewall rules activated by an
- updown script. The environment variables
- <envar>PLUTO_MY_PROTOCOL</envar>,
- <envar>PLUTO_PEER_PROTOCOL</envar>,
- <envar>PLUTO_MY_PORT</envar>, and <envar>PLUTO_PEER_PORT</envar>
- are available for use in <command>ipsec _updown</command>
- scripts (see &ipsec-updown.8;). Older workarounds for bugs
- involved a setting of <option>17/0</option> to denote
- <option>any single UDP port</option> (not UDP port 0). Some
- clients, most notably OSX, uses a random high port, instead of
- port 1701 for L2TP.
- </para>
-
- <important>
- <title>
- Use with <option>leftsubnet=</option>.
- </title>
- <para>
- With IKEv2, the <option>leftsubnet=</option> specification can
- include the protocol and port. Combining that syntax with
- <option>protoport=</option> is not supported.
- </para>
- </important>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>protostack</option>
- </term>
- <listitem>
- <para>
- decide which protocol stack is going to be used. Valid values
- are "xfrm" and "bsd". This option should no longer be set, as
- the stack is currently auto-detected. The values "klips, "mast",
- "netkey", "native", "kame" and "auto" are obsolete. The option
- is kept only because it is suspected that Linux and BSD will get
- userspace stacks with IPsec support soon (such as dpdk).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>redirect-to</option>
- </term>
- <listitem>
- <para>
- Where to send remote peers to via the
- <option>send-redirect</option> option. This can be an IP address
- or hostname (FQDN).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>reject-simultaneous-ike-auth</option>
- </term>
- <listitem>
-
- <para>
- When libreswan receives IKE_AUTH request from the peer while having
- an outstanding IKE_AUTH request for the same connection, reject with
- AUTHENTICATION_FAILED to avoid potential SA mismatch issues. This only
- applies to permanent IKEv2 connections so that the revival mechanism
- ensures connection retry.
- </para>
-
- <para>
- The accepted values are <option>yes</option> (the default) or
- <option>no</option>.
- </para>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>rekey</option>
- </term>
- <listitem>
- <para>
- whether a connection should be renegotiated when it is about to
- expire; acceptable values are <option>yes</option> (the default)
- and <option>no</option>. The two ends need not agree, but while
- a value of <option>no</option> prevents Pluto from requesting
- renegotiation, it does not prevent responding to renegotiation
- requested from the other end, so <option>no</option> will be
- largely ineffective unless both ends agree on it.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>rekeyfuzz</option>
- </term>
- <listitem>
- <para>
- maximum percentage by which <option>rekeymargin</option> should
- be randomly increased to randomize rekeying intervals (important
- for hosts with many connections); acceptable values are an
- integer, which may exceed 100, followed by a `%' (default set by
- &ipsec-pluto.8;,
- currently <option>100%</option>). The value of
- <option>rekeymargin</option>, after this random increase, must
- not exceed <option>salifetime</option>. The value
- <option>0%</option> will suppress time randomization. Relevant
- only locally, other end need not agree on it.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>rekeymargin</option>
- </term>
- <listitem>
- <para>
- how long before connection expiry or keying-channel expiry
- should attempts to negotiate a replacement begin; acceptable
- values as for <option>salifetime</option> (default
- <option>9m</option>). Relevant only locally, other end need not
- agree on it.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>remote-peer-type</option>
- </term>
- <listitem>
- <para>
- Set the remote peer type. This can enable additional processing
- during the IKEv1 negotiation. Acceptable values are
- <option>cisco</option> or <option>ietf</option> (the
- default). When set to cisco, support for Cisco IPsec gateway
- redirection and Cisco obtained DNS and domainname are
- enabled. This includes automatically updating (and restoring)
- /etc/resolv.conf. These options require that XAUTH is also
- enabled on this connection.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>replay-window</option>
- </term>
- <listitem>
- <para>
- The size of the IPsec SA replay window protection in packets.
- Kernels (Linux, and most BSDs) support a window size of at least
- 2040 packets. The default replay window size is 128 packets.
- </para>
- <para>
- A value of 0 disables replay protection. Disabling of replay
- protection is sometimes used on a pair of IPsec servers in a
- High Availability setup, or on servers with very unpredictable
- latency, such as mobile networks, which can cause an excessive
- amount of out of order packets.
- </para>
- <para>
- Disabling replay protection will also disable Extended Sequence
- Numbers (esn=no), as advise from RFC 4303 caused some stacks to
- not support ESN without a replay-window.
- </para>
- <para>
- Note: on Linux, sequence errors can be seen in
- /proc/net/xfrm_stat.
- </para>
- <para>
- Note: the BSD <option>setkey</option> utility displays the
- replay window size in bytes (8 packets per byte) and not
- packets.
- </para>
- <para>
- Technically, at least the Linux kernel can install IPsec SA's
- with an IPsec SA Sequence Number, but this is currently not
- supported by libreswan.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>reqid</option>
- </term>
- <listitem>
- <para>
- a unique identifier used to match IPsec SAs using iptables with
- XFRM. This identifier is normally automatically allocated in
- groups of 4. It is exported to the _updown script as REQID. On
- Linux, reqids are supported with IP Connection Tracking and NAT
- (iptables). Automatically generated values use the range 16380
- and higher. Manually specified reqid values therefore must be
- between 1 and 16379.
- </para>
- <para>
- Automatically generated reqids use a range of 0-3 (eg 16380-16383 for the
- first reqid). These are used depending on the exact policy (AH, AH+ESP,
- IPCOMP, etc).
- </para>
- <para>
- WARNING: Manually assigned reqids are all
- identical. Instantiations of connections (those using %any
- wildcards) will all use the same reqid. If you use manual
- assigning you should make sure your connections only match
- single road warrior only or you break multiple road warriors
- behind same NAT router because this feature requires unique
- reqids to work.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>require-id-on-certificate</option>
- </term>
- <listitem>
- <para>
- When using certificates, check whether the IKE peer ID is
- present as a subjectAltName (SAN) on the peer
- certificate. Accepted values are <option>yes</option> (the
- default) or <option>no</option>. This check should only be
- disabled when intentionally using certificates that do not have
- their peer ID specified as a SAN on the certificate. These
- certificates violate RFC 4945 Section 3.1 and are normally
- rejected to prevent a compromised host from assuming the IKE
- identity of another host. The SAN limits the IDs that the peer
- is able to assume.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>retransmit-interval</option>
- </term>
- <listitem>
- <para>
- the initial interval time period, specified in msecs, that pluto
- waits before retransmitting an IKE packet. This interval is
- doubled for each attempt (exponential back-off). The default
- set by
- &ipsec-pluto.8;,
- currently is <option>500</option>.
- </para>
- <para>
- See also: <option>retransmit-timeout</option> and
- <option>rekey</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>retransmit-timeout</option>
- </term>
- <listitem>
- <para>
- how long a single packet, including retransmits of that packet,
- may take before the IKE attempt is aborted. If rekeying is
- enabled, a new IKE attempt is started. The default set by
- &ipsec-pluto.8;, currently is <option>60s</option>.
- </para>
- <para>
- See also: <option>retransmit-interval</option> and
- <option>rekey</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftrsasigkey</option>
- </term>
- <term>
- <option>rightrsasigkey</option>
- </term>
- <listitem>
- <para>
- the left participant's public key for RSA signature
- authentication, in base-64 encoded RFC 2537 format (with 0s
- prepended), or one of the following:
- <variablelist>
- <varlistentry>
- <term>
- <option>%none</option>
- </term>
- <listitem>
- <para>
- the same as not specifying a value (useful to override a
- default)
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>%dnsondemand</option>
- </term>
- <listitem>
- <para>
- (the default) the key is to be fetched from DNS at the
- time it is needed.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>%dnsonload</option>
- </term>
- <listitem>
- <para>
- the key is to be fetched from DNS at the time the
- connection description is read from
- <option>ipsec.conf</option>; currently this will be
- treated as <option>%none</option> if
- <option>right=%any</option> or
- <option>right=%opportunistic</option>.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>%dns</option>
- </term>
- <listitem>
- <para>
- currently treated as <option>%dnsonload</option> but
- will change to <option>%dnsondemand</option> in the
- future. The identity used for the left participant must
- be a specific host, not <option>%any</option> or
- another magic value.
- </para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>
- <option>%cert</option>
- </term>
- <listitem>
- <para>
- the information required from a certificate defined in
- <option>%leftcert</option> and automatically define
- leftid for you
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
- <caution>
- <para>
- If two connection descriptions specify different public keys
- for the same <option>leftid</option>, confusion and
- madness will ensue.
- </para>
- </caution>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>salifetime</option>
- </term>
- <listitem>
- <para>
- how long a particular instance of a connection (a set of
- encryption/authentication keys for user packets) should last,
- from successful negotiation to expiry; acceptable values are an
- integer optionally followed by <option>s</option> (a time in
- seconds) or a decimal number followed by <option>m</option>,
- <option>h</option>, or <option>d</option> (a time in minutes,
- hours, or days respectively) (default <option>8h</option>,
- maximum <option>24h</option>). Normally, the connection is
- renegotiated (via the keying channel) before it expires. The
- two ends need not exactly agree on <option>salifetime</option>,
- although if they do not, there will be some clutter of
- superseded connections on the end which thinks the lifetime is
- longer.
- </para>
- <para>
- The keywords "keylife" and "lifetime" are obsoleted aliases for
- "salifetime." Change your configs to use "salifetime" instead.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>seccomp</option>
- </term>
- <listitem>
- <para>
- Set the seccomp kernel syscall whitelisting feature. When set to
- <option>enabled</option>, if pluto calls a syscall that is not
- on the compiled-in whitelist, the kernel will assume an exploit
- is attempting to use pluto for malicious access to the system
- and terminate the pluto daemon. When set to
- <option>tolerant</option>, the kernel will only block the rogue
- syscall and pluto will attempt to continue. If set to
- <option>disabled</option>, pluto is allowed to call any syscall
- offered by the kernel, although it might be restricted via other
- security mechanisms, such as capabilities, SElinux, AppArmor or
- other OS security features.
- </para>
- <para>
- By default, seccomp is disabled, as there is a significant
- performance penalty, custom updown scripts could trigger false
- positives, and system library updates could also trigger false
- positives. A false positive (or real malicious remote code
- execution of a bad syscall) will cause the pluto daemon to crash
- or hang.
- </para>
- <para>
- <option>Warning:</option> The restrictions of pluto are
- inherited by the updown scripts, so these scripts are also not
- allowed to use syscalls that are forbidden for pluto.
- </para>
- <para>
- To see if a seccomp rule got triggered, you must run with
- seccomp=enabled, and keep an eye on
- <option>type=SECCOMP</option> messages in the audit log (usually
- <option>/var/log/audit/audit.log</option>. Note that logging can
- be delayed by many seconds.
- </para>
- <para>
- This feature can be tested using <command>ipsec whack
- --seccomp-crashtest</command>. <option>Warning: </option> With
- seccomp=enabled, pluto will be terminated by the kernel. With
- seccomp=tolerant or seccomp=disabled, pluto will report the
- results of the seccomp test. SECCOMP will log the forbidden
- syscall numbers to the audit log, but only with
- seccomp=enabled. The tool scmp_sys_resolver from the libseccomp
- development package can be used to translate the syscall number
- into a name. See programs/pluto/pluto_seccomp.c for the list of
- allowed syscalls.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>secretsfile</option>
- </term>
- <listitem>
- <para>
- pathname of the file that stores the secret credentials such as
- preshared keys (PSKs). See <option>man ipsec.secrets</option>
- for the syntax. The default value is
- <filename>@@IPSEC_SECRETS@@</filename>.
- </para>
- </listitem>
-</varlistentry>
--- /dev/null
+<refsect1 id='author'>
+ <title>AUTHOR</title>
+ <para>
+ <author><personname><firstname>Paul</firstname><surname>Wouters</surname></personname></author>
+ </para>
+</refsect1>
--- /dev/null
+<refsect1 id='bugs'>
+ <title>
+ BUGS
+ </title>
+ <para>
+ Before reporting new bugs, please ensure you are using the latest
+ version of Libreswan.
+ </para>
+
+ <para>
+ When <option>type</option> or <option>failureshunt</option> is set
+ to <option>drop</option> or <option>reject,</option> &Libreswan;
+ blocks outbound packets using eroutes, but assumes inbound
+ blocking is handled by the firewall. &Libreswan; offers firewall
+ hooks via an “updown” script. However, the default
+ <command>ipsec _updown</command> provides no help in controlling a
+ modern firewall.
+ </para>
+
+ <para>
+ Including attributes of the keying channel (authentication
+ methods, <option>ikelifetime</option>, etc.) as an
+ attribute of a connection, rather than of a participant pair, is
+ dubious and incurs limitations.
+ </para>
+
+ <para>
+ The use of <option>%any</option> with the <option>protoport=</option>
+ option is ambiguous. Should the SA permits any port through or should
+ the SA negotiate any single port through? The first is a basic conn with
+ a wildcard. The second is a template. The second is the current behaviour,
+ and it's wrong for quite a number of uses involving TCP. The keyword
+ <option>%one</option> may be introduced in the
+ future to separate these two cases.
+ </para>
+
+ <para>
+ It would be good to have a line-continuation syntax, especially
+ for the very long lines involved in RSA signature keys.
+ </para>
+
+ <para>
+ The ability to specify different identities, <option>authby</option>,
+ and public keys for different automatic-keyed connections between
+ the same participants is misleading; this doesn't work dependably
+ because the identity of the participants is not known early enough.
+ This is especially awkward for the “Road Warrior” case,
+ where the remote IP address is specified as <literal>0.0.0.0</literal>,
+ and that is considered to be the “participant” for such
+ connections.
+ </para>
+
+ <para>
+ If conns are to be added before DNS is available, <option>left=</option>
+ <option>FQDN</option>, <option>leftnextop=</option><option>FQDN</option>,
+ and <option>leftrsasigkey=%dnsonload</option> will fail.
+ &ipsec-pluto.8;
+ does not actually use the public key for our side of a conn but it
+ isn't generally known at a add-time which side is ours (Road
+ Warrior and Opportunistic conns are currently exceptions).
+ </para>
+
+</refsect1>
--- /dev/null
+<refsect1 id='choosing_a_connection'>
+ <title>
+ CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE
+ </title>
+ <para>
+ When choosing a connection to apply to an outbound packet caught
+ with a <option>%trap,</option> the system prefers
+ the one with the most specific eroute that includes the packet's
+ source and destination IP addresses. Source subnets are examined
+ before destination subnets. For initiating, only routed
+ connections are considered. For responding, unrouted but added
+ connections are considered.
+ </para>
+ <para>
+ When choosing a connection to use to respond to a negotiation
+ that doesn't match an ordinary conn, an opportunistic connection may
+ be instantiated. Eventually, its instance will be /32 -> /32, but
+ for earlier stages of the negotiation, there will not be enough
+ information about the client subnets to complete the
+ instantiation.
+ </para>
+</refsect1>
--- /dev/null
+<refsect1 id='description'>
+
+ <title>
+ DESCRIPTION
+ </title>
+
+ <para>
+ The <filename>ipsec.conf</filename> file specifies most
+ configuration and control information for the &Libreswan; IPsec
+ subsystem (the major exception is secrets for authentication; see
+ &ipsec.secrets.5;). &Libreswan; reads this file during start up
+ (technically, if &Libreswan;'s daemon &ipsec-pluto.8; is invoked
+ directly then the file <filename>ipsec.conf</filename> is not
+ needed; however, this is not recommended). Configurations can be
+ added using eithe this configuration file or by using
+ <command>ipsec whack</command> directly.
+ </para>
+
+ <para>
+ <filename>ipsec.conf</filename> is a text file, consisting of one
+ or more <option>sections</option>.
+ </para>
+
+ <para>
+ Within the file, white space followed by <option>#</option>
+ followed by anything to the end of the line is a comment and is
+ ignored, as are empty lines that are not within a section.
+ </para>
+
+ <para>
+ A line that contains <option>include</option> and a file name,
+ separated by white space, is replaced by the contents of that
+ file. If the file name is not a full pathname, it is considered
+ to be relative to the directory that contains the including file.
+ Such inclusions can be nested. Only a single filename may be
+ supplied, and it may not contain white space, but it may include
+ shell wildcards (see &glob.3;); for example:
+ </para>
+
+ <para>
+ <option>include</option> <filename>/etc/ipsec.d/*.conf</filename>
+ </para>
+
+ <para>
+ The intention of the include facility is mostly to permit keeping
+ information on connections, or sets of connections, separate from
+ the main configuration file. This permits such connection
+ descriptions to be changed, copied to the other security gateways
+ involved, etc., without having to constantly extract them from the
+ configuration file and then insert them back into it. Note also
+ the <option>also</option> parameters (described below) which
+ permit splitting a single logical section (e.g. a connection
+ description) into several distinct sections.
+ </para>
+
+ <para>
+ The first significant line of the file may specify a version of
+ this specification for backwards compatibility with freeswan and
+ openswan. It is ignored and unused. For compatibility with
+ openswan, specify:
+ </para>
+
+ <para>
+ <option>version 2</option>
+ </para>
+
+ <para>
+ A section begins with a line of the form:
+ </para>
+
+ <para>
+ <replaceable>type</replaceable> <replaceable>name</replaceable>
+ </para>
+
+ <para>
+ where <replaceable>type</replaceable> indicates what type of
+ section follows, and <replaceable>name</replaceable> is an
+ arbitrary name that distinguishes the section from others of the
+ same type. Names must start with a letter and may contain only
+ letters, digits, periods, underscores, and hyphens. All
+ subsequent non-empty lines that begin with white space are part of
+ the section; comments within a section must begin with white space
+ too. There may be only one section of a given type with a given
+ name.
+ </para>
+
+ <para>
+ There are two types of section: a <option>config</option>
+ section specifies general configuration information for
+ &Libreswan;, and a
+ <option>conn</option> section specifies an IPsec connection.
+ </para>
+
+ <para>
+ Lines within the section are generally of the form
+ </para>
+
+ <para>
+ <replaceable>parameter</replaceable>=<replaceable>value</replaceable>
+ </para>
+
+ <para>
+ (note the mandatory preceding white space). There can be white
+ space on either side of the <option>=</option>. Parameter
+ names follow the same syntax as section names, and are specific to
+ a section type. Unless otherwise explicitly specified, no
+ parameter name may appear more than once in a section.
+ </para>
+
+ <para>
+ An empty <replaceable>value</replaceable> stands for the empty
+ string. A non-empty <replaceable>value</replaceable> may contain
+ white space only if the entire <replaceable>value</replaceable> is
+ enclosed in double quotes (<option>"</option>); a
+ <replaceable>value</replaceable> cannot itself contain a double
+ quote, nor may it be continued across more than one line.
+ </para>
+
+ <para>
+ Numeric values are specified to be either an integer (a sequence
+ of digits) or a decimal number (sequence of digits optionally
+ followed by `.' and another sequence of digits).
+ </para>
+
+ <para>
+ There is currently one parameter that is available in any type of
+ section:
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term><option>also=<replaceable>value</replaceable></option></term>
+ <listitem>
+ <para>
+ The <replaceable>value</replaceable> is a section name. The
+ parameters of that section are inserted, in place, into this
+ section (i.e., as if they had been written as part of and at
+ that point in the section's definition). The specified
+ section must exist, and must have the same section type.
+ Multiple and nested <option>also</option> are permitted
+ (duplicate insertions of the same section are ignored).
+ When the same <option>parameter</option> appears in
+ multiple sections, the first definition encountered is used.
+ This allows, for example, keeping the encryption keys for a
+ connection in a separate file from the rest of the
+ description, by using both an <option>also</option> parameter
+ and an <option>include</option> line.
+ </para>
+ <para>
+ Putting <option>also</option> at the end of the section after
+ any <option>parameter</option> definitions is
+ recommended. This way, the section's
+ <option>parameter</option>
+ <replaceable>value</replaceable> overrides
+ <option>also</option> sections.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ A section with name <option>%default</option> specifies
+ defaults for sections of the same type. For each parameter in it,
+ any section of that type that does not have a parameter of the
+ same name gets a copy of the one from the
+ <option>%default</option> section. There may be multiple
+ <option>%default</option> sections of a given type and
+ multiple default values for a given parameter (the last
+ <option>value</option> is used).
+ <option>%default</option> sections may not contain any
+ <option>also</option> parameters.
+ </para>
+
+</refsect1>
--- /dev/null
+<refsect1 id='default_policy_groups'>
+ <title>
+ DEFAULT POLICY GROUPS
+ </title>
+ <para>
+ The standard &Libreswan; install includes several policy groups
+ which provide a way of classifying possible peers into IPsec
+ security classes: <option>private</option> (talk encrypted only),
+ <option>private-or-clear</option> (prefer encryption),
+ <option>clear-or-private</option> (respond to requests for
+ encryption), <option>clear</option> and <option>block</option>.
+ </para>
+</refsect1>
--- /dev/null
+
+ <title>CONN SECTIONS</title>
+ <para>
+ A <option>conn</option> section contains a <option>connection
+ specification</option>, defining a network connection to be made
+ using IPsec. The name given is arbitrary, and is used to identify
+ the connection to &ipsec.8; sub-commands. Here's a simple
+ example:
+ </para>
+
+ <programlisting><xi:include href="d.ipsec.conf/exampleleftright.example" parse="text"
+ xmlns:xi="http://www.w3.org/2001/XInclude"/></programlisting>
+
+ <para>
+ A note on terminology... In automatic keying, there are two
+ kinds of communications going on: transmission of user IP packets, and
+ gateway-to-gateway negotiations for keying, rekeying, and general
+ control. The data path (a set of “Child SAs”) used for
+ user packets is herein referred to as the “connection”;
+ the path used for negotiations (built with “IKE SAs”)
+ is referred to as the “keying channel”.
+ </para>
+
+ <para>
+ To avoid trivial editing of the configuration file to suit it to each system
+ involved in a connection,
+ connection specifications are written in terms of
+ <option>left</option>
+ and
+ <option>right</option>
+ participants,
+ rather than in terms of local and remote.
+ Which participant is considered
+ <option>left</option>
+ or
+ <option>right</option>
+ is arbitrary;
+ IPsec figures out which one it is being run on based on internal information.
+ This permits using identical connection specifications on both ends.
+ There are cases where there is no symmetry; a good convention is to
+ use
+ <option>left</option>
+ for the local side and
+ <option>right</option>
+ for the remote side (the first letters are a good mnemonic).
+ </para>
+
+ <para>
+ Many of the parameters relate to one participant or the other;
+ only the ones for
+ <option>left</option>
+ are listed here, but every parameter whose name begins with
+ <option>left</option>
+ has a
+ <option>right</option>
+ counterpart,
+ whose description is the same but with
+ <option>left</option>
+ and
+ <option>right</option>
+ reversed.
+ </para>
+
+ <para>
+ Parameters are optional unless marked “(required)”
+ </para>
+
--- /dev/null
+<refsect1 id='files'>
+ <title>
+ FILES
+ </title>
+ <para>
+ <filename>/etc/ipsec.conf</filename>
+ <filename>/etc/ipsec.d/policies/clear</filename>
+ <filename>/etc/ipsec.d/policies/clear-or-private</filename>
+ <filename>/etc/ipsec.d/policies/private-or-clear</filename>
+ <filename>/etc/ipsec.d/policies/private</filename>
+ <filename>/etc/ipsec.d/policies/block</filename>
+ </para>
+</refsect1>
--- /dev/null
+<refsect1 id='history'>
+ <title>
+ HISTORY
+ </title>
+ <para>
+ Designed for the FreeS/WAN project <<ulink
+ url='https://www.freeswan.org'>https://www.freeswan.org</ulink>>
+ by Henry Spencer.
+ </para>
+</refsect1>
--- /dev/null
+<refsect1 id='oe_conns'>
+ <title>
+ OPPORTUNISTIC CONNS
+ </title>
+ <para>
+ For Opportunistic connections, the system requires creating
+ special named conns that are used to implement the default policy
+ groups. Currently, these names cannot be changed.
+ </para>
+ <programlisting><xi:include href="d.ipsec.conf/oe_conns.example" parse="text"
+ xmlns:xi="http://www.w3.org/2001/XInclude"/></programlisting>
+</refsect1>
--- /dev/null
+<refsect1 id='policy_group_files'>
+ <title>
+ POLICY GROUP FILES
+ </title>
+ <para>
+ The optional files under
+ <filename>@@IPSEC_CONFDDIR@@/policies</filename>,
+ including
+ </para>
+ <para>
+ <filename>@@IPSEC_CONFDDIR@@/policies/clear</filename>
+ <filename>@@IPSEC_CONFDDIR@@/policies/clear-or-private</filename>
+ <filename>@@IPSEC_CONFDDIR@@/policies/private-or-clear</filename>
+ <filename>@@IPSEC_CONFDDIR@@/policies/private</filename>
+ <filename>@@IPSEC_CONFDDIR@@/policies/block</filename>
+ </para>
+ <para>
+ may contain policy group configuration information to supplement
+ <option>ipsec.conf</option>. Their contents are not
+ security-sensitive.
+ </para>
+ <para>
+ These files are text files. Each consists of a list of CIDR
+ blocks, one per line. White space followed by # followed by
+ anything to the end of the line is a comment and is ignored, as
+ are empty lines.
+ </para>
+ <para>
+ A connection in <filename>ipsec.conf</filename> that has
+ <option>right=%group</option> or
+ <option>right=%opportunisticgroup</option> is a policy group
+ connection. When a policy group file of the same name is loaded at
+ system start, the connection is instantiated such that each CIDR
+ block serves as an instance's <option>right</option> value. The
+ system treats the resulting instances as normal connections.
+ </para>
+ <para>
+ For example, given a suitable connection definition
+ <option>private</option>, and the file
+ <filename>@@IPSEC_CONFDDIR@@/policies/private</filename> with an
+ entry 192.0.2.3, the system creates a connection instance
+ <option>private#192.0.2.3.</option> This connection inherits all
+ details from <option>private</option>, except that its right
+ client is 192.0.2.3.
+ </para>
+</refsect1>
--- /dev/null
+<refsect1 id='see_also'>
+ <title>
+ SEE ALSO
+ </title>
+ <para>
+ &ipsec.8;, &ipsec-rsasigkey.8;
+ </para>
+</refsect1>
--- /dev/null
+<refsect1>
+ <title>
+ SPECIFYING UNITS
+ </title>
+
+ <refsect2 id='unit_bytes'>
+ <title>
+ BYTE COUNTS AND BINARY DATA
+ </title>
+ <para>
+ Options, such as <option>ipsec-max-bytes</option>, that expect a
+ numeric byte count, also accept deciml fractions, and the
+ following multipliers as a suffix:
+ <variablelist>
+ <varlistentry>
+ <term><option>KiB</option></term>
+ <listitem><para>kilobytes (1024 bytes)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>MiB</option></term>
+ <listitem><para>megabytes (1024*1024 bytes)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>GiB</option></term>
+ <listitem><para>gigabytes (1024*1024*1024 bytes)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>TiB</option></term>
+ <listitem><para>terabytes (1024*1024*1024*1024 bytes)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>PiB</option></term>
+ <listitem><para>petabytes (1024*1024*1024*1024*1024 bytes)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>EiB</option></term>
+ <listitem><para>exabytes (1024*1024*1024*1024*1024*1024 bytes)</para></listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </refsect2>
+
+ <refsect2 id='unit_duration'>
+ <title>
+ DURATION
+ </title>
+ <para>
+ Options, such as <option>retransmit-timeout</option>, that
+ expect a numeric duration, also accept decimal fractions, and
+ the following multipliers as a suffix:
+ <variablelist>
+ <varlistentry>
+ <term><option>us</option></term>
+ <listitem><para>microseconds (1/1000000 seconds)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>ms</option></term>
+ <listitem><para>milliseconds (1/1000 seconds)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>s</option></term>
+ <listitem><para>seconds</para></listitem></varlistentry>
+ <varlistentry><term><option>m</option></term>
+ <listitem><para>minutes (60 seconds)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>h</option></term>
+ <listitem><para>hours (60*60 seconds)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>d</option></term>
+ <listitem><para>days (24*60*60 seconds)</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>w</option></term>
+ <listitem><para>weeks (7*24*60*60 seconds)</para></listitem>
+ </varlistentry>
+ </variablelist>
+ For instance, 1ms and 1000us, 0.5s and 500ms, 1.5h and 90m, are
+ each equivalent.
+ </para>
+</refsect2>
+
+</refsect1>
+++ /dev/null
-<refsect1 id='see_also'>
- <title>
- SEE ALSO
- </title>
- <para>
- &ipsec.8;, &ipsec-rsasigkey.8;
- </para>
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>seedbits</option>
- </term>
- <listitem>
- <para>
- Pluto uses the NSS crypto library as its random source. Some
- government Three Letter Agencies require that pluto reads
- additional bits from /dev/random and feed these into the NSS RNG
- before drawing random from the NSS library, despite the NSS
- library itself already seeding its internal state. This process
- can block pluto for an extended time during startup, depending
- on the entropy of the system. Therefore, the default is to not
- perform this redundant seeding. If specifying a value, it is
- recommended to specify at least 460 bits (for FIPS) or 440 bits
- (for BSI).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term><option>send-no-esp-tfc</option></term>
- <listitem>
- <para>
- Whether or not to tell the remote peer that we do not support Traffic Flow Confidentiality ("TFC")
- (RFC-4303). Possible values are <option>no</option> (the default) which allows the
- peer to use TFC or <option>yes</option> which prevents to peer from using TFC.
- This does not affect whether this endpoint uses TFC, which only depends on the
- local <option>tfc</option> setting. This option is only valid for IKEv2.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>send-redirect</option>
- </term>
- <listitem>
- <para>
- Whether to send requests for the remote peer to redirect
- IKE/IPsec SA's during IKE_AUTH. Valid options are
- <option>no</option> (the default) and <option>yes</option>. If
- set, the option <option>redirect-to=</option> must also be set
- to indicate where to redirect peers to. For redirection during
- IKE_SA_INIT exchange, see the <option>global-redirect=</option>
- and <option>global-redirect-to=</option> options. Runtime
- redirects can be triggered via the <command>ipsec
- redirect</command> command.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>send-vendorid</option>&yN_options;
- </term>
- <listitem>
- <para>
- whether to send our Vendor ID during IKE. Acceptable values
- are: <option>no</option> (the default) and
- <option>yes</option>. The vendor id sent can be configured using
- the "config setup" option <option>myvendorid=</option>. It
- defaults to OE-Libreswan-VERSION.
- </para>
- <para>
- Vendor ID's can be useful in tracking interoperability
- problems. However, specific vendor identification and software
- versions can be useful to an attacker when there are known
- vulnerabilities to a specific vendor/version.
- </para>
- <para>
- The prefix OE stands for "Opportunistic Encryption". This prefix
- was historically used by The FreeS/WAN Project and The Openswan
- Project (openswan up to version 2.6.38) and in one Xeleranized
- openswan versions (2.6.39). Further Xeleranized openswan's use
- the prefix OSW.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>sendca</option>
- </term>
- <listitem>
- <para>
- How many of the available X.509 intermediate CA certificates to
- send with the End certificate (root CA's are never sent).
- Specifying <option>none</option> sends no intermediate
- certificates, <option>issuer</option> sends the End
- certificate's issuing intermediate CA, and <option>all</option>
- sends all intermediate CAs (the default).
- </para>
- <para>
- Prior to &Libreswan; version 5.3, the default was
- <option>none</option> (that is, no intermediate CAs were sent).
- &Libreswan; never sends intermediate certificates when
- establishing a connection using IKEv1's Agressive Mode.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftsendcert</option>
- </term>
- <term>
- <option>rightsendcert</option>
- </term>
- <listitem>
- <para>
- This option configures when &Libreswan; will send &X.509;
- certificates to the remote host. Acceptable values are:
-
- <variablelist spacing="compact">
-
- <varlistentry>
- <term><option>yes</option></term>
- <term><option>always</option></term>
- <listitem><para>always send a certificate</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>sendifasked</option></term>
- <listitem><para>send a certificate when the peer asks for it
- (for instance by sending a CERTREQ
- payload)</para></listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>no</option></term>
- <term><option>never</option></term>
- <listitem><para>never send a certificate</para></listitem>
- </varlistentry>
-
- </variablelist>
-
- The default for this option is <option>always</option>. Note
- that while <option>always</option> is suboptimal, setting this
- to <option>sendifasked</option> may break compatibility with
- other vendor's IPsec implementations, such as &Cisco;. If you
- find that you are getting errors about no ID/Key found, you
- likely need to revert this option to <option>always</option>.
- </para>
-
- <para>
- This option was added in &Libreswan; 2.5.14; in &Libreswan;
- 2.28, the default was changed from <option>sendifasked</option>
- to <option>always</option>; and in &Libreswan; 3.0, the related
- and obsolete global option <option>nocrsend=</option> was
- removed.
- </para>
-
- </listitem>
-</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>audit-log</option>=&Yn_options;
+ </term>
+ <listitem>
+ <para>
+ Whether pluto should produce Linux Auditing System log messages.
+ If enabled, pluto will log <option>start</option>,
+ <command>stop</command> and <option>fail</option> for the
+ negotiation of IKE and IPsec SA's. The kernel will also log
+ success and failures for actually adding and removing IPsec SA's
+ from the kernel's SADB. Valid options are
+ <option>yes</option>(the default) and <option>no</option>. On
+ non-Linux systems, this option is ignored. If enabled but the
+ kernel is lacking audit support, audit messages are not sent.
+ If the kernel has audit support and using it fails, pluto will
+ abort. Note that for compliance reasons, audit log messages
+ contain the relevant IP addresses, even if
+ <option>logip=no</option>.
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3, when <command>pluto</command>
+ was invoked directly and without a configuration file, this
+ option was set to <option>no</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>crl-strict=</option>
+ </term>
+ <listitem>
+ <para>
+ if not set, pluto is tolerant about missing or expired X.509
+ Certificate Revocation Lists (CRL's), and will allow peer
+ certificates as long as they do not appear on an expired CRL.
+ When this option is enabled, all connections with an expired or
+ missing CRL will be denied. Active connections will be
+ terminated at rekey time. This setup is more secure, but
+ vulnerable to downtime if the CRL expires. Acceptable values
+ are <option>yes</option> or <option>no</option> (the default).
+ </para>
+ <para>
+ This option used to be called <option>strictcrlpolicy</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term><option>crl-timeout</option></term>
+ <listitem>
+ <para>
+ The timeout for used when fetching CRLs. The default is 5s.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>crlcheckinterval</option>
+ </term>
+ <listitem>
+ <para>
+ interval expressed in second units, for example
+ crlcheckinterval=8h for 8 hours, after which pluto will fetch
+ new Certificate Revocation List (CRL) from crl distribution
+ points. List of used CRL distribution points are collected from
+ CA certificates and end certificates. Loaded X.509 CRL's are
+ verified to be valid and updates are imported to NSS database.
+ If set to <option>0</option>, which is also the
+ default value if this option is not specified, CRL updating is
+ disabled.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>curl-iface</option>
+ </term>
+ <listitem>
+ <para>
+ The name of the interface that is used for CURL lookups. This is
+ needed on rare situations where the interface needs to be forced
+ to be different from the default interface used based on the
+ routing table.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ddos-ike-threshold</option>
+ </term>
+ <listitem>
+ <para>
+ The number of half-open IKE SAs before the pluto IKE daemon will
+ be placed in busy mode. When in busy mode, pluto activates
+ anti-DDoS counter measures. The default is 25000. See also
+ <option>ddos-mode</option> and <command>ipsec whack
+ --ddos-XXX</command>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ddos-mode</option>
+ </term>
+ <listitem>
+ <para>
+ The startup mode of the DDoS defense mechanism. Acceptable
+ values are <option>busy</option>, <option>unlimited</option>
+ or <option>auto</option> (the default). This option can also be
+ given to the IKE daemon while running, for example by issuing
+ <command>ipsec whack --ddos--busy</command>. When
+ in busy mode, pluto activates anti-DDoS counter
+ measures. Currently, counter measures consist of requiring IKEv2
+ anti-DDoS cookies on new incoming IKE requests, and a more
+ aggressive cleanup of partially established or AUTH_NULL
+ connections.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dns-resolver=</option>
+ </term>
+ <listitem>
+ <para>
+ The DNS resolver to be configured by &ipsec-updown.8;. Both
+ <parameter>file</parameter>
+ (<filename>/etc/resolve.conf</filename>)
+ <parameter>systemd</parameter>
+ (<command>systemd-resolved</command> are recognized. The
+ configured value is passed to &ipsec-updown.8; in the
+ environment variable <envar>PLUTO_DNS_RESOLVER</envar>.
+ </para>
+ <para>
+ The default is <parameter>file</parameter>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dnssec-anchors=<filename>file</filename></option>
+ </term>
+ <listitem>
+ <para>
+ The location of a file containing additional DNSSEC Trust
+ Anchors. This can be used when a network is using split-DNS and
+ the internal hierarchy is using DNSSEC trust anchors.
+ </para>
+ <para>
+ There is no default value.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dnssec-enable</option>
+ </term>
+ <listitem>
+ <para>
+ Whether pluto should perform dnssec validation using libunbound,
+ provided libreswan was compiled with USE_DNSSEC. A value of
+ <option>yes</option> (the default) means pluto
+ should perform DNSSEC validation. Note that pluto reads the file
+ <option>/etc/resolv.conf</option> to determine
+ which nameservers to use.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dnssec-rootkey-file=<filename>rootkey</filename></option>
+ </term>
+ <listitem>
+ <para>
+ The location of the DNSSEC root zone public key file.
+ </para>
+ <para>
+ The default is <option>@@DEFAULT_DNSSEC_ROOTKEY_FILE@@</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>dumpdir=<filename><replaceable>directory</replaceable></filename></option>
+ </term>
+ <listitem>
+ <para>
+ in what directory should things started by
+ <option>setup</option> (notably the Pluto daemon) be allowed to
+ dump core? The default value is <filename>@@RUNDIR@@</filename>.
+ When SELinux runs in enforced mode, changing this requires a
+ similar change in the SELinux policy for the pluto daemon.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>expire-lifetime</option>
+ </term>
+ <listitem>
+ <para>
+ The time in seconds until the acquire kernel state times out.
+ On &Linux;, the default value, determined by
+ <filename>/proc/sys/net/core/xfrm_acq_expires</filename> is 30
+ seconds. On BSD, this option is ignored.
+ </para>
+ <para>
+ On-demand connections (such as Opportunistic,
+ <option>auto=ondemand</option>, or <command>ipsec
+ route</command>) have an IPsec trap policy installed in the
+ kernel. If an outgoing (or inbound) packet matches this policy,
+ a state is created in the kernel and then the kernel sends an
+ ACQUIRE message to the IKE daemon pluto. While this state is in
+ place, no new acquires will come in for this connection. The
+ default should be fine for most people. One use case of
+ shortening these is if opportunistc encryption is used towards
+ cloud instances that can quickly re-use IP addresses.
+ </para>
+ <para>
+ See also <option>failureshunt</option> and
+ <option>negotiationshunt</option>
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3 this option was called
+ <option>xfrmlifetime</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>expire-shunt-interval=<replaceable>seconds</replaceable></option>
+ </term>
+ <listitem>
+ <para>
+ How often to scan for Opportunistic Encryption failure shunts
+ (kernel policies) that have expired and should be removed.
+ </para>
+ <para>
+ When an Opportuistic Encryption negotiation fails, a failure
+ shunt is installed to either block (<option>drop</option>) or
+ allows(<option>pass</option>) traffic to the peer. These shunts
+ are given a lifetime of 15 minutes (see
+ <option>shuntlifetime</option>) after which time they expire and
+ should be removed. The option
+ <option>expire-shunt-interval</option> determines how frequently
+ these shunts are checked. The default interval is 20 seconds.
+ </para>
+ <para>
+ Note: because these shunts (kernel policies) are not
+ bound to a connection instance they are refered to as bare.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>global-redirect-to</option>
+ </term>
+ <listitem>
+ <para>
+ Where to send remote peers to via the <option>global-redirect</option>
+ option. This can be a list, or a single entry, of IP addresses or hostnames
+ (FQDNs). If there is a list of entries, they must be separated with
+ comma's. One specified entry means all peers will be redirected
+ to it, while multiple specified entries means peers will be
+ evenly distributed across the specified servers. This
+ configuration can be changed at runtime via the
+ <command>ipsec whack --global-redirect-to</command> command.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>global-redirect</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to send requests for the remote peer to redirect
+ IKE/IPsec SA's during IKE_SA_INIT. Valid options are
+ <option>no</option> (the default),
+ <option>yes</option> and <option>auto</option>,
+ where auto means that the requests will be sent if DDoS mode
+ is active (see <option>ddos-mode</option>). If set,
+ the option <option>global-redirect-to=</option> must also be
+ set to indicate where to redirect peers to. For specific connection
+ redirection after IKE SA authentication, see the
+ <option>send-redirect=</option> and <option>redirect-to=</option>
+ options. This configuration can be changed at runtime via the
+ <command>ipsec whack --global-redirect</command> command.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ike-socket-bufsize</option>
+ </term>
+ <listitem>
+ <para>
+ Set the IKE socket buffer size. Default size is determined by
+ the OS (as of writing, this seems to be set to 212992. On Linux
+ this is visible via /proc/sys/net/core/rmem_default and
+ /proc/sys/net/core/wmem_default. On Linux, this option uses
+ SO_RCVBUFFORCE and SO_SNDBUFFORCE so that it can override
+ rmem_max/wmem_max values of the OS. This requires CAP_NET_ADMIN
+ (which is also required for other tasks). This option can also
+ be toggled on a running system using <option>ipsec
+ whack --ike-socket-bufsize bufsize</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ike-socket-errqueue</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to enable or disable receiving socket errors via
+ IP_RECVERR. The default is enabled. This will cause the socket
+ to receive, process and log socket errors, such as ICMP
+ unreachable messages or Connection Refused messages. Disabling
+ this only makes sense on very busy servers, and even then it
+ might not make much of a difference. This option can also be
+ toggled on a running system using <option>ipsec
+ whack --ike-socket-errqueue-toggle</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ikev1-policy</option>
+ </term>
+ <listitem>
+ <para>
+ What to do with received IKEv1 packets. Valid options are
+ <option>drop</option> (default) which will
+ silently drop any received IKEv1 packet, <option>accept</option>,
+ and <option>reject</option> which will reply with an error. If
+ this option is set to drop or reject, an attempt to load an
+ IKEv1 connection will fail, as these connections would never be
+ able to receive a packet for processing.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ipsec-interface-managed</option>
+ </term>
+ <listitem>
+ <para>
+ Specify whether the IPsec Interface specified by
+ <option>ipsec-interface</option> managed by
+ &Libreswan;. Possible values are:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ <option>yes</option> (default)
+ </term>
+ <listitem>
+ <para>
+ &Libreswan; is responsible for managing the IPsec
+ Interface. For instance, creating it when needed, adding
+ the address specified by <option>interface-ip</option>,
+ installing any kernel policy or state, and marking it
+ <option>up</option> and <option>down</option>.
+ </para>
+ <para>
+ In this mode <option>ipsec-interface</option> identifies
+ the IPsec interface network device. For instance,
+ <option>ipsec-interface=1</option> specifies the network
+ device <option>ipsec1</option>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>no</option>
+ </term>
+ <listitem>
+ <para>
+ &Libreswan; assumes that the IPsec interface specified by
+ <option>ipsec-interface</option> exists and &Libreswan; is
+ only responsible for managing kernel policy and state.
+ </para>
+ <para>
+ In this mode <option>ipsec-interface</option> identifies
+ the low level kernel ID. For instance, on &Linux;,
+ <option>ipsec-interface=1</option> identifies the device
+ with the XFRM if_id 1.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ipsecdir</option>
+ </term>
+ <listitem>
+ <para>
+ Specifies a directory for administrator-controlled configuration
+ files and directories. The default value is
+ <option>@@IPSEC_CONFDDIR@@</option>. It may contain the following
+ files and directories:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>
+ passwd
+ </term>
+ <listitem>
+ <para>
+ (optional) for IKEv1 XAUTH support if not using PAM (this file
+ should not be world-readable). See README.XAUTH for more
+ information.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ nsspassword
+ </term>
+ <listitem>
+ <para>
+ (optional) passwords needed to unlock the NSS database in
+ <filename>@@IPSEC_NSSDIR@@</filename> (this file should
+ not be world-readable). See README.nss for more
+ information.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ policies/
+ </term>
+ <listitem>
+ <para>
+ a directory containing policy group configuration
+ information. See <option>POLICY GROUP
+ FILES</option> in this document for more information.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ When SELinux runs in enforced mode, changing this requires a
+ similar change in the SELinux policy for the pluto daemon.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>keep-alive</option>
+ </term>
+ <listitem>
+ <para>
+ The delay (in seconds) for NAT-T keep-alive packets, if these
+ are enabled using <option>nat-keepalive</option>
+ This parameter may eventually become per-connection.
+ </para>
+ </listitem>
+</varlistentry>
+
--- /dev/null
+<varlistentry>
+ <term>
+ <option>listen-tcp</option>
+ </term>
+ <listitem>
+ <para>
+ Whether the pluto IKE daemon should listen on the (pseudo)
+ standard TCP port <option>4500</option>. The default is
+ "no". The TCP usage complies to RFC 9329 for IKE and ESP over
+ TCP support. Connections can specify their own non-standard TCP
+ port using <option>leftikeport=</option> and
+ <option>tcp-remoteport=</option> for a non-standard peer TCP
+ port.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>listen-udp</option>
+ </term>
+ <listitem>
+ <para>
+ Whether the pluto IKE daemon should listen on the standard UDP
+ ports of <option>500</option> and <option>4500</option>. The
+ value "yes" means to listen on these ports, and is the default.
+ This should almost never be disabled. In the rare case where it
+ is known that only ever TCP or non-standard UDP ports will be
+ used, this option can disable the standard UDP
+ ports. Connections can specify their own non-standard port using
+ leftikeport=.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>listen</option>
+ </term>
+ <listitem>
+ <para>
+ IP address to listen on, defaults to ANY. Currently only
+ accepts one IP address.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>logappend</option>=&Yn_options;
+ </term>
+ <listitem>
+ <para>
+ If pluto is instructed to log to a file using
+ <option>logfile=</option>, this option determines whether the
+ log file should be appended to or overwritten. Valid options
+ are <option>yes</option> (the default) to append and
+ <option>no</option> to overwrite. Since on modern systems,
+ pluto is restarted by other daemons, such as systemd, this
+ option should be left at its default <option>yes</option> value
+ to preserve the log entries of previous runs of pluto. This
+ option is mainly of use for running the test suite, which needs
+ to create new log files from scratch.
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3 <command>pluto</command>, when
+ invoked without a config file, had this option disabled.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>logfile</option>
+ </term>
+ <listitem>
+ <para>
+ do not use syslog, but rather log to stderr, and direct stderr
+ to the argument file. This option used to be called
+ plutostderrlog=
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>logip</option>
+ </term>
+ <listitem>
+ <para>
+ If pluto is instructed to log the IP address of incoming
+ connections. Valid options are <option>yes</option> (the
+ default) and <option>no</option>. Note that this only affects
+ regular logging. Any enabled debugging via
+ <option>plutodebug=</option> will still contain IP addresses of
+ peers. This option is mostly meant for servers that want to
+ avoid logging IP addresses of incoming clients. Other
+ identifiable information might still be logged, such as ID
+ payloads and X.509 certificate details. When using ID of type
+ IP address, this option will not hide the actual IP address as
+ part of the ID. Most deployments will not want to change this
+ from the default. If logging of IP addresses is unwanted,
+ <option>audit-log=no</option> should also be set.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>logtime</option>
+ </term>
+ <listitem>
+ <para>
+ When pluto is directed to log to a file using
+ <option>logfile=</option>, this option determines whether or not
+ to log the current timestamp as prefix. Values are
+ <option>yes</option> (the default) or <option>no</option>. The
+ no value can be used to create logs without ephemeral
+ timestamps, such as those created when running the test suite.
+ This option used to be called plutostderrlogtime=
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>max-halfopen-ike</option>
+ </term>
+ <listitem>
+ <para>
+ The number of half-open IKE SAs before the IKE daemon starts
+ refusing all new IKE attempts. Established IKE peers are not
+ affected. The default value is 50000.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>myvendorid</option>
+ </term>
+ <listitem>
+ <para>
+ The string to use as our vendor id (VID) when
+ send-vendorid=yes. The default is OE-Libreswan-VERSION.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nflog-all</option>
+ </term>
+ <listitem>
+ <para>
+ If set, the NFLOG group number to log <option>all</option>
+ pre-crypt and post-decrypt traffic to. The default value of
+ <option>0</option> means no logging at all. This option is only
+ available on linux kernel 2.6.14 and later. It allows common
+ network utilities such as tcpdump, wireshark and dumpcap, to use
+ nflog:XXX pseudo interfaces where XXX is the nflog group
+ number. During startup and shutdown of the IPsec service,
+ iptables commands will be used to add or remove the global NFLOG
+ table rules. The rules are setup with the nflog-prefix
+ <option>all-ipsec</option>. See also the per-connection
+ <option>nflog</option> option.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nhelpers</option>
+ </term>
+ <listitem>
+ <para>
+ how many <option>pluto helpers</option> are started to help with
+ cryptographic operations. Pluto will start as many helpers as
+ the number of CPU's, minus 1 to dedicate to the main thread.
+ For machines with less than 4 CPU's, an equal number of helpers
+ to CPU's are started. A value of 0 forces pluto to do all
+ operations inline using the main process. A value of -1 tells
+ pluto to perform the above calculation. Any other value forces
+ the number to that amount.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>nssdir</option>
+ </term>
+ <listitem>
+ <para>
+ Specifies a directory for NSS database files. The default value
+ is <option>@@IPSEC_NSSDIR@@</option>. It may contain the
+ following files:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>pkcs11.txt</term>
+ <listitem><para>
+ Detailed info about NSS database creation parameters.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>cert9.db</term>
+ <listitem><para>
+ NSS Certificate database.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>key4.db</term>
+ <listitem><para>
+ NSS Key database.
+ </para></listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ When SELinux runs in enforced mode, changing this requires a similar
+ change in the SELinux policy for the pluto daemon.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-cache-max-age</option>
+ </term>
+ <listitem>
+ <para>
+ The maximum age (in seconds) before a new fetch will be
+ attempted. The default is 1 day.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-cache-min-age</option>
+ </term>
+ <listitem>
+ <para>
+ The minimum age (in seconds) before a new fetch will be
+ attempted. The default is 1 hour.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-cache-size</option>
+ </term>
+ <listitem>
+ <para>
+ The maximum size (in number of certificates) of OCSP responses
+ that will be kept in the cache. The default is 1000. Setting
+ this value to 0 means the cache is disabled.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-enable</option>
+ </term>
+ <listitem>
+ <para>
+ Whether to perform Online Certificate Store Protocol ("OCSP")
+ checks on those certificates that have an OCSP URI
+ defined. Acceptable values are <option>yes</option> or
+ <option>no</option> (the default).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-method</option>
+ </term>
+ <listitem>
+ <para>
+ The HTTP methods used for fetching OCSP data. Valid options are
+ <option>get</option> (the default) and
+ <option>post</option>. Note that this behaviour depends on the
+ NSS crypto library that is actually performing the
+ fetching. When set to the get method, post is attempted only as
+ fallback in case of failure. When set to post, only the post
+ method is ever used.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-strict</option>
+ </term>
+ <listitem>
+ <para>
+ if set to no, pluto is tolerant about failing to obtain an OCSP
+ responses and a certificate is not rejected when the OCSP
+ request fails, only when the OCSP request succeeds and lists the
+ certificate as revoked. If set to yes, any failure on obtaining
+ an OCSP status for a certificate will be fatal and the
+ certificate will be rejected. Acceptable values are
+ <option>yes</option> or <option>no</option> (the default).
+ </para>
+ <para>
+ The strict mode refers to the NSS
+ ocspMode_FailureIsVerificationFailure mode, while non-strict
+ mode refers to the NSS ocspMode_FailureIsNotAVerificationFailure
+ mode.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-timeout</option>
+ </term>
+ <listitem>
+ <para>
+ The time until an OCSP request is aborted and considered
+ failed. The default value is 2 seconds.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-trustname</option>
+ </term>
+ <listitem>
+ <para>
+ The nickname of the certificate that has been imported into the
+ NSS database of the server handling the OCSP requests. This
+ requires the ocsp-uri option to be set as well. This option and
+ the previous options sets the OCSP <option>default
+ responder</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>ocsp-uri</option>
+ </term>
+ <listitem>
+ <para>
+ The URI to use for OCSP requests instead of the default OCSP URI
+ listed in the CA certificate. This requires the ocsp-trustname
+ option to be set to the nick (friendly name) of the OCSP server
+ certificate, which needs to be present in the NSS
+ database. These option combined with the next option sets the
+ OCSP <option>default responder</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>plutodebug=<replaceable>option</replaceable></option>
+ </term>
+ <listitem>
+ <para>
+ A comma separated list of options that globally enable internal
+ debug logs. For debug logs of a single connection, see
+ <option>debug=</option>.
+ </para>
+ <note>
+ <para>
+ This feature is used by &Libreswan; developers when debugging
+ libreswan internals. The default logs should provide
+ sufficient information to diagnose most configuration and
+ connection problems.
+ </para>
+ </note>
+ <para>
+
+ Below is a select list of debug options (for a complete list
+ <command>ipsec whack --debug help</command>):
+
+ <variablelist>
+
+ <varlistentry>
+ <term>
+ <option>updown</option>
+ </term>
+ <listitem>
+ <para>
+ Run the &ipsec-updown.8; scripts with <command>set -v
+ -x</command>. Helpful when &ipsec-updown.8; isn't
+ behaving as expected.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>routing</option>
+ </term>
+ <listitem>
+ <para>
+ Dump connection changes (for instance, routed, up,
+ negotiating, ...) and how they interact with the kernel.
+ Helpful when debugging connection transitions, and
+ corresponding updates to kernel state/policy.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>base</option>
+ </term>
+ <listitem>
+ <para>
+ In addition to <option>routing</option>, include general
+ debug messages.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>cpu-usage</option>
+ </term>
+ <listitem>
+ <para>
+ Dump the CPU time consumed as an event is processed.
+ Only recommended when diagnosing performance problems.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>refcnt</option>
+ </term>
+ <listitem>
+ <para>
+ Dump all changes to all reference counters. Only
+ recommended when tracking down a memory leak.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>all</option>
+ </term>
+ <listitem>
+ <para>
+ Equivalent to <option>routing/</option>,
+ <option>base</option>, <option>cpu-usage</option>, and
+ <option>refcnt</option>. Recommend using either
+ <option>routing</option>, or <option>base</option>
+ instead.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>crypt</option>
+ </term>
+ <listitem>
+ <para>
+ Dump changes to reference counters. Only recommended
+ when debugging code making calls into the &NSS; library.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>private</option>
+ </term>
+ <listitem>
+ <para>
+ Dump the cryptographic material used by the IKE and
+ Child SAs. The format is similar to that expected by
+ <command>tcpdump</command> and
+ <command>wireshark</command>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>tmi</option>
+ </term>
+ <listitem>
+ <para>
+ It stands for Too Much Information. Need we say more?
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ All lines of debugging output are prefixed with "|" to
+ distinguish them from normal diagnostic messages (the the
+ command <command>grep -v -e '|' pluto.log</command> can be used
+ to filter out the debug logs).
+
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>protostack</option>
+ </term>
+ <listitem>
+ <para>
+ decide which protocol stack is going to be used. Valid values
+ are "xfrm" and "bsd". This option should no longer be set, as
+ the stack is currently auto-detected. The values "klips, "mast",
+ "netkey", "native", "kame" and "auto" are obsolete. The option
+ is kept only because it is suspected that Linux and BSD will get
+ userspace stacks with IPsec support soon (such as dpdk).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>seccomp</option>
+ </term>
+ <listitem>
+ <para>
+ Set the seccomp kernel syscall whitelisting feature. When set to
+ <option>enabled</option>, if pluto calls a syscall that is not
+ on the compiled-in whitelist, the kernel will assume an exploit
+ is attempting to use pluto for malicious access to the system
+ and terminate the pluto daemon. When set to
+ <option>tolerant</option>, the kernel will only block the rogue
+ syscall and pluto will attempt to continue. If set to
+ <option>disabled</option>, pluto is allowed to call any syscall
+ offered by the kernel, although it might be restricted via other
+ security mechanisms, such as capabilities, SElinux, AppArmor or
+ other OS security features.
+ </para>
+ <para>
+ By default, seccomp is disabled, as there is a significant
+ performance penalty, custom updown scripts could trigger false
+ positives, and system library updates could also trigger false
+ positives. A false positive (or real malicious remote code
+ execution of a bad syscall) will cause the pluto daemon to crash
+ or hang.
+ </para>
+ <para>
+ <option>Warning:</option> The restrictions of pluto are
+ inherited by the updown scripts, so these scripts are also not
+ allowed to use syscalls that are forbidden for pluto.
+ </para>
+ <para>
+ To see if a seccomp rule got triggered, you must run with
+ seccomp=enabled, and keep an eye on
+ <option>type=SECCOMP</option> messages in the audit log (usually
+ <option>/var/log/audit/audit.log</option>. Note that logging can
+ be delayed by many seconds.
+ </para>
+ <para>
+ This feature can be tested using <command>ipsec whack
+ --seccomp-crashtest</command>. <option>Warning: </option> With
+ seccomp=enabled, pluto will be terminated by the kernel. With
+ seccomp=tolerant or seccomp=disabled, pluto will report the
+ results of the seccomp test. SECCOMP will log the forbidden
+ syscall numbers to the audit log, but only with
+ seccomp=enabled. The tool scmp_sys_resolver from the libseccomp
+ development package can be used to translate the syscall number
+ into a name. See programs/pluto/pluto_seccomp.c for the list of
+ allowed syscalls.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>secretsfile</option>
+ </term>
+ <listitem>
+ <para>
+ pathname of the file that stores the secret credentials such as
+ preshared keys (PSKs). See <option>man ipsec.secrets</option>
+ for the syntax. The default value is
+ <filename>@@IPSEC_SECRETS@@</filename>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>seedbits</option>
+ </term>
+ <listitem>
+ <para>
+ Pluto uses the NSS crypto library as its random source. Some
+ government Three Letter Agencies require that pluto reads
+ additional bits from /dev/random and feed these into the NSS RNG
+ before drawing random from the NSS library, despite the NSS
+ library itself already seeding its internal state. This process
+ can block pluto for an extended time during startup, depending
+ on the entropy of the system. Therefore, the default is to not
+ perform this redundant seeding. If specifying a value, it is
+ recommended to specify at least 460 bits (for FIPS) or 440 bits
+ (for BSI).
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>shuntlifetime</option>
+ </term>
+ <listitem>
+ <para>
+ The time until bare shunts (kernel policies not associated with
+ connections) are deleted from the kernel. The default value is
+ 15m. When using Opportunistic Encryption to a specific host
+ fails, the system will either install a %pass or %hold shunt to
+ let the traffic out clear text or block it. During the the
+ shuntlifetime, no new Opportunistic Encryption attempt will be
+ started, although the system will still respond to incoming OE
+ requests from the remote IP. See also
+ <option>failureshunt</option> and
+ <option>negotiationshunt</option>
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>statsbin</option>
+ </term>
+ <listitem>
+ <para>
+ This option specifies an optional external program to report
+ tunnel state changes too. The default is not to report tunnel
+ state changes. This program can be used to notify the user's
+ desktop (dbus, NetworkManager) or to report tunnel changes to a
+ central logging server.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>syslog</option>
+ </term>
+ <listitem>
+ <para>
+ the &syslog.2; <replaceable>facility</replaceable> name and
+ priority to use for startup/shutdown log messages, default
+ <option>daemon.error</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>uniqueids</option>=&Yn_options;
+ </term>
+ <listitem>
+ <para>
+ Whether IDs should be considered identifying remote parties
+ uniquely. Acceptable values are <option>yes</option> (the
+ default) and <option>no</option>. Participant IDs normally are
+ unique, so a new connection instance using the same remote ID is
+ almost invariably intended to replace an old existing
+ connection.
+ </para>
+ <para>
+ When the connection is defined to be a server (using
+ xauthserver=) and the connection policy is authby=secret, this
+ option is ignored (as of 3.20) and old connections will never be
+ replaced. This situation is commonly known as clients using a
+ "Group ID".
+ </para>
+ <para>
+ This option may disappear in the near future. People using
+ identical X.509 certificates on multiple devices are urged to
+ upgrade to use separate certificates per client and device.
+ </para>
+ <para>
+ Prior to &Libreswan; version 5.3, when <command>pluto</command>
+ was started directly and without a configuration file, this
+ option was set to <option>no</option>.
+ </para>
+ </listitem>
+</varlistentry>
--- /dev/null
+<varlistentry>
+ <term>
+ <option>virtual-private</option>
+ </term>
+ <listitem>
+ <para>
+ contains the networks that are allowed as (left|right)subnet=
+ for the remote clients when using the <option>vhost:</option> or
+ <option>vnet:</option> keywords in the
+ <option>(left|right)subnet=</option> parameters. In other
+ words, the address ranges that may live behind a NAT router
+ through which a client connects. This value is usually set to
+ all the RFC-1918 address space, excluding the space used in the
+ local subnet behind the NAT (An IP address cannot live at two
+ places at once). IPv4 address ranges are denoted as
+ <option>%v4:a.b.c.d/mm</option> and IPv6 is denoted as
+ <option>%v6:aaaa::bbbb:cccc:dddd:eeee/mm</option>. One can
+ exclude subnets by using the <option>!</option>. For example,
+ if the VPN server is giving access to 192.168.1.0/24, this
+ option should be set to:
+ <option>virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24</option>.
+ This parameter is only needed on the server side and not on the
+ client side that resides behind the NAT router, as the client
+ will just use its IP address for the inner IP setting. This
+ parameter may eventually become per-connection. See also
+ <option>leftsubnet=</option>
+ </para>
+ <para>
+ Note: It seems that T-Mobile in the US and Rogers/Fido in Canada
+ have started using 25.0.0.0/8 as their pre-NAT range. This range
+ technically belongs to the Defence Interoperable Network
+ Services Authority (DINSA), an agency of the Ministry of Defence
+ of the United Kingdom. The network range seems to not have been
+ announced for decades, which is probably why these organisations
+ "borrowed" this range. To support roadwarriors on these 3G
+ networks, you might have to add it to the virtual-private= line.
+ </para>
+ </listitem>
+</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>sha2-truncbug</option>
- </term>
- <listitem>
- <para>
- The default ESP hash truncation for sha2_256 is 128 bits. Some
- IPsec implementations (Linux before 2.6.33, some Cisco (2811?)
- routers) implement the draft version which stated 96 bits. If a
- draft implementation communicates with an RFC implementation,
- both ends will reject encrypted packets from each other.
- </para>
- <para>
- This option enables using the draft 96 bits version to interop
- with those implementations. Currently the accepted values are
- <option>no</option>, (the default) signifying default RFC
- truncation of 128 bits, or <option>yes</option>, signifying the
- draft 96 bits truncation.
- </para>
- <para>
- Another workaround is to switch from sha2_256 to sha2_128 or
- sha2_512.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>share-lease</option>
- </term>
- <listitem>
- <para>
- Whether multiple outoging IKEv1 connections that are not
- specifying a local subnet should use the lease IP given by
- the server of the first connection. The default and expected
- behaviour (of emulating a Cisco client) is <option>yes</option>.
- It can be disabled by setting it to <option>no</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>shuntlifetime</option>
- </term>
- <listitem>
- <para>
- The time until bare shunts (kernel policies not associated with
- connections) are deleted from the kernel. The default value is
- 15m. When using Opportunistic Encryption to a specific host
- fails, the system will either install a %pass or %hold shunt to
- let the traffic out clear text or block it. During the the
- shuntlifetime, no new Opportunistic Encryption attempt will be
- started, although the system will still respond to incoming OE
- requests from the remote IP. See also
- <option>failureshunt</option> and
- <option>negotiationshunt</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftsourceip</option>
- </term>
- <term>
- <option>rightsourceip</option>
- </term>
- <listitem>
- <para>
- the IP address for this host to use when transmitting a packet
- to the other side of this link. Relevant only locally, the
- other end need not agree. This option is used to make the
- gateway itself use its internal IP, which is part of the
- leftsubnet, to communicate to the rightsubnet or
- right. Otherwise, it will use its <option>nearest</option> IP
- address, which is its public IP address. This option is mostly
- used when defining subnet-subnet connections, so that the
- gateways can talk to each other and the subnet at the other end,
- without the need to build additional host-subnet, subnet-host
- and host-host tunnels. Both IPv4 and IPv6 addresses are
- supported.
- </para>
- </listitem>
-</varlistentry>
-
+++ /dev/null
-<varlistentry>
- <term>
- <option>statsbin</option>
- </term>
- <listitem>
- <para>
- This option specifies an optional external program to report
- tunnel state changes too. The default is not to report tunnel
- state changes. This program can be used to notify the user's
- desktop (dbus, NetworkManager) or to report tunnel changes to a
- central logging server.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftsubnet=&ip_selector;[,...]</option>
- </term>
- <term>
- <option>rightsubnet=&ip_selector;[,...]</option>
- </term>
- <listitem>
- <para>
- A comma separated list of traffic selectors behind the
- <option>left</option> or <option>right</option> participant.
- </para>
- <para>
- Each traffic selector expressed as: <systemitem
- class="ipaddress"> <replaceable>network-prefix</replaceable> /
- <replaceable>netmask</replaceable>/
- <replaceable>protocol</replaceable>/
- <replaceable>port</replaceable> </systemitem> where trailing
- elements may be omitted. For instance:
- <code>leftsubnet=1.2.3.0/24,1:2::/64</code>,
- <code>leftsubnet=1.2.3.4/32/tcp,1:2::/128/tcp</code>,
- <code>leftsubnet=1.2.3.4/31/tcp/22,1:2::/128/tcp/22</code>.
- </para>
- <para>
- If both <code>leftsubnet=</code> and <code>rightsubnet=</code>
- are specified, all combinations will be established as a single
- IPsec tunnel.
- </para>
- <para>
- When omitted, essentially assumed to be <code>left</code>,
- signifying that the left end of the connection goes to the left
- participant only.
- </para>
-
- <note>
- <para>
- Support for specifying multiple selectors and the protocol and
- port was added in &Libreswan; version 5.
- </para>
- </note>
-
- <important>
- <title>
- IKEv1
- </title>
- <para>
- In IKEv1 only a single selector is allowed and it is limited
- to specifying a subnet as in: <code>
- <replaceable>network</replaceable> /
- <replaceable>netmask</replaceable> </code>
- </para>
- </important>
-
- <important>
- <title>
- IKEv1
- </title>
- <para>
- IKEv1 supports two magic shorthands <code>vhost:</code> and
- <code>vnet:</code>, which can list subnets in the same syntax
- as <replaceable>virtual-private</replaceable>. The value
- <code>%priv</code> expands to the networks specified in
- <code>virtual-private</code>. The value <code>%no</code>
- means no subnet. A common use for allowing roadwarriors to
- come in on public IPs or via accepted NATed networks from
- RFC1918 is to use <code>leftsubnet=vhost:%no,%priv</code>. The
- <code>vnet:</code> option can be used to allow RFC1918 subnets
- without hardcoding them. When using vnet the connection will
- instantiate, allowing for multiple tunnels with different
- subnets.
- </para>
- </important>
-
- <important>
- <title>
- Use with <code>leftprotport</code> and
- <code>leftsubnets</code>
- </title>
- <para>
- Compatible with libreswan version 4, a simple
- <code>leftsubnet</code> (specifying a single network prefix
- and netmask) may be combined with <code>leftprotoport</code>
- and <code>leftsubnets</code>. Anything more complicated
- should be converted to use the selector syntax.
- </para>
- </important>
-
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftsubnets=&ip_subnet;[,...]</option>
- </term>
- <term>
- <option>rightsubnets=&ip_subnet;[,...]</option>
- </term>
- <listitem>
- <para>
- Specify multiple private subnets behind the participant,
- expressed as
- <option>networkA</option><option>/</option><option>netmaskA</option>,<option>networkB</option><option>/</option><option>netmaskB</option><option>[,...]</option>.
- If both a <option>leftsubnets=</option> and
- <option>rightsubnets=</option> are defined, all combinations of
- subnet tunnels will be established as separate IPsec tunnels.
- You cannot use <option>leftsubnet=</option> and
- <option>leftsubnets=</option> together. For examples see
- <option>testing/pluto/multinet-*</option>. Be aware that when
- using spaces as separator, that the entire option value needs to
- be in double quotes.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>syslog</option>
- </term>
- <listitem>
- <para>
- the &syslog.2; <replaceable>facility</replaceable> name and
- priority to use for startup/shutdown log messages, default
- <option>daemon.error</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>tcp-remoteport</option>
- </term>
- <listitem>
- <para>
- Which remote TCP port to use when IKE over TCP is attempted. The
- default value is to use the NAT-T IKE port (4500). This value is
- not negotiated and should be configured properly on all
- endpoints. When opening a TCP socket to the remote host in this
- port, a regular ephemeral source port is obtained from the
- OS. For changing the UDP ports, see
- <option>leftikeport=</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term><option>tfc</option></term>
- <listitem>
- <para>
- Enable Traffic Flow Confidentiality ("TFC") (RFC-4303) for outgoing ESP
- packets in Tunnel Mode. When enabled, ESP packets are padded to the
- specified size (up to the PMTU size) to prevent leaking information based
- on ESP packet size. This option is ignored for AH and for ESP in Transport
- Mode as those always leak traffic characteristics and applying TFC will
- not do anything. Acceptable values are positive numbers. The value 0 means
- TFC padding is not performed. Currently this feature is only implemented
- for the Linux XFRM stack. In IKEv2, when the notify payload
- ESP_TFC_PADDING_NOT_SUPPORTED is received, TFC padding is disabled. The
- default is not to do any TFC padding, but this might change in the near
- future.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>type</option>
- </term>
- <listitem>
- <para>
- the type of the connection; currently the accepted values are
- <option>tunnel</option> (the default) signifying a host-to-host,
- host-to-subnet, or subnet-to-subnet tunnel;
- <option>transport</option>, signifying host-to-host transport
- mode; <option>passthrough</option>, signifying that no IPsec
- processing should be done at all; <option>drop</option>,
- signifying that packets should be discarded.
- </para>
- <para>
- Historic Note: &KLIPS; supported the option
- <option>reject</option> signifying that packets should be
- discarded and a diagnostic ICMP returned. Support for &KLIPS;,
- and this option, have been removed.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>uniqueids</option>=&Yn_options;
- </term>
- <listitem>
- <para>
- Whether IDs should be considered identifying remote parties
- uniquely. Acceptable values are <option>yes</option> (the
- default) and <option>no</option>. Participant IDs normally are
- unique, so a new connection instance using the same remote ID is
- almost invariably intended to replace an old existing
- connection.
- </para>
- <para>
- When the connection is defined to be a server (using
- xauthserver=) and the connection policy is authby=secret, this
- option is ignored (as of 3.20) and old connections will never be
- replaced. This situation is commonly known as clients using a
- "Group ID".
- </para>
- <para>
- This option may disappear in the near future. People using
- identical X.509 certificates on multiple devices are urged to
- upgrade to use separate certificates per client and device.
- </para>
- <para>
- Prior to &Libreswan; version 5.3, when <command>pluto</command>
- was started directly and without a configuration file, this
- option was set to <option>no</option>.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<refsect1>
- <title>
- SPECIFYING UNITS
- </title>
-
- <refsect2 id='unit_bytes'>
- <title>
- BYTE COUNTS AND BINARY DATA
- </title>
- <para>
- Options, such as <option>ipsec-max-bytes</option>, that expect a
- numeric byte count, also accept deciml fractions, and the
- following multipliers as a suffix:
- <variablelist>
- <varlistentry>
- <term><option>KiB</option></term>
- <listitem><para>kilobytes (1024 bytes)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>MiB</option></term>
- <listitem><para>megabytes (1024*1024 bytes)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>GiB</option></term>
- <listitem><para>gigabytes (1024*1024*1024 bytes)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>TiB</option></term>
- <listitem><para>terabytes (1024*1024*1024*1024 bytes)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>PiB</option></term>
- <listitem><para>petabytes (1024*1024*1024*1024*1024 bytes)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>EiB</option></term>
- <listitem><para>exabytes (1024*1024*1024*1024*1024*1024 bytes)</para></listitem>
- </varlistentry>
- </variablelist>
- </para>
- </refsect2>
-
- <refsect2 id='unit_duration'>
- <title>
- DURATION
- </title>
- <para>
- Options, such as <option>retransmit-timeout</option>, that
- expect a numeric duration, also accept decimal fractions, and
- the following multipliers as a suffix:
- <variablelist>
- <varlistentry>
- <term><option>us</option></term>
- <listitem><para>microseconds (1/1000000 seconds)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>ms</option></term>
- <listitem><para>milliseconds (1/1000 seconds)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>s</option></term>
- <listitem><para>seconds</para></listitem></varlistentry>
- <varlistentry><term><option>m</option></term>
- <listitem><para>minutes (60 seconds)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>h</option></term>
- <listitem><para>hours (60*60 seconds)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>d</option></term>
- <listitem><para>days (24*60*60 seconds)</para></listitem>
- </varlistentry>
- <varlistentry>
- <term><option>w</option></term>
- <listitem><para>weeks (7*24*60*60 seconds)</para></listitem>
- </varlistentry>
- </variablelist>
- For instance, 1ms and 1000us, 0.5s and 500ms, 1.5h and 90m, are
- each equivalent.
- </para>
-</refsect2>
-
-</refsect1>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftupdown</option>
- </term>
- <term>
- <option>rightupdown</option>
- </term>
- <listitem>
- <para>
- The script to run to adjust routing and/or firewalling when the
- status of the connection changes (default <command>ipsec
- _updown</command>). May include positional parameters separated
- by white space (although this requires enclosing the whole
- string in quotes); including shell metacharacters is unwise. An
- example to enable routing when using the XFRM stack, one can
- use:
- </para>
- <para>
- <simplelist columns='1'>
- <member><computeroutput>updown="ipsec _updown --route yes"</computeroutput></member>
- </simplelist>
- </para>
- <para>
- To disable calling an updown script, set it to the empty string,
- eg leftupdown="" or leftupdown="%disabled".
- </para>
- <para>
- Connections with <option>type=</option> set to
- <option>passthrough</option>, <option>reject</option> or
- <option>drop</option> never run <command>ipsec _updown</command>.
- </para>
- <para>
- See &libreswan.7; for details.
- </para>
- <para>
- Relevant only locally, other end need not agree on it.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftusername</option>
- </term>
- <term>
- <option>rightusername</option>
- </term>
- <listitem>
- <para>
- The username associated with this connection. The username can
- be the IKEv2 XAUTH username, a GSSAPI username or IKEv2 CP
- username. For the XAUTH username, the XAUTH password can be
- configured in the <option>ipsec.secrets</option> file. This
- option was previously called leftxauthusername.</para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>virtual-private</option>
- </term>
- <listitem>
- <para>
- contains the networks that are allowed as (left|right)subnet=
- for the remote clients when using the <option>vhost:</option> or
- <option>vnet:</option> keywords in the
- <option>(left|right)subnet=</option> parameters. In other
- words, the address ranges that may live behind a NAT router
- through which a client connects. This value is usually set to
- all the RFC-1918 address space, excluding the space used in the
- local subnet behind the NAT (An IP address cannot live at two
- places at once). IPv4 address ranges are denoted as
- <option>%v4:a.b.c.d/mm</option> and IPv6 is denoted as
- <option>%v6:aaaa::bbbb:cccc:dddd:eeee/mm</option>. One can
- exclude subnets by using the <option>!</option>. For example,
- if the VPN server is giving access to 192.168.1.0/24, this
- option should be set to:
- <option>virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.1.0/24</option>.
- This parameter is only needed on the server side and not on the
- client side that resides behind the NAT router, as the client
- will just use its IP address for the inner IP setting. This
- parameter may eventually become per-connection. See also
- <option>leftsubnet=</option>
- </para>
- <para>
- Note: It seems that T-Mobile in the US and Rogers/Fido in Canada
- have started using 25.0.0.0/8 as their pre-NAT range. This range
- technically belongs to the Defence Interoperable Network
- Services Authority (DINSA), an agency of the Ministry of Defence
- of the United Kingdom. The network range seems to not have been
- announced for decades, which is probably why these organisations
- "borrowed" this range. To support roadwarriors on these 3G
- networks, you might have to add it to the virtual-private= line.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>vti-interface</option>
- </term>
- <listitem>
- <para>
- This option is deprecated. See <option>ipsec-interface</option>
- instead.
- </para>
- <para>
- This option is used to create "Routing based VPNs"
- (as opposed to "Policy based VPNs"). It will create a new interface
- that can be used to route traffic in for encryption/decryption. The Virtual
- Tunnel Interface ("VTI") interface name is used to for all IPsec SA's created by
- this connection. This requires that the connection also enables either
- the <option>mark=</option> or <option>mark-in= /
- mark-out-</option> option(s). All traffic marked with the proper MARKs
- will be automatically encrypted if there is an IPsec SA policy covering the
- source/destination traffic. Tools such as tcpdump and iptables can be
- used on all cleartext pre-encrypt and post-decrypt traffic on the device.
- See the libreswan wiki for example configurations that use VTI.
- </para>
- <para>
- VTI interfaces are currently only supported on Linux with
- XFRM. The _updown script handles certain Linux specific
- interfaces settings required for proper functioning
- (disable_policy, rp_filter, forwarding, etc). Interface names
- are limited to 16 characters and may not allow all characters to
- be used. If marking and <option>vti-routing=yes</option> is
- used, no manual iptables should be required. However,
- administrators can use the iptables mangle table to mark traffic
- manually if desired.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>vti-routing</option>
- </term>
- <listitem>
- <para>
- Whether or not to add network rules or routes for IPsec
- SA's to the respective VTI devices. Valid values are
- <option>yes</option> (the default) or <option>no</option>.
- When using "routing based VPNs" with a subnets policy of 0.0.0.0/0,
- this setting needs to set to <option>no</option> to prevent
- imploding the tunnel, and the administrator is expected to manually
- add ip rules and ip routes to configure what traffic must be encrypted.
- When set to <option>yes</option>, the _updown script will
- automatically route the leftsubnet/rightsubnet traffic into the
- VTI device specified with <option>vti-interface</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>vti-shared</option>
- </term>
- <listitem>
- <para>
- Whether or not the VTI device is shared amongst connections.
- Valid values are <option>no</option> (the default) or
- <option>yes</option>. When set to no, the VTI device is
- automatically deleted if the connection is a single
- non-instantiated connection. If a connection instantiates (eg
- right=%any) then this option has no effect, as the VTI device is
- not removed as it is shared with multiple roadwarriors.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftvti</option>
- </term>
- <term>
- <option>rightvti</option>
- </term>
- <listitem>
- <para>
- the address/mask to configure on the VTI interface when
- <option>vti-interface</option> is set. It takes the form of
- <option>network</option><option>/</option><option>netmask</option>
- Currently, IPv4 and IPv6 addresses with cidr netmask are
- supported. This option is often used in combination with routed
- based VPNs.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>xauthby</option>
- </term>
- <listitem>
- <para>
- When IKEv1 XAUTH support is available, set the method used by
- XAUTH to authenticate the user with IKEv1. The currently
- supported values are <option>file</option> (the default),
- <option>pam</option> or <option>alwaysok</option>. The password
- file is located at <option>/etc/ipsec.d/passwd</option>, and
- follows a syntax similar to the Apache htpasswd file, except an
- additional connection name argument (and optional static IP
- address) are also present:
- </para>
- <para>
- <option>username:password:conname:ipaddress</option>
- </para>
- <para>
- For supported password hashing methods, see &crypt.3;. If pluto
- is running in FIPS mode, some hash methods, such as MD5, might
- not be available. Threads are used to launch an xauth
- authentication helper for file as well as PAM methods.
- </para>
- <para>
- The <option>alwaysok</option> should only be used if the XAUTH
- user authentication is not really used, but is required for
- interoperability, as it defeats the whole point of XAUTH which
- is to rely on a secret only known by a human. See also
- <option>pam-authorize=yes</option>
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftxauthclient</option>
- </term>
- <term>
- <option>rightxauthclient</option>
- </term>
- <listitem>
- <para>
- Left is an XAUTH client. The xauth connection will have to be
- started interactively and cannot be configured using
- <option>auto=start</option>. Instead, it has to be started from
- the commandline using <command>ipsec up
- <replaceable>connection</replaceable></command>. You will then
- be prompted for the username and password. To setup an XAUTH
- connection non-interactively, which defeats the whole purpose of
- XAUTH, but is regularly requested by users, it is possible to
- use a whack command - <command>ipsec whack --name baduser
- --ipsecgroup-xauth --xauthname badusername --xauthpass password
- --initiate</command> The other side of the connection should be
- configured as <option>rightxauthserver</option>. Acceptable
- values are <option>yes</option> or <option>no</option> (the
- default).
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>xauthfail</option>
- </term>
- <listitem>
- <para>
- When XAUTH support is available, set the failure method desired
- when authentication has failed. The currently supported values
- are <option>hard</option> (the default) and
- <option>soft</option>. A soft failure means the IPsec SA is
- allowed to be established, as if authentication had passed
- successfully, but the XAUTH_FAILED environment variable will be
- set to 1 for the updown script, which can then be used to
- redirect the user into a walled garden, for example a payment
- portal.
- </para>
- </listitem>
-</varlistentry>
+++ /dev/null
-<varlistentry>
- <term>
- <option>leftxauthserver</option>
- </term>
- <term>
- <option>rightxauthserver</option>
- </term>
- <listitem>
- <para>
- Left is an XAUTH server. This can use PAM for authentication or
- md5 passwords in <option>/etc/ipsec.d/passwd</option>. These are
- additional credentials to verify the user identity, and should
- not be confused with the XAUTH <option>group secret</option>,
- which is just a regular PSK defined in
- <option>ipsec.secrets</option>. The other side of the
- connection should be configured as
- <option>rightxauthclient</option>. XAUTH connections cannot
- rekey, so <option>rekey=no</option> should be specified in this
- conn. For further details on how to compile and use XAUTH, see
- README.XAUTH. Acceptable values are <option>yes</option> or
- <option>no</option> (the default).
- </para>
- </listitem>
-</varlistentry>
<!ENTITY % entities SYSTEM "entities.xml">%entities;
-<!ENTITY accept-redirect SYSTEM "d.ipsec.conf/accept-redirect.xml">
-<!ENTITY accept-redirect-to SYSTEM "d.ipsec.conf/accept-redirect-to.xml">
-<!ENTITY aggressive SYSTEM "d.ipsec.conf/aggressive.xml">
-<!ENTITY ah SYSTEM "d.ipsec.conf/ah.xml">
-<!ENTITY reject-simultaneous-ike-auth SYSTEM "d.ipsec.conf/reject-simultaneous-ike-auth.xml">
-<!ENTITY audit-log SYSTEM "d.ipsec.conf/audit-log.xml">
-<!ENTITY authby SYSTEM "d.ipsec.conf/authby.xml">
-<!ENTITY author SYSTEM "d.ipsec.conf/author.xml">
-<!ENTITY auto SYSTEM "d.ipsec.conf/auto.xml">
-<!ENTITY bugs SYSTEM "d.ipsec.conf/bugs.xml">
-<!ENTITY choosing_a_connection SYSTEM "d.ipsec.conf/choosing_a_connection.xml">
-<!ENTITY cisco-unity SYSTEM "d.ipsec.conf/cisco-unity.xml">
-<!ENTITY cisco-split SYSTEM "d.ipsec.conf/cisco-split.xml">
-<!ENTITY clientaddrfamily SYSTEM "d.ipsec.conf/clientaddrfamily.xml">
-<!ENTITY compress SYSTEM "d.ipsec.conf/compress.xml">
-<!ENTITY connsections SYSTEM "d.ipsec.conf/connsections.xml">
-<!ENTITY crl-strict SYSTEM "d.ipsec.conf/crl-strict.xml">
-<!ENTITY crl-timeout SYSTEM "d.ipsec.conf/crl-timeout.xml">
-<!ENTITY crlcheckinterval SYSTEM "d.ipsec.conf/crlcheckinterval.xml">
-<!ENTITY curl-iface SYSTEM "d.ipsec.conf/curl-iface.xml">
-<!ENTITY dns-resolver SYSTEM "d.ipsec.conf/dns-resolver.xml">
-<!ENTITY ddos-ike-threshold SYSTEM "d.ipsec.conf/ddos-ike-threshold.xml">
-<!ENTITY ddos-mode SYSTEM "d.ipsec.conf/ddos-mode.xml">
-<!ENTITY debug SYSTEM "d.ipsec.conf/debug.xml">
-<!ENTITY decap-dscp SYSTEM "d.ipsec.conf/decap-dscp.xml">
-<!ENTITY default_policy_groups SYSTEM "d.ipsec.conf/default_policy_groups.xml">
-<!ENTITY dns-match-id SYSTEM "d.ipsec.conf/dns-match-id.xml">
-<!ENTITY dnssec-anchors SYSTEM "d.ipsec.conf/dnssec-anchors.xml">
-<!ENTITY dnssec-enable SYSTEM "d.ipsec.conf/dnssec-enable.xml">
-<!ENTITY dnssec-rootkey-file SYSTEM "d.ipsec.conf/dnssec-rootkey-file.xml">
-<!ENTITY dpddelay SYSTEM "d.ipsec.conf/dpddelay.xml">
-<!ENTITY dpdtimeout SYSTEM "d.ipsec.conf/dpdtimeout.xml">
-<!ENTITY dumpdir SYSTEM "d.ipsec.conf/dumpdir.xml">
-<!ENTITY enable-tcp SYSTEM "d.ipsec.conf/enable-tcp.xml">
-<!ENTITY encap-dscp SYSTEM "d.ipsec.conf/encap-dscp.xml">
-<!ENTITY encapsulation SYSTEM "d.ipsec.conf/encapsulation.xml">
-<!ENTITY esn SYSTEM "d.ipsec.conf/esn.xml">
-<!ENTITY esp SYSTEM "d.ipsec.conf/esp.xml">
-<!ENTITY exampleleftright SYSTEM "d.ipsec.conf/exampleleftright.xml">
-<!ENTITY expire-shunt-interval SYSTEM "d.ipsec.conf/expire-shunt-interval.xml">
-<!ENTITY failureshunt SYSTEM "d.ipsec.conf/failureshunt.xml">
-<!ENTITY fake-strongswan SYSTEM "d.ipsec.conf/fake-strongswan.xml">
-<!ENTITY files SYSTEM "d.ipsec.conf/files.xml">
-<!ENTITY fragmentation SYSTEM "d.ipsec.conf/fragmentation.xml">
-<!ENTITY global-redirect SYSTEM "d.ipsec.conf/global-redirect.xml">
-<!ENTITY global-redirect-to SYSTEM "d.ipsec.conf/global-redirect-to.xml">
-<!ENTITY history SYSTEM "d.ipsec.conf/history.xml">
-<!ENTITY hostaddrfamily SYSTEM "d.ipsec.conf/hostaddrfamily.xml">
-<!ENTITY ignore-peer-dns SYSTEM "d.ipsec.conf/ignore-peer-dns.xml">
-<!ENTITY ike SYSTEM "d.ipsec.conf/ike.xml">
-<!ENTITY ike-socket-bufsize SYSTEM "d.ipsec.conf/ike-socket-bufsize.xml">
-<!ENTITY ike-socket-errqueue SYSTEM "d.ipsec.conf/ike-socket-errqueue.xml">
-<!ENTITY ikelifetime SYSTEM "d.ipsec.conf/ikelifetime.xml">
-<!ENTITY ikepad SYSTEM "d.ipsec.conf/ikepad.xml">
-<!ENTITY ikev1-policy SYSTEM "d.ipsec.conf/ikev1-policy.xml">
-<!ENTITY initial-contact SYSTEM "d.ipsec.conf/initial-contact.xml">
-<!ENTITY interface-ip SYSTEM "d.ipsec.conf/interface-ip.xml">
-<!ENTITY intermediate SYSTEM "d.ipsec.conf/intermediate.xml">
-<!ENTITY ipsec-interface SYSTEM "d.ipsec.conf/ipsec-interface.xml">
-<!ENTITY ipsec-interface-managed SYSTEM "d.ipsec.conf/ipsec-interface-managed.xml">
-<!ENTITY ipsec-max-bytes SYSTEM "d.ipsec.conf/ipsec-max-bytes.xml">
-<!ENTITY ipsec-max-packets SYSTEM "d.ipsec.conf/ipsec-max-packets.xml">
-<!ENTITY ipsecdir SYSTEM "d.ipsec.conf/ipsecdir.xml">
-<!ENTITY iptfs SYSTEM "d.ipsec.conf/iptfs.xml">
-<!ENTITY keep-alive SYSTEM "d.ipsec.conf/keep-alive.xml">
-<!ENTITY keyexchange SYSTEM "d.ipsec.conf/keyexchange.xml">
-<!ENTITY host SYSTEM "d.ipsec.conf/host.xml">
-<!ENTITY addresspool SYSTEM "d.ipsec.conf/addresspool.xml">
-<!ENTITY auth SYSTEM "d.ipsec.conf/auth.xml">
-<!ENTITY autheap SYSTEM "d.ipsec.conf/autheap.xml">
-<!ENTITY ca SYSTEM "d.ipsec.conf/ca.xml">
-<!ENTITY cat SYSTEM "d.ipsec.conf/cat.xml">
-<!ENTITY cert SYSTEM "d.ipsec.conf/cert.xml">
-<!ENTITY ckaid SYSTEM "d.ipsec.conf/ckaid.xml">
-<!ENTITY firewall SYSTEM "d.ipsec.conf/firewall.xml">
-<!ENTITY id SYSTEM "d.ipsec.conf/id.xml">
-<!ENTITY ikeport SYSTEM "d.ipsec.conf/ikeport.xml">
-<!ENTITY modecfgclient SYSTEM "d.ipsec.conf/modecfgclient.xml">
-<!ENTITY modecfgserver SYSTEM "d.ipsec.conf/modecfgserver.xml">
-<!ENTITY nexthop SYSTEM "d.ipsec.conf/nexthop.xml">
-<!ENTITY protoport SYSTEM "d.ipsec.conf/protoport.xml">
-<!ENTITY rsasigkey SYSTEM "d.ipsec.conf/rsasigkey.xml">
-<!ENTITY sendcert SYSTEM "d.ipsec.conf/sendcert.xml">
-<!ENTITY sourceip SYSTEM "d.ipsec.conf/sourceip.xml">
-<!ENTITY subnet SYSTEM "d.ipsec.conf/subnet.xml">
-<!ENTITY subnets SYSTEM "d.ipsec.conf/subnets.xml">
-<!ENTITY updown SYSTEM "d.ipsec.conf/updown.xml">
-<!ENTITY username SYSTEM "d.ipsec.conf/username.xml">
-<!ENTITY vti SYSTEM "d.ipsec.conf/vti.xml">
-<!ENTITY xauthclient SYSTEM "d.ipsec.conf/xauthclient.xml">
-<!ENTITY xauthserver SYSTEM "d.ipsec.conf/xauthserver.xml">
-<!ENTITY listen SYSTEM "d.ipsec.conf/listen.xml">
-<!ENTITY listen-tcp SYSTEM "d.ipsec.conf/listen-tcp.xml">
-<!ENTITY listen-udp SYSTEM "d.ipsec.conf/listen-udp.xml">
-<!ENTITY logappend SYSTEM "d.ipsec.conf/logappend.xml">
-<!ENTITY logfile SYSTEM "d.ipsec.conf/logfile.xml">
-<!ENTITY logip SYSTEM "d.ipsec.conf/logip.xml">
-<!ENTITY logtime SYSTEM "d.ipsec.conf/logtime.xml">
-<!ENTITY mark SYSTEM "d.ipsec.conf/mark.xml">
-<!ENTITY mark-in SYSTEM "d.ipsec.conf/mark-in.xml">
-<!ENTITY mark-out SYSTEM "d.ipsec.conf/mark-out.xml">
-<!ENTITY max-halfopen-ike SYSTEM "d.ipsec.conf/max-halfopen-ike.xml">
-<!ENTITY metric SYSTEM "d.ipsec.conf/metric.xml">
-<!ENTITY mobike SYSTEM "d.ipsec.conf/mobike.xml">
-<!ENTITY modecfgoptions SYSTEM "d.ipsec.conf/modecfgoptions.xml">
-<!ENTITY modecfgpull SYSTEM "d.ipsec.conf/modecfgpull.xml">
-<!ENTITY ms-dh-downgrade SYSTEM "d.ipsec.conf/ms-dh-downgrade.xml">
-<!ENTITY mtu SYSTEM "d.ipsec.conf/mtu.xml">
-<!ENTITY myvendorid SYSTEM "d.ipsec.conf/myvendorid.xml">
-<!ENTITY narrowing SYSTEM "d.ipsec.conf/narrowing.xml">
-<!ENTITY nat-ikev1-method SYSTEM "d.ipsec.conf/nat-ikev1-method.xml">
-<!ENTITY nat-keepalive SYSTEM "d.ipsec.conf/nat-keepalive.xml">
-<!ENTITY negotiationshunt SYSTEM "d.ipsec.conf/negotiationshunt.xml">
-<!ENTITY nflog-group SYSTEM "d.ipsec.conf/nflog-group.xml">
-<!ENTITY nflog-all SYSTEM "d.ipsec.conf/nflog-all.xml">
-<!ENTITY nhelpers SYSTEM "d.ipsec.conf/nhelpers.xml">
-<!ENTITY nic-offload SYSTEM "d.ipsec.conf/nic-offload.xml">
-<!ENTITY nm-configured SYSTEM "d.ipsec.conf/nm-configured.xml">
-<!ENTITY nopmtudisc SYSTEM "d.ipsec.conf/nopmtudisc.xml">
-<!ENTITY nssdir SYSTEM "d.ipsec.conf/nssdir.xml">
-<!ENTITY ocsp-cache-max-age SYSTEM "d.ipsec.conf/ocsp-cache-max-age.xml">
-<!ENTITY ocsp-cache-min-age SYSTEM "d.ipsec.conf/ocsp-cache-min-age.xml">
-<!ENTITY ocsp-cache-size SYSTEM "d.ipsec.conf/ocsp-cache-size.xml">
-<!ENTITY ocsp-enable SYSTEM "d.ipsec.conf/ocsp-enable.xml">
-<!ENTITY ocsp-method SYSTEM "d.ipsec.conf/ocsp-method.xml">
-<!ENTITY ocsp-strict SYSTEM "d.ipsec.conf/ocsp-strict.xml">
-<!ENTITY ocsp-timeout SYSTEM "d.ipsec.conf/ocsp-timeout.xml">
-<!ENTITY ocsp-trustname SYSTEM "d.ipsec.conf/ocsp-trustname.xml">
-<!ENTITY ocsp-uri SYSTEM "d.ipsec.conf/ocsp-uri.xml">
-<!ENTITY oe_conns SYSTEM "d.ipsec.conf/oe_conns.xml">
-<!ENTITY overlapip SYSTEM "d.ipsec.conf/overlapip.xml">
-<!ENTITY pam-authorize SYSTEM "d.ipsec.conf/pam-authorize.xml">
-<!ENTITY pfs SYSTEM "d.ipsec.conf/pfs.xml">
-<!ENTITY phase2 SYSTEM "d.ipsec.conf/phase2.xml">
-<!ENTITY plutodebug SYSTEM "d.ipsec.conf/plutodebug.xml">
-<!ENTITY policy-label SYSTEM "d.ipsec.conf/policy-label.xml">
-<!ENTITY policy_group_files SYSTEM "d.ipsec.conf/policy_group_files.xml">
-<!ENTITY ppk SYSTEM "d.ipsec.conf/ppk.xml">
-<!ENTITY ppk-ids SYSTEM "d.ipsec.conf/ppk-ids.xml">
-<!ENTITY priority SYSTEM "d.ipsec.conf/priority.xml">
-<!ENTITY protostack SYSTEM "d.ipsec.conf/protostack.xml">
-<!ENTITY redirect-to SYSTEM "d.ipsec.conf/redirect-to.xml">
-<!ENTITY rekey SYSTEM "d.ipsec.conf/rekey.xml">
-<!ENTITY rekeyfuzz SYSTEM "d.ipsec.conf/rekeyfuzz.xml">
-<!ENTITY rekeymargin SYSTEM "d.ipsec.conf/rekeymargin.xml">
-<!ENTITY remote-peer-type SYSTEM "d.ipsec.conf/remote-peer-type.xml">
-<!ENTITY replay-window SYSTEM "d.ipsec.conf/replay-window.xml">
-<!ENTITY reqid SYSTEM "d.ipsec.conf/reqid.xml">
-<!ENTITY require-id-on-certificate SYSTEM "d.ipsec.conf/require-id-on-certificate.xml">
-<!ENTITY retransmit-interval SYSTEM "d.ipsec.conf/retransmit-interval.xml">
-<!ENTITY retransmit-timeout SYSTEM "d.ipsec.conf/retransmit-timeout.xml">
-<!ENTITY salifetime SYSTEM "d.ipsec.conf/salifetime.xml">
-<!ENTITY seccomp SYSTEM "d.ipsec.conf/seccomp.xml">
-<!ENTITY secretsfile SYSTEM "d.ipsec.conf/secretsfile.xml">
-<!ENTITY see_also SYSTEM "d.ipsec.conf/see_also.xml">
-<!ENTITY seedbits SYSTEM "d.ipsec.conf/seedbits.xml">
-<!ENTITY send-no-esp-tfc SYSTEM "d.ipsec.conf/send-no-esp-tfc.xml">
-<!ENTITY send-redirect SYSTEM "d.ipsec.conf/send-redirect.xml">
-<!ENTITY send-vendorid SYSTEM "d.ipsec.conf/send-vendorid.xml">
-<!ENTITY sendca SYSTEM "d.ipsec.conf/sendca.xml">
-<!ENTITY sha2-truncbug SYSTEM "d.ipsec.conf/sha2-truncbug.xml">
-<!ENTITY share-lease SYSTEM "d.ipsec.conf/share-lease.xml">
-<!ENTITY shuntlifetime SYSTEM "d.ipsec.conf/shuntlifetime.xml">
-<!ENTITY statsbin SYSTEM "d.ipsec.conf/statsbin.xml">
-<!ENTITY syslog SYSTEM "d.ipsec.conf/syslog.xml">
-<!ENTITY tcp-remoteport SYSTEM "d.ipsec.conf/tcp-remoteport.xml">
-<!ENTITY tfc SYSTEM "d.ipsec.conf/tfc.xml">
-<!ENTITY type SYSTEM "d.ipsec.conf/type.xml">
-<!ENTITY uniqueids SYSTEM "d.ipsec.conf/uniqueids.xml">
-<!ENTITY units SYSTEM "d.ipsec.conf/units.xml">
-<!ENTITY virtual-private SYSTEM "d.ipsec.conf/virtual-private.xml">
-<!ENTITY vti-interface SYSTEM "d.ipsec.conf/vti-interface.xml">
-<!ENTITY vti-routing SYSTEM "d.ipsec.conf/vti-routing.xml">
-<!ENTITY vti-shared SYSTEM "d.ipsec.conf/vti-shared.xml">
-<!ENTITY xauthby SYSTEM "d.ipsec.conf/xauthby.xml">
-<!ENTITY xauthfail SYSTEM "d.ipsec.conf/xauthfail.xml">
-<!ENTITY expire-lifetime SYSTEM "d.ipsec.conf/expire-lifetime.xml">
+<!ENTITY sect.exampleleftright SYSTEM "d.ipsec.conf/sect/exampleleftright.xml">
+
+<!ENTITY sect.author SYSTEM "d.ipsec.conf/sect/author.xml">
+<!ENTITY sect.bugs SYSTEM "d.ipsec.conf/sect/bugs.xml">
+<!ENTITY sect.choosing_a_connection SYSTEM "d.ipsec.conf/sect/choosing_a_connection.xml">
+<!ENTITY sect.connsections SYSTEM "d.ipsec.conf/sect/connsections.xml">
+<!ENTITY sect.default_policy_groups SYSTEM "d.ipsec.conf/sect/default_policy_groups.xml">
+<!ENTITY sect.files SYSTEM "d.ipsec.conf/sect/files.xml">
+<!ENTITY sect.history SYSTEM "d.ipsec.conf/sect/history.xml">
+<!ENTITY sect.oe_conns SYSTEM "d.ipsec.conf/sect/oe_conns.xml">
+<!ENTITY sect.policy_group_files SYSTEM "d.ipsec.conf/sect/policy_group_files.xml">
+<!ENTITY sect.see_also SYSTEM "d.ipsec.conf/sect/see_also.xml">
+<!ENTITY sect.units SYSTEM "d.ipsec.conf/sect/units.xml">
+
+<!ENTITY conn.accept-redirect SYSTEM "d.ipsec.conf/conn/accept-redirect.xml">
+<!ENTITY conn.accept-redirect-to SYSTEM "d.ipsec.conf/conn/accept-redirect-to.xml">
+<!ENTITY conn.addresspool SYSTEM "d.ipsec.conf/conn/addresspool.xml">
+<!ENTITY conn.aggressive SYSTEM "d.ipsec.conf/conn/aggressive.xml">
+<!ENTITY conn.ah SYSTEM "d.ipsec.conf/conn/ah.xml">
+<!ENTITY conn.auth SYSTEM "d.ipsec.conf/conn/auth.xml">
+<!ENTITY conn.authby SYSTEM "d.ipsec.conf/conn/authby.xml">
+<!ENTITY conn.autheap SYSTEM "d.ipsec.conf/conn/autheap.xml">
+<!ENTITY conn.auto SYSTEM "d.ipsec.conf/conn/auto.xml">
+<!ENTITY conn.ca SYSTEM "d.ipsec.conf/conn/ca.xml">
+<!ENTITY conn.cat SYSTEM "d.ipsec.conf/conn/cat.xml">
+<!ENTITY conn.cert SYSTEM "d.ipsec.conf/conn/cert.xml">
+<!ENTITY conn.cisco-split SYSTEM "d.ipsec.conf/conn/cisco-split.xml">
+<!ENTITY conn.cisco-unity SYSTEM "d.ipsec.conf/conn/cisco-unity.xml">
+<!ENTITY conn.ckaid SYSTEM "d.ipsec.conf/conn/ckaid.xml">
+<!ENTITY conn.clientaddrfamily SYSTEM "d.ipsec.conf/conn/clientaddrfamily.xml">
+<!ENTITY conn.compress SYSTEM "d.ipsec.conf/conn/compress.xml">
+<!ENTITY conn.debug SYSTEM "d.ipsec.conf/conn/debug.xml">
+<!ENTITY conn.decap-dscp SYSTEM "d.ipsec.conf/conn/decap-dscp.xml">
+<!ENTITY conn.dns-match-id SYSTEM "d.ipsec.conf/conn/dns-match-id.xml">
+<!ENTITY conn.dpddelay SYSTEM "d.ipsec.conf/conn/dpddelay.xml">
+<!ENTITY conn.dpdtimeout SYSTEM "d.ipsec.conf/conn/dpdtimeout.xml">
+<!ENTITY conn.enable-tcp SYSTEM "d.ipsec.conf/conn/enable-tcp.xml">
+<!ENTITY conn.encap-dscp SYSTEM "d.ipsec.conf/conn/encap-dscp.xml">
+<!ENTITY conn.encapsulation SYSTEM "d.ipsec.conf/conn/encapsulation.xml">
+<!ENTITY conn.esn SYSTEM "d.ipsec.conf/conn/esn.xml">
+<!ENTITY conn.esp SYSTEM "d.ipsec.conf/conn/esp.xml">
+<!ENTITY conn.failureshunt SYSTEM "d.ipsec.conf/conn/failureshunt.xml">
+<!ENTITY conn.fake-strongswan SYSTEM "d.ipsec.conf/conn/fake-strongswan.xml">
+<!ENTITY conn.firewall SYSTEM "d.ipsec.conf/conn/firewall.xml">
+<!ENTITY conn.fragmentation SYSTEM "d.ipsec.conf/conn/fragmentation.xml">
+<!ENTITY conn.host SYSTEM "d.ipsec.conf/conn/host.xml">
+<!ENTITY conn.hostaddrfamily SYSTEM "d.ipsec.conf/conn/hostaddrfamily.xml">
+<!ENTITY conn.id SYSTEM "d.ipsec.conf/conn/id.xml">
+<!ENTITY conn.ignore-peer-dns SYSTEM "d.ipsec.conf/conn/ignore-peer-dns.xml">
+<!ENTITY conn.ike SYSTEM "d.ipsec.conf/conn/ike.xml">
+<!ENTITY conn.ikelifetime SYSTEM "d.ipsec.conf/conn/ikelifetime.xml">
+<!ENTITY conn.ikepad SYSTEM "d.ipsec.conf/conn/ikepad.xml">
+<!ENTITY conn.ikeport SYSTEM "d.ipsec.conf/conn/ikeport.xml">
+<!ENTITY conn.initial-contact SYSTEM "d.ipsec.conf/conn/initial-contact.xml">
+<!ENTITY conn.interface-ip SYSTEM "d.ipsec.conf/conn/interface-ip.xml">
+<!ENTITY conn.intermediate SYSTEM "d.ipsec.conf/conn/intermediate.xml">
+<!ENTITY conn.ipsec-interface SYSTEM "d.ipsec.conf/conn/ipsec-interface.xml">
+<!ENTITY conn.ipsec-max-bytes SYSTEM "d.ipsec.conf/conn/ipsec-max-bytes.xml">
+<!ENTITY conn.ipsec-max-packets SYSTEM "d.ipsec.conf/conn/ipsec-max-packets.xml">
+<!ENTITY conn.iptfs SYSTEM "d.ipsec.conf/conn/iptfs.xml">
+<!ENTITY conn.keyexchange SYSTEM "d.ipsec.conf/conn/keyexchange.xml">
+<!ENTITY conn.mark SYSTEM "d.ipsec.conf/conn/mark.xml">
+<!ENTITY conn.mark-in SYSTEM "d.ipsec.conf/conn/mark-in.xml">
+<!ENTITY conn.mark-out SYSTEM "d.ipsec.conf/conn/mark-out.xml">
+<!ENTITY conn.metric SYSTEM "d.ipsec.conf/conn/metric.xml">
+<!ENTITY conn.mobike SYSTEM "d.ipsec.conf/conn/mobike.xml">
+<!ENTITY conn.modecfgclient SYSTEM "d.ipsec.conf/conn/modecfgclient.xml">
+<!ENTITY conn.modecfgoptions SYSTEM "d.ipsec.conf/conn/modecfgoptions.xml">
+<!ENTITY conn.modecfgpull SYSTEM "d.ipsec.conf/conn/modecfgpull.xml">
+<!ENTITY conn.modecfgserver SYSTEM "d.ipsec.conf/conn/modecfgserver.xml">
+<!ENTITY conn.ms-dh-downgrade SYSTEM "d.ipsec.conf/conn/ms-dh-downgrade.xml">
+<!ENTITY conn.mtu SYSTEM "d.ipsec.conf/conn/mtu.xml">
+<!ENTITY conn.narrowing SYSTEM "d.ipsec.conf/conn/narrowing.xml">
+<!ENTITY conn.nat-ikev1-method SYSTEM "d.ipsec.conf/conn/nat-ikev1-method.xml">
+<!ENTITY conn.nat-keepalive SYSTEM "d.ipsec.conf/conn/nat-keepalive.xml">
+<!ENTITY conn.negotiationshunt SYSTEM "d.ipsec.conf/conn/negotiationshunt.xml">
+<!ENTITY conn.nexthop SYSTEM "d.ipsec.conf/conn/nexthop.xml">
+<!ENTITY conn.nflog-group SYSTEM "d.ipsec.conf/conn/nflog-group.xml">
+<!ENTITY conn.nic-offload SYSTEM "d.ipsec.conf/conn/nic-offload.xml">
+<!ENTITY conn.nm-configured SYSTEM "d.ipsec.conf/conn/nm-configured.xml">
+<!ENTITY conn.nopmtudisc SYSTEM "d.ipsec.conf/conn/nopmtudisc.xml">
+<!ENTITY conn.overlapip SYSTEM "d.ipsec.conf/conn/overlapip.xml">
+<!ENTITY conn.pam-authorize SYSTEM "d.ipsec.conf/conn/pam-authorize.xml">
+<!ENTITY conn.pfs SYSTEM "d.ipsec.conf/conn/pfs.xml">
+<!ENTITY conn.phase2 SYSTEM "d.ipsec.conf/conn/phase2.xml">
+<!ENTITY conn.policy-label SYSTEM "d.ipsec.conf/conn/policy-label.xml">
+<!ENTITY conn.ppk SYSTEM "d.ipsec.conf/conn/ppk.xml">
+<!ENTITY conn.ppk-ids SYSTEM "d.ipsec.conf/conn/ppk-ids.xml">
+<!ENTITY conn.priority SYSTEM "d.ipsec.conf/conn/priority.xml">
+<!ENTITY conn.protoport SYSTEM "d.ipsec.conf/conn/protoport.xml">
+<!ENTITY conn.redirect-to SYSTEM "d.ipsec.conf/conn/redirect-to.xml">
+<!ENTITY conn.reject-simultaneous-ike-auth SYSTEM "d.ipsec.conf/conn/reject-simultaneous-ike-auth.xml">
+<!ENTITY conn.rekey SYSTEM "d.ipsec.conf/conn/rekey.xml">
+<!ENTITY conn.rekeyfuzz SYSTEM "d.ipsec.conf/conn/rekeyfuzz.xml">
+<!ENTITY conn.rekeymargin SYSTEM "d.ipsec.conf/conn/rekeymargin.xml">
+<!ENTITY conn.remote-peer-type SYSTEM "d.ipsec.conf/conn/remote-peer-type.xml">
+<!ENTITY conn.replay-window SYSTEM "d.ipsec.conf/conn/replay-window.xml">
+<!ENTITY conn.reqid SYSTEM "d.ipsec.conf/conn/reqid.xml">
+<!ENTITY conn.require-id-on-certificate SYSTEM "d.ipsec.conf/conn/require-id-on-certificate.xml">
+<!ENTITY conn.retransmit-interval SYSTEM "d.ipsec.conf/conn/retransmit-interval.xml">
+<!ENTITY conn.retransmit-timeout SYSTEM "d.ipsec.conf/conn/retransmit-timeout.xml">
+<!ENTITY conn.rsasigkey SYSTEM "d.ipsec.conf/conn/rsasigkey.xml">
+<!ENTITY conn.salifetime SYSTEM "d.ipsec.conf/conn/salifetime.xml">
+<!ENTITY conn.send-no-esp-tfc SYSTEM "d.ipsec.conf/conn/send-no-esp-tfc.xml">
+<!ENTITY conn.send-redirect SYSTEM "d.ipsec.conf/conn/send-redirect.xml">
+<!ENTITY conn.send-vendorid SYSTEM "d.ipsec.conf/conn/send-vendorid.xml">
+<!ENTITY conn.sendca SYSTEM "d.ipsec.conf/conn/sendca.xml">
+<!ENTITY conn.sendcert SYSTEM "d.ipsec.conf/conn/sendcert.xml">
+<!ENTITY conn.sha2-truncbug SYSTEM "d.ipsec.conf/conn/sha2-truncbug.xml">
+<!ENTITY conn.share-lease SYSTEM "d.ipsec.conf/conn/share-lease.xml">
+<!ENTITY conn.sourceip SYSTEM "d.ipsec.conf/conn/sourceip.xml">
+<!ENTITY conn.subnet SYSTEM "d.ipsec.conf/conn/subnet.xml">
+<!ENTITY conn.subnets SYSTEM "d.ipsec.conf/conn/subnets.xml">
+<!ENTITY conn.tcp-remoteport SYSTEM "d.ipsec.conf/conn/tcp-remoteport.xml">
+<!ENTITY conn.tfc SYSTEM "d.ipsec.conf/conn/tfc.xml">
+<!ENTITY conn.type SYSTEM "d.ipsec.conf/conn/type.xml">
+<!ENTITY conn.updown SYSTEM "d.ipsec.conf/conn/updown.xml">
+<!ENTITY conn.username SYSTEM "d.ipsec.conf/conn/username.xml">
+<!ENTITY conn.vti SYSTEM "d.ipsec.conf/conn/vti.xml">
+<!ENTITY conn.vti-interface SYSTEM "d.ipsec.conf/conn/vti-interface.xml">
+<!ENTITY conn.vti-routing SYSTEM "d.ipsec.conf/conn/vti-routing.xml">
+<!ENTITY conn.vti-shared SYSTEM "d.ipsec.conf/conn/vti-shared.xml">
+<!ENTITY conn.xauthby SYSTEM "d.ipsec.conf/conn/xauthby.xml">
+<!ENTITY conn.xauthclient SYSTEM "d.ipsec.conf/conn/xauthclient.xml">
+<!ENTITY conn.xauthfail SYSTEM "d.ipsec.conf/conn/xauthfail.xml">
+<!ENTITY conn.xauthserver SYSTEM "d.ipsec.conf/conn/xauthserver.xml">
+
+<!ENTITY setup.audit-log SYSTEM "d.ipsec.conf/setup/audit-log.xml">
+<!ENTITY setup.crl-strict SYSTEM "d.ipsec.conf/setup/crl-strict.xml">
+<!ENTITY setup.crl-timeout SYSTEM "d.ipsec.conf/setup/crl-timeout.xml">
+<!ENTITY setup.crlcheckinterval SYSTEM "d.ipsec.conf/setup/crlcheckinterval.xml">
+<!ENTITY setup.curl-iface SYSTEM "d.ipsec.conf/setup/curl-iface.xml">
+<!ENTITY setup.ddos-ike-threshold SYSTEM "d.ipsec.conf/setup/ddos-ike-threshold.xml">
+<!ENTITY setup.ddos-mode SYSTEM "d.ipsec.conf/setup/ddos-mode.xml">
+<!ENTITY setup.dns-resolver SYSTEM "d.ipsec.conf/setup/dns-resolver.xml">
+<!ENTITY setup.dnssec-anchors SYSTEM "d.ipsec.conf/setup/dnssec-anchors.xml">
+<!ENTITY setup.dnssec-enable SYSTEM "d.ipsec.conf/setup/dnssec-enable.xml">
+<!ENTITY setup.dnssec-rootkey-file SYSTEM "d.ipsec.conf/setup/dnssec-rootkey-file.xml">
+<!ENTITY setup.dumpdir SYSTEM "d.ipsec.conf/setup/dumpdir.xml">
+<!ENTITY setup.expire-lifetime SYSTEM "d.ipsec.conf/setup/expire-lifetime.xml">
+<!ENTITY setup.expire-shunt-interval SYSTEM "d.ipsec.conf/setup/expire-shunt-interval.xml">
+<!ENTITY setup.global-redirect SYSTEM "d.ipsec.conf/setup/global-redirect.xml">
+<!ENTITY setup.global-redirect-to SYSTEM "d.ipsec.conf/setup/global-redirect-to.xml">
+<!ENTITY setup.ike-socket-bufsize SYSTEM "d.ipsec.conf/setup/ike-socket-bufsize.xml">
+<!ENTITY setup.ike-socket-errqueue SYSTEM "d.ipsec.conf/setup/ike-socket-errqueue.xml">
+<!ENTITY setup.ikev1-policy SYSTEM "d.ipsec.conf/setup/ikev1-policy.xml">
+<!ENTITY setup.ipsec-interface-managed SYSTEM "d.ipsec.conf/setup/ipsec-interface-managed.xml">
+<!ENTITY setup.ipsecdir SYSTEM "d.ipsec.conf/setup/ipsecdir.xml">
+<!ENTITY setup.keep-alive SYSTEM "d.ipsec.conf/setup/keep-alive.xml">
+<!ENTITY setup.listen SYSTEM "d.ipsec.conf/setup/listen.xml">
+<!ENTITY setup.listen-tcp SYSTEM "d.ipsec.conf/setup/listen-tcp.xml">
+<!ENTITY setup.listen-udp SYSTEM "d.ipsec.conf/setup/listen-udp.xml">
+<!ENTITY setup.logappend SYSTEM "d.ipsec.conf/setup/logappend.xml">
+<!ENTITY setup.logfile SYSTEM "d.ipsec.conf/setup/logfile.xml">
+<!ENTITY setup.logip SYSTEM "d.ipsec.conf/setup/logip.xml">
+<!ENTITY setup.logtime SYSTEM "d.ipsec.conf/setup/logtime.xml">
+<!ENTITY setup.max-halfopen-ike SYSTEM "d.ipsec.conf/setup/max-halfopen-ike.xml">
+<!ENTITY setup.myvendorid SYSTEM "d.ipsec.conf/setup/myvendorid.xml">
+<!ENTITY setup.nflog-all SYSTEM "d.ipsec.conf/setup/nflog-all.xml">
+<!ENTITY setup.nhelpers SYSTEM "d.ipsec.conf/setup/nhelpers.xml">
+<!ENTITY setup.nssdir SYSTEM "d.ipsec.conf/setup/nssdir.xml">
+<!ENTITY setup.ocsp-cache-max-age SYSTEM "d.ipsec.conf/setup/ocsp-cache-max-age.xml">
+<!ENTITY setup.ocsp-cache-min-age SYSTEM "d.ipsec.conf/setup/ocsp-cache-min-age.xml">
+<!ENTITY setup.ocsp-cache-size SYSTEM "d.ipsec.conf/setup/ocsp-cache-size.xml">
+<!ENTITY setup.ocsp-enable SYSTEM "d.ipsec.conf/setup/ocsp-enable.xml">
+<!ENTITY setup.ocsp-method SYSTEM "d.ipsec.conf/setup/ocsp-method.xml">
+<!ENTITY setup.ocsp-strict SYSTEM "d.ipsec.conf/setup/ocsp-strict.xml">
+<!ENTITY setup.ocsp-timeout SYSTEM "d.ipsec.conf/setup/ocsp-timeout.xml">
+<!ENTITY setup.ocsp-trustname SYSTEM "d.ipsec.conf/setup/ocsp-trustname.xml">
+<!ENTITY setup.ocsp-uri SYSTEM "d.ipsec.conf/setup/ocsp-uri.xml">
+<!ENTITY setup.plutodebug SYSTEM "d.ipsec.conf/setup/plutodebug.xml">
+<!ENTITY setup.protostack SYSTEM "d.ipsec.conf/setup/protostack.xml">
+<!ENTITY setup.seccomp SYSTEM "d.ipsec.conf/setup/seccomp.xml">
+<!ENTITY setup.secretsfile SYSTEM "d.ipsec.conf/setup/secretsfile.xml">
+<!ENTITY setup.seedbits SYSTEM "d.ipsec.conf/setup/seedbits.xml">
+<!ENTITY setup.shuntlifetime SYSTEM "d.ipsec.conf/setup/shuntlifetime.xml">
+<!ENTITY setup.statsbin SYSTEM "d.ipsec.conf/setup/statsbin.xml">
+<!ENTITY setup.syslog SYSTEM "d.ipsec.conf/setup/syslog.xml">
+<!ENTITY setup.uniqueids SYSTEM "d.ipsec.conf/setup/uniqueids.xml">
+<!ENTITY setup.virtual-private SYSTEM "d.ipsec.conf/setup/virtual-private.xml">
]>
<refpurpose>IPsec configuration and connections</refpurpose>
</refnamediv>
- &connsections;
- &units;
+ §.connsections;
+ §.units;
<refsect1 id='conn_sections'>
- &exampleleftright;
+ §.exampleleftright;
<refsect2 id='conn_parameters__general'>
<title>
values of these parameters.
</para>
<variablelist>
- &keyexchange;
- &hostaddrfamily;
- &clientaddrfamily;
- &type;
- &iptfs;
- &host;
- &subnet;
- &subnets;
- &vti;
- &addresspool;
- &protoport;
- &nexthop;
- &sourceip;
- &updown;
- &cat;
- &firewall;
+ &conn.keyexchange;
+ &conn.hostaddrfamily;
+ &conn.clientaddrfamily;
+ &conn.type;
+ &conn.iptfs;
+ &conn.host;
+ &conn.subnet;
+ &conn.subnets;
+ &conn.vti;
+ &conn.addresspool;
+ &conn.protoport;
+ &conn.nexthop;
+ &conn.sourceip;
+ &conn.updown;
+ &conn.cat;
+ &conn.firewall;
</variablelist>
<para>
If one or both security gateways are doing forwarding
the values of these parameters.
</para>
<variablelist>
- &auto;
- &authby;
- &ike;
- &phase2;
- &sha2-truncbug;
- &ms-dh-downgrade;
- &dns-match-id;
- &require-id-on-certificate;
- &ppk;
- &ppk-ids;
- &nat-ikev1-method;
- &share-lease;
- &esp;
- &ah;
- &fragmentation;
- &ikepad;
- &mobike;
- &intermediate;
- &esn;
- &decap-dscp;
- &encap-dscp;
- &nopmtudisc;
- &narrowing;
- &nic-offload;
- &id;
- &rsasigkey;
- &cert;
- &ckaid;
- &auth;
- &autheap;
- &ca;
- &ikeport;
- &sendcert;
- &xauthserver;
- &xauthclient;
- &username;
- &modecfgserver;
- &modecfgclient;
- &xauthby;
- &xauthfail;
- &pam-authorize;
- &modecfgpull;
- &modecfgoptions;
- &remote-peer-type;
- &nm-configured;
- &encapsulation;
- &enable-tcp;
- &tcp-remoteport;
- &nat-keepalive;
- &initial-contact;
- &cisco-unity;
- &cisco-split;
- &ignore-peer-dns;
- &accept-redirect-to;
- &accept-redirect;
- &redirect-to;
- &send-redirect;
- &fake-strongswan;
- &send-vendorid;
- &overlapip;
- &reqid;
- &dpddelay;
- &dpdtimeout;
- &pfs;
- &aggressive;
- &salifetime;
- &ipsec-max-bytes;
- &ipsec-max-packets;
- &replay-window;
- &rekey;
- &rekeymargin;
- &rekeyfuzz;
- &ikelifetime;
- &retransmit-timeout;
- &retransmit-interval;
- &compress;
- &metric;
- &mtu;
- &tfc;
- &send-no-esp-tfc;
- &nflog-group;
- &mark;
- &mark-in;
- &mark-out;
- &vti-interface;
- &vti-routing;
- &vti-shared;
- &ipsec-interface;
- &interface-ip;
- &priority;
- &sendca;
- &policy-label;
- &failureshunt;
- &negotiationshunt;
- &debug;
- &reject-simultaneous-ike-auth;
+ &conn.auto;
+ &conn.authby;
+ &conn.ike;
+ &conn.phase2;
+ &conn.sha2-truncbug;
+ &conn.ms-dh-downgrade;
+ &conn.dns-match-id;
+ &conn.require-id-on-certificate;
+ &conn.ppk;
+ &conn.ppk-ids;
+ &conn.nat-ikev1-method;
+ &conn.share-lease;
+ &conn.esp;
+ &conn.ah;
+ &conn.fragmentation;
+ &conn.ikepad;
+ &conn.mobike;
+ &conn.intermediate;
+ &conn.esn;
+ &conn.decap-dscp;
+ &conn.encap-dscp;
+ &conn.nopmtudisc;
+ &conn.narrowing;
+ &conn.nic-offload;
+ &conn.id;
+ &conn.rsasigkey;
+ &conn.cert;
+ &conn.ckaid;
+ &conn.auth;
+ &conn.autheap;
+ &conn.ca;
+ &conn.ikeport;
+ &conn.sendcert;
+ &conn.xauthserver;
+ &conn.xauthclient;
+ &conn.username;
+ &conn.modecfgserver;
+ &conn.modecfgclient;
+ &conn.xauthby;
+ &conn.xauthfail;
+ &conn.pam-authorize;
+ &conn.modecfgpull;
+ &conn.modecfgoptions;
+ &conn.remote-peer-type;
+ &conn.nm-configured;
+ &conn.encapsulation;
+ &conn.enable-tcp;
+ &conn.tcp-remoteport;
+ &conn.nat-keepalive;
+ &conn.initial-contact;
+ &conn.cisco-unity;
+ &conn.cisco-split;
+ &conn.ignore-peer-dns;
+ &conn.accept-redirect-to;
+ &conn.accept-redirect;
+ &conn.redirect-to;
+ &conn.send-redirect;
+ &conn.fake-strongswan;
+ &conn.send-vendorid;
+ &conn.overlapip;
+ &conn.reqid;
+ &conn.dpddelay;
+ &conn.dpdtimeout;
+ &conn.pfs;
+ &conn.aggressive;
+ &conn.salifetime;
+ &conn.ipsec-max-bytes;
+ &conn.ipsec-max-packets;
+ &conn.replay-window;
+ &conn.rekey;
+ &conn.rekeymargin;
+ &conn.rekeyfuzz;
+ &conn.ikelifetime;
+ &conn.retransmit-timeout;
+ &conn.retransmit-interval;
+ &conn.compress;
+ &conn.metric;
+ &conn.mtu;
+ &conn.tfc;
+ &conn.send-no-esp-tfc;
+ &conn.nflog-group;
+ &conn.mark;
+ &conn.mark-in;
+ &conn.mark-out;
+ &conn.vti-interface;
+ &conn.vti-routing;
+ &conn.vti-shared;
+ &conn.ipsec-interface;
+ &conn.interface-ip;
+ &conn.priority;
+ &conn.sendca;
+ &conn.policy-label;
+ &conn.failureshunt;
+ &conn.negotiationshunt;
+ &conn.debug;
+ &conn.reject-simultaneous-ike-auth;
</variablelist>
</refsect2>
</refsect1>
<option>config setup</option> section are:
</para>
<variablelist>
- &protostack;
- &listen;
- &ike-socket-bufsize;
- &ike-socket-errqueue;
- &listen-udp;
- &listen-tcp;
- &nflog-all;
- &keep-alive;
- &virtual-private;
- &myvendorid;
- &nhelpers;
- &seedbits;
- &ikev1-policy;
- &crlcheckinterval;
- &crl-strict;
- &crl-timeout;
- &curl-iface;
- &ocsp-enable;
- &ocsp-strict;
- &ocsp-method;
- &ocsp-timeout;
- &ocsp-uri;
- &ocsp-trustname;
- &ocsp-cache-size;
- &ocsp-cache-min-age;
- &ocsp-cache-max-age;
- &syslog;
- &plutodebug;
- &uniqueids;
- &logfile;
- &logappend;
- &logip;
- &audit-log;
- &logtime;
- &ddos-mode;
- &ddos-ike-threshold;
- &global-redirect;
- &global-redirect-to;
- &max-halfopen-ike;
- &expire-shunt-interval;
- &shuntlifetime;
- &expire-lifetime;
- &dumpdir;
- &statsbin;
- &ipsecdir;
- &nssdir;
- &secretsfile;
- &seccomp;
- &dnssec-enable;
- &dnssec-rootkey-file;
- &dnssec-anchors;
- &ipsec-interface-managed;
- &dns-resolver;
+ &setup.protostack;
+ &setup.listen;
+ &setup.ike-socket-bufsize;
+ &setup.ike-socket-errqueue;
+ &setup.listen-udp;
+ &setup.listen-tcp;
+ &setup.nflog-all;
+ &setup.keep-alive;
+ &setup.virtual-private;
+ &setup.myvendorid;
+ &setup.nhelpers;
+ &setup.seedbits;
+ &setup.ikev1-policy;
+ &setup.crlcheckinterval;
+ &setup.crl-strict;
+ &setup.crl-timeout;
+ &setup.curl-iface;
+ &setup.ocsp-enable;
+ &setup.ocsp-strict;
+ &setup.ocsp-method;
+ &setup.ocsp-timeout;
+ &setup.ocsp-uri;
+ &setup.ocsp-trustname;
+ &setup.ocsp-cache-size;
+ &setup.ocsp-cache-min-age;
+ &setup.ocsp-cache-max-age;
+ &setup.syslog;
+ &setup.plutodebug;
+ &setup.uniqueids;
+ &setup.logfile;
+ &setup.logappend;
+ &setup.logip;
+ &setup.audit-log;
+ &setup.logtime;
+ &setup.ddos-mode;
+ &setup.ddos-ike-threshold;
+ &setup.global-redirect;
+ &setup.global-redirect-to;
+ &setup.max-halfopen-ike;
+ &setup.expire-shunt-interval;
+ &setup.shuntlifetime;
+ &setup.expire-lifetime;
+ &setup.dumpdir;
+ &setup.statsbin;
+ &setup.ipsecdir;
+ &setup.nssdir;
+ &setup.secretsfile;
+ &setup.seccomp;
+ &setup.dnssec-enable;
+ &setup.dnssec-rootkey-file;
+ &setup.dnssec-anchors;
+ &setup.ipsec-interface-managed;
+ &setup.dns-resolver;
</variablelist>
</refsect1>
- &oe_conns;
- &policy_group_files;
- &default_policy_groups;
- &choosing_a_connection;
- &files;
- &see_also;
- &history;
- &bugs;
- &author;
+ §.oe_conns;
+ §.policy_group_files;
+ §.default_policy_groups;
+ §.choosing_a_connection;
+ §.files;
+ §.see_also;
+ §.history;
+ §.bugs;
+ §.author;
</refentry>
projects / 0xmirror / libreswan.git / commitdiff