1IPSEC.CONF(5)                 Executable programs                IPSEC.CONF(5)
2
3
4

NAME

6       ipsec.conf - IPsec configuration and connections
7

DESCRIPTION

9       The ipsec.conf file specifies most configuration and control
10       information for the Libreswan IPsec subsystem. (The major exception is
11       secrets for authentication; see ipsec.secrets(5).) Its contents are not
12       security-sensitive. Configurations can be added using this
13       configuration file or by using ipsec whack directly. This means that
14       technically, the ipsec.conf file is optional, but a few warnings might
15       show up when this file is missing.
16
17       ipsec.conf is a text file, consisting of one or more sections. White
18       space followed by # followed by anything to the end of the line is a
19       comment and is ignored, as are empty lines that are not within a
20       section.
21
22       A line that contains include and a file name, separated by white space,
23       is replaced by the contents of that file, preceded and followed by
24       empty lines. If the file name is not a full pathname, it is considered
25       to be relative to the directory that contains the including file. Such
26       inclusions can be nested. Only a single filename may be supplied, and
27       it may not contain white space, but it may include shell wildcards (see
28       sh(1)); for example:
29
30       include /etc/ipsec.d/*.conf
31
32       The intention of the include facility is mostly to permit keeping
33       information on connections, or sets of connections, separate from the
34       main configuration file. This permits such connection descriptions to
35       be changed, copied to the other security gateways involved, etc.,
36       without having to constantly extract them from the configuration file
37       and then insert them back into it. Note also the also and alsoflip
38       parameters (described below) which permit splitting a single logical
39       section (e.g. a connection description) into several distinct sections.
40
41       The first significant line of the file may specify a version of this
42       specification for backwards compatibility with freeswan and openswan.
43       It is ignored and unused. For compatibility with openswan, specify:
44
45       version 2
46
47       A section begins with a line of the form:
48
49       type name
50
51       where type indicates what type of section follows, and name is an
52       arbitrary name that distinguishes the section from others of the same
53       type. (Names must start with a letter and may contain only letters,
54       digits, periods, underscores, and hyphens.) All subsequent non-empty
55       lines that begin with white space are part of the section; comments
56       within a section must begin with white space too. There may be only one
57       section of a given type with a given name.
58
59       Lines within the section are generally of the form
60
61            parameter=value
62
63       (note the mandatory preceding white space). There can be white space on
64       either side of the =. Parameter names follow the same syntax as section
65       names, and are specific to a section type. Unless otherwise explicitly
66       specified, no parameter name may appear more than once in a section.
67
68       An empty value stands for the system default value (if any) of the
69       parameter, i.e. it is roughly equivalent to omitting the parameter line
70       entirely. A value may contain white space only if the entire value is
71       enclosed in double quotes ("); a value cannot itself contain a double
72       quote, nor may it be continued across more than one line.
73
74       Numeric values are specified to be either an “integer” (a sequence of
75       digits) or a “decimal number” (sequence of digits optionally followed
76       by `.' and another sequence of digits).
77
78       There is currently one parameter that is available in any type of
79       section:
80
81       also
82           the value is a section name; the parameters of that section are
83           appended to this section, as if they had been written as part of
84           it. The specified section must exist, must follow the current one,
85           and must have the same section type. (Nesting is permitted, and
86           there may be more than one also in a single section, although it is
87           forbidden to append the same section more than once.) This allows,
88           for example, keeping the encryption keys for a connection in a
89           separate file from the rest of the description, by using both an
90           also parameter and an include line. (Caution, see BUGS below for
91           some restrictions.)
92
93       alsoflip
94           can be used in a conn section. It acts like an also that flips the
95           referenced section's entries left-for-right.
96
97       Parameter names beginning with x- (or X-, or x_, or X_) are reserved
98       for user extensions and will never be assigned meanings by IPsec.
99       Parameters with such names must still observe the syntax rules (limits
100       on characters used in the name; no white space in a non-quoted value;
101       no newlines or double quotes within the value). All other as-yet-unused
102       parameter names are reserved for future IPsec improvements.
103
104       A section with name %default specifies defaults for sections of the
105       same type. For each parameter in it, any section of that type that does
106       not have a parameter of the same name gets a copy of the one from the
107       %default section. There may be multiple %default sections of a given
108       type, but only one default may be supplied for any specific parameter
109       name.  %default sections may not contain also or alsoflip parameters.
110
111       Currently there are two types of section: a config section specifies
112       general configuration information for IPsec, while a conn section
113       specifies an IPsec connection.
114

CONN SECTIONS

116       A conn section contains a connection specification, defining a network
117       connection to be made using IPsec. The name given is arbitrary, and is
118       used to identify the connection to ipsec_auto(8) Here's a simple
119       example:
120
121
122           conn snt
123                left=10.11.11.1
124                leftsubnet=10.0.1.0/24
125                leftnexthop=172.16.55.66
126                leftsourceip=10.0.1.1
127                right=192.168.22.1
128                rightsubnet=10.0.2.0/24
129                rightnexthop=172.16.88.99
130                rightsourceip=10.0.2.1
131                keyingtries=%forever
132
133       A note on terminology... In automatic keying, there are two kinds of
134       communications going on: transmission of user IP packets, and
135       gateway-to-gateway negotiations for keying, rekeying, and general
136       control. The data path (a set of “IPsec SAs”) used for user packets is
137       herein referred to as the “connection”; the path used for negotiations
138       (built with “ISAKMP SAs”) is referred to as the “keying channel”.
139
140       To avoid trivial editing of the configuration file to suit it to each
141       system involved in a connection, connection specifications are written
142       in terms of left and right participants, rather than in terms of local
143       and remote. Which participant is considered left or right is arbitrary;
144       IPsec figures out which one it is being run on based on internal
145       information. This permits using identical connection specifications on
146       both ends. There are cases where there is no symmetry; a good
147       convention is to use left for the local side and right for the remote
148       side (the first letters are a good mnemonic).
149
150       Many of the parameters relate to one participant or the other; only the
151       ones for left are listed here, but every parameter whose name begins
152       with left has a right counterpart, whose description is the same but
153       with left and right reversed.
154
155       Parameters are optional unless marked “(required)”
156
157   CONN PARAMETERS: GENERAL
158       The following parameters are relevant to IKE automatic keying. Unless
159       otherwise noted, for a connection to work, in general it is necessary
160       for the two ends to agree exactly on the values of these parameters.
161
162       keyexchange
163           method of key exchange; the default and currently the only accepted
164           value is ike
165
166       hostaddrfamily
167           the address family of the hosts; currently the accepted values are
168           ipv4 and ipv6. The default is to detect this based on the IP
169           addresses specified or the IP addresses resolved, so this option is
170           not needed, unless you specify hostnames that resolve to both IPv4
171           and IPv6. This option used to be named connaddrfamily but its use
172           was broken so it was obsoleted in favour or using the new
173           hostaddrfamily and clientaddrfamily.
174
175       clientaddrfamily
176           the address family of the clients (subnets); currently the accepted
177           values are ipv4 and ipv6. The default is to detect this based on
178           the network IP addresses specified or the network IP addresses
179           resolved, so this option is not needed, unless you specify names
180           that resolve to both IPv4 and IPv6.
181
182       type
183           the type of the connection; currently the accepted values are
184           tunnel (the default) signifying a host-to-host, host-to-subnet, or
185           subnet-to-subnet tunnel; transport, signifying host-to-host
186           transport mode; passthrough, signifying that no IPsec processing
187           should be done at all; drop, signifying that packets should be
188           discarded; and reject, signifying that packets should be discarded
189           and a diagnostic ICMP returned.
190
191       left
192           (required) the IP address or DNS hostname of the left participant's
193           public-network interface, Currently, IPv4 and IPv6 IP addresses are
194           supported. If a DNS hostname is used, it will be resolved to an IP
195           address on load time, and whenever a connection is rekeying or
196           restarting (such as when restarted via a DPD failure detection).
197           This allows one to use a DNS hostname when the endpoint is on a
198           dynamic IP address.
199
200           There are several magic values. If it is %defaultroute, left will
201           be filled in automatically with the local address of the
202           default-route interface (as determined at IPsec startup time); this
203           also overrides any value supplied for leftnexthop. (Either left or
204           right may be %defaultroute, but not both.) The value %any signifies
205           an address to be filled in (by automatic keying) during
206           negotiation. The value %opportunistic signifies that both left and
207           leftnexthop are to be filled in (by automatic keying) from DNS data
208           for left's client. The value can also contain the interface name,
209           which will then later be used to obtain the IP address from to fill
210           in. For example %ppp0. The values %group and %opportunisticgroup
211           makes this a policy group conn: one that will be instantiated into
212           a regular or opportunistic conn for each CIDR block listed in the
213           policy group file with the same name as the conn.
214
215           If using IP addresses in combination with NAT, always use the
216           actual local machine's (NATed) IP address, and if the remote (eg
217           right=) is NATed as well, the remote's public (not NATed) IP
218           address. Note that this makes the configuration no longer
219           symmetrical on both sides, so you cannot use an identical
220           configuration file on both hosts.
221
222       leftsubnet
223           private subnet behind the left participant, expressed as
224           network/netmask (actually, any form acceptable to
225           ipsec_ttosubnet(3)); Currently, IPv4 and IPv6 ranges are supported.
226           if omitted, essentially assumed to be left/32, signifying that the
227           left end of the connection goes to the left participant only
228
229           It supports two magic shorthands vhost: and vnet:, which can list
230           subnets in the same syntax as virtual-private. The value %priv
231           expands to the networks specified in virtual-private. The value %no
232           means no subnet. A common use for allowing roadwarriors to come in
233           on public IPs or via accepted NATed networks from RFC1918 is to use
234           leftsubnet=vhost:%no,%priv. The vnet: option can be used to allow
235           RFC1918 subnets without hardcoding them. When using vnet the
236           connection will instantiate, allowing for multiple tunnels with
237           different subnets.
238
239       leftsubnets
240           specify multiple private subnets behind the left participant,
241           expressed as { networkA/netmaskA, networkB/netmaskB [...]  } If
242           both a leftsubnets= and rightsubnets= are defined, all combinations
243           of subnet tunnels will be established as IPsec tunnels. You cannot
244           use leftsubnet= and leftsubnets= together. For examples see
245           testing/pluto/multinet-*. Be aware that when using spaces as
246           separator, that the entire option value needs to be in double
247           quotes.
248
249       leftvti
250           the address/mask to configure on the VTI interface when
251           vti-interface is set. It takes the form of network/netmask
252           (actually, any form acceptable to ipsec_ttosubnet(3)); Currently,
253           IPv4 and IPv6 ranges are supported. This option is often used in
254           combination with routed based VPNs.
255
256       leftaddresspool
257           address pool from where the IKEv1 ModeCFG or IKEv2 server can
258           assign IP addresses to clients. When configured as a server, using
259           leftxauthserver=yes this option specifies the address pool from
260           which IP addresses are taken to assign the clients. The syntax of
261           the address pool specifies a range (not a CIDR) for IPv4 and CIDR
262           for IPv6, in the following syntax:
263           rightaddresspool=192.168.1.100-192.168.1.200 or
264           rightaddresspool=2001:db8:0:3:1::/97 Generally, the
265           rightaddresspool= option will be accompanied by
266           rightxauthclient=yes, leftxauthserver=yes and leftsubnet=0.0.0.0/0
267           option.
268
269           When leftaddresspool= is specified, the connection may not specify
270           either leftsubnet= or leftsubnets=. Address pools are fully
271           allocated when the connection is loaded, so the ranges should be
272           sane. For example, specifying a range
273           rightaddresspool=10.0.0.0-11.0.0.0 will lead to massive memory
274           allocation. Address pools specifying the exact same range are
275           shared between different connections. Different addresspools should
276           not be defined to partially overlap.
277
278       leftprotoport
279           allowed protocols and ports over connection, also called Port
280           Selectors. The argument is in the form protocol, which can be a
281           number or a name that will be looked up in /etc/protocols, such as
282           leftprotoport=icmp, or in the form of protocol/port, such as
283           tcp/smtp. Ports can be defined as a number (eg. 25) or as a name
284           (eg smtp) which will be looked up in /etc/services. A special
285           keyword %any can be used to allow all ports of a certain protocol.
286           The most common use of this option is for L2TP connections to only
287           allow l2tp packets (UDP port 1701), eg: leftprotoport=17/1701.
288
289           To filter on specific icmp type and code, use the higher 8 bits for
290           type and the lower 8 bits for port. For example, to allow icmp echo
291           packets (type 8, code 0) the 'port' would be 0x0800, or 2048 in
292           decimal, so you configure leftprotoport=icmp/2048. Similarly, to
293           allow ipv6-icmp Neighbour Discovery which has type 136 (0x88) and
294           code 0(0x00) this becomes 0x8800 or in decimal 34816 resulting in
295           leftprotoport=ipv6-icmp/34816 .
296
297           Some clients, notably older Windows XP and some Mac OSX clients,
298           use a random high port as source port. In those cases
299           rightprotoport=17/%any can be used to allow all UDP traffic on the
300           connection. Note that this option is part of the proposal, so it
301           cannot be arbitrarily left out if one end does not care about the
302           traffic selection over this connection - both peers have to agree.
303           The Port Selectors show up in the output of ipsec eroute and ipsec
304           auto --status eg:"l2tp":
305           193.110.157.131[@aivd.libreswan.org]:7/1701...%any:17/1701 This
306           option only filters outbound traffic. Inbound traffic selection
307           must still be based on firewall rules activated by an updown
308           script. The variables $PLUTO_MY_PROTOCOL, $PLUTO_PEER_PROTOCOL,
309           $PLUTO_MY_PORT, and $PLUTO_PEER_PORT are available for use in
310           updown scripts. Older workarounds for bugs involved a setting of
311           17/0 to denote any single UDP port (not UDP port 0). Some clients,
312           most notably OSX, uses a random high port, instead of port 1701 for
313           L2TP.
314
315       leftnexthop
316           next-hop gateway IP address for the left participant's connection
317           to the public network; defaults to %direct (meaning right). If the
318           value is to be overridden by the left=%defaultroute method (see
319           above), an explicit value must not be given. If that method is not
320           being used, but leftnexthop is %defaultroute, the next-hop gateway
321           address of the default-route interface will be used. The magic
322           value %direct signifies a value to be filled in (by automatic
323           keying) with the peer's address. Relevant only locally, other end
324           need not agree on it.
325
326       leftsourceip
327           the IP address for this host to use when transmitting a packet to
328           the other side of this link. Relevant only locally, the other end
329           need not agree. This option is used to make the gateway itself use
330           its internal IP, which is part of the leftsubnet, to communicate to
331           the rightsubnet or right. Otherwise, it will use its nearest IP
332           address, which is its public IP address. This option is mostly used
333           when defining subnet-subnet connections, so that the gateways can
334           talk to each other and the subnet at the other end, without the
335           need to build additional host-subnet, subnet-host and host-host
336           tunnels. Both IPv4 and IPv6 addresses are supported.
337
338       leftupdown
339           what "updown" script to run to adjust routing and/or firewalling
340           when the status of the connection changes (default ipsec _updown).
341           May include positional parameters separated by white space
342           (although this requires enclosing the whole string in quotes);
343           including shell metacharacters is unwise. An example to enable
344           routing when using the XFRM stack, one can use:
345
346           leftupdown="ipsec _updown --route yes"
347
348           To disable calling an updown script, set it to the empty string, eg
349           leftupdown="" or leftupdown="%disabled".
350
351           See ipsec_pluto(8) for details. Relevant only locally, other end
352           need not agree on it.
353
354       leftcat
355           Whether to perform Client Address Translation ("CAT") when using
356           Opportunistic IPsec behind NAT. Accepted values are no (the
357           default) and yes. This option should only be enabled on the special
358           Opportunistic IPsec connections, usually called "private" and
359           "private-or-clear". When set, this option causes the given
360           addresspool IP from the remote peer to be NATed with iptables. It
361           will also install an additional IPsec SA policy to cover the
362           pre-NAT IP. See the Opportunistic IPsec information on the
363           libreswan website for more information and examples.
364
365       leftfirewall
366           This option is obsolete and should not used anymore.
367
368       If one or both security gateways are doing forwarding firewalling
369       (possibly including masquerading), and this is specified using the
370       firewall parameters, tunnels established with IPsec are exempted from
371       it so that packets can flow unchanged through the tunnels. (This means
372       that all subnets connected in this manner must have distinct,
373       non-overlapping subnet address blocks.) This is done by the default
374       updown script (see ipsec_pluto(8)).
375
376       The implementation of this makes certain assumptions about firewall
377       setup, and the availability of the Linux Advanced Routing tools. In
378       situations calling for more control, it may be preferable for the user
379       to supply his own updown script, which makes the appropriate
380       adjustments for his system.
381
382   CONN PARAMETERS: AUTOMATIC KEYING
383       The following parameters are relevant to automatic keying via IKE.
384       Unless otherwise noted, for a connection to work, in general it is
385       necessary for the two ends to agree exactly on the values of these
386       parameters.
387
388       auto
389           what operation, if any, should be done automatically at IPsec
390           startup; currently-accepted values are add (signifying an ipsec
391           auto --add), ondemand (signifying that plus an ipsec auto
392           --ondemand), start (signifying that plus an ipsec auto --up), and
393           ignore (also the default) (signifying no automatic startup
394           operation), and keep (signifying an add plus an attempt to keep the
395           connection up once the remote peer brought it up). See the config
396           setup discussion below. Relevant only locally, other end need not
397           agree on it (but in general, for an intended-to-be-permanent
398           connection, both ends should use auto=start to ensure that any
399           reboot causes immediate renegotiation).
400
401           The option ondemand used to be called route
402
403       authby
404           how the two security gateways should authenticate each other; the
405           default value is rsasig,ecdsa which allows ECDSA with SHA-2 and RSA
406           with SHA2 or SHA1. To limit this further, there are the options of
407           ecdsa for ECDSA digital signatures using SHA-2, rsa-sha2 for
408           RSASSA-PSS digital signatures based authentication with SHA2-256,
409           rsa-sha2_384 for RSASSA-PSS digital signatures based authentication
410           with SHA2-384, rsa-sha2_512 for RSASSA-PSS digital signatures based
411           authentication with SHA2-512, rsa-sha1 for RSA-PKCSv1.5 digital
412           signatures based authentication with SHA1, secret for shared
413           secrets (PSK) authentication, secret|rsasig for either, never if
414           negotiation is never to be attempted or accepted (useful for
415           shunt-only conns), and null for null-authentication.
416
417           If asymmetric authentication is requested, IKEv2 must be enabled,
418           and the options leftauth= and rightauth= should be used instead of
419           authby.
420
421           For IKEv1, SHA2 based signatures are not defined and ECDSA is not
422           implemented, so the default authby= value is rsa-sha1. Using
423           authby=rsasig results in only rsa-sha1 as well. For IKEv2, using
424           authby=rsasig means using rsa-sha2_512, rsa-sha2_384, rsa-sha2_256
425           and rsa-sha1, where rsa-sha1 will used only if RFC 7427 is not
426           supported by the peer.
427
428           As per RFC 8221, authby=rsa-sha1 is only supported in the old
429           style, meaning RSA-PKCSv1.5. The SHA2 variants are only supported
430           for the new style of RFC 7427, so authby=rsa-sha2 will use the new
431           style. The default authby= will remove rsa-sha1 in the near future.
432           It is strongly recommended that if certificates are used, the
433           certificates and the authby= signature methods used are the same,
434           as it increases interoperability and keeps the authentication of
435           everything within one digital signature system.
436
437           Digital signatures are superior in every way to shared secrets.
438           Especially IKEv1 in Aggressive Mode is vulnerable to offline
439           dictionary attacks and is performed routinely by at least the NSA
440           on monitored internet traffic globally. The never option is only
441           used for connections that do not actually start an IKE negotiation,
442           such as type=passthrough connections. The auth method null is used
443           for "anonymous opportunistic IPsec" and should not be used for
444           regular pre-configured IPsec VPNs.
445
446       ike
447           IKE encryption/authentication algorithm to be used for the
448           connection (phase 1 aka ISAKMP SA or IKE SA). If this option is not
449           set, the builtin defaults will be used. This is the preferred
450           method, and allows for gradual automatic updates using the same
451           configuration. Some distributions, such as Fedora and RHEL/CentOS,
452           use a System Wide Crypto Policy that sets the default ike= (and
453           esp=) lines. Specifying your own ike= line means overriding all
454           these system or software recommended defaults, but can be necessary
455           at times. Note that libreswan does not support using a PRF
456           algorithm that is different from the INTEGRITY (hash) algorithm by
457           design.
458
459           The format is "cipher-hash;modpgroup, cipher-hash;modpgroup, ..."
460           Any omitited option will be filled in with all allowed default
461           values. Multiple proposals are separated by a comma. If an ike=
462           line is specified, no other received proposals will be accepted
463           than those specified on the IKE line. Some examples are
464           ike=3des-sha1,aes-sha1, ike=aes, ike=aes_ctr, ike=aes_gcm256-sha2,
465           ike=aes128-md5;modp2048, ike=aes256-sha2;dh19,
466           ike=aes128-sha1;dh22, ike=3des-md5;modp1024,aes-sha1;modp1536.
467
468           IKEv2 allows combining elements into a single proposal. These can
469           be specified by using the + symbol. An example is:
470           ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14.
471           Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305) and
472           non-AEAD algorithms (aes, 3des) cannot be combined into a single
473           proposal. To support aes and aes_gcm, two proposals separated by a
474           comma must be used.
475
476           The default IKE proposal depends on the version of libreswan used.
477           It follow the recommendations of RFC4306, RFC7321 and as of this
478           writing their successor draft documents RFC4306bis and RFC7321bis.
479           As for libreswan 3.32, SHA1 and MODP1536(dh5) are still allowed per
480           default for backwards compatibility, but 3DES and MODP1024(dh2) are
481           not allowed per default. As of libreswan 4.x, modp1024(dh2) support
482           is no longer compiled in at all. For IKEv2, the defaults include
483           AES, AES-GCM, DH14 and stronger, and SHA2. The default key size is
484           256 bits. The default AES_GCM ICV is 16 bytes.
485
486           Note that AES-GCM is an AEAD algorithm, meaning that it performs
487           encryption+authentication in one step. This means that AES-GCM must
488           not specify an authentication algorithm. However, for IKE it does
489           require a PRF function, so the second argument to an AEAD algorithm
490           denotes the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with
491           SHA2 as the prf. Note that for phase2alg, there is no prf, so
492           AES-GCM is specified for ESP as esp=aes_gcm-null. The AES-GCM and
493           AES-CCM algorithms support 8,12 and 16 byte ICV's. These can be
494           specified using a postfix, for example aes_gcm_a (for 8), aes_gcm_b
495           (for 12) and aes_gcm_c (for 16). The default (aes_gcm without
496           postfix) refers to the 16 byte ICV version. It is strongly
497           recommended to NOT use the 8 or 12 byte versions of GCM or CCM.
498           These versions are NOT included in the default and will be removed
499           in a future version, following the recommendation of RFC 8247 or it
500           successor.
501
502           Weak algorithms are regularly removed from libreswan. Currently,
503           1DES and modp768(DH1) have been removed and modp1024(DH2) has been
504           disabled at compile time. Additionally, MD5 and SHA1 will be
505           removed within the next few years. Null encryption is available,
506           and should only be used for testing or benchmarking purposes.
507           Please do not request for insecure algorithms to be re-added to
508           libreswan. IKEv1 has been disabled per default, and will soon no
509           longer be compiled in by default.
510
511           For all Diffie-Hellman groups, the "dh" keyword can be used instead
512           of the "modp" keyword. For example ike=3des-sha1;dh19.
513           Diffie-Hellman groups 19,20 and 21 from RFC-5903 are supported.
514           Curve25519 from RFC-8031 is supported as "dh31". Curve448 and GOST
515           DH groups are not yet supported in libreswan because these are not
516           supported yet in the NSS crypto library.
517
518           Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are implemented
519           but not compiled in by default. These DH groups are extremely
520           controversial and MUST NOT be used unless forced (administratively)
521           by the other party. This is further documented in RFC 8247, but the
522           summary is that it cannot be proven that these DH groups do not
523           contain a cryptographic trapdoor (a backdoor by the USG who
524           provided these primes without revealing the seeds and generation
525           process used).
526
527           The modp syntax will be removed in favour of the dh syntax in the
528           future
529
530       phase2
531           Sets the type of SA that will be produced. Valid options are: esp
532           for encryption (the default), ah for authentication only.
533
534           The very first IPsec designs called for use of AH plus ESP to offer
535           authentication, integrity and confidentiality. That dual protocol
536           use was a significant burden, so ESP was extended to offer all
537           three services, and AH remained as an auth/integ. The old mode of
538           ah+esp is no longer supported in compliance with RFC 8221 Section
539           4. Additionally, AH does not play well with NATs, so it is strongly
540           recommended to use ESP with the null cipher if you require
541           unencrypted authenticated transport.
542
543       phase2alg
544           This option is alias to esp.
545
546       sha2-truncbug
547           The default ESP hash truncation for sha2_256 is 128 bits. Some
548           IPsec implementations (Linux before 2.6.33, some Cisco (2811?)
549           routers) implement the draft version which stated 96 bits. If a
550           draft implementation communicates with an RFC implementation, both
551           ends will reject encrypted packets from each other.
552
553           This option enables using the draft 96 bits version to interop with
554           those implementations. Currently the accepted values are no, (the
555           default) signifying default RFC truncation of 128 bits, or yes,
556           signifying the draft 96 bits truncation.
557
558           Another workaround is to switch from sha2_256 to sha2_128 or
559           sha2_512.
560
561       ms-dh-downgrade
562           Whether to allow a downgrade of DiffieHellman group during rekey
563           (using CREATE_CHILD_SA). Microsoft Windows (at the time of writing,
564           Feb 2018) defaults to using the very weak modp1024 (DH2). This can
565           be changed using a Windows registry setting to use modp2048 (DH14).
566           However, at rekey times, it will shamelessly use modp1024 again and
567           the connection might fail. Setting this option to yes (and adding
568           modp1024 proposals to the ike line) this will allow this downgrade
569           attack to happen. This should only be used to support Windows that
570           feature this bug. Currently the accepted values are no, (the
571           default) or yes.
572
573       dns-match-id
574           Whether to perform an additional DNS lookup and confirm the remote
575           ID payload with the DNS name in the reverse DNS PTR record.
576           Accepted values are no (the default) or yes. This check should be
577           enabled when Opportunistic IPsec is enabled in a mode that is based
578           on packet triggers (on-demand) using IPSECKEY records in DNS. Since
579           in that case the IKE daemon pluto does not know the remote ID, it
580           only knows the remote IP address, this option forces it to confirm
581           the peer's proposed ID (and thus its public/private key) with its
582           actual IP address as listed in the DNS. This prevents attacks where
583           mail.example.com's IP address is taken over by a neighbour machine
584           with a valid web.example.com setup. This check is not needed for
585           certificate based Opportunistic IPsec, as "mail.example.com"s
586           certificate does not have an entry for "web.example.com". It is
587           also not needed for DNS server triggered Opportunistic IPsec, as in
588           that case the IKE daemon pluto is informed of both the IP address,
589           and the hostname/public key.
590
591       require-id-on-certificate
592           When using certificates, check whether the IKE peer ID is present
593           as a subjectAltName (SAN) on the peer certificate. Accepted values
594           are yes (the default) or no. This check should only be disabled
595           when intentionally using certificates that do not have their peer
596           ID specified as a SAN on the certificate. These certificates
597           violate RFC 4945 Section 3.1 and are normally rejected to prevent a
598           compromised host from assuming the IKE identity of another host.
599           The SAN limits the IDs that the peer is able to assume.
600
601       ppk
602           EXPERIMENTAL: Post-quantum preshared keys (PPKs) to be used.
603           Currently the accepted values are propose or yes (the default),
604           signifying we propose to use PPK for this connection; insist,
605           signifying we allow communication only if PPK is used for key
606           derivation; never or no, signifying that PPK should not be used for
607           key derivation. PPKs can be used in connections that allow only
608           IKEv2. In libreswan that would mean that ikev2 option must have
609           value insist. (currently based on draft-fluhrer-qr-ikev2, not
610           raft-ietf-ipsecme-qr-ikev2-00)
611
612       nat-ikev1-method
613           NAT Traversal in IKEv1 is negotiated via Vendor ID options as
614           specified in RFC 3947. However, many implementations only support
615           the draft version of the RFC. Libreswan sends both the RFC and the
616           most common draft versions (02, 02_n and 03) to maximize
617           interoperability. Unfortunately, there are known broken
618           implementations of RFC 3947, notably Cisco routers that have not
619           been updated to the latest firmware. As the NAT-T payload is sent
620           in the very first packet of the initiator, there is no method to
621           auto-detect this problem and initiate a workaround.
622
623           This option allows fine tuning which of the NAT-T payloads to
624           consider for sending and processing. Currently the accepted values
625           are drafts, rfc, both (the default) and none. To interoperate with
626           known broken devices, use nat-ikev1-method=drafts. To prevent the
627           other end from triggering IKEv1 NAT-T encapsulation, set this to
628           none. This will omit the NAT-T payloads used to determine NAT,
629           forcing the other end not to use encapsulation.
630
631       esp
632           Specifies the algorithms that will be offered/accepted when
633           negotiating a a Child SA. The general syntax is:
634
635                    ESP = PROPOSAL[,PROPOSAL...]
636                    PROPOSAL = ENCRYPT_ALGS[-INTEG_ALGS[-DH_ALGS]]
637                    ENCRYPT_ALGS = ENCRYPT_ALG[+ENCRYPT_ALG...]
638                    INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]
639                    DH_ALGS = DH_ALG[+DH_ALG...]
640
641
642           During startup, ipsec_pluto(8) will log all supported ESP
643           algorithms.
644
645           Specifying the DH algorithms explicitly is not recommended. When
646           PFS is enabled, and the DH algorithms are omitted, each PROPOSAL
647           will automatically include the DH algorithm negotiated during the
648           IKE exchange.
649
650           AEAD algorithms such as AES_GCM and AES_CCM no not require a
651           separate integrity algorithm. For example esp=aes_gcm256 or
652           esp=aes_ccm.
653
654           For instance:
655
656                    esp=aes_gcm,aes128+aes256-sha2_512+sha2_256-dh14+dh19
657                    esp=aes128-sha2_512-dh14+dh19
658
659
660           If not specified, a secure set of defaults will be used. The
661           program:
662
663                    ipsec algparse esp=...
664
665
666           can be used to query these defaults.
667
668       ah
669           A comma separated list of AH algorithms that will be
670           offered/accepted when negotiating the Child SA. The general syntax
671           is:
672
673                    AH = PROPOSAL[,PROPOSAL...]
674                    PROPOSAL = INTEG_ALGS[-DH_ALGS]
675                    INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]
676                    DH_ALGS = DH_ALG[+DH_ALG...]
677
678
679           During startup, ipsec_pluto(8) will log all supported AH
680           algorithms.
681
682           Specifying the DH algorithms explicitly is not recommended. When
683           PFS is enabled, and the DH algorithms are omitted, each PROPOSAL
684           will automatically include the DH algorithm negotiated during the
685           IKE exchange.
686
687           The default is not to use AH. If for some (invalid) reason you
688           still think you need AH, please use esp with the null encryption
689           cipher instead.
690
691           For instance:
692
693                    ah=sha2_256+sha2_512
694                    ah=sha2_256+sha2_512-dh14+dh19
695
696
697           If not specified, a secure set of defaults will be used. The
698           program:
699
700                    ipsec algparse ah=...
701
702
703           can be used to query these defaults.
704
705       fragmentation
706           Whether or not to allow IKE fragmentation. Valid values are yes,
707           (the default), no or force.
708
709           IKEv1 fragmentation capabilities are negotiated via a well-known
710           private vendor id. IKEv2 fragmentation support is implemented using
711           RFC 7383. If pluto does not receive the fragmentation payload, no
712           IKE fragments will be sent, regardless of the fragmentation=
713           setting. When set to yes, IKE fragmentation will be attempted on
714           the first re-transmit of an IKE packet of a size larger then 576
715           bytes for IPv4 and 1280 bytes for IPv6. If fragmentation is set to
716           force, IKE fragmentation is used on initial transmits of such sized
717           packets as well. When we have received IKE fragments for a
718           connection, pluto behaves as if in force mode.
719
720       ikepad
721           Whether or not to pad IKEv1 messages to a multiple of 4 bytes.
722           Valid values are yes, (the default) and no.
723
724           IKE padding is allowed in IKEv1 but has been known to cause
725           interoperability issues. The ikepad= option can be used to disable
726           IKEv1 padding. This used to be required for some devices (such as
727           Checkpoint in Aggressive Mode) that reject padded IKEv1 packets. A
728           bug was fixed in libreswan 3.25 that applied wrong IKE padding in
729           XAUTH, so it is suspected that Checkpoint padding issue bas been
730           resolved. And this option should not be needed by anyone. In IKEv2,
731           no padding is allowed, and this option has no effect. If you find a
732           device that seems to require IKE padding, please contact the
733           libreswan developers. This option should almost never be enabled
734           and might be removed in a future version.
735
736       ikev2
737           Whether to use IKEv2 (RFC 7296) or IKEv1 (RFC 4301). Currently the
738           accepted values are yes (the default), signifying only IKEv2 is
739           accepted, or no, signifying only IKEv1 is accepted. Previous
740           versions allowed the keywords propose or permit that would allow
741           either IKEv1 or IKEv2, but this is no longer supported. The permit
742           option is interpreted as no and the propose option is interpreted
743           as yes. Older versions also supported keyword insist which is now
744           interpreted as yes.
745
746       mobike
747           Whether to allow MOBIKE (RFC 4555) to enable a connection to
748           migrate its endpoint without needing to restart the connection from
749           scratch. This is used on mobile devices that switch between wired,
750           wireless or mobile data connections. Current values are no (the
751           default) or yes, Only connection acting as modecfgclient will allow
752           the initiator to migrate using mobike. Only connections acting as
753           modecfgserver will allow clients to migrate.
754
755           VTI and MOBIKE might not work well when used together.
756
757       esn
758           Whether or not to enable Extended Sequence Number (ESN) for the
759           IPsec SA. This option is only implemented for IKEv2. ESN is
760           typically used for very high-speed links (10Gbps or faster) where
761           the standard 32 bit sequence number is exhausted too quickly,
762           causing IPsec SA's rekeys to happen too often. Accepted values are
763           either (the default), yes and no. If either is specified as an
764           initiator, the responder will make the choice. As a responder, if
765           either is received, yes is picked.
766
767           If replay-window is set to 0, ESN is disabled as some (most?) IPsec
768           stacks won't support ESN in such a configuration.
769
770       decap-dscp
771           Enable decapsulating the Differentiated Services Code Point (DSCP,
772           formerly known as Terms Of Service (TOS)) bits. If these bits are
773           set on the inner (encrypted) IP packets, these bits are set on the
774           decrypted IP packets. Acceptable values are no (the default) or
775           yes. Currently this feature is only implemented for the Linux XFRM
776           stack.
777
778       nopmtudisc
779           Disable Path MTU discovery for the IPsec SA. Acceptable values are
780           no (the default) or yes. Currently this feature is only implemented
781           for the Linux XFRM stack.
782
783       narrowing
784           IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options.
785           Currently the accepted values are no, (the default) signifying no
786           narrowing will be proposed or accepted, or yes, signifying IKEv2
787           negotiation may allow establishing an IPsec connection with
788           narrowed down traffic selectors. This option is ignored for IKEv1.
789
790           There are security implications in allowing narrowing down the
791           proposal. For one, what should be done with packets that we hoped
792           to tunnel, but cannot. Should these be dropped or send in the
793           clear? Second, this could cause thousands of narrowed down Child
794           SAs to be created if the conn has a broad policy (eg 0/0 to 0/0).
795           One possible good use case scenario is that a remote end (that you
796           fully trust) allows you to define a 0/0 to them, while adjusting
797           what traffic you route via them, and what traffic remains outside
798           the tunnel. However, it is always preferred to setup the exact
799           tunnel policy you want, as this will be much clearer to the user.
800
801       sareftrack
802           Set the method of tracking reply packets with SArefs when using an
803           SAref compatible stack. Currently only the mast stack supports
804           this. Acceptable values are yes (the default), no or conntrack.
805           This option is ignored when SArefs are not supported. This option
806           is passed as PLUTO_SAREF_TRACKING to the updown script which makes
807           the actual decisions whether to perform any iptables/ip_conntrack
808           manipulation. A value of yes means that an IPSEC mangle table will
809           be created. This table will be used to match reply packets. A value
810           of conntrack means that additionally, subsequent packets using this
811           connection will be marked as well, reducing the lookups needed to
812           find the proper SAref by using the ip_conntrack state. A value of
813           no means no IPSEC mangle table is created, and SAref tracking is
814           left to a third-party (kernel) module. In case of a third party
815           module, the SArefs can be relayed using the statsbin= notification
816           helper.
817
818       nic-offload
819           Set the method of Network Interface Controller (NIC) hardware
820           offload for ESP/AH packet processing. Acceptable values are auto
821           (the default), yes or no. This option is separate from any CPU
822           hardware offload available and is currently only available on Linux
823           4.13+ using the XFRM IPsec stack, when compiled with the options
824           CONFIG_XFRM_OFFLOAD, CONFIG_INET_ESP_OFFLOAD and
825           CONFIG_INET6_ESP_OFFLOAD. The auto option will attempt to
826           auto-detect the presence of kernel and hardware support, and then
827           automatically mark the IPsec SA for hardware offloading. One vendor
828           supporting this offload method is Mellanox.
829
830       leftid
831           how the left participant should be identified for authentication;
832           defaults to left. Can be an IP address or a fully-qualified domain
833           name which will be resolved. If preceded by @, the value is used as
834           a literal string and will not be resolved. To support opaque
835           identifiers (usually of type ID_KEY_ID, such as used by Cisco to
836           specify Group Name, use square brackets, eg rightid=@[GroupName].
837           The magic value %fromcert causes the ID to be set to a DN taken
838           from a certificate that is loaded. Prior to 2.5.16, this was the
839           default if a certificate was specified. The magic value %none sets
840           the ID to no ID. This is included for completeness, as the ID may
841           have been set in the default conn, and one wishes for it to default
842           instead of being explicitly set. The magic value %myid stands for
843           the current setting of myid. This is set in config setup or by
844           ipsec_whack(8)), or, if not set, it is the IP address in
845           %defaultroute (if that is supported by a TXT record in its reverse
846           domain), or otherwise it is the system's hostname (if that is
847           supported by a TXT record in its forward domain), or otherwise it
848           is undefined.
849
850           When using certificate based ID's, one need to specify the full
851           RDN, optionally using wildcard matching (eg CN='*'). If the RDN
852           contains a comma, this can be masked using a comma (eg OU='Foo,,
853           Bar and associates')
854
855       leftrsasigkey
856           the left participant's public key for RSA signature authentication,
857           in RFC 2537 format using ipsec_ttodata(3) encoding. The magic value
858           %none means the same as not specifying a value (useful to override
859           a default). The value %dnsondemand (the default) means the key is
860           to be fetched from DNS at the time it is needed. The value
861           %dnsonload means the key is to be fetched from DNS at the time the
862           connection description is read from ipsec.conf; currently this will
863           be treated as %none if right=%any or right=%opportunistic. The
864           value %dns is currently treated as %dnsonload but will change to
865           %dnsondemand in the future. The identity used for the left
866           participant must be a specific host, not %any or another magic
867           value. The value %cert will load the information required from a
868           certificate defined in %leftcert and automatically define leftid
869           for you.  Caution: if two connection descriptions specify different
870           public keys for the same leftid, confusion and madness will ensue.
871
872       leftcert
873           If you are using leftrsasigkey=%cert this defines the certificate
874           nickname of your certificate in the NSS database. This can be on
875           software or hardware security device.
876
877       leftckaid
878           The hex CKAID of the X.509 certificate. Certificates are stored in
879           the NSS database.
880
881       leftauth
882           How the security gateways will authenticate to the other side in
883           the case of asymmetric authentication; acceptable values are rsasig
884           or rsa for RSA Authentication with SHA-1, rsa-sha2 for RSA-PSS
885           digital signatures based authentication with SHA2-256, rsa-sha2_384
886           for RSA-PSS digital signatures based authentication with SHA2-384,
887           rsa-sha2_512 for RSA-PSS digital signatures based authentication
888           with SHA2-512, ecdsa for ECDSA digital signatures based
889           authentication, secret for shared secrets (PSK) authentication and
890           null for null-authentication. There is no default value - if unset,
891           the symmetrical authby= keyword is used to determine the
892           authentication policy of the connection.
893
894           Asymmetric authentication is only supported with IKEv2. If
895           symmetric authentication is required, use authby= instead of
896           leftauth and rightauth. If leftauth is set, rightauth must also be
897           set and authby= must not be set. Asymmetric authentication cannot
898           use secret (psk) on one side and null on the other side - use psk
899           on both ends instead.
900
901           When using EAPONLY authentication, which omits the regular IKEv2
902           AUTH payload, leftauth= (or rightauth=) should be set to eaponly.
903
904           Be aware that the symmetric keyword is authby= but the asymmetric
905           keyword is leftauth and rightauth (without the "by").
906
907       leftautheap
908           Whether the security gateways will authenticate uing an EAP method.
909           Acceptable values are none (the default) and tls for EAPTLS. If EAP
910           is the only authentication method, set leftauth=none in addition to
911           leftautheap=tls=.
912
913           The EAP authentication mechanisms are only available for IKEv2
914           based connections.
915
916       leftca
917           specifies the authorized Certificate Authority (CA) that signed the
918           certificate of the peer. If undefined, it defaults to the CA that
919           signed the certificate specified in leftcert. The special
920           rightca=%same is implied when not specifying a rightca and means
921           that only peers with certificates signed by the same CA as the
922           leftca will be allowed. This option is only useful in complex multi
923           CA certificate situations. When using a single CA, it can be safely
924           omitted for both left and right.
925
926       leftikeport
927           The UDP IKE port to listen on or send data to. This port cannot be
928           0 or 500. For TCP, see tcp-remoteport=
929
930       leftsendcert
931           This option configures when Libreswan will send X.509 certificates
932           to the remote host. Acceptable values are yes|always (signifying
933           that we should always send a certificate), sendifasked (signifying
934           that we should send a certificate if the remote end asks for it),
935           and no|never (signifying that we will never send a X.509
936           certificate). The default for this option is sendifasked which may
937           break compatibility with other vendor's IPsec implementations, such
938           as Cisco and SafeNet. If you find that you are getting errors about
939           no ID/Key found, you likely need to set this to always. This
940           per-conn option replaces the obsolete global nocrsend option.
941
942       leftxauthserver
943           Left is an XAUTH server. This can use PAM for authentication or md5
944           passwords in /etc/ipsec.d/passwd. These are additional credentials
945           to verify the user identity, and should not be confused with the
946           XAUTH group secret, which is just a regular PSK defined in
947           ipsec.secrets. The other side of the connection should be
948           configured as rightxauthclient. XAUTH connections cannot rekey, so
949           rekey=no should be specified in this conn. For further details on
950           how to compile and use XAUTH, see README.XAUTH. Acceptable values
951           are yes or no (the default).
952
953       leftxauthclient
954           Left is an XAUTH client. The xauth connection will have to be
955           started interactively and cannot be configured using auto=start.
956           Instead, it has to be started from the commandline using ipsec auto
957           --up connname. You will then be prompted for the username and
958           password. To setup an XAUTH connection non-interactively, which
959           defeats the whole purpose of XAUTH, but is regularly requested by
960           users, it is possible to use a whack command - ipsec whack --name
961           baduser --ipsecgroup-xauth --xauthname badusername --xauthpass
962           password --initiate The other side of the connection should be
963           configured as rightxauthserver. Acceptable values are yes or no
964           (the default).
965
966       leftusername
967           The username associated with this connection. The username can be
968           the IKEv2 XAUTH username, a GSSAPI username or IKEv2 CP username.
969           For the XAUTH username, the XAUTH password can be configured in the
970           ipsec.secrets file. This option was previously called
971           leftxauthusername.
972
973       leftmodecfgserver
974           Left is a Mode Config server. It can push network configuration to
975           the client. Acceptable values are yes or no (the default).
976
977       leftmodecfgclient
978           Left is a Mode Config client. It can receive network configuration
979           from the server. Acceptable values are yes or no (the default).
980
981       xauthby
982           When IKEv1 XAUTH support is available, set the method used by XAUTH
983           to authenticate the user with IKEv1. The currently supported values
984           are file (the default), pam or alwaysok. The password file is
985           located at /etc/ipsec.d/passwd, and follows a syntax similar to the
986           Apache htpasswd file, except an additional connection name argument
987           (and optional static IP address) are also present:
988
989                 username:password:conname:ipaddress
990
991           For supported password hashing methods, see crypt(3). If pluto is
992           running in FIPS mode, some hash methods, such as MD5, might not be
993           available. Threads are used to launch an xauth authentication
994           helper for file as well as PAM methods.
995
996           The alwaysok should only be used if the XAUTH user authentication
997           is not really used, but is required for interoperability, as it
998           defeats the whole point of XAUTH which is to rely on a secret only
999           known by a human. See also pam-authorize=yes
1000
1001       xauthfail
1002           When XAUTH support is available, set the failure method desired
1003           when authentication has failed. The currently supported values are
1004           hard (the default) and soft. A soft failure means the IPsec SA is
1005           allowed to be established, as if authentication had passed
1006           successfully, but the XAUTH_FAILED environment variable will be set
1007           to 1 for the updown script, which can then be used to redirect the
1008           user into a walled garden, for example a payment portal.
1009
1010       pam-authorize
1011           IKEv1 supports PAM authorization via XAUTH using xauthby=pam. IKEv2
1012           does not support receiving a plaintext username and password.
1013           Libreswan does not yet support EAP authentication methods for IKE.
1014           The pam-authorize=yes option performs an authorization call via
1015           PAM, but only includes the remote ID (not username or password).
1016           This allows for backends to disallow an ID based on non-password
1017           situations, such as "user disabled" or "user over quota". See also
1018           xauthby=pam
1019
1020       modecfgpull
1021           Pull the Mode Config network information from the server.
1022           Acceptable values are yes or no (the default).
1023
1024       modecfgdns, modecfgdomains, modecfgbanner
1025           When configured as IKEv1 ModeCFG or IKEv2 server, specifying any of
1026           these options will cause those options and values to be sent to the
1027           connecting client. Libreswan as a client will use these received
1028           options to either update /etc/resolv.conf or the running unbound
1029           DNS server. When the connection is brought down, the previous DNS
1030           resolving state is restored.
1031
1032           The modecfgdns option takes a comma or space separated list of IP
1033           addresses that can be used for DNS resolution. The modecfgdomains
1034           option takes a comma or space separated list of internal domain
1035           names that are reachable via the supplied modecfgdns DNS servers.
1036
1037           The IKEv1 split tunnel directive will be sent automatically if the
1038           xauth server side has configured a network other than 0.0.0.0/0.
1039           For IKEv2, this is automated via narrowing.
1040
1041       remote-peer-type
1042           Set the remote peer type. This can enable additional processing
1043           during the IKE negotiation. Acceptable values are cisco or ietf
1044           (the default). When set to cisco, support for Cisco IPsec gateway
1045           redirection and Cisco obtained DNS and domainname are enabled. This
1046           includes automatically updating (and restoring) /etc/resolv.conf.
1047           These options require that XAUTH is also enabled on this
1048           connection.
1049
1050       nm-configured
1051           Mark this connection as controlled by Network Manager. Acceptable
1052           values are yes or no (the default). Currently, setting this to yes
1053           will cause libreswan to skip reconfiguring resolv.conf when used
1054           with XAUTH and ModeConfig.
1055
1056       encapsulation
1057           In some cases, for example when ESP packets are filtered or when a
1058           broken IPsec peer does not properly recognise NAT, it can be useful
1059           to force RFC-3948 encapsulation. In other cases, where IKE is
1060           NAT'ed but ESP packets can or should flow without encapsulation, it
1061           can be useful to ignore the NAT-Traversal auto-detection.
1062           encapsulation=yes forces the NAT detection code to lie and tell the
1063           remote peer that RFC-3948 encapsulation (ESP in port 4500 packets)
1064           is required.  encapsulation=no ignores the NAT detection causing
1065           ESP packets to send send without encapsulation. The default value
1066           of encapsulation=auto follows the regular outcome of the NAT
1067           auto-detection code performed in IKE. This option replaced the
1068           obsoleted forceencaps option.
1069
1070       enable-tcp
1071           Normally, IKE negotiation and ESP encapsulation happens over UDP.
1072           This option enables support for IKE and ESP over TCP as per RFC
1073           8229. Acceptable values are no(the default), yes meaning only TCP
1074           will be used, or fallback meaning that TCP will be attempted only
1075           after negotiation over UDP failed. Since performance over TCP is
1076           much less, and TCP sessions are vulnerable to simply RST resets and
1077           MITM attacks causing the TCP connection to close, this option
1078           should really only be used in fallback mode. If used in fallback
1079           mode, it is recommend to reduce the retransmit-timeout from the
1080           default 60s to a much shorter value such as 10s, so that one does
1081           not have to wait a minute for the TCP fallback to be attempted.
1082
1083       tcp-remoteport
1084           Which remote TCP port to use when IKE over TCP is attempted. The
1085           default value is to use the NAT-T IKE port (4500). This value is
1086           not negotiated and should be configured properly on all endpoints.
1087           When opening a TCP socket to the remote host in this port, a
1088           regular ephemeral source port is obtained from the OS. For changing
1089           the UDP ports, see leftikeport=
1090
1091       nat-keepalive
1092           whether to send any NAT-T keep-alives. These one byte packets are
1093           send to prevent the NAT router from closing its port when there is
1094           not enough traffic on the IPsec connection. Acceptable values are:
1095           yes (the default) and no.
1096
1097       initial-contact
1098           whether to send an INITIAL_CONTACT payload to the peer we are
1099           initiating to, if we currently have no IPsec SAs up with that peer.
1100           Acceptable values are: yes (the default) and no. It is recommended
1101           to leave this option set, unless multiple clients with the same
1102           identity are expected to connect using the same subnets and should
1103           operate at the same time. Or if a reconnecting client should not
1104           delete its old instance (eg perhaps it is still running). This is
1105           unlikely to be true.
1106
1107       cisco-unity
1108           whether to send a CISCO_UNITY payload to the peer. Acceptable
1109           values are: no (the default) and yes. It is recommended to leave
1110           this option unset, unless the remote peer (Cisco client or server)
1111           requires it. This option does not modify local behaviour. It can be
1112           needed to connect as a client to a Cisco server. It can also be
1113           needed to act as a server for a Cisco client, which otherwise might
1114           send back an error DEL_REASON_NON_UNITY_PEER.
1115
1116       ignore-peer-dns
1117           whether to ignore received DNS configuration. Acceptable values
1118           are: no (the default) and yes. Normally, when a roadwarrior
1119           connects to a remote VPN, the remote VPN server sends a list of DNS
1120           domains and DNS nameserver IP addresses that the roadwarrior can
1121           use to reach internal only resources through the VPN. This option
1122           allows the roadwarrior to ignore the server's suggestion. The
1123           roadwarrior will normally use this information to update the DNS
1124           resolving process. What is changed depends on the detected DNS
1125           configuration. It can modify /etc/resolv.conf directly, or
1126           reconfigure a locally running DNS server (unbound, knot, stubby or
1127           systemd-resolved) or inform NetworkManager.
1128
1129       accept-redirect
1130           Whether requests of the remote peer to redirect IKE/IPsec SA's are
1131           accepted. Valid options are no (the default) and yes. See also
1132           accept-redirect-to.
1133
1134       accept-redirect-to
1135           Specify the comma separated list of addresses we accept being
1136           redirected to. Both IPv4 and IPv6 addresses are supported as well
1137           the FQDNs. The value %any, as well as not specifying any address,
1138           signifes that we will redirect to any address gateway sends us in
1139           REDIRECT notify payload.
1140
1141           The value of this option is not considered at all if
1142           accept-redirect is set to no.
1143
1144       send-redirect
1145           Whether to send requests for the remote peer to redirect IKE/IPsec
1146           SA's during IKE_AUTH. Valid options are no (the default) and yes.
1147           If set, the option redirect-to= must also be set to indicate where
1148           to redirect peers to. For redirection during IKE_SA_INIT exchange,
1149           see the global-redirect= and global-redirect-to= options. Runtime
1150           redirects can be triggered via the ipsec whack --redirect command.
1151
1152       redirect-to
1153           Where to send remote peers to via the send-redirect option. This
1154           can be an IP address or hostname (FQDN).
1155
1156       fake-strongswan
1157           whether to send a STRONGSWAN Vendor ID payload to the peer.
1158           Acceptable values are: no (the default) and yes. This used to be
1159           required because strongswan rejects certain proposals with private
1160           use numbers such as esp=twofish or esp=serpent unless it receives a
1161           strongswan vendorid by the peer. This option sends such an
1162           (unversioned) vendor id. Note that libreswan and strongswan no
1163           longer support twofish or serpent, so enabling this option likely
1164           will no longer do anything.
1165
1166       send-vendorid
1167           whether to send our Vendor ID during IKE. Acceptable values are: no
1168           (the default) and yes. The vendor id sent can be configured using
1169           the "config setup" option myvendorid=. It defaults to
1170           OE-Libreswan-VERSION.
1171
1172           Vendor ID's can be useful in tracking interoperability problems.
1173           However, specific vendor identification and software versions can
1174           be useful to an attacker when there are known vulnerabilities to a
1175           specific vendor/version.
1176
1177           The prefix OE stands for "Opportunistic Encryption". This prefix
1178           was historically used by The FreeS/WAN Project and The Openswan
1179           Project (openswan up to version 2.6.38) and in one Xeleranized
1180           openswan versions (2.6.39). Further Xeleranized openswan's use the
1181           prefix OSW.
1182
1183       overlapip
1184           a boolean (yes/no) that determines, when (left|right)subnet=vhost:
1185           is used, if the virtual IP claimed by this states created from this
1186           connection can with states created from other connections.
1187
1188           Note that connection instances created by the Opportunistic
1189           Encryption or PKIX (x.509) instantiation system are distinct
1190           internally. They will inherit this policy bit.
1191
1192           The default is no.
1193
1194           This feature is only available with kernel drivers that support SAs
1195           to overlapping conns. At present only the (klips) mast protocol
1196           stack supports this feature.
1197
1198       reqid
1199           a unique identifier used to match IPsec SAs using iptables with
1200           XFRM. This identifier is normally automatically allocated in groups
1201           of 4. It is exported to the _updown script as REQID. On Linux,
1202           reqids are supported with IP Connection Tracking and NAT
1203           (iptables). Automatically generated values use the range 16380 and
1204           higher. Manually specified reqid values therefore must be between 1
1205           and 16379.
1206
1207           Automatically generated reqids use a range of 0-3 (eg 16380-16383
1208           for the first reqid). These are used depending on the exact policy
1209           (AH, AH+ESP, IPCOMP, etc).
1210
1211           WARNING: Manually assigned reqids are all identical. Instantiations
1212           of connections (those using %any wildcards) will all use the same
1213           reqid. If you use manual assigning you should make sure your
1214           connections only match single road warrior only or you break
1215           multiple road warriors behind same NAT router because this feature
1216           requires unique reqids to work.
1217
1218       dpddelay
1219           Set the delay (in time units, defaults to seconds) between Dead
1220           Peer Detection (IKEv1 RFC 3706) or IKEv2 Liveness keepalives that
1221           are sent for this connection (default 0 seconds). Set to enable
1222           checking. If dpddelay is set, dpdtimeout also needs to be set.
1223
1224       dpdtimeout
1225           Set the length of time (in time units, defaults to seconds) that we
1226           will idle without hearing back from our peer. After this period has
1227           elapsed with no response and no traffic, we will declare the peer
1228           dead, and remove the SA (default 0 seconds). Set value bigger than
1229           dpddelay to enable. If dpdtimeout is set, dpddelay also needs to be
1230           set.
1231
1232       dpdaction
1233           When a DPD enabled peer is declared dead, what action should be
1234           taken.  hold (default) means the eroute will be put into %hold
1235           status, while clear means the eroute and SA with both be cleared.
1236           restart means that ALL SAs to the dead peer will renegotiated.
1237
1238           dpdaction=clear is really only useful on the server of a Road
1239           Warrior config.
1240
1241           The value restart_by_peer has been obsoleted and its functionality
1242           moved into the regular restart action.
1243
1244       pfs
1245           whether Perfect Forward Secrecy of keys is desired on the
1246           connection's keying channel (with PFS, penetration of the
1247           key-exchange protocol does not compromise keys negotiated earlier);
1248           Acceptable values are yes (the default) and no.
1249
1250       pfsgroup
1251           This option is obsoleted, please use phase2alg if you need the PFS
1252           to be different from phase1 (the default) using:
1253           phase2alg=aes128-md5;modp1024
1254
1255       aggressive
1256           Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This option
1257           has no effect when IKEv2 is used. Acceptable values are no (the
1258           default) or yes. When this option is enabled, IKEv1 Main Mode will
1259           no longer be allowed for this connection. The old name of this
1260           option was aggrmode.
1261
1262           Aggressive Mode is less secure, and more vulnerable to Denial Of
1263           Service attacks. It is also vulnerable to brute force attacks with
1264           software such as ikecrack. It should not be used, and it should
1265           especially not be used with XAUTH and group secrets (PSK). If the
1266           remote system administrator insists on staying irresponsible,
1267           enable this option.
1268
1269           Aggressive Mode is further limited to only proposals with one DH
1270           group as there is no room to negotiate the DH group. Therefore it
1271           is mandatory for Aggressive Mode connections that both ike= and
1272           phase2alg= options are specified with only one fully specified
1273           proposal using one DH group.
1274
1275           The KE payload is created in the first exchange packet when using
1276           aggressive mode. The KE payload depends on the DH group used. This
1277           is why there cannot be multiple DH groups in IKEv1 aggressive mode.
1278           In IKEv2, which uses a similar method to IKEv1 Aggressive Mode,
1279           there is an INVALID_KE response payload that can inform the
1280           initiator of the responder's desired DH group and so an IKEv2
1281           connection can actually recover from picking the wrong DH group by
1282           restarting its negotiation.
1283
1284       salifetime
1285           how long a particular instance of a connection (a set of
1286           encryption/authentication keys for user packets) should last, from
1287           successful negotiation to expiry; acceptable values are an integer
1288           optionally followed by s (a time in seconds) or a decimal number
1289           followed by m, h, or d (a time in minutes, hours, or days
1290           respectively) (default 8h, maximum 24h). Normally, the connection
1291           is renegotiated (via the keying channel) before it expires. The two
1292           ends need not exactly agree on salifetime, although if they do not,
1293           there will be some clutter of superseded connections on the end
1294           which thinks the lifetime is longer.
1295
1296           The keywords "keylife" and "lifetime" are obsoleted aliases for
1297           "salifetime." Change your configs to use "salifetime" instead.
1298
1299       ipsec-max-bytes
1300           how many bytes can be sent, or how many bytes can be received on an
1301           IPsec SA instance for a connection; acceptable values are an
1302           integer optionally followed by KiB, MiB, GiB, TiB, PiB or EiB to
1303           signify kilobytes, megabytes, gigabytes, terabytes, petabytes or
1304           exabytes.
1305
1306           An IPsec SA contains two keys, one for inbound and one for outbound
1307           traffic. The ipsec-max-bytes sets two limits on each of these keys:
1308           the hard limit which is the total number of bytes that a given key
1309           can encrypt, and the soft limit which is the number of bytes that
1310           can be encrypted before a renegotiation of the IPsec SA is
1311           initiated. Normally the renegotation (via the IKE SA) is completed
1312           before the ipsec-max-bytes value is reached.
1313
1314           Pluto sets the the original initiator's soft limit to 25% of
1315           ipsec-max-bytes (with 12% fuzz) and on the original responder's
1316           soft limit to 50% of ipsec-max-bytes (with 12% fuzz). This way the
1317           original initiator hopefully is the one initiating the
1318           renegotiation of the IPsec SA.
1319
1320           This option is not negotiated between IKE peers. Each end of the
1321           IPsec SA sets their own limits independently.
1322
1323           The default (hard limit) is 2^63 bytes. The original initiator's
1324           soft limit is 2^61 bytes (approx.) and the original responder's
1325           soft limit is 2^62 bytes (approx.).
1326
1327       ipsec-max-packets
1328           how many packets can be sent/received on a particular instance of a
1329           connection (a set of encryption/authentication keys for user
1330           packets) , from successful negotiation to expiry.
1331
1332           Default values and caveats are the same as for ipsec-max-bytes.
1333           This option uses a prefix without "B" for bytes.
1334
1335       replay-window
1336           The size of the IPsec SA replay window protection in packets.
1337           Kernels (Linux, and most BSDs) support a window size of at least
1338           2040 packets. The default replay window size is 128 packets.
1339
1340           A value of 0 disables replay protection. Disabling of replay
1341           protection is sometimes used on a pair of IPsec servers in a High
1342           Availability setup, or on servers with very unpredictable latency,
1343           such as mobile networks, which can cause an excessive amount of out
1344           of order packets.
1345
1346           Disabling replay protection will also disable Extended Sequence
1347           Numbers (esn=no), as advise from RFC 4303 caused some stacks to not
1348           support ESN without a replay-window.
1349
1350           Note: on Linux, sequence errors can be seen in /proc/net/xfrm_stat.
1351
1352           Note: the BSD setkey utility displays the replay window size in
1353           bytes (8 packets per byte) and not packets.
1354
1355           Technically, at least the Linux kernel can install IPsec SA's with
1356           an IPsec SA Sequence Number, but this is currently not supported by
1357           libreswan.
1358
1359       rekey
1360           whether a connection should be renegotiated when it is about to
1361           expire; acceptable values are yes (the default) and no. The two
1362           ends need not agree, but while a value of no prevents Pluto from
1363           requesting renegotiation, it does not prevent responding to
1364           renegotiation requested from the other end, so no will be largely
1365           ineffective unless both ends agree on it.
1366
1367       rekeymargin
1368           how long before connection expiry or keying-channel expiry should
1369           attempts to negotiate a replacement begin; acceptable values as for
1370           salifetime (default 9m). Relevant only locally, other end need not
1371           agree on it.
1372
1373       rekeyfuzz
1374           maximum percentage by which rekeymargin should be randomly
1375           increased to randomize rekeying intervals (important for hosts with
1376           many connections); acceptable values are an integer, which may
1377           exceed 100, followed by a `%' (default set by ipsec_pluto(8),
1378           currently 100%). The value of rekeymargin, after this random
1379           increase, must not exceed salifetime. The value 0% will suppress
1380           time randomization. Relevant only locally, other end need not agree
1381           on it.
1382
1383       keyingtries
1384           how many attempts (a whole number or %forever) should be made to
1385           negotiate a connection, or a replacement for one, before giving up
1386           (default %forever). The value %forever or 0 means to keep trying
1387           forever. For Opportunistic Encryption connections, a keyingtries
1388           value of %forever or 0 is set to 1 and a warning message will be
1389           logged. This is because an expired failureshunt triggers new
1390           keyingtries on-demand later, when there is traffic. This prevents
1391           accumulating an infinite amount of attempts to peers that do not
1392           support Opportunistic Encryption. For Opportunistic, a keyingtries
1393           value of > 1 is allowed but currently not recommended. The meaning
1394           of failureshunt= is unclear when there is continued (failed) keying
1395           happening with a negotiationshunt installed. Relevant only locally,
1396           other end need not agree on it.
1397
1398       ikelifetime
1399           how long the keying channel of a connection (buzzphrase: “IKE SA”
1400           or “Parent SA”) should last before being renegotiated; acceptable
1401           values as for salifetime. The default as of version 4.2 is 8h,
1402           before that it was 1h. The maximum is 24h. The two-ends-disagree
1403           case is similar to that of salifetime.
1404
1405       retransmit-timeout
1406           how long a single packet, including retransmits of that packet, may
1407           take before the IKE attempt is aborted. If rekeying is enabled, a
1408           new IKE attempt is started. The default set by ipsec_pluto(8),
1409           currently is 60s. See also: retransmit-interval, rekey and
1410           keyingtries.
1411
1412       retransmit-interval
1413           the initial interval time period, specified in msecs, that pluto
1414           waits before retransmitting an IKE packet. This interval is doubled
1415           for each attempt (exponential back-off). The default set by
1416           ipsec_pluto(8), currently is 500. See also: retransmit-timeout,
1417           rekey and keyingtries.
1418
1419       compress
1420           whether IPComp compression of content is proposed on the connection
1421           (link-level compression does not work on encrypted data, so to be
1422           effective, compression must be done before encryption); acceptable
1423           values are yes and no (the default).
1424
1425           For IKEv1, compress settings on both peers must match. For IKEv2,
1426           compression can only be suggested and a mismatched compress setting
1427           results in connection without compression.
1428
1429           When set to yes, compression is negotiated for the DEFLATE
1430           compression algorithm.
1431
1432       metric
1433           Set the metric for added routes. This value is passed to the
1434           _updown scripts as PLUTO_METRIC. Acceptable values are positive
1435           numbers, with the default being 1.
1436
1437       mtu
1438           Set the MTU for the route(s) to the remote endpoint and/or subnets.
1439           This is sometimes required when the overhead of the IPsec
1440           encapsulation would cause the packet the become too big for a
1441           router on the path. Since IPsec cannot trust any unauthenticated
1442           ICMP messages, PATH MTU discovery does not work. This can also be
1443           needed when using "6to4" IPV6 deployments, which adds another
1444           header on the packet size. Acceptable values are positive numbers.
1445           There is no default.
1446
1447       tfc
1448           Enable Traffic Flow Confidentiality ("TFC") (RFC-4303) for outgoing
1449           ESP packets in Tunnel Mode. When enabled, ESP packets are padded to
1450           the specified size (up to the PMTU size) to prevent leaking
1451           information based on ESP packet size. This option is ignored for AH
1452           and for ESP in Transport Mode as those always leak traffic
1453           characteristics and applying TFC will not do anything. Acceptable
1454           values are positive numbers. The value 0 means TFC padding is not
1455           performed. Currently this feature is only implemented for the Linux
1456           XFRM stack. In IKEv2, when the notify payload
1457           ESP_TFC_PADDING_NOT_SUPPORTED is received, TFC padding is disabled.
1458           The default is not to do any TFC padding, but this might change in
1459           the near future.
1460
1461       send-no-esp-tfc
1462           Whether or not to tell the remote peer that we do not support
1463           Traffic Flow Confidentiality ("TFC") (RFC-4303). Possible values
1464           are no (the default) which allows the peer to use TFC or yes which
1465           prevents to peer from using TFC. This does not affect whether this
1466           endpoint uses TFC, which only depends on the local tfc setting.
1467           This option is only valid for IKEv2.
1468
1469       nflog
1470           If set, the NFLOG group number to log this connection's pre-crypt
1471           and post-decrypt traffic to. The default value of 0 means no
1472           logging at all. This option is only available on linux kernel
1473           2.6.14 and later. It allows common network utilities such as
1474           tcpdump, wireshark and dumpcap, to use nflog:XXX pseudo interfaces
1475           where XXX is the nflog group number. During the updown phase of a
1476           connection, iptables will be used to add and remove the
1477           source/destination pair to the nflog group specified. The rules are
1478           setup with the nflog-prefix matching the connection name. See also
1479           the global nflog-all option.
1480
1481       mark
1482           If set, the MARK to set for the IPsec SA of this connection. The
1483           format of a CONNMARK is mark/mask. If the mask is left out, a
1484           default mask of 0xffffffff is used. A mark value of -1 means to
1485           assign a new global unique mark number for each instance of the
1486           connection. Global marks start at 1001. This option is only
1487           available on linux XFRM kernels. It can be used with iptables to
1488           create custom iptables rules using CONNMARK. It can also be used
1489           with Virtual Tunnel Interfaces ("VTI") to direct marked traffic to
1490           specific vtiXX devices.
1491
1492       mark-in
1493           The same as mark, but mark-in only applies to the inbound half of
1494           the IPsec SA. It overrides any mark= setting.
1495
1496       mark-out
1497           The same as mark, but mark-out only applies to the outbound half of
1498           the IPsec SA. It overrides any mark= setting.
1499
1500       vti-interface
1501           This option is used to create "Routing based VPNs" (as opposed to
1502           "Policy based VPNs"). It will create a new interface that can be
1503           used to route traffic in for encryption/decryption. The Virtual
1504           Tunnel Interface ("VTI") interface name is used to for all IPsec
1505           SA's created by this connection. This requires that the connection
1506           also enables either the mark= or mark-in= / mark-out- option(s).
1507           All traffic marked with the proper MARKs will be automatically
1508           encrypted if there is an IPsec SA policy covering the
1509           source/destination traffic. Tools such as tcpdump and iptables can
1510           be used on all cleartext pre-encrypt and post-decrypt traffic on
1511           the device. See the libreswan wiki for example configurations that
1512           use VTI.
1513
1514           VTI interfaces are currently only supported on Linux with XFRM. The
1515           _updown script handles certain Linux specific interfaces settings
1516           required for proper functioning (disable_policy, rp_filter,
1517           forwarding, etc). Interface names are limited to 16 characters and
1518           may not allow all characters to be used. If marking and
1519           vti-routing=yes is used, no manual iptables should be required.
1520           However, administrators can use the iptables mangle table to mark
1521           traffic manually if desired.
1522
1523       vti-routing
1524           Whether or not to add network rules or routes for IPsec SA's to the
1525           respective VTI devices. Valid values are yes (the default) or no.
1526           When using "routing based VPNs" with a subnets policy of 0.0.0.0/0,
1527           this setting needs to set to no to prevent imploding the tunnel,
1528           and the administrator is expected to manually add ip rules and ip
1529           routes to configure what traffic must be encrypted. When set to
1530           yes, the _updown script will automatically route the
1531           leftsubnet/rightsubnet traffic into the VTI device specified with
1532           vti-interface
1533
1534       vti-shared
1535           Whether or not the VTI device is shared amongst connections. Valid
1536           values are no (the default) or yes. When set to no, the VTI device
1537           is automatically deleted if the connection is a single
1538           non-instantiated connection. If a connection instantiates (eg
1539           right=%any) then this option has no effect, as the VTI device is
1540           not removed as it is shared with multiple roadwarriors.
1541
1542       ipsec-interface
1543           Create or use an existing virtual interface ipsecXXX for "Routing
1544           based VPNs" (as opposed to "Policy based VPNs"). Valid options are
1545           yes, no or a number. When using a number, the IPsec interface
1546           created and/or used will use that number as part of the interface
1547           name. For example setting ipsec-interface=5 will create and/or use
1548           the ipsec5 interface. The value 0 cannot be used and is interpreted
1549           as no. The value yes is interpreted as the number 1, and thus will
1550           use the interface named ipsec1. An IP address can be configured for
1551           this interface via the interface-ip= option.
1552
1553           The ipsec-interface is used to route outbound traffic that needs to
1554           be encrypted, and will decrypt inbound traffic that arrives on this
1555           interface. All traffic that is routed to this interface will be
1556           automatically encrypted providing the IPsec SA policy covers this
1557           traffic. Traffic not matching the IPsec SA will be dropped. Tools
1558           such as tcpdump, iptables, ifconfig and tools that need traffic
1559           counters can be used on all cleartext pre-encrypt and post-decrypt
1560           traffic on the device. When leftsubnet= is equal to rightsubnet=,
1561           the routing needs to be manged by an external routing daemon or
1562           manually by the administrator.
1563
1564           This option is currently only supported on Linux kernels 4.19 or
1565           later when compiled with XFRMi support (CONFIG_XFRM_INTERFACE). The
1566           number of the ipsecX device corresponds with the XFRM IF_ID policy
1567           option of the IPsec SA in the Linux kernel. On Linux, XFRMi
1568           interfaces can be managed by libreswan automatically or can be
1569           preconfigured on the system using the existing init system or via
1570           networking tools such as systemd-networkd and NetworkManager. The
1571           _updown script handles certain Linux specific interfaces settings
1572           required for proper functioning, such as forwarding and routing
1573           rules for IPsec traffic.
1574
1575           The ipsec-interface=0 will create an interface with the same name
1576           as the old KLIPS interface, ipsec0. This interface name should only
1577           be used when required for migration from KLIPS to XFRM interfaces.
1578           Since XFRM IF_ID and marking cannot use 0, this is mapped to 16384.
1579           This means that the devices ipsec0 and ipsec16384 cannot both be in
1580           use.
1581
1582       interface-ip=
1583           NOTE: This option is currently not implemented pending pluto IP
1584           address reference counting. The IP address and netmask to configure
1585           on a virtual device (eg ipsecXXX). This is often used when building
1586           Routing based IPsec tunnels using transport mode and GRE, but can
1587           also be useful in other scenarios. Currently requires
1588           ipsec-interface=. See also leftvti= for cnofiguring IP addresses
1589           when using VTI.
1590
1591       priority
1592           The priority in the kernel SPD/SAD database, when matching up
1593           packets. Each kernel (XFRM, OSX, etc) has its own mechanism for
1594           setting the priority. Setting this option to non-zero passes the
1595           priority to the kernel stack unmodified. The maximum value depends
1596           on the stack. It is recommended not to exceed 65536
1597
1598           XFRM use a priority system based on "most specific match first". It
1599           uses an internal algorithm to calculate these based on network
1600           prefix length, protocol and port selectors. A lower value means a
1601           higher priority.
1602
1603           Typical values are about the 2000 range. These can be seen on the
1604           XFRM stack using ip xfrm policy when the connection is up. For
1605           "anonymous IPsec" or Opportunistic Encryption based connections, a
1606           much lower priority (65535) is used to ensure administrator
1607           configured IPsec always takes precedence over opportunistic IPsec.
1608
1609       sendca
1610           How much of our available X.509 trust chain to send with the End
1611           certificate, excluding any root CA's. Specifying issuer sends just
1612           the issuing intermediate CA, while
1613            all will send the entire chain of intermediate CA's.none (the
1614           default) will not send any CA certs.
1615
1616       labeled-ipsec
1617           This option is obsolete. To enable labeled IPsec, setting the
1618           policy-label= is enough. See also policy-label= and
1619           secctx-attr-type=
1620
1621       policy-label
1622           The string representation of an access control security label that
1623           is interpreted by the LSM (e.g. SELinux) for use with Labeled
1624           IPsec. See also labeled-ipsec= and secctx-attr-type=. For example,
1625           policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023
1626
1627       failureshunt
1628           what to do with packets when negotiation fails. The default is
1629           none: no shunt; passthrough, drop, and reject have the obvious
1630           meanings.
1631
1632       negotiationshunt
1633           What to do with packets during the IKE negotiation. Valid options
1634           are hold (the default) or passthrough. This should almost always be
1635           left to the default hold value to avoid cleartext packet leaking.
1636           The only reason to set this to passthrough is if plaintext service
1637           availability is more important than service security or privacy, a
1638           scenario that also implies failureshunt=passthrough and most likely
1639           authby=%null using Opportunistic Encryption.
1640

CONFIG SECTIONS

1642       At present, the only config section known to the IPsec software is the
1643       one named setup, which contains information used when the software is
1644       being started (see ipsec_setup(8)). Here's an example:
1645
1646
1647           config setup
1648                logfile=/var/log/pluto.log
1649                plutodebug=all
1650
1651       Parameters are optional unless marked “(required)”.
1652
1653       The currently-accepted parameter names in a config setup section are:
1654
1655       protostack
1656           decide which protocol stack is going to be used. Valid values are
1657           "xfrm" and "bsd". This option should no longer be set, as the stack
1658           is currently auto-detected. The values "klips, "mast", "netkey",
1659           "native", "kame" and "auto" are obsolete. The option is kept only
1660           because it is suspected that Linux and BSD will get userspace
1661           stacks with IPsec support soon (such as dpdk).
1662
1663       listen
1664           IP address to listen on, defaults to ANY. Currently only accepts
1665           one IP address.
1666
1667       ike-socket-bufsize
1668           Set the IKE socket buffer size. Default size is determined by the
1669           OS (as of writing, this seems to be set to 212992. On Linux this is
1670           visible via /proc/sys/net/core/rmem_default and
1671           /proc/sys/net/core/wmem_default. On Linux, this option uses
1672           SO_RCVBUFFORCE and SO_SNDBUFFORCE so that it can override
1673           rmem_max/wmem_max values of the OS. This requires CAP_NET_ADMIN
1674           (which is also required for other tasks). This option can also be
1675           toggled on a running system using ipsec whack --ike-socket-bufsize
1676           bufsize.
1677
1678       ike-socket-errqueue
1679           Whether to enable or disable receiving socket errors via
1680           IP_RECVERR. The default is enabled. This will cause the socket to
1681           receive, process and log socket errors, such as ICMP unreachable
1682           messages or Connection Refused messages. Disabling this only makes
1683           sense on very busy servers, and even then it might not make much of
1684           a difference. This option can also be toggled on a running system
1685           using ipsec whack --ike-socket-errqueue-toggle.
1686
1687       listen-udp
1688           Whether the pluto IKE daemon should listen on the standard UDP
1689           ports of 500 and 4500. The value "yes" means to listen on these
1690           ports, and is the default. This should almost never be disabled. In
1691           the rare case where it is known that only ever TCP or non-standard
1692           UDP ports will be used, this option can disable the standard UDP
1693           ports. Connections can specify their own non-standard port using
1694           leftikeport=.
1695
1696       listen-tcp
1697           Whether the pluto IKE daemon should listen on the (pseudo) standard
1698           TCP port 4500. The value "no" is the current default, but this will
1699           be changed in the future to "yes". The TCP usage complies to RFC
1700           8229 for IKE and ESP over TCP support. Connections can specify
1701           their own non-standard port using leftikeport=.
1702
1703       nflog-all
1704           If set, the NFLOG group number to log all pre-crypt and
1705           post-decrypt traffic to. The default value of 0 means no logging at
1706           all. This option is only available on linux kernel 2.6.14 and
1707           later. It allows common network utilities such as tcpdump,
1708           wireshark and dumpcap, to use nflog:XXX pseudo interfaces where XXX
1709           is the nflog group number. During startup and shutdown of the IPsec
1710           service, iptables commands will be used to add or remove the global
1711           NFLOG table rules. The rules are setup with the nflog-prefix
1712           all-ipsec. See also the per-connection nflog option.
1713
1714       keep-alive
1715           The delay (in seconds) for NAT-T keep-alive packets, if these are
1716           enabled using nat-keepalive This parameter may eventually become
1717           per-connection.
1718
1719       virtual-private
1720           contains the networks that are allowed as (left|right)subnet= for
1721           the remote clients when using the vhost: or vnet: keywords in the
1722           (left|right)subnet= parameters. In other words, the address ranges
1723           that may live behind a NAT router through which a client connects.
1724           This value is usually set to all the RFC-1918 address space,
1725           excluding the space used in the local subnet behind the NAT (An IP
1726           address cannot live at two places at once). IPv4 address ranges are
1727           denoted as %v4:a.b.c.d/mm and IPv6 is denoted as
1728           %v6:aaaa::bbbb:cccc:dddd:eeee/mm. One can exclude subnets by using
1729           the !. For example, if the VPN server is giving access to
1730           192.168.1.0/24, this option should be set to:
1731           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.
1732           This parameter is only needed on the server side and not on the
1733           client side that resides behind the NAT router, as the client will
1734           just use its IP address for the inner IP setting. This parameter
1735           may eventually become per-connection. See also leftsubnet=
1736
1737           Note: It seems that T-Mobile in the US and Rogers/Fido in Canada
1738           have started using 25.0.0.0/8 as their pre-NAT range. This range
1739           technically belongs to the Defence Interoperable Network Services
1740           Authority (DINSA), an agency of the Ministry of Defence of the
1741           United Kingdom. The network range seems to not have been announced
1742           for decades, which is probably why these organisations "borrowed"
1743           this range. To support roadwarriors on these 3G networks, you might
1744           have to add it to the virtual-private= line.
1745
1746       myvendorid
1747           The string to use as our vendor id (VID) when send-vendorid=yes.
1748           The default is OE-Libreswan-VERSION.
1749
1750       nhelpers
1751           how many pluto helpers are started to help with cryptographic
1752           operations. Pluto will start as many helpers as the number of
1753           CPU's, minus 1 to dedicate to the main thread. For machines with
1754           less than 4 CPU's, an equal number of helpers to CPU's are started.
1755           A value of 0 forces pluto to do all operations inline using the
1756           main process. A value of -1 tells pluto to perform the above
1757           calculation. Any other value forces the number to that amount.
1758
1759       seedbits
1760           Pluto uses the NSS crypto library as its random source. Some
1761           government Three Letter Agencies require that pluto reads
1762           additional bits from /dev/random and feed these into the NSS RNG
1763           before drawing random from the NSS library, despite the NSS library
1764           itself already seeding its internal state. This process can block
1765           pluto for an extended time during startup, depending on the entropy
1766           of the system. Therefore, the default is to not perform this
1767           redundant seeding. If specifying a value, it is recommended to
1768           specify at least 460 bits (for FIPS) or 440 bits (for BSI).
1769
1770       ikev1-secctx-attr-type
1771           The value for the IKEv1 IPsec SA security context attribute
1772           identifier that is used for Labeled IPsec. Defaults to the private
1773           use IANA value 32001 from the IPsec SA attributes registry. Old
1774           openswan versions might still be using the (stolen) value 10, which
1775           has since been assigned by IANA for something else. Other values
1776           are not recommended unless IANA assigns an actual value for this
1777           option. Labeled IPsec using IKEv2 does not use this option, it only
1778           uses an IANA allocated Notify number. See also policy-label.
1779
1780       ikev1-policy
1781           What to do with received IKEv1 packets. Valid options are accept
1782           (default), reject which will reply with an error, and drop which
1783           will silently drop any received IKEv1 packet. If this option is set
1784           to drop or reject, an attempt to load an IKEv1 connection will
1785           fail, as these connections would never be able to receive a packet
1786           for processing.
1787
1788       crlcheckinterval
1789           interval expressed in second units, for example crlcheckinterval=8h
1790           for 8 hours, after which pluto will fetch new Certificate
1791           Revocation List (CRL) from crl distribution points. List of used
1792           CRL distribution points are collected from CA certificates and end
1793           certificates. Loaded X.509 CRL's are verified to be valid and
1794           updates are imported to NSS database. If set to 0, which is also
1795           the default value if this option is not specified, CRL updating is
1796           disabled.
1797
1798       crl-strict
1799           if not set, pluto is tolerant about missing or expired X.509
1800           Certificate Revocation Lists (CRL's), and will allow peer
1801           certificates as long as they do not appear on an expired CRL. When
1802           this option is enabled, all connections with an expired or missing
1803           CRL will be denied. Active connections will be terminated at rekey
1804           time. This setup is more secure, but vulnerable to downtime if the
1805           CRL expires. Acceptable values are yes or no (the default). This
1806           option used to be called strictcrlpolicy.
1807
1808       curl-iface
1809           The name of the interface that is used for CURL lookups. This is
1810           needed on rare situations where the interface needs to be forced to
1811           be different from the default interface used based on the routing
1812           table.
1813
1814       curl-timeout
1815           The timeout for the curl library calls used to fetch CRL and OCSP
1816           requests. The default is 5s.
1817
1818       ocsp-enable
1819           Whether to perform Online Certificate Store Protocol ("OCSP")
1820           checks on those certificates that have an OCSP URI defined.
1821           Acceptable values are yes or no (the default).
1822
1823       ocsp-strict
1824           if set to no, pluto is tolerant about failing to obtain an OCSP
1825           responses and a certificate is not rejected when the OCSP request
1826           fails, only when the OCSP request succeeds and lists the
1827           certificate as revoked. If set to yes, any failure on obtaining an
1828           OCSP status for a certificate will be fatal and the certificate
1829           will be rejected. Acceptable values are yes or no (the default).
1830
1831           The strict mode refers to the NSS
1832           ocspMode_FailureIsVerificationFailure mode, while non-strict mode
1833           refers to the NSS ocspMode_FailureIsNotAVerificationFailure mode.
1834
1835       ocsp-method
1836           The HTTP methods used for fetching OCSP data. Valid options are get
1837           (the default) and post. Note that this behaviour depends on the NSS
1838           crypto library that is actually performing the fetching. When set
1839           to the get method, post is attempted only as fallback in case of
1840           failure. When set to post, only the post method is ever used.
1841
1842       ocsp-timeout
1843           The time until an OCSP request is aborted and considered failed.
1844           The default value is 2 seconds.
1845
1846       ocsp-uri
1847           The URI to use for OCSP requests instead of the default OCSP URI
1848           listed in the CA certificate. This requires the ocsp-trustname
1849           option to be set to the nick (friendly name) of the OCSP server
1850           certificate, which needs to be present in the NSS database. These
1851           option combined with the next option sets the OCSP default
1852           responder.
1853
1854       ocsp-trustname
1855           The nickname of the certificate that has been imported into the NSS
1856           database of the server handling the OCSP requests. This requires
1857           the ocsp-uri option to be set as well. This option and the previous
1858           options sets the OCSP default responder.
1859
1860       ocsp-cache-size
1861           The maximum size (in number of certificates) of OCSP responses that
1862           will be kept in the cache. The default is 1000. Setting this value
1863           to 0 means the cache is disabled.
1864
1865       ocsp-cache-min-age
1866           The minimum age (in seconds) before a new fetch will be attempted.
1867           The default is 1 hour.
1868
1869       ocsp-cache-max-age
1870           The maximum age (in seconds) before a new fetch will be attempted.
1871           The default is 1 day.
1872
1873       syslog
1874           the syslog(2) “facility” name and priority to use for
1875           startup/shutdown log messages, default daemon.error.
1876
1877       plutodebug
1878           how much Pluto debugging output should be logged. An empty value,
1879           or the magic value none, means no debug output (the default).
1880           Otherwise only the specified types of output (a quoted list, names
1881           without the --debug- prefix, separated by white space) are enabled;
1882
1883           The current option values are base that represents moderate amounts
1884           of information, cpu-usage for getting timing/load based information
1885           (best used without any other debugging options), crypt for all
1886           crypto related operations and tmi (Too Much Information) for
1887           excessive logging. To log any sensitive private key or password
1888           material, use the special private value.
1889
1890           The old plutodebug options (control, controlmore, x509, kernel,
1891           etc) are mapped to either base or tmi. Note that all maps to base
1892           and not tmi.
1893
1894       uniqueids
1895           Whether IDs should be considered identifying remote parties
1896           uniquely. Acceptable values are yes (the default) and no.
1897           Participant IDs normally are unique, so a new connection instance
1898           using the same remote ID is almost invariably intended to replace
1899           an old existing connection.
1900
1901           When the connection is defined to be a server (using xauthserver=)
1902           and the connection policy is authby=secret, this option is ignored
1903           (as of 3.20) and old connections will never be replaced. This
1904           situation is commonly known as clients using a "Group ID".
1905
1906           This option may disappear in the near future. People using
1907           identical X.509 certificates on multiple devices are urged to
1908           upgrade to use separate certificates per client and device.
1909
1910       logfile
1911           do not use syslog, but rather log to stderr, and direct stderr to
1912           the argument file. This option used to be called plutostderrlog=
1913
1914       logappend
1915           If pluto is instructed to log to a file using logfile=, this option
1916           determines whether the log file should be appended to or
1917           overwritten. Valid options are yes (the default) to append and no
1918           to overwrite. Since on modern systems, pluto is restarted by other
1919           daemons, such as systemd, this option should be left at its default
1920           yes value to preserve the log entries of previous runs of pluto.
1921           The option is mainly of use for running the test suite, which needs
1922           to create new log files from scratch.
1923
1924       logip
1925           If pluto is instructed to log the IP address of incoming
1926           connections. Valid options are yes (the default) and no. Note that
1927           this only affects regular logging. Any enabled debugging via
1928           plutodebug= will still contain IP addresses of peers. This option
1929           is mostly meant for servers that want to avoid logging IP addresses
1930           of incoming clients. Other identifiable information might still be
1931           logged, such as ID payloads and X.509 certificate details. When
1932           using ID of type IP address, this option will not hide the actual
1933           IP address as part of the ID. Most deployments will not want to
1934           change this from the default. If logging of IP addresses is
1935           unwanted, audit-log=no should also be set.
1936
1937       audit-log
1938           Whether pluto should produce Linux Auditing System log messages. If
1939           enabled, pluto will log start, stop and fail for the negotiation of
1940           IKE and IPsec SA's. The kernel will also log success and failures
1941           for actually adding and removing IPsec SA's from the kernel's SADB.
1942           Valid options are yes(the default) and no. On non-Linux systems,
1943           this option is ignored. If enabled but the kernel is lacking audit
1944           support, audit messages are not sent. If the kernel has audit
1945           support and using it fails, pluto will abort. Note that for
1946           compliance reasons, audit log messages contain the relevant IP
1947           addresses, even if logip=no.
1948
1949       logtime
1950           When pluto is directed to log to a file using logfile=, this option
1951           determines whether or not to log the current timestamp as prefix.
1952           Values are yes (the default) or no. The no value can be used to
1953           create logs without ephemeral timestamps, such as those created
1954           when running the test suite. This option used to be called
1955           plutostderrlogtime=
1956
1957       ddos-mode
1958           The startup mode of the DDoS defense mechanism. Acceptable values
1959           are busy, unlimited or auto (the default). This option can also be
1960           given to the IKE daemon while running, for example by issuing ipsec
1961           whack --ddos--busy. When in busy mode, pluto activates anti-DDoS
1962           counter measures. Currently, counter measures consist of requiring
1963           IKEv2 anti-DDoS cookies on new incoming IKE requests, and a more
1964           aggressive cleanup of partially established or AUTH_NULL
1965           connections.
1966
1967       ddos-ike-threshold
1968           The number of half-open IKE SAs before the pluto IKE daemon will be
1969           placed in busy mode. When in busy mode, pluto activates anti-DDoS
1970           counter measures. The default is 25000. See also ddos-mode and
1971           ipsec whack --ddos-XXX.
1972
1973       global-redirect
1974           Whether to send requests for the remote peer to redirect IKE/IPsec
1975           SA's during IKE_SA_INIT. Valid options are no (the default), yes
1976           and auto, where auto means that the requests will be sent if DDoS
1977           mode is active (see ddos-mode). If set, the option
1978           global-redirect-to= must also be set to indicate where to redirect
1979           peers to. For specific connection redirection after IKE SA
1980           authentication, see the send-redirect= and redirect-to= options.
1981           This configuration can be changed at runtime via the ipsec whack
1982           --global-redirect command.
1983
1984       global-redirect-to
1985           Where to send remote peers to via the global-redirect option. This
1986           can be a list, or a single entry, of IP addresses or hostnames
1987           (FQDNs). If there is a list of entries, they must be separated with
1988           comma's. One specified entry means all peers will be redirected to
1989           it, while multiple specified entries means peers will be evenly
1990           distributed across the specified servers. This configuration can be
1991           changed at runtime via the ipsec whack --global-redirect-to
1992           command.
1993
1994       max-halfopen-ike
1995           The number of half-open IKE SAs before the IKE daemon starts
1996           refusing all new IKE attempts. Established IKE peers are not
1997           affected. The default value is 50000.
1998
1999       shuntlifetime
2000           The time until bare shunts (kernel policies not associated with
2001           connections) are deleted from the kernel. The default value is 15m.
2002           When using Opportunistic Encryption to a specific host fails, the
2003           system will either install a %pass or %hold shunt to let the
2004           traffic out clear text or block it. During the the shuntlifetime,
2005           no new Opportunistic Encryption attempt will be started, although
2006           the system will still respond to incoming OE requests from the
2007           remote IP. See also failureshunt and negotiationshunt
2008
2009       xfrmlifetime
2010           The time in seconds until the XFRM acquire state times out. The
2011           default value is 30 seconds. For auto=ondemand connections and
2012           Opportunistic connections an IPsec policy is installed in the
2013           kernel. If an incoming or outgoing packet matches this policy, a
2014           state is created in the kernel and the kernel sends an ACQUIRE
2015           message to the IKE daemon pluto. While this state is in place, no
2016           new acquires will come in for this connection. The default should
2017           be fine for most people. One use case of shortening these is if
2018           opportunistc encryption is used towards cloud instances that can
2019           quickly re-use IP addresses. This value is only used during the
2020           libreswan startup process by the ipsec _stackmanager helper. See
2021           also failureshunt and negotiationshunt
2022
2023       dumpdir
2024           in what directory should things started by setup (notably the Pluto
2025           daemon) be allowed to dump core? The default value is
2026           /var/run/pluto. When SELinux runs in enforced mode, changing this
2027           requires a similar change in the SELinux policy for the pluto
2028           daemon.
2029
2030       statsbin
2031           This option specifies an optional external program to report tunnel
2032           state changes too. The default is not to report tunnel state
2033           changes. This program can be used to notify the user's desktop
2034           (dbus, NetworkManager) or to report tunnel changes to a central
2035           logging server.
2036
2037       ipsecdir
2038           Specifies a directory for administrator-controlled configuration
2039           files and directories. The default value is /etc/ipsec.d. It may
2040           contain the following files and directories:
2041
2042           passwd
2043               (optional) for XAUTH support if not using PAM (this file should
2044               not be world-readable). See README.XAUTH for more information.
2045
2046           nsspassword
2047               (optional) passwords needed to unlock the NSS database in
2048               /var/lib/ipsec/nss (this file should not be world-readable).
2049               See README.nss for more information.
2050
2051           policies/
2052               a directory containing policy group configuration information.
2053               See POLICY GROUP FILES in this document for more information.
2054
2055           cacerts/
2056               DEPRECATED: a directory to store trust anchors (root
2057               certificate authority certificates). The preferred (and
2058               default) approach is to store CA certs in the NSS database
2059               instead. See README.nss for more information.
2060
2061           crls/
2062               DEPRECATED: a directory to store certificate revocation lists.
2063               The preferred (and default) approach is to store CRLs in the
2064               NSS database instead. See README.nss for more information.
2065
2066           When SELinux runs in enforced mode, changing this requires a
2067           similar change in the SELinux policy for the pluto daemon.
2068
2069       nssdir
2070           Specifies a directory for NSS database files. The default value is
2071           /var/lib/ipsec/nss. It may contain the following files:
2072
2073           pkcs11.txt
2074               Detailed info about NSS database creation parameteres.
2075
2076           cert9.db
2077               NSS Certificate database.
2078
2079           key4.db
2080               NSS Key database.
2081
2082           When SELinux runs in enforced mode, changing this requires a
2083           similar change in the SELinux policy for the pluto daemon.
2084
2085       secretsfile
2086           pathname of the file that stores the secret credentials such as
2087           preshared keys (PSKs). See man ipsec.secrets for the syntax. The
2088           default value is /etc/ipsec.secrets.
2089
2090       seccomp
2091           Set the seccomp kernel syscall whitelisting feature. When set to
2092           enabled, if pluto calls a syscall that is not on the compiled-in
2093           whitelist, the kernel will assume an exploit is attempting to use
2094           pluto for malicious access to the system and terminate the pluto
2095           daemon. When set to tolerant, the kernel will only block the rogue
2096           syscall and pluto will attempt to continue. If set to disabled,
2097           pluto is allowed to call any syscall offered by the kernel,
2098           although it might be restricted via other security mechanisms, such
2099           as capabilities, SElinux, AppArmor or other OS security features.
2100
2101           The current default is disabled, but it is expected that in the
2102           future this feature will be enabled on all supported operating
2103           systems. Similarly, it is expected that further privilege
2104           separation will reduce the allowed syscalls - for example for the
2105           crypto helpers or DNS helpers.
2106
2107           Warning: The restrictions of pluto are inherited by the updown
2108           scripts, so these scripts are also not allowed to use syscalls that
2109           are forbidden for pluto.
2110
2111           This feature can be tested using ipsec whack --seccomp-crashtest.
2112           Warning: With seccomp=enabled, pluto will be terminated by the
2113           kernel. With seccomp=tolerant or seccomp=disabled, pluto will
2114           report the results of the seccomp test. SECCOMP will log the
2115           forbidden syscall numbers to the audit log, but only with
2116           seccomp=enabled. The tool scmp_sys_resolver from the libseccomp
2117           development package can be used to translate the syscall number
2118           into a name. See programs/pluto/pluto_seccomp.c for the list of
2119           allowed syscalls.
2120
2121       dnssec-enable
2122           Whether pluto should perform dnssec validation using libunbound,
2123           provided libreswan was compiled with USE_DNSSEC. A value of yes
2124           (the default) means pluto should perform DNSSEC validation. Note
2125           that pluto reads the file /etc/resolv.conf to determine which
2126           nameservers to use.
2127
2128       dnssec-rootkey-file
2129           The location of the DNSSEC root zone public key file. The default
2130           is /var/lib/unbound/root.key but this can be changed at compile
2131           time.
2132
2133       dnssec-anchors
2134           The location of a file containing additional DNSSEC Trust Anchors.
2135           This can be used when a network is using split-DNS and the internal
2136           hierarchy is using DNSSEC trust anchors. There is no default value.
2137

OPPORTUNISTIC CONNS

2139       For Opportunistic connections, the system requires creating special
2140       named conns that are used to implement the default policy groups.
2141       Currently, these names cannot be changed.
2142
2143
2144           conn clear
2145                type=passthrough
2146                authby=never
2147                left=%defaultroute
2148                right=%group
2149                auto=route
2150
2151           conn clear-or-private
2152                type=passthrough
2153                left=%defaultroute
2154                leftid=%myid
2155                right=%opportunisticgroup
2156                failureshunt=passthrough
2157                keyingtries=3
2158                ikelifetime=1h
2159                salifetime=1h
2160                rekey=no
2161                auto=route
2162
2163           conn private-or-clear
2164                type=tunnel
2165                left=%defaultroute
2166                leftid=%myid
2167                right=%opportunisticgroup
2168                failureshunt=passthrough
2169                keyingtries=3
2170                ikelifetime=1h
2171                salifetime=1h
2172                rekey=no
2173                auto=route
2174
2175           conn private
2176                type=tunnel
2177                left=%defaultroute
2178                leftid=%myid
2179                right=%opportunisticgroup
2180                failureshunt=drop
2181                keyingtries=3
2182                ikelifetime=1h
2183                salifetime=1h
2184                rekey=no
2185                auto=route
2186
2187           conn block
2188                type=reject
2189                authby=never
2190                left=%defaultroute
2191                right=%group
2192                auto=route
2193
2194
2195       These conns will only work if %defaultroute works. The leftid will be
2196       the interfaces IP address by default, but it can also be set to
2197       %fromcert or use a DNS name.
2198

POLICY GROUP FILES

2200       The optional files under /etc/ipsec.d/policies, including
2201
2202
2203           /etc/ipsec.d/policies/clear
2204           /etc/ipsec.d/policies/clear-or-private
2205           /etc/ipsec.d/policies/private-or-clear
2206           /etc/ipsec.d/policies/private
2207           /etc/ipsec.d/policies/block
2208
2209
2210       may contain policy group configuration information to supplement
2211       ipsec.conf. Their contents are not security-sensitive.
2212
2213       These files are text files. Each consists of a list of CIDR blocks, one
2214       per line. White space followed by # followed by anything to the end of
2215       the line is a comment and is ignored, as are empty lines.
2216
2217       A connection in ipsec.conf that has right=%group or
2218       right=%opportunisticgroup is a policy group connection. When a policy
2219       group file of the same name is loaded at system start, the connection
2220       is instantiated such that each CIDR block serves as an instance's right
2221       value. The system treats the resulting instances as normal connections.
2222
2223       For example, given a suitable connection definition private, and the
2224       file /etc/ipsec.d/policies/private with an entry 192.0.2.3, the system
2225       creates a connection instance private#192.0.2.3.  This connection
2226       inherits all details from private, except that its right client is
2227       192.0.2.3.
2228

DEFAULT POLICY GROUPS

2230       The standard Libreswan install includes several policy groups which
2231       provide a way of classifying possible peers into IPsec security
2232       classes: private (talk encrypted only), private-or-clear (prefer
2233       encryption), clear-or-private (respond to requests for encryption),
2234       clear and block.
2235

CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE

2237       When choosing a connection to apply to an outbound packet caught with a
2238       %trap, the system prefers the one with the most specific eroute that
2239       includes the packet's source and destination IP addresses. Source
2240       subnets are examined before destination subnets. For initiating, only
2241       routed connections are considered. For responding, unrouted but added
2242       connections are considered.
2243
2244       When choosing a connection to use to respond to a negotiation that
2245       doesn't match an ordinary conn, an opportunistic connection may be
2246       instantiated. Eventually, its instance will be /32 -> /32, but for
2247       earlier stages of the negotiation, there will not be enough information
2248       about the client subnets to complete the instantiation.
2249

FILES

2251           /etc/ipsec.conf
2252           /etc/ipsec.d/policies/clear
2253           /etc/ipsec.d/policies/clear-or-private
2254           /etc/ipsec.d/policies/private-or-clear
2255           /etc/ipsec.d/policies/private
2256           /etc/ipsec.d/policies/block
2257

SEE ALSO

2259       ipsec(8), ipsec_auto(8), ipsec_rsasigkey(8)
2260

HISTORY

2262       Designed for the FreeS/WAN project <https://www.freeswan.org> by Henry
2263       Spencer.
2264

BUGS

2266       Before reporting new bugs, please ensure you are using the latest
2267       version of Libreswan.
2268
2269       When type or failureshunt is set to drop or reject, Libreswan blocks
2270       outbound packets using eroutes, but assumes inbound blocking is handled
2271       by the firewall. Libreswan offers firewall hooks via an “updown”
2272       script. However, the default ipsec _updown provides no help in
2273       controlling a modern firewall.
2274
2275       Including attributes of the keying channel (authentication methods,
2276       ikelifetime, etc.) as an attribute of a connection, rather than of a
2277       participant pair, is dubious and incurs limitations.
2278
2279       The use of %any with the protoport= option is ambiguous. Should the SA
2280       permits any port through or should the SA negotiate any single port
2281       through? The first is a basic conn with a wildcard. The second is a
2282       template. The second is the current behaviour, and it's wrong for quite
2283       a number of uses involving TCP. The keyword %one may be introduced in
2284       the future to separate these two cases.
2285
2286       It would be good to have a line-continuation syntax, especially for the
2287       very long lines involved in RSA signature keys.
2288
2289       The ability to specify different identities, authby, and public keys
2290       for different automatic-keyed connections between the same participants
2291       is misleading; this doesn't work dependably because the identity of the
2292       participants is not known early enough. This is especially awkward for
2293       the “Road Warrior” case, where the remote IP address is specified as
2294       0.0.0.0, and that is considered to be the “participant” for such
2295       connections.
2296
2297       If conns are to be added before DNS is available, left=FQDN,
2298       leftnextop=FQDN, and leftrsasigkey=%dnsonload will fail.
2299       ipsec_pluto(8) does not actually use the public key for our side of a
2300       conn but it isn't generally known at a add-time which side is ours
2301       (Road Warrior and Opportunistic conns are currently exceptions).
2302
2303       The myid option does not affect explicit
2304        ipsec auto --add or ipsec auto --replace commands for implicit conns.
2305

AUTHOR

2307       Paul Wouters
2308           documenter
2309
2310
2311
2312libreswan                         09/05/2023                     IPSEC.CONF(5)
Impressum