1IPSEC.CONF(5) Executable programs IPSEC.CONF(5)
2
3
4
6 ipsec.conf - IPsec configuration and connections
7
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
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, and
321 interfaces=%defaultroute is used in the config setup section, the
322 next-hop gateway address of the default-route interface will be
323 used. The magic value %direct signifies a value to be filled in (by
324 automatic keying) with the peer's address. Relevant only locally,
325 other end need not agree on it.
326
327 leftsourceip
328 the IP address for this host to use when transmitting a packet to
329 the other side of this link. Relevant only locally, the other end
330 need not agree. This option is used to make the gateway itself use
331 its internal IP, which is part of the leftsubnet, to communicate to
332 the rightsubnet or right. Otherwise, it will use its nearest IP
333 address, which is its public IP address. This option is mostly used
334 when defining subnet-subnet connections, so that the gateways can
335 talk to each other and the subnet at the other end, without the
336 need to build additional host-subnet, subnet-host and host-host
337 tunnels. Both IPv4 and IPv6 addresses are supported.
338
339 leftupdown
340 what "updown" script to run to adjust routing and/or firewalling
341 when the status of the connection changes (default ipsec _updown).
342 May include positional parameters separated by white space
343 (although this requires enclosing the whole string in quotes);
344 including shell metacharacters is unwise. An example to enable
345 routing when using the XFRM stack, one can use:
346
347 leftupdown="ipsec _updown --route yes"
348
349 To disable calling an updown script, set it to the empty string, eg
350 leftupdown="" or leftupdown="%disabled".
351
352 See ipsec_pluto(8) for details. Relevant only locally, other end
353 need not agree on it.
354
355 leftcat
356 Whether to perform Client Address Translation ("CAT") when using
357 Opportunistic IPsec behind NAT. Accepted values are no (the
358 default) and yes. This option should only be enabled on the special
359 Opportunistic IPsec connections, usually called "private" and
360 "private-or-clear". When set, this option causes the given
361 addresspool IP from the remote peer to be NATed with iptables. It
362 will also install an additional IPsec SA policy to cover the
363 pre-NAT IP. See the Opportunistic IPsec information on the
364 libreswan website for more information and examples.
365
366 leftfirewall
367 This option is obsolete and should not used anymore.
368
369 If one or both security gateways are doing forwarding firewalling
370 (possibly including masquerading), and this is specified using the
371 firewall parameters, tunnels established with IPsec are exempted from
372 it so that packets can flow unchanged through the tunnels. (This means
373 that all subnets connected in this manner must have distinct,
374 non-overlapping subnet address blocks.) This is done by the default
375 updown script (see ipsec_pluto(8)).
376
377 The implementation of this makes certain assumptions about firewall
378 setup, and the availability of the Linux Advanced Routing tools. In
379 situations calling for more control, it may be preferable for the user
380 to supply his own updown script, which makes the appropriate
381 adjustments for his system.
382
383 CONN PARAMETERS: AUTOMATIC KEYING
384 The following parameters are relevant to automatic keying via IKE.
385 Unless otherwise noted, for a connection to work, in general it is
386 necessary for the two ends to agree exactly on the values of these
387 parameters.
388
389 auto
390 what operation, if any, should be done automatically at IPsec
391 startup; currently-accepted values are add (signifying an ipsec
392 auto --add), ondemand (signifying that plus an ipsec auto
393 --ondemand), start (signifying that plus an ipsec auto --up), and
394 ignore (also the default) (signifying no automatic startup
395 operation), and keep (signifying an add plus an attempt to keep the
396 connection up once the remote peer brought it up). See the config
397 setup discussion below. Relevant only locally, other end need not
398 agree on it (but in general, for an intended-to-be-permanent
399 connection, both ends should use auto=start to ensure that any
400 reboot causes immediate renegotiation).
401
402 The option ondemand used to be called route
403
404 authby
405 how the two security gateways should authenticate each other; the
406 default value is rsasig,ecdsa which allows ECDSA with SHA-2 and RSA
407 with SHA2 or SHA1. To limit this further, there are the options of
408 ecdsa for ECDSA digital signatures using SHA-2, rsa-sha2 for
409 RSASSA-PSS digital signatures based authentication with SHA2-256,
410 rsa-sha2_384 for RSASSA-PSS digital signatures based authentication
411 with SHA2-384, rsa-sha2_512 for RSASSA-PSS digital signatures based
412 authentication with SHA2-512, rsa-sha1 for RSA-PKCSv1.5 digital
413 signatures based authentication with SHA1, secret for shared
414 secrets (PSK) authentication, secret|rsasig for either, never if
415 negotiation is never to be attempted or accepted (useful for
416 shunt-only conns), and null for null-authentication.
417
418 If asymmetric authentication is requested, IKEv2 must be enabled,
419 and the options leftauth= and rightauth= should be used instead of
420 authby.
421
422 For IKEv1, SHA2 based signatures are not defined and ECDSA is not
423 implemented, so the default authby= value is rsa-sha1. Using
424 authby=rsasig results in only rsa-sha1 as well. For IKEv2, using
425 authby=rsasig means using rsa-sha2_512, rsa-sha2_384, rsa-sha2_256
426 and rsa-sha1, where rsa-sha1 will used only if RFC 7427 is not
427 supported by the peer.
428
429 As per RFC 8221, authby=rsa-sha1 is only supported in the old
430 style, meaning RSA-PKCSv1.5. The SHA2 variants are only supported
431 for the new style of RFC 7427, so authby=rsa-sha2 will use the new
432 style. The default authby= will remove rsa-sha1 in the near future.
433 It is strongly recommended that if certificates are used, the
434 certificates and the authby= signature methods used are the same,
435 as it increases interoperability and keeps the authentication of
436 everything within one digital signature system.
437
438 Digital signatures are superior in every way to shared secrets.
439 Especially IKEv1 in Aggressive Mode is vulnerable to offline
440 dictionary attacks and is performed routinely by at least the NSA
441 on monitored internet traffic globally. The never option is only
442 used for connections that do not actually start an IKE negotiation,
443 such as type=passthrough connections. The auth method null is used
444 for "anonymous opportunistic IPsec" and should not be used for
445 regular pre-configured IPsec VPNs.
446
447 ike
448 IKE encryption/authentication algorithm to be used for the
449 connection (phase 1 aka ISAKMP SA or IKE SA). If this option is not
450 set, the builtin defaults will be used. This is the preferred
451 method, and allows for gradual automatic updates using the same
452 configuration. Some distributions, such as Fedora and RHEL/CentOS,
453 use a System Wide Crypto Policy that sets the default ike= (and
454 esp=) lines. Specifying your own ike= line means overriding all
455 these system or software recommended defaults, but can be necessary
456 at times. Note that libreswan does not support using a PRF
457 algorithm that is different from the INTEGRITY (hash) algorithm by
458 design.
459
460 The format is "cipher-hash;modpgroup, cipher-hash;modpgroup, ..."
461 Any omitited option will be filled in with all allowed default
462 values. Multiple proposals are separated by a comma. If an ike=
463 line is specified, no other received proposals will be accepted
464 than those specified on the IKE line. Some examples are
465 ike=3des-sha1,aes-sha1, ike=aes, ike=aes_ctr, ike=aes_gcm256-sha2,
466 ike=aes128-md5;modp2048, ike=aes256-sha2;dh19,
467 ike=aes128-sha1;dh22, ike=3des-md5;modp1024,aes-sha1;modp1536.
468
469 IKEv2 allows combining elements into a single proposal. These can
470 be specified by using the + symbol. An example is:
471 ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14.
472 Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305) and
473 non-AEAD algorithms (aes, 3des) cannot be combined into a single
474 proposal. To support aes and aes_gcm, two proposals separated by a
475 comma must be used.
476
477 The default IKE proposal depends on the version of libreswan used.
478 It follow the recommendations of RFC4306, RFC7321 and as of this
479 writing their successor draft documents RFC4306bis and RFC7321bis.
480 As for libreswan 3.32, SHA1 and MODP1536(dh5) are still allowed per
481 default for backwards compatibility, but 3DES and MODP1024(dh2) are
482 not allowed per default. As of libreswan 4.x, modp1024(dh2) support
483 is no longer compiled in at all. For IKEv2, the defaults include
484 AES, AES-GCM, DH14 and stronger, and SHA2. The default key size is
485 256 bits. The default AES_GCM ICV is 16 bytes.
486
487 Note that AES-GCM is an AEAD algorithm, meaning that it performs
488 encryption+authentication in one step. This means that AES-GCM must
489 not specify an authentication algorithm. However, for IKE it does
490 require a PRF function, so the second argument to an AEAD algorithm
491 denotes the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with
492 SHA2 as the prf. Note that for phase2alg, there is no prf, so
493 AES-GCM is specified for ESP as esp=aes_gcm-null. The AES-GCM and
494 AES-CCM algorithms support 8,12 and 16 byte ICV's. These can be
495 specified using a postfix, for example aes_gcm_a (for 8), aes_gcm_b
496 (for 12) and aes_gcm_c (for 16). The default (aes_gcm without
497 postfix) refers to the 16 byte ICV version. It is strongly
498 recommended to NOT use the 8 or 12 byte versions of GCM or CCM.
499 These versions are NOT included in the default and will be removed
500 in a future version, following the recommendation of RFC 8247 or it
501 successor.
502
503 Weak algorithms are regularly removed from libreswan. Currently,
504 1DES and modp768(DH1) have been removed and modp1024(DH2) has been
505 disabled at compile time. Additionally, MD5 and SHA1 will be
506 removed within the next few years. Null encryption is available,
507 and should only be used for testing or benchmarking purposes.
508 Please do not request for insecure algorithms to be re-added to
509 libreswan. IKEv1 has been disabled per default, and will soon no
510 longer be compiled in by default.
511
512 For all Diffie-Hellman groups, the "dh" keyword can be used instead
513 of the "modp" keyword. For example ike=3des-sha1;dh19.
514 Diffie-Hellman groups 19,20 and 21 from RFC-5903 are supported.
515 Curve25519 from RFC-8031 is supported as "dh31". Curve448 and GOST
516 DH groups are not yet supported in libreswan because these are not
517 supported yet in the NSS crypto library.
518
519 Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are implemented
520 but not compiled in by default. These DH groups are extremely
521 controversial and MUST NOT be used unless forced (administratively)
522 by the other party. This is further documented in RFC 8247, but the
523 summary is that it cannot be proven that these DH groups do not
524 contain a cryptographic trapdoor (a backdoor by the USG who
525 provided these primes without revealing the seeds and generation
526 process used).
527
528 The modp syntax will be removed in favour of the dh syntax in the
529 future
530
531 phase2
532 Sets the type of SA that will be produced. Valid options are: esp
533 for encryption (the default), ah for authentication only.
534
535 The very first IPsec designs called for use of AH plus ESP to offer
536 authentication, integrity and confidentiality. That dual protocol
537 use was a significant burden, so ESP was extended to offer all
538 three services, and AH remained as an auth/integ. The old mode of
539 ah+esp is no longer supported in compliance with RFC 8221 Section
540 4. Additionally, AH does not play well with NATs, so it is strongly
541 recommended to use ESP with the null cipher if you require
542 unencrypted authenticated transport.
543
544 phase2alg
545 This option is alias to esp.
546
547 sha2-truncbug
548 The default ESP hash truncation for sha2_256 is 128 bits. Some
549 IPsec implementations (Linux before 2.6.33, some Cisco (2811?)
550 routers) implement the draft version which stated 96 bits. If a
551 draft implementation communicates with an RFC implementation, both
552 ends will reject encrypted packets from each other.
553
554 This option enables using the draft 96 bits version to interop with
555 those implementations. Currently the accepted values are no, (the
556 default) signifying default RFC truncation of 128 bits, or yes,
557 signifying the draft 96 bits truncation.
558
559 Another workaround is to switch from sha2_256 to sha2_128 or
560 sha2_512.
561
562 ms-dh-downgrade
563 Whether to allow a downgrade of DiffieHellman group during rekey
564 (using CREATE_CHILD_SA). Microsoft Windows (at the time of writing,
565 Feb 2018) defaults to using the very weak modp1024 (DH2). This can
566 be changed using a Windows registry setting to use modp2048 (DH14).
567 However, at rekey times, it will shamelessly use modp1024 again and
568 the connection might fail. Setting this option to yes (and adding
569 modp1024 proposals to the ike line) this will allow this downgrade
570 attack to happen. This should only be used to support Windows that
571 feature this bug. Currently the accepted values are no, (the
572 default) or yes.
573
574 dns-match-id
575 Whether to perform an additional DNS lookup and confirm the remote
576 ID payload with the DNS name in the reverse DNS PTR record.
577 Accepted values are no (the default) or yes. This check should be
578 enabled when Opportunistic IPsec is enabled in a mode that is based
579 on packet triggers (on-demand) using IPSECKEY records in DNS. Since
580 in that case the IKE daemon pluto does not know the remote ID, it
581 only knows the remote IP address, this option forces it to confirm
582 the peer's proposed ID (and thus its public/private key) with its
583 actual IP address as listed in the DNS. This prevents attacks where
584 mail.example.com's IP address is taken over by a neighbour machine
585 with a valid web.example.com setup. This check is not needed for
586 certificate based Opportunistic IPsec, as "mail.example.com"s
587 certificate does not have an entry for "web.example.com". It is
588 also not needed for DNS server triggered Opportunistic IPsec, as in
589 that case the IKE daemon pluto is informed of both the IP address,
590 and the hostname/public key.
591
592 require-id-on-certificate
593 When using certificates, check whether the IKE peer ID is present
594 as a subjectAltName (SAN) on the peer certificate. Accepted values
595 are yes (the default) or no. This check should only be disabled
596 when intentionally using certificates that do not have their peer
597 ID specified as a SAN on the certificate. These certificates
598 violate RFC 4945 Section 3.1 and are normally rejected to prevent a
599 compromised host from assuming the IKE identity of another host.
600 The SAN limits the IDs that the peer is able to assume.
601
602 ppk
603 EXPERIMENTAL: Post-quantum preshared keys (PPKs) to be used.
604 Currently the accepted values are propose or yes (the default),
605 signifying we propose to use PPK for this connection; insist,
606 signifying we allow communication only if PPK is used for key
607 derivation; never or no, signifying that PPK should not be used for
608 key derivation. PPKs can be used in connections that allow only
609 IKEv2. In libreswan that would mean that ikev2 option must have
610 value insist. (currently based on draft-fluhrer-qr-ikev2, not
611 raft-ietf-ipsecme-qr-ikev2-00)
612
613 nat-ikev1-method
614 NAT Traversal in IKEv1 is negotiated via Vendor ID options as
615 specified in RFC 3947. However, many implementations only support
616 the draft version of the RFC. Libreswan sends both the RFC and the
617 most common draft versions (02, 02_n and 03) to maximize
618 interoperability. Unfortunately, there are known broken
619 implementations of RFC 3947, notably Cisco routers that have not
620 been updated to the latest firmware. As the NAT-T payload is sent
621 in the very first packet of the initiator, there is no method to
622 auto-detect this problem and initiate a workaround.
623
624 This option allows fine tuning which of the NAT-T payloads to
625 consider for sending and processing. Currently the accepted values
626 are drafts, rfc, both (the default) and none. To interoperate with
627 known broken devices, use nat-ikev1-method=drafts. To prevent the
628 other end from triggering IKEv1 NAT-T encapsulation, set this to
629 none. This will omit the NAT-T payloads used to determine NAT,
630 forcing the other end not to use encapsulation.
631
632 esp
633 Specifies the algorithms that will be offered/accepted when
634 negotiating a a Child SA. The general syntax is:
635
636 ESP = PROPOSAL[,PROPOSAL...]
637 PROPOSAL = ENCRYPT_ALGS[-INTEG_ALGS[-DH_ALGS]]
638 ENCRYPT_ALGS = ENCRYPT_ALG[+ENCRYPT_ALG...]
639 INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]
640 DH_ALGS = DH_ALG[+DH_ALG...]
641
642
643 During startup, ipsec_pluto(8) will log all supported ESP
644 algorithms.
645
646 Specifying the DH algorithms explicitly is not recommended. When
647 PFS is enabled, and the DH algorithms are omitted, each PROPOSAL
648 will automatically include the DH algorithm negotiated during the
649 IKE exchange.
650
651 AEAD algorithms such as AES_GCM and AES_CCM no not require a
652 separate integrity algorithm. For example esp=aes_gcm256 or
653 esp=aes_ccm.
654
655 For instance:
656
657 esp=aes_gcm,aes128+aes256-sha2_512+sha2_256-dh14+dh19
658 esp=aes128-sha2_512-dh14+dh19
659
660
661 If not specified, a secure set of defaults will be used. The
662 program:
663
664 ipsec algparse esp=...
665
666
667 can be used to query these defaults.
668
669 ah
670 A comma separated list of AH algorithms that will be
671 offered/accepted when negotiating the Child SA. The general syntax
672 is:
673
674 AH = PROPOSAL[,PROPOSAL...]
675 PROPOSAL = INTEG_ALGS[-DH_ALGS]
676 INTEG_ALGS = INTEG_ALG[+INTEG_ALG...]
677 DH_ALGS = DH_ALG[+DH_ALG...]
678
679
680 During startup, ipsec_pluto(8) will log all supported AH
681 algorithms.
682
683 Specifying the DH algorithms explicitly is not recommended. When
684 PFS is enabled, and the DH algorithms are omitted, each PROPOSAL
685 will automatically include the DH algorithm negotiated during the
686 IKE exchange.
687
688 The default is not to use AH. If for some (invalid) reason you
689 still think you need AH, please use esp with the null encryption
690 cipher instead.
691
692 For instance:
693
694 ah=sha2_256+sha2_512
695 ah=sha2_256+sha2_512-dh14+dh19
696
697
698 If not specified, a secure set of defaults will be used. The
699 program:
700
701 ipsec algparse ah=...
702
703
704 can be used to query these defaults.
705
706 fragmentation
707 Whether or not to allow IKE fragmentation. Valid values are yes,
708 (the default), no or force.
709
710 IKEv1 fragmentation capabilities are negotiated via a well-known
711 private vendor id. IKEv2 fragmentation support is implemented using
712 RFC 7383. If pluto does not receive the fragmentation payload, no
713 IKE fragments will be sent, regardless of the fragmentation=
714 setting. When set to yes, IKE fragmentation will be attempted on
715 the first re-transmit of an IKE packet of a size larger then 576
716 bytes for IPv4 and 1280 bytes for IPv6. If fragmentation is set to
717 force, IKE fragmentation is used on initial transmits of such sized
718 packets as well. When we have received IKE fragments for a
719 connection, pluto behaves as if in force mode.
720
721 ikepad
722 Whether or not to pad IKEv1 messages to a multiple of 4 bytes.
723 Valid values are yes, (the default) and no.
724
725 IKE padding is allowed in IKEv1 but has been known to cause
726 interoperability issues. The ikepad= option can be used to disable
727 IKEv1 padding. This used to be required for some devices (such as
728 Checkpoint in Aggressive Mode) that reject padded IKEv1 packets. A
729 bug was fixed in libreswan 3.25 that applied wrong IKE padding in
730 XAUTH, so it is suspected that Checkpoint padding issue bas been
731 resolved. And this option should not be needed by anyone. In IKEv2,
732 no padding is allowed, and this option has no effect. If you find a
733 device that seems to require IKE padding, please contact the
734 libreswan developers. This option should almost never be enabled
735 and might be removed in a future version.
736
737 ikev2
738 Whether to use IKEv2 (RFC 7296) or IKEv1 (RFC 4301). Currently the
739 accepted values are yes (the default), signifying only IKEv2 is
740 accepted, or no, signifying only IKEv1 is accepted. Previous
741 versions allowed the keywords propose or permit that would allow
742 either IKEv1 or IKEv2, but this is no longer supported. The permit
743 option is interpreted as no and the propose option is interpreted
744 as yes. Older versions also supported keyword insist which is now
745 interpreted as yes.
746
747 mobike
748 Whether to allow MOBIKE (RFC 4555) to enable a connection to
749 migrate its endpoint without needing to restart the connection from
750 scratch. This is used on mobile devices that switch between wired,
751 wireless or mobile data connections. Current values are no (the
752 default) or yes, Only connection acting as modecfgclient will allow
753 the initiator to migrate using mobike. Only connections acting as
754 modecfgserver will allow clients to migrate.
755
756 VTI and MOBIKE might not work well when used together.
757
758 esn
759 Whether or not to enable Extended Sequence Number (ESN) for the
760 IPsec SA. This option is only implemented for IKEv2. ESN is
761 typically used for very high-speed links (10Gbps or faster) where
762 the standard 32 bit sequence number is exhausted too quickly,
763 causing IPsec SA's rekeys to happen too often. Accepted values are
764 either (the default), yes and no. If either is specified as an
765 initiator, the responder will make the choice. As a responder, if
766 either is received, yes is picked.
767
768 If replay-window is set to 0, ESN is disabled as some (most?) IPsec
769 stacks won't support ESN in such a configuration.
770
771 decap-dscp
772 Enable decapsulating the Differentiated Services Code Point (DSCP,
773 formerly known as Terms Of Service (TOS)) bits. If these bits are
774 set on the inner (encrypted) IP packets, these bits are set on the
775 decrypted IP packets. Acceptable values are no (the default) or
776 yes. Currently this feature is only implemented for the Linux XFRM
777 stack.
778
779 nopmtudisc
780 Disable Path MTU discovery for the IPsec SA. Acceptable values are
781 no (the default) or yes. Currently this feature is only implemented
782 for the Linux XFRM stack.
783
784 narrowing
785 IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options.
786 Currently the accepted values are no, (the default) signifying no
787 narrowing will be proposed or accepted, or yes, signifying IKEv2
788 negotiation may allow establishing an IPsec connection with
789 narrowed down traffic selectors. This option is ignored for IKEv1.
790
791 There are security implications in allowing narrowing down the
792 proposal. For one, what should be done with packets that we hoped
793 to tunnel, but cannot. Should these be dropped or send in the
794 clear? Second, this could cause thousands of narrowed down Child
795 SAs to be created if the conn has a broad policy (eg 0/0 to 0/0).
796 One possible good use case scenario is that a remote end (that you
797 fully trust) allows you to define a 0/0 to them, while adjusting
798 what traffic you route via them, and what traffic remains outside
799 the tunnel. However, it is always preferred to setup the exact
800 tunnel policy you want, as this will be much clearer to the user.
801
802 sareftrack
803 Set the method of tracking reply packets with SArefs when using an
804 SAref compatible stack. Currently only the mast stack supports
805 this. Acceptable values are yes (the default), no or conntrack.
806 This option is ignored when SArefs are not supported. This option
807 is passed as PLUTO_SAREF_TRACKING to the updown script which makes
808 the actual decisions whether to perform any iptables/ip_conntrack
809 manipulation. A value of yes means that an IPSEC mangle table will
810 be created. This table will be used to match reply packets. A value
811 of conntrack means that additionally, subsequent packets using this
812 connection will be marked as well, reducing the lookups needed to
813 find the proper SAref by using the ip_conntrack state. A value of
814 no means no IPSEC mangle table is created, and SAref tracking is
815 left to a third-party (kernel) module. In case of a third party
816 module, the SArefs can be relayed using the statsbin= notification
817 helper.
818
819 nic-offload
820 Set the method of Network Interface Controller (NIC) hardware
821 offload for ESP/AH packet processing. Acceptable values are auto
822 (the default), yes or no. This option is separate from any CPU
823 hardware offload available and is currently only available on Linux
824 4.13+ using the XFRM IPsec stack, when compiled with the options
825 CONFIG_XFRM_OFFLOAD, CONFIG_INET_ESP_OFFLOAD and
826 CONFIG_INET6_ESP_OFFLOAD. The auto option will attempt to
827 auto-detect the presence of kernel and hardware support, and then
828 automatically mark the IPsec SA for hardware offloading. One vendor
829 supporting this offload method is Mellanox.
830
831 leftid
832 how the left participant should be identified for authentication;
833 defaults to left. Can be an IP address or a fully-qualified domain
834 name which will be resolved. If preceded by @, the value is used as
835 a literal string and will not be resolved. To support opaque
836 identifiers (usually of type ID_KEY_ID, such as used by Cisco to
837 specify Group Name, use square brackets, eg rightid=@[GroupName].
838 The magic value %fromcert causes the ID to be set to a DN taken
839 from a certificate that is loaded. Prior to 2.5.16, this was the
840 default if a certificate was specified. The magic value %none sets
841 the ID to no ID. This is included for completeness, as the ID may
842 have been set in the default conn, and one wishes for it to default
843 instead of being explicitly set. The magic value %myid stands for
844 the current setting of myid. This is set in config setup or by
845 ipsec_whack(8)), or, if not set, it is the IP address in
846 %defaultroute (if that is supported by a TXT record in its reverse
847 domain), or otherwise it is the system's hostname (if that is
848 supported by a TXT record in its forward domain), or otherwise it
849 is undefined.
850
851 When using certificate based ID's, one need to specify the full
852 RDN, optionally using wildcard matching (eg CN='*'). If the RDN
853 contains a comma, this can be masked using a comma (eg OU='Foo,,
854 Bar and associates')
855
856 leftrsasigkey
857 the left participant's public key for RSA signature authentication,
858 in RFC 2537 format using ipsec_ttodata(3) encoding. The magic value
859 %none means the same as not specifying a value (useful to override
860 a default). The value %dnsondemand (the default) means the key is
861 to be fetched from DNS at the time it is needed. The value
862 %dnsonload means the key is to be fetched from DNS at the time the
863 connection description is read from ipsec.conf; currently this will
864 be treated as %none if right=%any or right=%opportunistic. The
865 value %dns is currently treated as %dnsonload but will change to
866 %dnsondemand in the future. The identity used for the left
867 participant must be a specific host, not %any or another magic
868 value. The value %cert will load the information required from a
869 certificate defined in %leftcert and automatically define leftid
870 for you. Caution: if two connection descriptions specify different
871 public keys for the same leftid, confusion and madness will ensue.
872
873 leftcert
874 If you are using leftrsasigkey=%cert this defines the certificate
875 nickname of your certificate in the NSS database. This can be on
876 software or hardware security device.
877
878 leftckaid
879 The hex CKAID of the X.509 certificate. Certificates are stored in
880 the NSS database.
881
882 leftauth
883 How the security gateways will authenticate to the other side in
884 the case of asymmetric authentication; acceptable values are rsasig
885 or rsa for RSA Authentication with SHA-1, rsa-sha2 for RSA-PSS
886 digital signatures based authentication with SHA2-256, rsa-sha2_384
887 for RSA-PSS digital signatures based authentication with SHA2-384,
888 rsa-sha2_512 for RSA-PSS digital signatures based authentication
889 with SHA2-512, ecdsa for ECDSA digital signatures based
890 authentication, secret for shared secrets (PSK) authentication and
891 null for null-authentication. There is no default value - if unset,
892 the symmetrical authby= keyword is used to determine the
893 authentication policy of the connection.
894
895 Asymmetric authentication is only supported with IKEv2. If
896 symmetric authentication is required, use authby= instead of
897 leftauth and rightauth. If leftauth is set, rightauth must also be
898 set and authby= must not be set. Asymmetric authentication cannot
899 use secret (psk) on one side and null on the other side - use psk
900 on both ends instead.
901
902 When using EAPONLY authentication, which omits the regular IKEv2
903 AUTH payload, leftauth= (or rightauth=) should be set to eaponly.
904
905 Be aware that the symmetric keyword is authby= but the asymmetric
906 keyword is leftauth and rightauth (without the "by").
907
908 leftautheap
909 Whether the security gateways will authenticate uing an EAP method.
910 Acceptable values are none (the default) and tls for EAPTLS. If EAP
911 is the only authentication method, set leftauth=none in addition to
912 leftautheap=tls=.
913
914 The EAP authentication mechanisms are only available for IKEv2
915 based connections.
916
917 leftca
918 specifies the authorized Certificate Authority (CA) that signed the
919 certificate of the peer. If undefined, it defaults to the CA that
920 signed the certificate specified in leftcert. The special
921 rightca=%same is implied when not specifying a rightca and means
922 that only peers with certificates signed by the same CA as the
923 leftca will be allowed. This option is only useful in complex multi
924 CA certificate situations. When using a single CA, it can be safely
925 omitted for both left and right.
926
927 leftikeport
928 The UDP IKE port to listen on or send data to. This port cannot be
929 0 or 500. For TCP, see tcp-remoteport=
930
931 leftsendcert
932 This option configures when Libreswan will send X.509 certificates
933 to the remote host. Acceptable values are yes|always (signifying
934 that we should always send a certificate), sendifasked (signifying
935 that we should send a certificate if the remote end asks for it),
936 and no|never (signifying that we will never send a X.509
937 certificate). The default for this option is sendifasked which may
938 break compatibility with other vendor's IPsec implementations, such
939 as Cisco and SafeNet. If you find that you are getting errors about
940 no ID/Key found, you likely need to set this to always. This
941 per-conn option replaces the obsolete global nocrsend option.
942
943 leftxauthserver
944 Left is an XAUTH server. This can use PAM for authentication or md5
945 passwords in /etc/ipsec.d/passwd. These are additional credentials
946 to verify the user identity, and should not be confused with the
947 XAUTH group secret, which is just a regular PSK defined in
948 ipsec.secrets. The other side of the connection should be
949 configured as rightxauthclient. XAUTH connections cannot rekey, so
950 rekey=no should be specified in this conn. For further details on
951 how to compile and use XAUTH, see README.XAUTH. Acceptable values
952 are yes or no (the default).
953
954 leftxauthclient
955 Left is an XAUTH client. The xauth connection will have to be
956 started interactively and cannot be configured using auto=start.
957 Instead, it has to be started from the commandline using ipsec auto
958 --up connname. You will then be prompted for the username and
959 password. To setup an XAUTH connection non-interactively, which
960 defeats the whole purpose of XAUTH, but is regularly requested by
961 users, it is possible to use a whack command - ipsec whack --name
962 baduser --ipsecgroup-xauth --xauthname badusername --xauthpass
963 password --initiate The other side of the connection should be
964 configured as rightxauthserver. Acceptable values are yes or no
965 (the default).
966
967 leftusername
968 The username associated with this connection. The username can be
969 the IKEv2 XAUTH username, a GSSAPI username or IKEv2 CP username.
970 For the XAUTH username, the XAUTH password can be configured in the
971 ipsec.secrets file. This option was previously called
972 leftxauthusername.
973
974 leftmodecfgserver
975 Left is a Mode Config server. It can push network configuration to
976 the client. Acceptable values are yes or no (the default).
977
978 leftmodecfgclient
979 Left is a Mode Config client. It can receive network configuration
980 from the server. Acceptable values are yes or no (the default).
981
982 xauthby
983 When IKEv1 XAUTH support is available, set the method used by XAUTH
984 to authenticate the user with IKEv1. The currently supported values
985 are file (the default), pam or alwaysok. The password file is
986 located at /etc/ipsec.d/passwd, and follows a syntax similar to the
987 Apache htpasswd file, except an additional connection name argument
988 (and optional static IP address) are also present:
989
990 username:password:conname:ipaddress
991
992 For supported password hashing methods, see crypt(3). If pluto is
993 running in FIPS mode, some hash methods, such as MD5, might not be
994 available. Threads are used to launch an xauth authentication
995 helper for file as well as PAM methods.
996
997 The alwaysok should only be used if the XAUTH user authentication
998 is not really used, but is required for interoperability, as it
999 defeats the whole point of XAUTH which is to rely on a secret only
1000 known by a human. See also pam-authorize=yes
1001
1002 xauthfail
1003 When XAUTH support is available, set the failure method desired
1004 when authentication has failed. The currently supported values are
1005 hard (the default) and soft. A soft failure means the IPsec SA is
1006 allowed to be established, as if authentication had passed
1007 successfully, but the XAUTH_FAILED environment variable will be set
1008 to 1 for the updown script, which can then be used to redirect the
1009 user into a walled garden, for example a payment portal.
1010
1011 pam-authorize
1012 IKEv1 supports PAM authorization via XAUTH using xauthby=pam. IKEv2
1013 does not support receiving a plaintext username and password.
1014 Libreswan does not yet support EAP authentication methods for IKE.
1015 The pam-authorize=yes option performs an authorization call via
1016 PAM, but only includes the remote ID (not username or password).
1017 This allows for backends to disallow an ID based on non-password
1018 situations, such as "user disabled" or "user over quota". See also
1019 xauthby=pam
1020
1021 modecfgpull
1022 Pull the Mode Config network information from the server.
1023 Acceptable values are yes or no (the default).
1024
1025 modecfgdns, modecfgdomains, modecfgbanner
1026 When configured as IKEv1 ModeCFG or IKEv2 server, specifying any of
1027 these options will cause those options and values to be sent to the
1028 connecting client. Libreswan as a client will use these received
1029 options to either update /etc/resolv.conf or the running unbound
1030 DNS server. When the connection is brought down, the previous DNS
1031 resolving state is restored.
1032
1033 The modecfgdns option takes a comma or space separated list of IP
1034 addresses that can be used for DNS resolution. The modecfgdomains
1035 option takes a comma or space separated list of internal domain
1036 names that are reachable via the supplied modecfgdns DNS servers.
1037
1038 The IKEv1 split tunnel directive will be sent automatically if the
1039 xauth server side has configured a network other than 0.0.0.0/0.
1040 For IKEv2, this is automated via narrowing.
1041
1042 remote-peer-type
1043 Set the remote peer type. This can enable additional processing
1044 during the IKE negotiation. Acceptable values are cisco or ietf
1045 (the default). When set to cisco, support for Cisco IPsec gateway
1046 redirection and Cisco obtained DNS and domainname are enabled. This
1047 includes automatically updating (and restoring) /etc/resolv.conf.
1048 These options require that XAUTH is also enabled on this
1049 connection.
1050
1051 nm-configured
1052 Mark this connection as controlled by Network Manager. Acceptable
1053 values are yes or no (the default). Currently, setting this to yes
1054 will cause libreswan to skip reconfiguring resolv.conf when used
1055 with XAUTH and ModeConfig.
1056
1057 encapsulation
1058 In some cases, for example when ESP packets are filtered or when a
1059 broken IPsec peer does not properly recognise NAT, it can be useful
1060 to force RFC-3948 encapsulation. In other cases, where IKE is
1061 NAT'ed but ESP packets can or should flow without encapsulation, it
1062 can be useful to ignore the NAT-Traversal auto-detection.
1063 encapsulation=yes forces the NAT detection code to lie and tell the
1064 remote peer that RFC-3948 encapsulation (ESP in port 4500 packets)
1065 is required. encapsulation=no ignores the NAT detection causing
1066 ESP packets to send send without encapsulation. The default value
1067 of encapsulation=auto follows the regular outcome of the NAT
1068 auto-detection code performed in IKE. This option replaced the
1069 obsoleted forceencaps option.
1070
1071 enable-tcp
1072 Normally, IKE negotiation and ESP encapsulation happens over UDP.
1073 This option enables support for IKE and ESP over TCP as per RFC
1074 8229. Acceptable values are no(the default), yes meaning only TCP
1075 will be used, or fallback meaning that TCP will be attempted only
1076 after negotiation over UDP failed. Since performance over TCP is
1077 much less, and TCP sessions are vulnerable to simply RST resets and
1078 MITM attacks causing the TCP connection to close, this option
1079 should really only be used in fallback mode. If used in fallback
1080 mode, it is recommend to reduce the retransmit-timeout from the
1081 default 60s to a much shorter value such as 10s, so that one does
1082 not have to wait a minute for the TCP fallback to be attempted.
1083
1084 tcp-remoteport
1085 Which remote TCP port to use when IKE over TCP is attempted. The
1086 default value is to use the NAT-T IKE port (4500). This value is
1087 not negotiated and should be configured properly on all endpoints.
1088 When opening a TCP socket to the remote host in this port, a
1089 regular ephemeral source port is obtained from the OS. For changing
1090 the UDP ports, see leftikeport=
1091
1092 nat-keepalive
1093 whether to send any NAT-T keep-alives. These one byte packets are
1094 send to prevent the NAT router from closing its port when there is
1095 not enough traffic on the IPsec connection. Acceptable values are:
1096 yes (the default) and no.
1097
1098 initial-contact
1099 whether to send an INITIAL_CONTACT payload to the peer we are
1100 initiating to, if we currently have no IPsec SAs up with that peer.
1101 Acceptable values are: yes (the default) and no. It is recommended
1102 to leave this option set, unless multiple clients with the same
1103 identity are expected to connect using the same subnets and should
1104 operate at the same time. Or if a reconnecting client should not
1105 delete its old instance (eg perhaps it is still running). This is
1106 unlikely to be true.
1107
1108 cisco-unity
1109 whether to send a CISCO_UNITY payload to the peer. Acceptable
1110 values are: no (the default) and yes. It is recommended to leave
1111 this option unset, unless the remote peer (Cisco client or server)
1112 requires it. This option does not modify local behaviour. It can be
1113 needed to connect as a client to a Cisco server. It can also be
1114 needed to act as a server for a Cisco client, which otherwise might
1115 send back an error DEL_REASON_NON_UNITY_PEER.
1116
1117 ignore-peer-dns
1118 whether to ignore received DNS configuration. Acceptable values
1119 are: no (the default) and yes. Normally, when a roadwarrior
1120 connects to a remote VPN, the remote VPN server sends a list of DNS
1121 domains and DNS nameserver IP addresses that the roadwarrior can
1122 use to reach internal only resources through the VPN. This option
1123 allows the roadwarrior to ignore the server's suggestion. The
1124 roadwarrior will normally use this information to update the DNS
1125 resolving process. What is changed depends on the detected DNS
1126 configuration. It can modify /etc/resolv.conf directly, or
1127 reconfigure a locally running DNS server (unbound, knot, stubby or
1128 systemd-resolved) or inform NetworkManager.
1129
1130 accept-redirect
1131 Whether requests of the remote peer to redirect IKE/IPsec SA's are
1132 accepted. Valid options are no (the default) and yes. See also
1133 accept-redirect-to.
1134
1135 accept-redirect-to
1136 Specify the comma separated list of addresses we accept being
1137 redirected to. Both IPv4 and IPv6 addresses are supported as well
1138 the FQDNs. The value %any, as well as not specifying any address,
1139 signifes that we will redirect to any address gateway sends us in
1140 REDIRECT notify payload.
1141
1142 The value of this option is not considered at all if
1143 accept-redirect is set to no.
1144
1145 send-redirect
1146 Whether to send requests for the remote peer to redirect IKE/IPsec
1147 SA's during IKE_AUTH. Valid options are no (the default) and yes.
1148 If set, the option redirect-to= must also be set to indicate where
1149 to redirect peers to. For redirection during IKE_SA_INIT exchange,
1150 see the global-redirect= and global-redirect-to= options. Runtime
1151 redirects can be triggered via the ipsec whack --redirect command.
1152
1153 redirect-to
1154 Where to send remote peers to via the send-redirect option. This
1155 can be an IP address or hostname (FQDN).
1156
1157 fake-strongswan
1158 whether to send a STRONGSWAN Vendor ID payload to the peer.
1159 Acceptable values are: no (the default) and yes. This used to be
1160 required because strongswan rejects certain proposals with private
1161 use numbers such as esp=twofish or esp=serpent unless it receives a
1162 strongswan vendorid by the peer. This option sends such an
1163 (unversioned) vendor id. Note that libreswan and strongswan no
1164 longer support twofish or serpent, so enabling this option likely
1165 will no longer do anything.
1166
1167 send-vendorid
1168 whether to send our Vendor ID during IKE. Acceptable values are: no
1169 (the default) and yes. The vendor id sent can be configured using
1170 the "config setup" option myvendorid=. It defaults to
1171 OE-Libreswan-VERSION.
1172
1173 Vendor ID's can be useful in tracking interoperability problems.
1174 However, specific vendor identification and software versions can
1175 be useful to an attacker when there are known vulnerabilities to a
1176 specific vendor/version.
1177
1178 The prefix OE stands for "Opportunistic Encryption". This prefix
1179 was historically used by The FreeS/WAN Project and The Openswan
1180 Project (openswan up to version 2.6.38) and in one Xeleranized
1181 openswan versions (2.6.39). Further Xeleranized openswan's use the
1182 prefix OSW.
1183
1184 overlapip
1185 a boolean (yes/no) that determines, when (left|right)subnet=vhost:
1186 is used, if the virtual IP claimed by this states created from this
1187 connection can with states created from other connections.
1188
1189 Note that connection instances created by the Opportunistic
1190 Encryption or PKIX (x.509) instantiation system are distinct
1191 internally. They will inherit this policy bit.
1192
1193 The default is no.
1194
1195 This feature is only available with kernel drivers that support SAs
1196 to overlapping conns. At present only the (klips) mast protocol
1197 stack supports this feature.
1198
1199 reqid
1200 a unique identifier used to match IPsec SAs using iptables with
1201 XFRM. This identifier is normally automatically allocated in groups
1202 of 4. It is exported to the _updown script as REQID. On Linux,
1203 reqids are supported with IP Connection Tracking and NAT
1204 (iptables). Automatically generated values use the range 16380 and
1205 higher. Manually specified reqid values therefore must be between 1
1206 and 16379.
1207
1208 Automatically generated reqids use a range of 0-3 (eg 16380-16383
1209 for the first reqid). These are used depending on the exact policy
1210 (AH, AH+ESP, IPCOMP, etc).
1211
1212 WARNING: Manually assigned reqids are all identical. Instantiations
1213 of connections (those using %any wildcards) will all use the same
1214 reqid. If you use manual assigning you should make sure your
1215 connections only match single road warrior only or you break
1216 multiple road warriors behind same NAT router because this feature
1217 requires unique reqids to work.
1218
1219 dpddelay
1220 Set the delay (in time units, defaults to seconds) between Dead
1221 Peer Detection (IKEv1 RFC 3706) or IKEv2 Liveness keepalives that
1222 are sent for this connection (default 0 seconds). Set to enable
1223 checking. If dpddelay is set, dpdtimeout also needs to be set.
1224
1225 dpdtimeout
1226 Set the length of time (in time units, defaults to seconds) that we
1227 will idle without hearing back from our peer. After this period has
1228 elapsed with no response and no traffic, we will declare the peer
1229 dead, and remove the SA (default 0 seconds). Set value bigger than
1230 dpddelay to enable. If dpdtimeout is set, dpddelay also needs to be
1231 set.
1232
1233 dpdaction
1234 When a DPD enabled peer is declared dead, what action should be
1235 taken. hold (default) means the eroute will be put into %hold
1236 status, while clear means the eroute and SA with both be cleared.
1237 restart means that ALL SAs to the dead peer will renegotiated.
1238
1239 dpdaction=clear is really only useful on the server of a Road
1240 Warrior config.
1241
1242 The value restart_by_peer has been obsoleted and its functionality
1243 moved into the regular restart action.
1244
1245 pfs
1246 whether Perfect Forward Secrecy of keys is desired on the
1247 connection's keying channel (with PFS, penetration of the
1248 key-exchange protocol does not compromise keys negotiated earlier);
1249 Acceptable values are yes (the default) and no.
1250
1251 pfsgroup
1252 This option is obsoleted, please use phase2alg if you need the PFS
1253 to be different from phase1 (the default) using:
1254 phase2alg=aes128-md5;modp1024
1255
1256 aggressive
1257 Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This option
1258 has no effect when IKEv2 is used. Acceptable values are no (the
1259 default) or yes. When this option is enabled, IKEv1 Main Mode will
1260 no longer be allowed for this connection. The old name of this
1261 option was aggrmode.
1262
1263 Aggressive Mode is less secure, and more vulnerable to Denial Of
1264 Service attacks. It is also vulnerable to brute force attacks with
1265 software such as ikecrack. It should not be used, and it should
1266 especially not be used with XAUTH and group secrets (PSK). If the
1267 remote system administrator insists on staying irresponsible,
1268 enable this option.
1269
1270 Aggressive Mode is further limited to only proposals with one DH
1271 group as there is no room to negotiate the DH group. Therefore it
1272 is mandatory for Aggressive Mode connections that both ike= and
1273 phase2alg= options are specified with only one fully specified
1274 proposal using one DH group.
1275
1276 The KE payload is created in the first exchange packet when using
1277 aggressive mode. The KE payload depends on the DH group used. This
1278 is why there cannot be multiple DH groups in IKEv1 aggressive mode.
1279 In IKEv2, which uses a similar method to IKEv1 Aggressive Mode,
1280 there is an INVALID_KE response payload that can inform the
1281 initiator of the responder's desired DH group and so an IKEv2
1282 connection can actually recover from picking the wrong DH group by
1283 restarting its negotiation.
1284
1285 salifetime
1286 how long a particular instance of a connection (a set of
1287 encryption/authentication keys for user packets) should last, from
1288 successful negotiation to expiry; acceptable values are an integer
1289 optionally followed by s (a time in seconds) or a decimal number
1290 followed by m, h, or d (a time in minutes, hours, or days
1291 respectively) (default 8h, maximum 24h). Normally, the connection
1292 is renegotiated (via the keying channel) before it expires. The two
1293 ends need not exactly agree on salifetime, although if they do not,
1294 there will be some clutter of superseded connections on the end
1295 which thinks the lifetime is longer.
1296
1297 The keywords "keylife" and "lifetime" are obsoleted aliases for
1298 "salifetime." Change your configs to use "salifetime" instead.
1299
1300 replay-window
1301 The size of the IPsec SA replay window protection. The default is
1302 128. Linux XFRM allows at least up to 2048. A value of of 0
1303 disables replay protection. Disabling of replay protection is
1304 sometimes used on a pair of IPsec servers in a High Availability
1305 setup, or on servers with very unpredictable latency, such as
1306 mobile networks, which can cause an excessive amount of out of
1307 order packets. Sequence errors can be seen in /proc/net/xfrm_stat.
1308
1309 Setting replay-window to 0 will also disable Extended Sequence
1310 Numbers (esn=no), as advise from RFC 4303 caused some stacks to not
1311 support ESN without a replay-window.
1312
1313 Note that technically, at least the Linux kernel can install IPsec
1314 SA's with an IPsec SA Sequence Number, but this is currently not
1315 supported by libreswan.
1316
1317 rekey
1318 whether a connection should be renegotiated when it is about to
1319 expire; acceptable values are yes (the default) and no. The two
1320 ends need not agree, but while a value of no prevents Pluto from
1321 requesting renegotiation, it does not prevent responding to
1322 renegotiation requested from the other end, so no will be largely
1323 ineffective unless both ends agree on it.
1324
1325 rekeymargin
1326 how long before connection expiry or keying-channel expiry should
1327 attempts to negotiate a replacement begin; acceptable values as for
1328 salifetime (default 9m). Relevant only locally, other end need not
1329 agree on it.
1330
1331 rekeyfuzz
1332 maximum percentage by which rekeymargin should be randomly
1333 increased to randomize rekeying intervals (important for hosts with
1334 many connections); acceptable values are an integer, which may
1335 exceed 100, followed by a `%' (default set by ipsec_pluto(8),
1336 currently 100%). The value of rekeymargin, after this random
1337 increase, must not exceed salifetime. The value 0% will suppress
1338 time randomization. Relevant only locally, other end need not agree
1339 on it.
1340
1341 keyingtries
1342 how many attempts (a whole number or %forever) should be made to
1343 negotiate a connection, or a replacement for one, before giving up
1344 (default %forever). The value %forever or 0 means to keep trying
1345 forever. For Opportunistic Encryption connections, a keyingtries
1346 value of %forever or 0 is set to 1 and a warning message will be
1347 logged. This is because an expired failureshunt triggers new
1348 keyingtries on-demand later, when there is traffic. This prevents
1349 accumulating an infinite amount of attempts to peers that do not
1350 support Opportunistic Encryption. For Opportunistic, a keyingtries
1351 value of > 1 is allowed but currently not recommended. The meaning
1352 of failureshunt= is unclear when there is continued (failed) keying
1353 happening with a negotiationshunt installed. Relevant only locally,
1354 other end need not agree on it.
1355
1356 ikelifetime
1357 how long the keying channel of a connection (buzzphrase: “IKE SA”
1358 or “Parent SA”) should last before being renegotiated; acceptable
1359 values as for salifetime. The default as of version 4.2 is 8h,
1360 before that it was 1h. The maximum is 24h. The two-ends-disagree
1361 case is similar to that of salifetime.
1362
1363 retransmit-timeout
1364 how long a single packet, including retransmits of that packet, may
1365 take before the IKE attempt is aborted. If rekeying is enabled, a
1366 new IKE attempt is started. The default set by ipsec_pluto(8),
1367 currently is 60s. See also: retransmit-interval, rekey and
1368 keyingtries.
1369
1370 retransmit-interval
1371 the initial interval time period, specified in msecs, that pluto
1372 waits before retransmitting an IKE packet. This interval is doubled
1373 for each attempt (exponential back-off). The default set by
1374 ipsec_pluto(8), currently is 500. See also: retransmit-timeout,
1375 rekey and keyingtries.
1376
1377 compress
1378 whether IPComp compression of content is proposed on the connection
1379 (link-level compression does not work on encrypted data, so to be
1380 effective, compression must be done before encryption); acceptable
1381 values are yes and no (the default).
1382
1383 For IKEv1, compress settings on both peers must match. For IKEv2,
1384 compression can only be suggested and a mismatched compress setting
1385 results in connection without compression.
1386
1387 When set to yes, compression is negotiated for the DEFLATE
1388 compression algorithm.
1389
1390 metric
1391 Set the metric for added routes. This value is passed to the
1392 _updown scripts as PLUTO_METRIC. Acceptable values are positive
1393 numbers, with the default being 1.
1394
1395 mtu
1396 Set the MTU for the route(s) to the remote endpoint and/or subnets.
1397 This is sometimes required when the overhead of the IPsec
1398 encapsulation would cause the packet the become too big for a
1399 router on the path. Since IPsec cannot trust any unauthenticated
1400 ICMP messages, PATH MTU discovery does not work. This can also be
1401 needed when using "6to4" IPV6 deployments, which adds another
1402 header on the packet size. Acceptable values are positive numbers.
1403 There is no default.
1404
1405 tfc
1406 Enable Traffic Flow Confidentiality ("TFC") (RFC-4303) for outgoing
1407 ESP packets in Tunnel Mode. When enabled, ESP packets are padded to
1408 the specified size (up to the PMTU size) to prevent leaking
1409 information based on ESP packet size. This option is ignored for AH
1410 and for ESP in Transport Mode as those always leak traffic
1411 characteristics and applying TFC will not do anything. Acceptable
1412 values are positive numbers. The value 0 means TFC padding is not
1413 performed. Currently this feature is only implemented for the Linux
1414 XFRM stack. In IKEv2, when the notify payload
1415 ESP_TFC_PADDING_NOT_SUPPORTED is received, TFC padding is disabled.
1416 The default is not to do any TFC padding, but this might change in
1417 the near future.
1418
1419 send-no-esp-tfc
1420 Whether or not to tell the remote peer that we do not support
1421 Traffic Flow Confidentiality ("TFC") (RFC-4303). Possible values
1422 are no (the default) which allows the peer to use TFC or yes which
1423 prevents to peer from using TFC. This does not affect whether this
1424 endpoint uses TFC, which only depends on the local tfc setting.
1425 This option is only valid for IKEv2.
1426
1427 nflog
1428 If set, the NFLOG group number to log this connection's pre-crypt
1429 and post-decrypt traffic to. The default value of 0 means no
1430 logging at all. This option is only available on linux kernel
1431 2.6.14 and later. It allows common network utilities such as
1432 tcpdump, wireshark and dumpcap, to use nflog:XXX pseudo interfaces
1433 where XXX is the nflog group number. During the updown phase of a
1434 connection, iptables will be used to add and remove the
1435 source/destination pair to the nflog group specified. The rules are
1436 setup with the nflog-prefix matching the connection name. See also
1437 the global nflog-all option.
1438
1439 mark
1440 If set, the MARK to set for the IPsec SA of this connection. The
1441 format of a CONNMARK is mark/mask. If the mask is left out, a
1442 default mask of 0xffffffff is used. A mark value of -1 means to
1443 assign a new global unique mark number for each instance of the
1444 connection. Global marks start at 1001. This option is only
1445 available on linux XFRM kernels. It can be used with iptables to
1446 create custom iptables rules using CONNMARK. It can also be used
1447 with Virtual Tunnel Interfaces ("VTI") to direct marked traffic to
1448 specific vtiXX devices.
1449
1450 mark-in
1451 The same as mark, but mark-in only applies to the inbound half of
1452 the IPsec SA. It overrides any mark= setting.
1453
1454 mark-out
1455 The same as mark, but mark-out only applies to the outbound half of
1456 the IPsec SA. It overrides any mark= setting.
1457
1458 vti-interface
1459 This option is used to create "Routing based VPNs" (as opposed to
1460 "Policy based VPNs"). It will create a new interface that can be
1461 used to route traffic in for encryption/decryption. The Virtual
1462 Tunnel Interface ("VTI") interface name is used to for all IPsec
1463 SA's created by this connection. This requires that the connection
1464 also enables either the mark= or mark-in= / mark-out- option(s).
1465 All traffic marked with the proper MARKs will be automatically
1466 encrypted if there is an IPsec SA policy covering the
1467 source/destination traffic. Tools such as tcpdump and iptables can
1468 be used on all cleartext pre-encrypt and post-decrypt traffic on
1469 the device. See the libreswan wiki for example configurations that
1470 use VTI.
1471
1472 VTI interfaces are currently only supported on Linux with XFRM. The
1473 _updown script handles certain Linux specific interfaces settings
1474 required for proper functioning (disable_policy, rp_filter,
1475 forwarding, etc). Interface names are limited to 16 characters and
1476 may not allow all characters to be used. If marking and
1477 vti-routing=yes is used, no manual iptables should be required.
1478 However, administrators can use the iptables mangle table to mark
1479 traffic manually if desired.
1480
1481 vti-routing
1482 Whether or not to add network rules or routes for IPsec SA's to the
1483 respective VTI devices. Valid values are yes (the default) or no.
1484 When using "routing based VPNs" with a subnets policy of 0.0.0.0/0,
1485 this setting needs to set to no to prevent imploding the tunnel,
1486 and the administrator is expected to manually add ip rules and ip
1487 routes to configure what traffic must be encrypted. When set to
1488 yes, the _updown script will automatically route the
1489 leftsubnet/rightsubnet traffic into the VTI device specified with
1490 vti-interface
1491
1492 vti-shared
1493 Whether or not the VTI device is shared amongst connections. Valid
1494 values are no (the default) or yes. When set to no, the VTI device
1495 is automatically deleted if the connection is a single
1496 non-instantiated connection. If a connection instantiates (eg
1497 right=%any) then this option has no effect, as the VTI device is
1498 not removed as it is shared with multiple roadwarriors.
1499
1500 ipsec-interface
1501 Create or use an existing virtual interface ipsecXXX for "Routing
1502 based VPNs" (as opposed to "Policy based VPNs"). Valid options are
1503 yes, no or a number. When using a number, the IPsec interface
1504 created and/or used will use that number as part of the interface
1505 name. For example setting ipsec-interface=5 will create and/or use
1506 the ipsec5 interface. The value 0 cannot be used and is interpreted
1507 as no. The value yes is interpreted as the number 1, and thus will
1508 use the interface named ipsec1. An IP address can be configured for
1509 this interface via the interface-ip= option.
1510
1511 The ipsec-interface is used to route outbound traffic that needs to
1512 be encrypted, and will decrypt inbound traffic that arrives on this
1513 interface. All traffic that is routed to this interface will be
1514 automatically encrypted providing the IPsec SA policy covers this
1515 traffic. Traffic not matching the IPsec SA will be dropped. Tools
1516 such as tcpdump, iptables, ifconfig and tools that need traffic
1517 counters can be used on all cleartext pre-encrypt and post-decrypt
1518 traffic on the device. When leftsubnet= is equal to rightsubnet=,
1519 the routing needs to be manged by an external routing daemon or
1520 manually by the administrator.
1521
1522 This option is currently only supported on Linux kernels 4.19 or
1523 later when compiled with XFRMi support (CONFIG_XFRM_INTERFACE). The
1524 number of the ipsecX device corresponds with the XFRM IF_ID policy
1525 option of the IPsec SA in the Linux kernel. On Linux, XFRMi
1526 interfaces can be managed by libreswan automatically or can be
1527 preconfigured on the system using the existing init system or via
1528 networking tools such as systemd-networkd and NetworkManager. The
1529 _updown script handles certain Linux specific interfaces settings
1530 required for proper functioning, such as forwarding and routing
1531 rules for IPsec traffic.
1532
1533 The ipsec-interface=0 will create an interface with the same name
1534 as the old KLIPS interface, ipsec0. This interface name should only
1535 be used when required for migration from KLIPS to XFRM interfaces.
1536 Since XFRM IF_ID and marking cannot use 0, this is mapped to 16384.
1537 This means that the devices ipsec0 and ipsec16384 cannot both be in
1538 use.
1539
1540 interface-ip=
1541 NOTE: This option is currently not implemented pending pluto IP
1542 address reference counting. The IP address and netmask to configure
1543 on a virtual device (eg ipsecXXX). This is often used when building
1544 Routing based IPsec tunnels using transport mode and GRE, but can
1545 also be useful in other scenarios. Currently requires
1546 ipsec-interface=. See also leftvti= for cnofiguring IP addresses
1547 when using VTI.
1548
1549 priority
1550 The priority in the kernel SPD/SAD database, when matching up
1551 packets. Each kernel (XFRM, OSX, etc) has its own mechanism for
1552 setting the priority. Setting this option to non-zero passes the
1553 priority to the kernel stack unmodified. The maximum value depends
1554 on the stack. It is recommended not to exceed 65536
1555
1556 XFRM use a priority system based on "most specific match first". It
1557 uses an internal algorithm to calculate these based on network
1558 prefix length, protocol and port selectors. A lower value means a
1559 higher priority.
1560
1561 Typical values are about the 2000 range. These can be seen on the
1562 XFRM stack using ip xfrm policy when the connection is up. For
1563 "anonymous IPsec" or Opportunistic Encryption based connections, a
1564 much lower priority (65535) is used to ensure administrator
1565 configured IPsec always takes precedence over opportunistic IPsec.
1566
1567 sendca
1568 How much of our available X.509 trust chain to send with the End
1569 certificate, excluding any root CA's. Specifying issuer sends just
1570 the issuing intermediate CA, while
1571 all will send the entire chain of intermediate CA's.none (the
1572 default) will not send any CA certs.
1573
1574 labeled-ipsec
1575 This option is obsolete. To enable labeled IPsec, setting the
1576 policy-label= is enough. See also policy-label= and
1577 secctx-attr-type=
1578
1579 policy-label
1580 The string representation of an access control security label that
1581 is interpreted by the LSM (e.g. SELinux) for use with Labeled
1582 IPsec. See also labeled-ipsec= and secctx-attr-type=. For example,
1583 policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023
1584
1585 failureshunt
1586 what to do with packets when negotiation fails. The default is
1587 none: no shunt; passthrough, drop, and reject have the obvious
1588 meanings.
1589
1590 negotiationshunt
1591 What to do with packets during the IKE negotiation. Valid options
1592 are hold (the default) or passthrough. This should almost always be
1593 left to the default hold value to avoid cleartext packet leaking.
1594 The only reason to set this to passthrough is if plaintext service
1595 availability is more important than service security or privacy, a
1596 scenario that also implies failureshunt=passthrough and most likely
1597 authby=%null using Opportunistic Encryption.
1598
1600 At present, the only config section known to the IPsec software is the
1601 one named setup, which contains information used when the software is
1602 being started (see ipsec_setup(8)). Here's an example:
1603
1604
1605 config setup
1606 logfile=/var/log/pluto.log
1607 plutodebug=all
1608
1609 Parameters are optional unless marked “(required)”.
1610
1611 The currently-accepted parameter names in a config setup section are:
1612
1613 protostack
1614 decide which protocol stack is going to be used. Valid values are
1615 "xfrm" and "bsd". This option should no longer be set, as the stack
1616 is currently auto-detected. The values "klips, "mast", "netkey",
1617 "native", "kame" and "auto" are obsolete. The option is kept only
1618 because it is suspected that Linux and BSD will get userspace
1619 stacks with IPsec support soon (such as dpdk).
1620
1621 listen
1622 IP address to listen on (default depends on interfaces= setting).
1623 Currently only accepts one IP address.
1624
1625 ike-socket-bufsize
1626 Set the IKE socket buffer size. Default size is determined by the
1627 OS (as of writing, this seems to be set to 212992. On Linux this is
1628 visible via /proc/sys/net/core/rmem_default and
1629 /proc/sys/net/core/wmem_default. On Linux, this option uses
1630 SO_RCVBUFFORCE and SO_SNDBUFFORCE so that it can override
1631 rmem_max/wmem_max values of the OS. This requires CAP_NET_ADMIN
1632 (which is also required for other tasks). This option can also be
1633 toggled on a running system using ipsec whack --ike-socket-bufsize
1634 bufsize.
1635
1636 ike-socket-errqueue
1637 Whether to enable or disable receiving socket errors via
1638 IP_RECVERR. The default is enabled. This will cause the socket to
1639 receive, process and log socket errors, such as ICMP unreachable
1640 messages or Connection Refused messages. Disabling this only makes
1641 sense on very busy servers, and even then it might not make much of
1642 a difference. This option can also be toggled on a running system
1643 using ipsec whack --ike-socket-errqueue-toggle.
1644
1645 listen-udp
1646 Whether the pluto IKE daemon should listen on the standard UDP
1647 ports of 500 and 4500. The value "yes" means to listen on these
1648 ports, and is the default. This should almost never be disabled. In
1649 the rare case where it is known that only ever TCP or non-standard
1650 UDP ports will be used, this option can disable the standard UDP
1651 ports. Connections can specify their own non-standard port using
1652 leftikeport=.
1653
1654 listen-tcp
1655 Whether the pluto IKE daemon should listen on the (pseudo) standard
1656 TCP port 4500. The value "no" is the current default, but this will
1657 be changed in the future to "yes". The TCP usage complies to RFC
1658 8229 for IKE and ESP over TCP support. Connections can specify
1659 their own non-standard port using leftikeport=.
1660
1661 nflog-all
1662 If set, the NFLOG group number to log all pre-crypt and
1663 post-decrypt traffic to. The default value of 0 means no logging at
1664 all. This option is only available on linux kernel 2.6.14 and
1665 later. It allows common network utilities such as tcpdump,
1666 wireshark and dumpcap, to use nflog:XXX pseudo interfaces where XXX
1667 is the nflog group number. During startup and shutdown of the IPsec
1668 service, iptables commands will be used to add or remove the global
1669 NFLOG table rules. The rules are setup with the nflog-prefix
1670 all-ipsec. See also the per-connection nflog option.
1671
1672 keep-alive
1673 The delay (in seconds) for NAT-T keep-alive packets, if these are
1674 enabled using nat-keepalive This parameter may eventually become
1675 per-connection.
1676
1677 virtual-private
1678 contains the networks that are allowed as (left|right)subnet= for
1679 the remote clients when using the vhost: or vnet: keywords in the
1680 (left|right)subnet= parameters. In other words, the address ranges
1681 that may live behind a NAT router through which a client connects.
1682 This value is usually set to all the RFC-1918 address space,
1683 excluding the space used in the local subnet behind the NAT (An IP
1684 address cannot live at two places at once). IPv4 address ranges are
1685 denoted as %v4:a.b.c.d/mm and IPv6 is denoted as
1686 %v6:aaaa::bbbb:cccc:dddd:eeee/mm. One can exclude subnets by using
1687 the !. For example, if the VPN server is giving access to
1688 192.168.1.0/24, this option should be set to:
1689 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.
1690 This parameter is only needed on the server side and not on the
1691 client side that resides behind the NAT router, as the client will
1692 just use its IP address for the inner IP setting. This parameter
1693 may eventually become per-connection. See also leftsubnet=
1694
1695 Note: It seems that T-Mobile in the US and Rogers/Fido in Canada
1696 have started using 25.0.0.0/8 as their pre-NAT range. This range
1697 technically belongs to the Defence Interoperable Network Services
1698 Authority (DINSA), an agency of the Ministry of Defence of the
1699 United Kingdom. The network range seems to not have been announced
1700 for decades, which is probably why these organisations "borrowed"
1701 this range. To support roadwarriors on these 3G networks, you might
1702 have to add it to the virtual-private= line.
1703
1704 myvendorid
1705 The string to use as our vendor id (VID) when send-vendorid=yes.
1706 The default is OE-Libreswan-VERSION.
1707
1708 nhelpers
1709 how many pluto helpers are started to help with cryptographic
1710 operations. Pluto will start as many helpers as the number of
1711 CPU's, minus 1 to dedicate to the main thread. For machines with
1712 less than 4 CPU's, an equal number of helpers to CPU's are started.
1713 A value of 0 forces pluto to do all operations inline using the
1714 main process. A value of -1 tells pluto to perform the above
1715 calculation. Any other value forces the number to that amount.
1716
1717 seedbits
1718 Pluto uses the NSS crypto library as its random source. Some
1719 government Three Letter Agencies require that pluto reads
1720 additional bits from /dev/random and feed these into the NSS RNG
1721 before drawing random from the NSS library, despite the NSS library
1722 itself already seeding its internal state. This process can block
1723 pluto for an extended time during startup, depending on the entropy
1724 of the system. Therefore, the default is to not perform this
1725 redundant seeding. If specifying a value, it is recommended to
1726 specify at least 460 bits (for FIPS) or 440 bits (for BSI).
1727
1728 ikev1-secctx-attr-type
1729 The value for the IKEv1 IPsec SA security context attribute
1730 identifier that is used for Labeled IPsec. Defaults to the private
1731 use IANA value 32001 from the IPsec SA attributes registry. Old
1732 openswan versions might still be using the (stolen) value 10, which
1733 has since been assigned by IANA for something else. Other values
1734 are not recommended unless IANA assigns an actual value for this
1735 option. Labeled IPsec using IKEv2 does not use this option, it only
1736 uses an IANA allocated Notify number. See also policy-label.
1737
1738 ikev1-policy
1739 What to do with received IKEv1 packets. Valid options are accept
1740 (default), reject which will reply with an error, and drop which
1741 will silently drop any received IKEv1 packet. If this option is set
1742 to drop or reject, an attempt to load an IKEv1 connection will
1743 fail, as these connections would never be able to receive a packet
1744 for processing.
1745
1746 crlcheckinterval
1747 interval expressed in second units, for example crlcheckinterval=8h
1748 for 8 hours, after which pluto will fetch new Certificate
1749 Revocation List (CRL) from crl distribution points. List of used
1750 CRL distribution points are collected from CA certificates and end
1751 certificates. Loaded X.509 CRL's are verified to be valid and
1752 updates are imported to NSS database. If set to 0, which is also
1753 the default value if this option is not specified, CRL updating is
1754 disabled.
1755
1756 crl-strict
1757 if not set, pluto is tolerant about missing or expired X.509
1758 Certificate Revocation Lists (CRL's), and will allow peer
1759 certificates as long as they do not appear on an expired CRL. When
1760 this option is enabled, all connections with an expired or missing
1761 CRL will be denied. Active connections will be terminated at rekey
1762 time. This setup is more secure, but vulnerable to downtime if the
1763 CRL expires. Acceptable values are yes or no (the default). This
1764 option used to be called strictcrlpolicy.
1765
1766 curl-iface
1767 The name of the interface that is used for CURL lookups. This is
1768 needed on rare situations where the interface needs to be forced to
1769 be different from the default interface used based on the routing
1770 table.
1771
1772 curl-timeout
1773 The timeout for the curl library calls used to fetch CRL and OCSP
1774 requests. The default is 5s.
1775
1776 ocsp-enable
1777 Whether to perform Online Certificate Store Protocol ("OCSP")
1778 checks on those certificates that have an OCSP URI defined.
1779 Acceptable values are yes or no (the default).
1780
1781 ocsp-strict
1782 if set to no, pluto is tolerant about failing to obtain an OCSP
1783 responses and a certificate is not rejected when the OCSP request
1784 fails, only when the OCSP request succeeds and lists the
1785 certificate as revoked. If set to yes, any failure on obtaining an
1786 OCSP status for a certificate will be fatal and the certificate
1787 will be rejected. Acceptable values are yes or no (the default).
1788
1789 The strict mode refers to the NSS
1790 ocspMode_FailureIsVerificationFailure mode, while non-strict mode
1791 refers to the NSS ocspMode_FailureIsNotAVerificationFailure mode.
1792
1793 ocsp-method
1794 The HTTP methods used for fetching OCSP data. Valid options are get
1795 (the default) and post. Note that this behaviour depends on the NSS
1796 crypto library that is actually performing the fetching. When set
1797 to the get method, post is attempted only as fallback in case of
1798 failure. When set to post, only the post method is ever used.
1799
1800 ocsp-timeout
1801 The time until an OCSP request is aborted and considered failed.
1802 The default value is 2 seconds.
1803
1804 ocsp-uri
1805 The URI to use for OCSP requests instead of the default OCSP URI
1806 listed in the CA certificate. This requires the ocsp-trustname
1807 option to be set to the nick (friendly name) of the OCSP server
1808 certificate, which needs to be present in the NSS database. These
1809 option combined with the next option sets the OCSP default
1810 responder.
1811
1812 ocsp-trustname
1813 The nickname of the certificate that has been imported into the NSS
1814 database of the server handling the OCSP requests. This requires
1815 the ocsp-uri option to be set as well. This option and the previous
1816 options sets the OCSP default responder.
1817
1818 ocsp-cache-size
1819 The maximum size (in number of certificates) of OCSP responses that
1820 will be kept in the cache. The default is 1000. Setting this value
1821 to 0 means the cache is disabled.
1822
1823 ocsp-cache-min-age
1824 The minimum age (in seconds) before a new fetch will be attempted.
1825 The default is 1 hour.
1826
1827 ocsp-cache-max-age
1828 The maximum age (in seconds) before a new fetch will be attempted.
1829 The default is 1 day.
1830
1831 syslog
1832 the syslog(2) “facility” name and priority to use for
1833 startup/shutdown log messages, default daemon.error.
1834
1835 plutodebug
1836 how much Pluto debugging output should be logged. An empty value,
1837 or the magic value none, means no debug output (the default).
1838 Otherwise only the specified types of output (a quoted list, names
1839 without the --debug- prefix, separated by white space) are enabled;
1840
1841 The current option values are base that represents moderate amounts
1842 of information, cpu-usage for getting timing/load based information
1843 (best used without any other debugging options), crypt for all
1844 crypto related operations and tmi (Too Much Information) for
1845 excessive logging. To log any sensitive private key or password
1846 material, use the special private value.
1847
1848 The old plutodebug options (control, controlmore, x509, kernel,
1849 etc) are mapped to either base or tmi. Note that all maps to base
1850 and not tmi.
1851
1852 uniqueids
1853 Whether IDs should be considered identifying remote parties
1854 uniquely. Acceptable values are yes (the default) and no.
1855 Participant IDs normally are unique, so a new connection instance
1856 using the same remote ID is almost invariably intended to replace
1857 an old existing connection.
1858
1859 When the connection is defined to be a server (using xauthserver=)
1860 and the connection policy is authby=secret, this option is ignored
1861 (as of 3.20) and old connections will never be replaced. This
1862 situation is commonly known as clients using a "Group ID".
1863
1864 This option may disappear in the near future. People using
1865 identical X.509 certificates on multiple devices are urged to
1866 upgrade to use separate certificates per client and device.
1867
1868 logfile
1869 do not use syslog, but rather log to stderr, and direct stderr to
1870 the argument file. This option used to be called plutostderrlog=
1871
1872 logappend
1873 If pluto is instructed to log to a file using logfile=, this option
1874 determines whether the log file should be appended to or
1875 overwritten. Valid options are yes (the default) to append and no
1876 to overwrite. Since on modern systems, pluto is restarted by other
1877 daemons, such as systemd, this option should be left at its default
1878 yes value to preserve the log entries of previous runs of pluto.
1879 The option is mainly of use for running the test suite, which needs
1880 to create new log files from scratch.
1881
1882 logip
1883 If pluto is instructed to log the IP address of incoming
1884 connections. Valid options are yes (the default) and no. Note that
1885 this only affects regular logging. Any enabled debugging via
1886 plutodebug= will still contain IP addresses of peers. This option
1887 is mostly meant for servers that want to avoid logging IP addresses
1888 of incoming clients. Other identifiable information might still be
1889 logged, such as ID payloads and X.509 certificate details. When
1890 using ID of type IP address, this option will not hide the actual
1891 IP address as part of the ID. Most deployments will not want to
1892 change this from the default. If logging of IP addresses is
1893 unwanted, audit-log=no should also be set.
1894
1895 audit-log
1896 Whether pluto should produce Linux Auditing System log messages. If
1897 enabled, pluto will log start, stop and fail for the negotiation of
1898 IKE and IPsec SA's. The kernel will also log success and failures
1899 for actually adding and removing IPsec SA's from the kernel's SADB.
1900 Valid options are yes(the default) and no. On non-Linux systems,
1901 this option is ignored. If enabled but the kernel is lacking audit
1902 support, audit messages are not sent. If the kernel has audit
1903 support and using it fails, pluto will abort. Note that for
1904 compliance reasons, audit log messages contain the relevant IP
1905 addresses, even if logip=no.
1906
1907 logtime
1908 When pluto is directed to log to a file using logfile=, this option
1909 determines whether or not to log the current timestamp as prefix.
1910 Values are yes (the default) or no. The no value can be used to
1911 create logs without ephemeral timestamps, such as those created
1912 when running the test suite. This option used to be called
1913 plutostderrlogtime=
1914
1915 ddos-mode
1916 The startup mode of the DDoS defense mechanism. Acceptable values
1917 are busy, unlimited or auto (the default). This option can also be
1918 given to the IKE daemon while running, for example by issuing ipsec
1919 whack --ddos--busy. When in busy mode, pluto activates anti-DDoS
1920 counter measures. Currently, counter measures consist of requiring
1921 IKEv2 anti-DDoS cookies on new incoming IKE requests, and a more
1922 aggressive cleanup of partially established or AUTH_NULL
1923 connections.
1924
1925 ddos-ike-threshold
1926 The number of half-open IKE SAs before the pluto IKE daemon will be
1927 placed in busy mode. When in busy mode, pluto activates anti-DDoS
1928 counter measures. The default is 25000. See also ddos-mode and
1929 ipsec whack --ddos-XXX.
1930
1931 global-redirect
1932 Whether to send requests for the remote peer to redirect IKE/IPsec
1933 SA's during IKE_SA_INIT. Valid options are no (the default), yes
1934 and auto, where auto means that the requests will be sent if DDoS
1935 mode is active (see ddos-mode). If set, the option
1936 global-redirect-to= must also be set to indicate where to redirect
1937 peers to. For specific connection redirection after IKE SA
1938 authentication, see the send-redirect= and redirect-to= options.
1939 This configuration can be changed at runtime via the ipsec whack
1940 --global-redirect command.
1941
1942 global-redirect-to
1943 Where to send remote peers to via the global-redirect option. This
1944 can be a list, or a single entry, of IP addresses or hostnames
1945 (FQDNs). If there is a list of entries, they must be separated with
1946 comma's. One specified entry means all peers will be redirected to
1947 it, while multiple specified entries means peers will be evenly
1948 distributed across the specified servers. This configuration can be
1949 changed at runtime via the ipsec whack --global-redirect-to
1950 command.
1951
1952 max-halfopen-ike
1953 The number of half-open IKE SAs before the IKE daemon starts
1954 refusing all new IKE attempts. Established IKE peers are not
1955 affected. The default value is 50000.
1956
1957 shuntlifetime
1958 The time until bare shunts (kernel policies not associated with
1959 connections) are deleted from the kernel. The default value is 15m.
1960 When using Opportunistic Encryption to a specific host fails, the
1961 system will either install a %pass or %hold shunt to let the
1962 traffic out clear text or block it. During the the shuntlifetime,
1963 no new Opportunistic Encryption attempt will be started, although
1964 the system will still respond to incoming OE requests from the
1965 remote IP. See also failureshunt and negotiationshunt
1966
1967 xfrmlifetime
1968 The time in seconds until the XFRM acquire state times out. The
1969 default value is 30 seconds. For auto=ondemand connections and
1970 Opportunistic connections an IPsec policy is installed in the
1971 kernel. If an incoming or outgoing packet matches this policy, a
1972 state is created in the kernel and the kernel sends an ACQUIRE
1973 message to the IKE daemon pluto. While this state is in place, no
1974 new acquires will come in for this connection. The default should
1975 be fine for most people. One use case of shortening these is if
1976 opportunistc encryption is used towards cloud instances that can
1977 quickly re-use IP addresses. This value is only used during the
1978 libreswan startup process by the ipsec _stackmanager helper. See
1979 also failureshunt and negotiationshunt
1980
1981 dumpdir
1982 in what directory should things started by setup (notably the Pluto
1983 daemon) be allowed to dump core? The default value is
1984 /var/run/pluto. When SELinux runs in enforced mode, changing this
1985 requires a similar change in the SELinux policy for the pluto
1986 daemon.
1987
1988 statsbin
1989 This option specifies an optional external program to report tunnel
1990 state changes too. The default is not to report tunnel state
1991 changes. This program can be used to notify the user's desktop
1992 (dbus, NetworkManager) or to report tunnel changes to a central
1993 logging server.
1994
1995 ipsecdir
1996 Specifies a directory for administrator-controlled configuration
1997 files and directories. The default value is /etc/ipsec.d. It may
1998 contain the following files and directories:
1999
2000 passwd
2001 (optional) for XAUTH support if not using PAM (this file should
2002 not be world-readable). See README.XAUTH for more information.
2003
2004 nsspassword
2005 (optional) passwords needed to unlock the NSS database in
2006 /var/lib/ipsec/nss (this file should not be world-readable).
2007 See README.nss for more information.
2008
2009 policies/
2010 a directory containing policy group configuration information.
2011 See POLICY GROUP FILES in this document for more information.
2012
2013 cacerts/
2014 DEPRECATED: a directory to store trust anchors (root
2015 certificate authority certificates). The preferred (and
2016 default) approach is to store CA certs in the NSS database
2017 instead. See README.nss for more information.
2018
2019 crls/
2020 DEPRECATED: a directory to store certificate revocation lists.
2021 The preferred (and default) approach is to store CRLs in the
2022 NSS database instead. See README.nss for more information.
2023
2024 When SELinux runs in enforced mode, changing this requires a
2025 similar change in the SELinux policy for the pluto daemon.
2026
2027 nssdir
2028 Specifies a directory for NSS database files. The default value is
2029 /var/lib/ipsec/nss. It may contain the following files:
2030
2031 pkcs11.txt
2032 Detailed info about NSS database creation parameteres.
2033
2034 cert9.db
2035 NSS Certificate database.
2036
2037 key4.db
2038 NSS Key database.
2039
2040 When SELinux runs in enforced mode, changing this requires a
2041 similar change in the SELinux policy for the pluto daemon.
2042
2043 secretsfile
2044 pathname of the file that stores the secret credentials such as
2045 preshared keys (PSKs). See man ipsec.secrets for the syntax. The
2046 default value is /etc/ipsec.secrets.
2047
2048 seccomp
2049 Set the seccomp kernel syscall whitelisting feature. When set to
2050 enabled, if pluto calls a syscall that is not on the compiled-in
2051 whitelist, the kernel will assume an exploit is attempting to use
2052 pluto for malicious access to the system and terminate the pluto
2053 daemon. When set to tolerant, the kernel will only block the rogue
2054 syscall and pluto will attempt to continue. If set to disabled,
2055 pluto is allowed to call any syscall offered by the kernel,
2056 although it might be restricted via other security mechanisms, such
2057 as capabilities, SElinux, AppArmor or other OS security features.
2058
2059 The current default is disabled, but it is expected that in the
2060 future this feature will be enabled on all supported operating
2061 systems. Similarly, it is expected that further privilege
2062 separation will reduce the allowed syscalls - for example for the
2063 crypto helpers or DNS helpers.
2064
2065 Warning: The restrictions of pluto are inherited by the updown
2066 scripts, so these scripts are also not allowed to use syscalls that
2067 are forbidden for pluto.
2068
2069 This feature can be tested using ipsec whack --seccomp-crashtest.
2070 Warning: With seccomp=enabled, pluto will be terminated by the
2071 kernel. With seccomp=tolerant or seccomp=disabled, pluto will
2072 report the results of the seccomp test. SECCOMP will log the
2073 forbidden syscall numbers to the audit log, but only with
2074 seccomp=enabled. The tool scmp_sys_resolver from the libseccomp
2075 development package can be used to translate the syscall number
2076 into a name. See programs/pluto/pluto_seccomp.c for the list of
2077 allowed syscalls.
2078
2079 dnssec-enable
2080 Whether pluto should perform dnssec validation using libunbound,
2081 provided libreswan was compiled with USE_DNSSEC. A value of yes
2082 (the default) means pluto should perform DNSSEC validation. Note
2083 that pluto reads the file /etc/resolv.conf to determine which
2084 nameservers to use.
2085
2086 dnssec-rootkey-file
2087 The location of the DNSSEC root zone public key file. The default
2088 is /var/lib/unbound/root.key but this can be changed at compile
2089 time.
2090
2091 dnssec-anchors
2092 The location of a file containing additional DNSSEC Trust Anchors.
2093 This can be used when a network is using split-DNS and the internal
2094 hierarchy is using DNSSEC trust anchors. There is no default value.
2095
2097 For Opportunistic connections, the system requires creating special
2098 named conns that are used to implement the default policy groups.
2099 Currently, these names cannot be changed.
2100
2101
2102 conn clear
2103 type=passthrough
2104 authby=never
2105 left=%defaultroute
2106 right=%group
2107 auto=route
2108
2109 conn clear-or-private
2110 type=passthrough
2111 left=%defaultroute
2112 leftid=%myid
2113 right=%opportunisticgroup
2114 failureshunt=passthrough
2115 keyingtries=3
2116 ikelifetime=1h
2117 salifetime=1h
2118 rekey=no
2119 auto=route
2120
2121 conn private-or-clear
2122 type=tunnel
2123 left=%defaultroute
2124 leftid=%myid
2125 right=%opportunisticgroup
2126 failureshunt=passthrough
2127 keyingtries=3
2128 ikelifetime=1h
2129 salifetime=1h
2130 rekey=no
2131 auto=route
2132
2133 conn private
2134 type=tunnel
2135 left=%defaultroute
2136 leftid=%myid
2137 right=%opportunisticgroup
2138 failureshunt=drop
2139 keyingtries=3
2140 ikelifetime=1h
2141 salifetime=1h
2142 rekey=no
2143 auto=route
2144
2145 conn block
2146 type=reject
2147 authby=never
2148 left=%defaultroute
2149 right=%group
2150 auto=route
2151
2152
2153 These conns will only work if %defaultroute works. The leftid will be
2154 the interfaces IP address by default, but it can also be set to
2155 %fromcert or use a DNS name.
2156
2158 The optional files under /etc/ipsec.d/policies, including
2159
2160
2161 /etc/ipsec.d/policies/clear
2162 /etc/ipsec.d/policies/clear-or-private
2163 /etc/ipsec.d/policies/private-or-clear
2164 /etc/ipsec.d/policies/private
2165 /etc/ipsec.d/policies/block
2166
2167
2168 may contain policy group configuration information to supplement
2169 ipsec.conf. Their contents are not security-sensitive.
2170
2171 These files are text files. Each consists of a list of CIDR blocks, one
2172 per line. White space followed by # followed by anything to the end of
2173 the line is a comment and is ignored, as are empty lines.
2174
2175 A connection in ipsec.conf that has right=%group or
2176 right=%opportunisticgroup is a policy group connection. When a policy
2177 group file of the same name is loaded at system start, the connection
2178 is instantiated such that each CIDR block serves as an instance's right
2179 value. The system treats the resulting instances as normal connections.
2180
2181 For example, given a suitable connection definition private, and the
2182 file /etc/ipsec.d/policies/private with an entry 192.0.2.3, the system
2183 creates a connection instance private#192.0.2.3. This connection
2184 inherits all details from private, except that its right client is
2185 192.0.2.3.
2186
2188 The standard Libreswan install includes several policy groups which
2189 provide a way of classifying possible peers into IPsec security
2190 classes: private (talk encrypted only), private-or-clear (prefer
2191 encryption), clear-or-private (respond to requests for encryption),
2192 clear and block.
2193
2195 When choosing a connection to apply to an outbound packet caught with a
2196 %trap, the system prefers the one with the most specific eroute that
2197 includes the packet's source and destination IP addresses. Source
2198 subnets are examined before destination subnets. For initiating, only
2199 routed connections are considered. For responding, unrouted but added
2200 connections are considered.
2201
2202 When choosing a connection to use to respond to a negotiation that
2203 doesn't match an ordinary conn, an opportunistic connection may be
2204 instantiated. Eventually, its instance will be /32 -> /32, but for
2205 earlier stages of the negotiation, there will not be enough information
2206 about the client subnets to complete the instantiation.
2207
2209 /etc/ipsec.conf
2210 /etc/ipsec.d/policies/clear
2211 /etc/ipsec.d/policies/clear-or-private
2212 /etc/ipsec.d/policies/private-or-clear
2213 /etc/ipsec.d/policies/private
2214 /etc/ipsec.d/policies/block
2215
2217 ipsec(8), ipsec_auto(8), ipsec_rsasigkey(8)
2218
2220 Designed for the FreeS/WAN project <https://www.freeswan.org> by Henry
2221 Spencer.
2222
2224 Before reporting new bugs, please ensure you are using the latest
2225 version of Libreswan.
2226
2227 When type or failureshunt is set to drop or reject, Libreswan blocks
2228 outbound packets using eroutes, but assumes inbound blocking is handled
2229 by the firewall. Libreswan offers firewall hooks via an “updown”
2230 script. However, the default ipsec _updown provides no help in
2231 controlling a modern firewall.
2232
2233 Including attributes of the keying channel (authentication methods,
2234 ikelifetime, etc.) as an attribute of a connection, rather than of a
2235 participant pair, is dubious and incurs limitations.
2236
2237 The use of %any with the protoport= option is ambiguous. Should the SA
2238 permits any port through or should the SA negotiate any single port
2239 through? The first is a basic conn with a wildcard. The second is a
2240 template. The second is the current behaviour, and it's wrong for quite
2241 a number of uses involving TCP. The keyword %one may be introduced in
2242 the future to separate these two cases.
2243
2244 It would be good to have a line-continuation syntax, especially for the
2245 very long lines involved in RSA signature keys.
2246
2247 The ability to specify different identities, authby, and public keys
2248 for different automatic-keyed connections between the same participants
2249 is misleading; this doesn't work dependably because the identity of the
2250 participants is not known early enough. This is especially awkward for
2251 the “Road Warrior” case, where the remote IP address is specified as
2252 0.0.0.0, and that is considered to be the “participant” for such
2253 connections.
2254
2255 If conns are to be added before DNS is available, left=FQDN,
2256 leftnextop=FQDN, and leftrsasigkey=%dnsonload will fail.
2257 ipsec_pluto(8) does not actually use the public key for our side of a
2258 conn but it isn't generally known at a add-time which side is ours
2259 (Road Warrior and Opportunistic conns are currently exceptions).
2260
2261 The myid option does not affect explicit
2262 ipsec auto --add or ipsec auto --replace commands for implicit conns.
2263
2265 Paul Wouters
2266 documenter
2267
2268
2269
2270libreswan 05/24/2022 IPSEC.CONF(5)