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