IPSEC.CONF(5)                                                                      Executable programs                                                                      IPSEC.CONF(5)

       ipsec.conf - IPsec configuration and connections

       The optional ipsec.conf file specifies most configuration and control information for the Libreswan IPsec subsystem. (The major exception is secrets for authentication; see
       ipsec.secrets(5).) Its contents are not security-sensitive.

       The file is a text file, consisting of one or more sections. White space followed by # followed by anything to the end of the line is a comment and is ignored, as are empty lines
       which are not within a section.

       A line which contains include and a file name, separated by white space, is replaced by the contents of that file, preceded and followed by empty lines. If the file name is not a
       full pathname, it is considered to be relative to the directory containing 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 sh(1)); for example:

       include /etc/ipsec.d/*.conf

       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 also and alsoflip parameters (described below) which permit splitting a single logical section (e.g. a connection description) into several
       actual sections.

       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:

       version 2

       A section begins with a line of the form:


       where type indicates what type of section follows, and name is an arbitrary name which 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 which 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.

       Lines within the section are generally of the form


       (note the mandatory preceding white space). There can be white space on either side of the =. 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.

       An empty value stands for the system default value (if any) of the parameter, i.e. it is roughly equivalent to omitting the parameter line entirely. A value may contain white
       space only if the entire value is enclosed in double quotes ("); a value cannot itself contain a double quote, nor may it be continued across more than one line.

       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

       There is currently one parameter which is available in any type of section:

           the value is a section name; the parameters of that section are appended to this section, as if they had been written as part of it. The specified section must exist, must
           follow the current one, and must have the same section type. (Nesting is permitted, and there may be more than one also in a single section, although it is forbidden to
           append the same section more than once.) 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 also parameter and an include line. (Caution, see BUGS below for some restrictions.)

           can be used in a conn section. It acts like an also that flips the referenced section's entries left-for-right.

       Parameter names beginning with x- (or X-, or x_, or X_) are reserved for user extensions and will never be assigned meanings by IPsec. Parameters with such names must still
       observe the syntax rules (limits on characters used in the name; no white space in a non-quoted value; no newlines or double quotes within the value). All other as-yet-unused
       parameter names are reserved for future IPsec improvements.

       A section with name %default specifies defaults for sections of the same type. For each parameter in it, any section of that type which does not have a parameter of the same name
       gets a copy of the one from the %default section. There may be multiple %default sections of a given type, but only one default may be supplied for any specific parameter name,
       and all %default sections of a given type must precede all non-%default sections of that type.  %default sections may not contain also or alsoflip parameters.

       Currently there are two types of section: a config section specifies general configuration information for IPsec, while a conn section specifies an IPsec connection.

       A conn section contains a connection specification, defining a network connection to be made using IPsec. The name given is arbitrary, and is used to identify the connection to
       ipsec_auto(8) Here's a simple example:

           conn snt

       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 “IPsec SAs”) used for user packets is herein referred to as the “connection”; the path used for negotiations (built with
       “ISAKMP SAs”) is referred to as the “keying channel”.

       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 left and right
       participants, rather than in terms of local and remote. Which participant is considered left or right 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 left for the
       local side and right for the remote side (the first letters are a good mnemonic).

       Many of the parameters relate to one participant or the other; only the ones for left are listed here, but every parameter whose name begins with left has a right counterpart,
       whose description is the same but with left and right reversed.

       Parameters are optional unless marked “(required)”

       The following parameters are relevant to IKE automatic keying. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on
       the values of these parameters.

           the connection address family of the connection; currently the accepted values are ipv4 (the default); or ipv6. This option is confusing, especially when doing IPv4-in-IPv6
           or IPv6-in-IPv4 tunnels. The developers hope to remove this option in the near future for proper auto-detection. For now, set connaddrfamily= to the family of the *subnet=
           options, and if those are not defined, to the family of the left=/right= options.

           IPv6 is supported with NETKEY and with KLIPS in all Libreswan versions

           the type of the connection; currently the accepted values are tunnel (the default) signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel; transport,
           signifying host-to-host transport mode; passthrough, signifying that no IPsec processing should be done at all; drop, signifying that packets should be discarded; and reject,
           signifying that packets should be discarded and a diagnostic ICMP returned.

           (required) the IP address of the left participant's public-network interface, in any form accepted by ipsec_ttoaddr(3). Currently, IPv4 and IPv6 IP addresses are supported.
           There are several magic values. If it is %defaultroute, and the config setup section's, interfaces specification contains %defaultroute, left 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 leftnexthop. (Either left or right may
           be %defaultroute, but not both.) The value %any signifies an address to be filled in (by automatic keying) during negotiation. The value %opportunistic signifies that both
           left and leftnexthop are to be filled in (by automatic keying) from DNS data for left'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 %ppp0 The values %group and %opportunisticgroup 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.

           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
           (not 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.

           private subnet behind the left participant, expressed as network/netmask (actually, any form acceptable to ipsec_ttosubnet(3)); Currently, IPv4 and IPv6 ranges are supported.
           if omitted, essentially assumed to be left/32, signifying that the left end of the connection goes to the left participant only

           It supports two magic shorthands vhost: and vnet:, which can list subnets in the same syntax as virtual-private. The value %priv expands to the networks specified in
           virtual-private. The value %no 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
           leftsubnet=vhost:%no,%priv. The vnet: 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.

           specify multiple private subnets behind the left participant, expressed as { networkA/netmaskAnetworkB/netmaskB[...]  } If both a leftsubnets= and rightsubnets= are defined,
           all combinations of subnet tunnels will be established as IPsec tunnels. You cannot use leftsubnet= and leftsubnets= together. For examples see testing/pluto/multinet-*.

           address pool from with the XAUTH server can assign IP addresses to clients. When configured as an XAUTH server, using leftxauthserver=yes this option specifies the address
           pool from which IP addresses are taken to assign the the XAUTH clients. The syntax of the address pool specifies a range (not a CIDR), in the following syntax:
           rightaddresspool= Generally, the rightaddresspool= option will be accompanied by rightxauthclient=yes, leftxauthserver=yes and
           leftsubnet= option.

           When leftaddresspool= is specified, the connection may not specify either leftsubnet= or leftsubnets=. Address pools are fully allocated when the connection is loaded, so the
           ranges should be sane. For example, specifying a range rightaddresspool= will lead to massive memory allocation. Address pools specifying the exact same
           range are shared between different connections. Different addresspools should not be defined to partially overlap.

           allowed protocols and ports over connection, also called Port Selectors. The argument is in the form protocol, which can be a number or a name that will be looked up in
           /etc/protocols, such as leftprotoport=icmp, or in the form of protocol/port, such as tcp/smtp. Ports can be defined as a number (eg. 25) or as a name (eg smtp) which will be
           looked up in /etc/services. A special keyword %any 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: leftprotoport=17/1701.

           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 leftprotoport=icmp/2048. 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 leftprotoport=ipv6-icmp/34816 .

           Some clients, notably older Windows XP and some Mac OSX clients, use a random high port as source port. In those cases rightprotoport=17/%any 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 ipsec eroute and ipsec auto --status eg:"l2tp":
 []:7/1701...%any:17/1701 This option only filters outbound traffic. Inbound traffic selection must still be based on firewall rules
           activated by an updown script. The variables $PLUTO_MY_PROTOCOL, $PLUTO_PEER_PROTOCOL, $PLUTO_MY_PORT, and $PLUTO_PEER_PORT are available for use in updown scripts. Older
           workarounds for bugs involved a setting of 17/0 to denote any single UDP port (not UDP port 0). Some clients, most notably OSX, uses a random high port, instead of port 1701
           for L2TP.

           next-hop gateway IP address for the left participant's connection to the public network; defaults to %direct (meaning right). If the value is to be overridden by the
           left=%defaultroute method (see above), an explicit value must not be given. If that method is not being used, but leftnexthop is %defaultroute, and interfaces=%defaultroute
           is used in the config setup section, the next-hop gateway address of the default-route interface will be used. The magic value %direct 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.

           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 nearest 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.

           what “updown” script to run to adjust routing and/or firewalling when the status of the connection changes (default ipsec _updown). 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
           NETKEY stack, one can use:

           leftupdown="ipsec _updown --route yes"

           See ipsec_pluto(8) for details. Relevant only locally, other end need not agree on it.

           This option is obsolete and should not used anymore.

       If one or both security gateways are doing forwarding firewalling (possibly including masquerading), and this is specified using the firewall parameters, tunnels established with
       IPsec are exempted from it so that packets can flow unchanged through the tunnels. (This means that all subnets connected in this manner must have distinct, non-overlapping
       subnet address blocks.) This is done by the default updown script (see ipsec_pluto(8)).

       The implementation of this makes certain assumptions about firewall setup, and the availability of the Linux Advanced Routing tools. In situations calling for more control, it
       may be preferable for the user to supply his own updown script, which makes the appropriate adjustments for his system.

       The following parameters are relevant to automatic keying via IKE. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly
       on the values of these parameters.

           what operation, if any, should be done automatically at IPsec startup; currently-accepted values are add (signifying an ipsec auto--add), ondemand (signifying that plus an
           ipsec auto--ondemand), start (signifying that plus an ipsec auto--up), and ignore (also the default) (signifying no automatic startup operation). See the config setup
           discussion below. Relevant only locally, other end need not agree on it (but in general, for an intended-to-be-permanent connection, both ends should use auto=start to ensure
           that any reboot causes immediate renegotiation).

           The option ondemand used to be called route

           how the two security gateways should authenticate each other; acceptable values are rsasig (the default) for RSA digital signatures based authentication, secret for shared
           secrets (PSK) authentication, secret|rsasig for either, never if negotiation is never to be attempted or accepted (useful for shunt-only conns), and null for

           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.

           IKE encryption/authentication algorithm to be used for the connection (phase 1 aka ISAKMP SA). The format is "cipher-hash;modpgroup, cipher-hash;modpgroup, ..."  Any left out
           option will be filled in with all allowed default options. Multiple proposals are separated by a comma. If an ike= line is specified, no other received proposals will be
           accepted. Formerly there was a distinction (by using a "!"  symbol) between "strict mode" or not. That mode has been obsoleted. If an ike= option is specified, the mode is
           always strict, meaning no other received proposals will be accepted. Some examples are ike=3des-sha1,aes-sha1, ike=aes, ike=aes_ctr, ike=aes_gcm256-sha2,
           ike=aes128-md5;modp2048, ike=aes128-sha1;dh22, ike=3des-md5;modp1024,aes-sha1;modp1536. The options must be suitable as a value of ipsec_spi(8)'s --ike option. The default is
           to use IKE, and to allow all combinations of:

                               cipher:                 3des or aes128 or aes256
                               hash:                   sha1 or md5
                               pfsgroup (DHgroup):     modp1024 or modp1536 or modp2048

           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, it does require a PRF function, so the second argument to an AEAD algorithm denotes the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with no authentication and
           using SHA2 as the prf. Note that for phase2alg, there is no prf, so AES-GCM is specified for ESP as phase2alg=aes_gcm-null. 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. It is strongly recommended to NOT use the 8 or 12 byte versions of GCM or CCM.

           Weak algorithms are regularly removed from libreswan. Currently, 1DES and modp768 have been removed and modp1024 will be removed in the near future. 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.

           Diffie-Hellman groups 22, 23 and 24 are also implemented as per RFC-5114. Instead of the modp key syntax, use the "dh" keyword, for example ike=3des-sha1;dh23

           The modp syntax will be removed in favour of the dh syntax.

           Sets the type of SA that will be produced. Valid options are: esp for encryption (the default), ah for authentication only.

           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. Only broken configurations (often used with racoon) require the strange double authentication using
           ah+esp. 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.

           Specifies the algorithms that will be offered/accepted for a phase2 negotiation. If not specified, a secure set of defaults will be used. Sets are separated using comma's.

           The default values are the same as for ike= Note also that not all ciphers available to the kernel (eg through CryptoAPI) are necessarily supported here.

           The format for ESP is ENC-AUTH followed by an optional PFSgroup. For instance, "3des-md5" or "aes256-sha1;modp2048" or "aes-sha1,aes-md5".

           For RFC-5114 DH groups, use the "dh" keyword, eg "aes256-sha1;dh23"

           The format for AH is AUTH followed by an optional PFSgroup. For instance, "md5" or "sha1;modp1536".

           AEAD algorithms such as AES-GCM and AES-CCM require null for the authentication algorithm, for example phase2alg=aes_ccm-null or phase2alg=aes_gcm-null. Note that the ike=
           syntax for aes_gcm does not specify a null authentication but specifies the prf instead. The supported key sizes are 128, 192 and 256, which are specified similarly to plain
           aes, i.e.  phase2alg=aes_gcm256. A subscript of _c, _b or _a can be used to refer to the different ICV variants where a means 8 bytes, b means 12 bytes and c means 16 bytes.
           The default when not using a subscript is the 16 byte ICV, the recommended value by RFC-4106. Therefor phase2alg=aes_gcm256-null is equivalent to phase2alg=aes_gcm_c256-null.
           It is recommended to migrate to the _c versions (without specifying _c), as support for smaller ICV's might be removed in the near future.

           The supported algorithms depend on the libreswan version, OS and kernel stack used. Possible ciphers are aes, 3des, aes_ctr, aes_gcm, aes_ccm, camellia, serpent and twofish.

           Note that openswan and versions of libreswan up to 3.6 require manually adding the salt size to the key size. Therefor, to configure an older version of openswan or
           libreswan, use: "phase2alg=aes_ccm_c-280-null" to interop with a new libreswan using "phase2alg=aes_ccm256". For CCM, the 'keysize' needs to be increased by 24, resulted in
           valid keysizes of 152, 215 and 280. For GCM the 'keysize' needs to be increased by 32, resulting valid 'keysizes' of 160, 224 and 288.

           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.

           This option enables using the draft 96 bits version to interop with those implementations. Currently the accepted values are no, (the default) signifying default RFC
           truncation of 128 bits, or yes, signifying the draft 96 bits truncation.

           Another workaround is to switch from sha2_256 to sha2_128 or sha2_512.

           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.

           This option allows fine tuning which of the NAT-T payloads to consider for sending and processing. Currently the accepted values are drafts, rfc or both (the default). To
           interoperate with known broken devices, use nat-ikev1-method=drafts.

           This option is obsolete. Please use phase2alg instead.

           AH authentication algorithm to be used for the connection, e.g here.  hmac-md5 The options must be suitable as a value of ipsec_spi(8)'s --ah option. 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. Note also that not all ciphers available to the
           kernel (eg through CryptoAPI) are necessarily supported here.

           Whether or not to allow IKE fragmentation. Valid values are are yes, (the default), no or force.

           IKEv1 fragmentation capabilities are negotiated via a well-known private vendor id. IKEv2 fragmentation support is implemented using RFC 7383. If pluto does not receive the
           fragmentation payload, no IKE fragments will be sent, regardless of the fragmentation= setting. When set to yes, 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.

           Whether or not to pad IKEv1 messages to a multiple of 4 bytes. Valid values are are yes, (the default) and no.

           IKE padding is allowed in IKEv1 but it is known to cause interoperability issues. The ikepad= option can be used to disable IKEv1 padding. This is required for some devices
           (such as Checkpoint in Aggressive Mode) that reject padded IKEv1 packets. In IKEv2, no padding is allowed, and this option has no effect. If you find a device that seems to
           require IKE padding in IKEv2, please contact the libreswan developers. This option should almost never be enabled.

           IKEv2 (RFC4309) settings to be used. Currently the accepted values are permit, (the default) signifying no IKEv2 should be transmitted, but will be accepted if the other ends
           initiates to us with IKEv2; never or no signifying no IKEv2 negotiation should be transmitted or accepted; propose or yes signifying that we permit IKEv2, and also use it as
           the default to initiate; insist, signifying we only accept and receive IKEv2 - IKEv1 negotiations will be rejected.

           If the ikev2= setting is set to permit or propose, Libreswan will try and detect a "bid down" attack from IKEv2 to IKEv1. Since there is no standard for transmitting the
           IKEv2 capability with IKEv1, Libreswan uses a special Vendor ID "CAN-IKEv2". If a fall back from IKEv2 to IKEv1 was detected, and the IKEv1 negotiation contains Vendor ID
           "CAN-IKEv2", Libreswan will immediately attempt and IKEv2 rekey and refuse to use the IKEv1 connection. With an ikev2= setting of insist, no IKEv1 negotiation is allowed, and
           no bid down attack is possible.

           IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options. Currently the accepted values are no, (the default) signifying no narrowing will be proposed or accepted, or
           yes, signifying IKEv2 negotiation may allow establishing an IPsec connection with narrowed down traffic selectors. This option is ignored for IKEv1.

           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.

           Set the method of tracking reply packets with SArefs when using an SAref compatible stack. Currently only the mast stack supports this. Acceptable values are yes (the
           default), no or conntrack. This option is ignored when SArefs are not supported. This option is passed as PLUTO_SAREF_TRACKING to the updown script which makes the actual
           decisions whether to perform any iptables/ip_conntrack manipulation. A value of yes means that an IPSEC mangle table will be created. This table will be used to match reply
           packets. A value of conntrack means that additionally, subsequent packets using this connection will be marked as well, reducing the lookups needed to find the proper SAref
           by using the ip_conntrack state. A value of no means no IPSEC mangle table is created, and SAref tracking is left to a third-party (kernel) module. In case of a third party
           module, the SArefs can be relayed using the statsbin= notification helper.

           how the left participant should be identified for authentication; defaults to left. Can be an IP address (in any ipsec_ttoaddr(3) syntax) or a fully-qualified domain name
           which will be resolved. If preceded by @, 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 rightid=@[GroupName]. The magic value %fromcert 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 %none 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. The magic value %myid stands for the current setting of myid. This is set
           in config setup or by ipsec_whack(8)), or, if not set, it is the IP address in %defaultroute (if that is supported by a TXT record in its reverse domain), or otherwise it is
           the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.

           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
           comma (eg OU='Foo,, Bar and associates')

           the left participant's public key for RSA signature authentication, in RFC 2537 format using ipsec_ttodata(3) encoding. The magic value %none means the same as not specifying
           a value (useful to override a default). The value %dnsondemand (the default) means the key is to be fetched from DNS at the time it is needed. The value %dnsonload means the
           key is to be fetched from DNS at the time the connection description is read from ipsec.conf; currently this will be treated as %none if right=%any or right=%opportunistic.
           The value %dns is currently treated as %dnsonload but will change to %dnsondemand in the future. The identity used for the left participant must be a specific host, not %any
           or another magic value. The value %cert will load the information required from a certificate defined in %leftcert and automatically define leftid for you.  Caution: if two
           connection descriptions specify different public keys for the same leftid, confusion and madness will ensue.

           if present, a second public key. Either key can authenticate the signature, allowing for key rollover.

           If you are using leftrsasigkey=%cert this defines the certificate nickname of your certificate in the NSS database. This can be on software or hardware security device.

           specifies the authorized Certificate Authority (CA) that signed the certificate of the peer. If undefined, it defaults to the CA that signed the certificate specified in
           leftcert. The special rightca=%same is implied when not specifying a rightca 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.

           This option configures when Libreswan will send X.509 certificates to the remote host. Acceptable values are yes|always (signifying that we should always send a certificate),
           sendifasked (signifying that we should send a certificate if the remote end asks for it), and no|never (signifying that we will never send a X.509 certificate). The default
           for this option is sendifasked which may break compatibility with other vendor's IPsec implementations, such as Cisco and SafeNet. If you find that you are getting errors
           about no ID/Key found, you likely need to set this to always. This per-conn option replaces the obsolete global nocrsend option.

           Left is an XAUTH server. This can use PAM for authentication or md5 passwords in /etc/ipsec.d/passwd. These are additional credentials to verify the user identity, and should
           not be confused with the XAUTH group secret, which is just a regular PSK defined in ipsec.secrets. The other side of the connection should be configured as rightxauthclient.
           XAUTH connections cannot rekey, so rekey=no should be specified in this conn. For further details on how to compile and use XAUTH, see README.XAUTH. Acceptable values are yes
           or no (the default).

           Left is an XAUTH client. The xauth connection will have to be started interactively and cannot be configured using auto=start. Instead, it has to be started from the
           commandline using ipsec auto --up connname. 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 - ipsec whack --name baduser --ipsecgroup-xauth --xauthname badusername
           --xauthpass password --initiate The other side of the connection should be configured as rightxauthserver. Acceptable values are yes or no (the default).

           The XAUTH username associated with this XAUTH connection. The XAUTH password can be configured in the ipsec.secrets file.

           Left is a Mode Config server. It can push network configuration to the client. Acceptable values are yes or no (the default).

           Left is a Mode Config client. It can receive network configuration from the server. Acceptable values are yes or no (the default).

           When IKEv1 XAUTH support is available, set the method used by XAUTH to authenticate the user with IKEv1. The currently supported values are file (the default), pam or
           alwaysok. The password file is located at /etc/ipsec.d/passwd, and follows a syntax similar to the Apache htpasswd file, except an additional connection name argument (and
           optional static IP address) are also present:


           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.

           The alwaysok 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 pam-authorize=yes

           When XAUTH support is available, set the failure method desired when authentication has failed. The currently supported values are hard (the default) and soft. 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.

           IKEv1 supports PAM authorization via XAUTH using xauthby=pam. IKEv2 does not support receiveing 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". See also xauthby=pam

           Pull the Mode Config network information from the server. Acceptable values are yes or no (the default).

       modecfgdns1, modecfgdns2, modecfgdomain, modecfgbanner
           When configured as modecfg server, specifying any of these options will cause those options and values to be sent to the modecfg client during the XAUTH+ModeCFG phase (phase

           When we are an XAUTH client, these options will be treated as defaults. If the remote XAUTH server did not pass us one of these options, the configured defaults are used to
           reconfigure the local DNS setup.

           The split tunneling directive will be sent automatically if the xauth server side has configured a network other than

           Set the remote peer type. This can enable additional processing during the IKE negotiation. Acceptable values are cisco or ietf (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.

           Mark this connection as controlled by Network Manager. Acceptable values are yes or no (the default). Currently, setting this to yes will cause libreswan to skip
           reconfiguring resolv.conf when used with XAUTH and ModeConfig.

           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.
           forceencaps=yes forces the NAT detection code to lie and tell the remote peer that RFC-3948 encapsulation (ESP in UDP port 4500 packets) is required. Acceptable values are
           yes or no (the default).

           whether to send any NAT-T keep-alives. These one byte packets are send to prevent the NAT router from closing its port when there is not enough traffic on the IPsec
           connection. Acceptable values are: yes (the default) and no.

           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: no (the default) and
           yes. It is recommended to leave this option unset, unless the remote peer requires it to allow reconnects. The only known peer at this time is Cisco, which will not allow a
           reconnect (despite authentication) to replace an existing IPsec SA unless it receives an INITIAL_CONTACT payload. Receiving this payload is ignored and the choice to replace
           or add an IPsec SA when libreswan is a responder is purely based on the uniqueids setting, which should be left enabled unless libreswan acts as an XAUTH server using PSK
           ("group secret"). This option can cause a few seconds of downtime on the IPsec tunnel between the time the remote clears the old IPsec SA in response to our INITIAL_CONTACT
           message, and the time we finish setting up the new IPsec SA. If there is an XAUTH step in between, and especially when XAUTH requires the use of some two-factor token, this
           downtime could be even longer.

           whether to send a CISCO_UNITY payload to the peer. Acceptable values are: no (the default) and yes. 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.

           whether to send our Vendor ID during IKE. Acceptable values are: no (the default) and yes. The vendor id sent can be configured using the "config setup" option myvendorid=.
           It defaults to OE-Libreswan-VERSION.

           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.

           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.

           a boolean (yes/no) that determines, when *subnet=vhost: is used, if the virtual IP claimed by this states created from this connection can with states created from other

           Note that connection instances created by the Opportunistic Encryption or PKIX (x.509) instantiation system are distinct internally. They will inherit this policy bit.

           The default is no.

           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.

           a unique identifier used to match IPsec SAs using iptables with NETKEY/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 therefor must be between 1 and 16379.

           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). Manually
           assigned reqids are all identical. Instantiations of connections (those using %any wildcards) will all use the same reqid.

           For KLIPS, when using the MAST variant, a different mechanism called SAref is in use. See overlapip and sareftrack.

           Set the delay (in seconds) between Dead Peer Detection (RFC 3706) keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this connection (default 30 seconds). If dpddelay is
           set, dpdtimeout also needs to be set.

           Set the length of time (in seconds) we will idle without hearing either an R_U_THERE poll from our peer, or an R_U_THERE_ACK reply. After this period has elapsed with no
           response and no traffic, we will declare the peer dead, and remove the SA (default 120 seconds). If dpdtimeout is set, dpdaction also needs to be set.

           When a DPD enabled peer is declared dead, what action should be taken.  hold (default) means the eroute will be put into %hold status, while clear means the eroute and SA
           with both be cleared.  restart means that ALL SAs to the dead peer will renegotiated.

           dpdaction=clear is really only useful on the server of a Road Warrior config.

           The value restart_by_peer has been obsoleted and its functionality moved into the regular restart action.

           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); Since there is no reason to ever refuse PFS, Libreswan will allow a connection defined with pfs=no to use PFS anyway. Acceptable values are yes (the default) and

           This option is obsoleted, please use phase2alg if you need the PFS to be different from phase1 (the default) using: phase2alg=aes128-md5;modp1024

           Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This option has no effect when IKEv2 is used. Acceptable values are no (the default) or yes. When this option is
           enabled, IKEv1 Main Mode will no longer be allowed for this connection.

           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 ikecrack. 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.

           Aggressive Mode is further limited to only proposals with one DH group as there is no room to negotiate the DH group. Therefor it is mandatory for Aggressive Mode connections
           that both ike= and phase2alg= options are specified with only one fully specified proposal using one DH group.

           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.

           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 s (a time in seconds) or a decimal number followed by m, h, or d (a time in minutes, hours, or days respectively) (default 8h,
           maximum 24h). Normally, the connection is renegotiated (via the keying channel) before it expires. The two ends need not exactly agree on salifetime, although if they do not,
           there will be some clutter of superseded connections on the end which thinks the lifetime is longer.

           The keywords "keylife" and "lifetime" are obsoleted aliases for "salifetime." Change your configs to use "salifetime" instead.

           whether a connection should be renegotiated when it is about to expire; acceptable values are yes (the default) and no. The two ends need not agree, but while a value of no
           prevents Pluto from requesting renegotiation, it does not prevent responding to renegotiation requested from the other end, so no will be largely ineffective unless both ends
           agree on it.

           how long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin; acceptable values as for salifetime (default 9m). Relevant only
           locally, other end need not agree on it.

           maximum percentage by which rekeymargin 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 100%). The value of rekeymargin, after this random increase, must not exceed
           salifetime. The value 0% will suppress time randomization. Relevant only locally, other end need not agree on it.

           how many attempts (a whole number or %forever) should be made to negotiate a connection, or a replacement for one, before giving up (default %forever). The value %forever
           means “never give up” (obsolete: this can be written 0). Relevant only locally, other end need not agree on it.

           how long the keying channel of a connection (buzzphrase: “ISAKMP SA”) should last before being renegotiated; acceptable values as for salifetime (default set by
           ipsec_pluto(8), currently 1h, maximum 24h). The two-ends-disagree case is similar to that of salifetime.

           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 60s. See also: retransmit-interval, rekey and keyingtries.

           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 500. See also: retransmit-timeout, rekey and keyingtries.

           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
           before encryption); acceptable values are yes and no (the default).

           As of libreswan 3.1, both ends must agree. In previous versions of libreswan, openswan and freeswan, compression was always accepted even if not configured. In light of the
           BEAST attacks on TLS, using compression and encryptions has come under more scrutiny, and it was decided that it should be possible for the local policy of an endpoint to
           disallow compression. A value of yes causes pluto to propose compression and reject proposals without it. A value of no prevents pluto from proposing compression; a proposal
           to compress will be rejected.

           Set the metric for the routes to the ipsecX or mastX interface. This makes it possible to do host failover from another interface to ipsec using route management. This value
           is passed to the _updown scripts as PLUTO_METRIC. This option is only available with KLIPS or MAST on Linux. Acceptable values are positive numbers, with the default being 1.

           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. Acceptable values are positive numbers. There is no default.

           If set, the NFLOG group number to log this connection's pre-crypt and post-decrypt traffic to. The default value of 0 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 nflog-all option.

           The priority in the kernel SPD/SAD database, when matching up packets. Each kernel (NETKEY, KLIPS, 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

           KLIPS and NETKEY 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.

           Typical values are about the 2000 range. These can be seen on the NETKEY stack using ip xfrm policy 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.

           How much of our available X.509 trust chain to send with the End certificate, excluding any root CA's. Specifying issuer sends just the issuing intermediate CA, while
            all will send the entire chain of intermediate CA's.none (the default) will not send any CA certs.

           whether KLIPS's normal tunnel-exit check (that a packet emerging from a tunnel has plausible addresses in its header) should be disabled; acceptable values are yes and no
           (the default). Tunnel-exit checks improve security and do not break any normal configuration. Relevant only locally, other end need not agree on it.

           Whether labeled IPsec should be enabled or not; acceptable values are no (the default) and yes. See also policy-label= and secctx-attr-type=

           The string representation of an access control security label that is interpreted by the LSM (e.g. SELinux) for use with Labeled IPsec. See also loopback=, labeled-ipsec= and
           secctx-attr-type=. For example, policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023

           what to do with packets when negotiation fails. The default is none: no shunt; passthrough, drop, and reject have the obvious meanings.

           What to do with packets during the IKE negotiation. Valid options are hold (the default) or passthrough. This should almost always be left to the default hold value to avoid
           cleartext packet leaking. The only reason to set this to passthrough is if plaintext service availability is more important than service security or privacy, a scenario that
           also implies failureshunt=passthrough and most likely authby=%null using Opportunistic Encryption.

       At present, the only config section known to the IPsec software is the one named setup, which contains information used when the software is being started (see ipsec_setup(8)).
       Here's an example:

           config setup
                interfaces="ipsec0=eth1 ipsec1=ppp0"

       Parameters are optional unless marked “(required)”.

       The currently-accepted parameter names in a config setup section are:

           the identity to be used for %myid.  %myid is used in the implicit policy group conns and can be used as an identity in explicit conns. If unspecified, %myid is set to the IP
           address in %defaultroute (if that is supported by a TXT record in its reverse domain), or otherwise the system's hostname (if that is supported by a TXT record in its forward
           domain), or otherwise it is undefined. An explicit value generally starts with ``@''.

           decide which protocol stack is going to be used. Valid values are "klips", "netkey" (the default) and "mast". The "mast" stack is a variation for the KLIPS stack. The value
           "auto" has been obsoleted.

           virtual and physical interfaces for IPsec to use: a single virtual=physical pair, a (quoted!) list of pairs separated by white space, or %none. One of the pairs may be
           written as %defaultroute, which means: find the interface d that the default route points to, and then act as if the value was ``ipsec0=d''.  %defaultroute is the default;
           %none must be used to denote no interfaces, or when using the NETKEY stack. If %defaultroute is used (implicitly or explicitly) information about the default route and its
           interface is noted for use by ipsec_auto(8).)

           IP address to listen on (default depends on interfaces= setting). Currently only accepts one IP address.

           The IKE port to listen on. The default value is 500. As IKE is an internet standard, changing this means pluto will no longer be able to interop with other devices, unless
           they have also been explicitly configured to use a non-standard IKE port. There might also be other subtle assumptions within the kernel that port 500 is used. Changing this
           port is strongly discouraged, and should probably only be done for testing or when required to circumvent VPN blocking technologies as employed by certain commercial
           companies and national governments. See also nat-ikeport.

           If set, the NFLOG group number to log all pre-crypt and post-decrypt traffic to. The default value of 0 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 all-ipsec.
           See also the per-connection nflog option.

           OBSOLETE. Support for NAT Traversal is always enabled.


           This option has been obsoleted since libreswan version 3.2. See the nat-keepalive option.

           The IKE NAT Traversal floating port (see RFC-3947) to listen on. The default value is 4500. As IKE/NATT is an internet standard, changing this means pluto will no longer be
           able to interoperate with other devices, unless they have also been explicitly configured to use a non-standard IKE/NATT port. There might also be other subtle assumptions
           within the kernel that port 4500 is used. Changing this port is strongly discouraged, and should probably only be done for testing or when required to circumvent VPN blocking
           technologies as employed by certain commercial companies and national governments. See also ikeport.

           The delay (in seconds) for NAT-T keep-alive packets, if these are enabled using nat-keepalive This parameter may eventually become per-connection.

           contains the networks that are allowed as subnet= for the remote clients when using the vhost: or vnet: keywords in the subnet= 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 %v4:a.b.c.d/mm and IPv6 is denoted as %v6:aaaa::bbbb:cccc:dddd:eeee/mm.
           One can exclude subnets by using the !. For example, if the VPN server is giving access to, this option should be set to:
           virtual-private=%v4:,%v4:,%v4:,%v4:! 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 leftsubnet=

           Note: It seems that T-Mobile in the US and Rogers/Fido in Canada have started using 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.

           The string to use as our vendor id (VID) when send-vendorid=yes. The default is OE-Libreswan-VERSION.

           This option is ignored for now. It used to determine if Opportunistic Encryption will be enabled. Opportunistic Encryption is the term to describe using IPsec tunnels without
           prearrangement. It uses IPSECKEY or TXT records to announce public RSA keys for certain IP's or identities. However, this feature is going to be moved outside of the pluto
           IKE daemon into a separate process, more closely tied with a local DNS(SEC) server. The default value used to be no, so this should not affect anyone. Contact the developers
           if you are interested in working on the re-implementation of OE.

           how many pluto helpers are started to help with cryptographic operations. Pluto will start (n-1) of them, where n is the number of CPU's you have (including hypherthreaded
           CPU's). A value of 0 forces pluto to do all operations in the main process. A value of -1 tells pluto to perform the above calculation. Any other value forces the number to
           that amount.

           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 ti