1IPSEC.CONF(5) Executable programs IPSEC.CONF(5)
2
6 ipsec.conf - IPsec configuration and connections
7
9 The optional 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.
13 The file is a text file, consisting of one or more sections. White
15 space followed by # followed by anything to the end of the line is a
16 comment and is ignored, as are empty lines which are not within a
17 section.
18 A line which contains include and a file name, separated by white
20 space, is replaced by the contents of that file, preceded and followed
21 by empty lines. If the file name is not a full pathname, it is
22 considered to be relative to the directory containing the including
23 file. Such inclusions can be nested. Only a single filename may be
24 supplied, and it may not contain white space, but it may include shell
25 wildcards (see sh(1)); for example:
26 include /etc/ipsec.d/*.conf
28 The intention of the include facility is mostly to permit keeping
30 information on connections, or sets of connections, separate from the
31 main configuration file. This permits such connection descriptions to
32 be changed, copied to the other security gateways involved, etc.,
33 without having to constantly extract them from the configuration file
34 and then insert them back into it. Note also the also and alsoflip
35 parameters (described below) which permit splitting a single logical
36 section (e.g. a connection description) into several actual sections.
37 The first significant line of the file may specify a version of this
39 specification for backwards compatibility with freeswan and openswan.
40 It is ignored and unused. For compatibility with openswan, specify:
41 version 2
43 A section begins with a line of the form:
45 type name
47 where type indicates what type of section follows, and name is an
49 arbitrary name which distinguishes the section from others of the same
50 type. (Names must start with a letter and may contain only letters,
51 digits, periods, underscores, and hyphens.) All subsequent non-empty
52 lines which begin with white space are part of the section; comments
53 within a section must begin with white space too. There may be only one
54 section of a given type with a given name.
55 Lines within the section are generally of the form
57 parameter=value
59 (note the mandatory preceding white space). There can be white space on
61 either side of the =. Parameter names follow the same syntax as section
62 names, and are specific to a section type. Unless otherwise explicitly
63 specified, no parameter name may appear more than once in a section.
64 An empty value stands for the system default value (if any) of the
66 parameter, i.e. it is roughly equivalent to omitting the parameter line
67 entirely. A value may contain white space only if the entire value is
68 enclosed in double quotes ("); a value cannot itself contain a double
69 quote, nor may it be continued across more than one line.
70 Numeric values are specified to be either an “integer” (a sequence of
72 digits) or a “decimal number” (sequence of digits optionally followed
73 by `.´ and another sequence of digits).
74 There is currently one parameter which is available in any type of
76 section:
77 also
79 the value is a section name; the parameters of that section are
80 appended to this section, as if they had been written as part of
81 it. The specified section must exist, must follow the current one,
82 and must have the same section type. (Nesting is permitted, and
83 there may be more than one also in a single section, although it is
84 forbidden to append the same section more than once.) This allows,
85 for example, keeping the encryption keys for a connection in a
86 separate file from the rest of the description, by using both an
87 also parameter and an include line. (Caution, see BUGS below for
88 some restrictions.)
89 alsoflip
91 can be used in a conn section. It acts like an also that flips the
92 referenced section´s entries left-for-right.
93 Parameter names beginning with x- (or X-, or x_, or X_) are reserved
95 for user extensions and will never be assigned meanings by IPsec.
96 Parameters with such names must still observe the syntax rules (limits
97 on characters used in the name; no white space in a non-quoted value;
98 no newlines or double quotes within the value). All other as-yet-unused
99 parameter names are reserved for future IPsec improvements.
100 A section with name %default specifies defaults for sections of the
102 same type. For each parameter in it, any section of that type which
103 does not have a parameter of the same name gets a copy of the one from
104 the %default section. There may be multiple %default sections of a
105 given type, but only one default may be supplied for any specific
106 parameter name, and all %default sections of a given type must precede
107 all non-%default sections of that type. %default sections may not
108 contain also or alsoflip parameters.
109 Currently there are two types of section: a config section specifies
111 general configuration information for IPsec, while a conn section
112 specifies an IPsec connection.
113
115 A conn section contains a connection specification, defining a network
116 connection to be made using IPsec. The name given is arbitrary, and is
117 used to identify the connection to ipsec_auto(8) Here´s a simple
118 example:
119 conn snt
122 left=10.11.11.1
123 leftsubnet=10.0.1.0/24
124 leftnexthop=172.16.55.66
125 leftsourceip=10.0.1.1
126 right=192.168.22.1
127 rightsubnet=10.0.2.0/24
128 rightnexthop=172.16.88.99
129 rightsourceip=10.0.2.1
130 keyingtries=%forever
131 A note on terminology... In automatic keying, there are two kinds of
133 communications going on: transmission of user IP packets, and
134 gateway-to-gateway negotiations for keying, rekeying, and general
135 control. The data path (a set of “IPsec SAs”) used for user packets is
136 herein referred to as the “connection”; the path used for negotiations
137 (built with “ISAKMP SAs”) is referred to as the “keying channel”.
138 To avoid trivial editing of the configuration file to suit it to each
140 system involved in a connection, connection specifications are written
141 in terms of left and right participants, rather than in terms of local
142 and remote. Which participant is considered left or right is arbitrary;
143 IPsec figures out which one it is being run on based on internal
144 information. This permits using identical connection specifications on
145 both ends. There are cases where there is no symmetry; a good
146 convention is to use left for the local side and right for the remote
147 side (the first letters are a good mnemonic).
148 Many of the parameters relate to one participant or the other; only the
150 ones for left are listed here, but every parameter whose name begins
151 with left has a right counterpart, whose description is the same but
152 with left and right reversed.
153 Parameters are optional unless marked “(required)”
155 CONN PARAMETERS: GENERAL
157 The following parameters are relevant to IKE automatic keying. Unless
158 otherwise noted, for a connection to work, in general it is necessary
159 for the two ends to agree exactly on the values of these parameters.
160 connaddrfamily
162 the connection address family of the connection; currently the
163 accepted values are ipv4 (the default); or ipv6. This option is
164 confusing, especially when doing IPv4-in-IPv6 or IPv6-in-IPv4
165 tunnels. The developers hope to remove this option in the near
166 future for proper auto-detection. For now, set connaddrfamily= to
167 the family of the *subnet= options, and if those are not defined,
168 to the family of the left=/right= options.
169 IPv6 is supported with NETKEY and with KLIPS in all Libreswan
171 versions
172 type
174 the type of the connection; currently the accepted values are
175 tunnel (the default) signifying a host-to-host, host-to-subnet, or
176 subnet-to-subnet tunnel; transport, signifying host-to-host
177 transport mode; passthrough, signifying that no IPsec processing
178 should be done at all; drop, signifying that packets should be
179 discarded; and reject, signifying that packets should be discarded
180 and a diagnostic ICMP returned.
181 left
183 (required) the IP address of the left participant´s public-network
184 interface, in any form accepted by ipsec_ttoaddr(3). Currently,
185 IPv4 and IPv6 IP addresses are supported. There are several magic
186 values. If it is %defaultroute, and the config setup section´s,
187 interfaces specification contains %defaultroute, left will be
188 filled in automatically with the local address of the default-route
189 interface (as determined at IPsec startup time); this also
190 overrides any value supplied for leftnexthop. (Either left or right
191 may be %defaultroute, but not both.) The value %any signifies an
192 address to be filled in (by automatic keying) during negotiation.
193 The value %opportunistic signifies that both left and leftnexthop
194 are to be filled in (by automatic keying) from DNS data for left´s
195 client. The value can also contain the interface name, which will
196 then later be used to obtain the IP address from to fill in. For
197 example %ppp0 The values %group and %opportunisticgroup makes this
198 a policy group conn: one that will be instantiated into a regular
199 or opportunistic conn for each CIDR block listed in the policy
200 group file with the same name as the conn.
201 If using IP addresses in combination with NAT, always use the
203 actual local machine´s (NATed) IP address, and if the remote (eg
204 right=) is NATed as well, the remote´s public (not NATed) IP
205 address. Note that this makes the configuration no longer
206 symmetrical on both sides, so you cannot use an identical
207 configuration file on both hosts.
208 leftsubnet
210 private subnet behind the left participant, expressed as
211 network/netmask (actually, any form acceptable to
212 ipsec_ttosubnet(3)); Currently, IPv4 and IPv6 ranges are supported.
213 if omitted, essentially assumed to be left/32, signifying that the
214 left end of the connection goes to the left participant only
215 It supports two magic shorthands vhost: and vnet:, which can list
217 subnets in the same syntax as virtual-private. The value %priv
218 expands to the networks specified in virtual-private. The value %no
219 means no subnet. A common use for allowing roadwarriors to come in
220 on public IPs or via accepted NATed networks from RFC1918 is to use
221 leftsubnet=vhost:%no,%priv. The vnet: option can be used to allow
222 RFC1918 subnets without hardcoding them. When using vnet the
223 connection will instantiate, allowing for multiple tunnels with
224 different subnets.
225 leftsubnets
227 specify multiple private subnets behind the left participant,
228 expressed as { networkA/netmaskA networkB/netmaskB [...] } If both
229 a leftsubnets= and rightsubnets= are defined, all combinations of
230 subnet tunnels will be established as IPsec tunnels. You cannot use
231 leftsubnet= and leftsubnets= together. For examples see
232 testing/pluto/multinet-*.
233 leftaddresspool
235 address pool from with the XAUTH server can assign IP addresses to
236 clients. When configured as an XAUTH server, using
237 leftxauthserver=yes this option specifies the address pool from
238 which IP addresses are taken to assign the the XAUTH clients. The
239 syntax of the address pool specifies a range (not a CIDR), in the
240 following syntax: rightaddresspool=192.168.1.100-192.168.1.200.
241 Generally, the rightaddresspool= option will be accompanied by
242 rightxauthclient=yes, leftxauthserver=yes and leftsubnet=0.0.0.0/0
243 option.
244 When leftaddresspool= is specified, the connection may not specify
246 either leftsubnet= or leftsubnets=. Address pools are fully
247 allocated when the connection is loaded, so the ranges should be
248 sane. For example, specifying a range
249 rightaddresspool=10.0.0.0-11.0.0.0 will lead to massive memory
250 allocation. Address pools specifying the exact same range are
251 shared between different connections. Different addresspools should
252 not be defined to partially overlap.
253 leftprotoport
255 allowed protocols and ports over connection, also called Port
256 Selectors. The argument is in the form protocol, which can be a
257 number or a name that will be looked up in /etc/protocols, such as
258 leftprotoport=icmp, or in the form of protocol/port, such as
259 tcp/smtp. Ports can be defined as a number (eg. 25) or as a name
260 (eg smtp) which will be looked up in /etc/services. A special
261 keyword %any can be used to allow all ports of a certain protocol.
262 The most common use of this option is for L2TP connections to only
263 allow l2tp packets (UDP port 1701), eg: leftprotoport=17/1701.
264 To filter on specific icmp type and code, use the higher 8 bits for
266 type and the lower 8 bits for port. For example, to allow icmp echo
267 packets (type 8, code 0) the ´port´ would be 0x0800, or 2048 in
268 decimal, so you configure leftprotoport=icmp/2048. Similarly, to
269 allow ipv6-icmp Neighbour Discovery which has type 136 (0x88) and
270 code 0(0x00) this becomes 0x8800 or in decimal 34816 resulting in
271 leftprotoport=ipv6-icmp/34816 .
272 Some clients, notably older Windows XP and some Mac OSX clients,
274 use a random high port as source port. In those cases
275 rightprotoport=17/%any can be used to allow all UDP traffic on the
276 connection. Note that this option is part of the proposal, so it
277 cannot be arbitrarily left out if one end does not care about the
278 traffic selection over this connection - both peers have to agree.
279 The Port Selectors show up in the output of ipsec eroute and ipsec
280 auto --status eg:"l2tp":
281 193.110.157.131[@aivd.libreswan.org]:7/1701...%any:17/1701 This
282 option only filters outbound traffic. Inbound traffic selection
283 must still be based on firewall rules activated by an updown
284 script. The variables $PLUTO_MY_PROTOCOL, $PLUTO_PEER_PROTOCOL,
285 $PLUTO_MY_PORT, and $PLUTO_PEER_PORT are available for use in
286 updown scripts. Older workarounds for bugs involved a setting of
287 17/0 to denote any single UDP port (not UDP port 0). Some clients,
288 most notably OSX, uses a random high port, instead of port 1701 for
289 L2TP.
290 leftnexthop
292 next-hop gateway IP address for the left participant´s connection
293 to the public network; defaults to %direct (meaning right). If the
294 value is to be overridden by the left=%defaultroute method (see
295 above), an explicit value must not be given. If that method is not
296 being used, but leftnexthop is %defaultroute, and
297 interfaces=%defaultroute is used in the config setup section, the
298 next-hop gateway address of the default-route interface will be
299 used. The magic value %direct signifies a value to be filled in (by
300 automatic keying) with the peer´s address. Relevant only locally,
301 other end need not agree on it.
302 leftsourceip
304 the IP address for this host to use when transmitting a packet to
305 the other side of this link. Relevant only locally, the other end
306 need not agree. This option is used to make the gateway itself use
307 its internal IP, which is part of the leftsubnet, to communicate to
308 the rightsubnet or right. Otherwise, it will use its nearest IP
309 address, which is its public IP address. This option is mostly used
310 when defining subnet-subnet connections, so that the gateways can
311 talk to each other and the subnet at the other end, without the
312 need to build additional host-subnet, subnet-host and host-host
313 tunnels. Both IPv4 and IPv6 addresses are supported.
314 leftupdown
316 what “updown” script to run to adjust routing and/or firewalling
317 when the status of the connection changes (default ipsec _updown).
318 May include positional parameters separated by white space
319 (although this requires enclosing the whole string in quotes);
320 including shell metacharacters is unwise. An example to enable
321 routing when using the NETKEY stack, one can use:
322 leftupdown="ipsec _updown --route yes"
324 See ipsec_pluto(8) for details. Relevant only locally, other end
326 need not agree on it.
327 leftfirewall
329 This option is obsolete and should not used anymore.
330 If one or both security gateways are doing forwarding firewalling
332 (possibly including masquerading), and this is specified using the
333 firewall parameters, tunnels established with IPsec are exempted from
334 it so that packets can flow unchanged through the tunnels. (This means
335 that all subnets connected in this manner must have distinct,
336 non-overlapping subnet address blocks.) This is done by the default
337 updown script (see ipsec_pluto(8)).
338 The implementation of this makes certain assumptions about firewall
340 setup, and the availability of the Linux Advanced Routing tools. In
341 situations calling for more control, it may be preferable for the user
342 to supply his own updown script, which makes the appropriate
343 adjustments for his system.
344 CONN PARAMETERS: AUTOMATIC KEYING
346 The following parameters are relevant to automatic keying via IKE.
347 Unless otherwise noted, for a connection to work, in general it is
348 necessary for the two ends to agree exactly on the values of these
349 parameters.
350 auto
352 what operation, if any, should be done automatically at IPsec
353 startup; currently-accepted values are add (signifying an ipsec
354 auto --add), ondemand (signifying that plus an ipsec auto
355 --ondemand), start (signifying that plus an ipsec auto --up), and
356 ignore (also the default) (signifying no automatic startup
357 operation). See the config setup discussion below. Relevant only
358 locally, other end need not agree on it (but in general, for an
359 intended-to-be-permanent connection, both ends should use
360 auto=start to ensure that any reboot causes immediate
361 renegotiation).
362 The option ondemand used to be called route
364 authby
366 how the two security gateways should authenticate each other;
367 acceptable values are rsasig (the default) for RSA digital
368 signatures based authentication, secret for shared secrets (PSK)
369 authentication, secret|rsasig for either, never if negotiation is
370 never to be attempted or accepted (useful for shunt-only conns),
371 and null for null-authentication.
372 Digital signatures are superior in every way to shared secrets.
374 Especially IKEv1 in Aggressive Mode is vulnerable to offline
375 dictionary attacks and is performed routinely by at least the NSA
376 on monitored internet traffic globally. The never option is only
377 used for connections that do not actually start an IKE negotiation,
378 such as type=passthrough connections. The auth method null is used
379 for "anonymous opportunistic IPsec" and should not be used for
380 regular pre-configured IPsec VPNs.
381 ike
383 IKE encryption/authentication algorithm to be used for the
384 connection (phase 1 aka ISAKMP SA). The format is
385 "cipher-hash;modpgroup, cipher-hash;modpgroup, ..." Any left out
386 option will be filled in with all allowed default options. Multiple
387 proposals are separated by a comma. If an ike= line is specified,
388 no other received proposals will be accepted. Formerly there was a
389 distinction (by using a "!" symbol) between "strict mode" or not.
390 That mode has been obsoleted. If an ike= option is specified, the
391 mode is always strict, meaning no other received proposals will be
392 accepted. Some examples are ike=3des-sha1,aes-sha1, ike=aes,
393 ike=aes_ctr, ike=aes_gcm256-sha2, ike=aes128-md5;modp2048,
394 ike=aes128-sha1;dh22, ike=3des-md5;modp1024,aes-sha1;modp1536. The
395 options must be suitable as a value of ipsec_spi(8)´s --ike option.
396 The default is to use IKE, and to allow all combinations of:
397 cipher: 3des or aes128 or aes256
399 hash: sha1 or md5
400 pfsgroup (DHgroup): modp1024 or modp1536 or modp2048
401 Note that AES-GCM is an AEAD algorithm, meaning that it performs
403 encryption+authentication in one step. This means that AES-GCM must
404 not specify an authentication algorithm. However, it does require a
405 PRF function, so the second argument to an AEAD algorithm denotes
406 the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with no
407 authentication and using SHA2 as the prf. Note that for phase2alg,
408 there is no prf, so AES-GCM is specified for ESP as
409 phase2alg=aes_gcm-null. The AES-GCM and AES-CCM algorithms support
410 8,12 and 16 byte ICV´s. These can be specified using a postfix, for
411 example aes_gcm_a (for 8), aes_gcm_b (for 12) and aes_gcm_c (for
412 16). The default (aes_gcm without postfix) refers to the 16 byte
413 ICV version. It is strongly recommended to NOT use the 8 or 12 byte
414 versions of GCM or CCM.
415 Weak algorithms are regularly removed from libreswan. Currently,
417 1DES and modp768 have been removed and modp1024 will be removed in
418 the near future. Additionally, md5 and sha1 will be removed within
419 the next few years. Null encryption is available, and should only
420 be used for testing or benchmarking purposes. Please do not request
421 for insecure algorithms to be re-added to libreswan.
422 Diffie-Hellman groups 22, 23 and 24 are also implemented as per
424 RFC-5114. Instead of the modp key syntax, use the "dh" keyword, for
425 example ike=3des-sha1;dh23
426 The modp syntax will be removed in favour of the dh syntax.
428 phase2
430 Sets the type of SA that will be produced. Valid options are: esp
431 for encryption (the default), ah for authentication only.
432 The very first IPsec designs called for use of AH plus ESP to offer
434 authentication, integrity and confidentiality. That dual protocol
435 use was a significant burden, so ESP was extended to offer all
436 three services, and AH remained as an auth/integ. Only broken
437 configurations (often used with racoon) require the strange double
438 authentication using ah+esp. Additionally, AH does not play well
439 with NATs, so it is strongly recommended to use ESP with the null
440 cipher if you require unencrypted authenticated transport.
441 phase2alg
443 Specifies the algorithms that will be offered/accepted for a phase2
444 negotiation. If not specified, a secure set of defaults will be
445 used. Sets are separated using comma´s.
446 The default values are the same as for ike= Note also that not all
448 ciphers available to the kernel (eg through CryptoAPI) are
449 necessarily supported here.
450 The format for ESP is ENC-AUTH followed by an optional PFSgroup.
452 For instance, "3des-md5" or "aes256-sha1;modp2048" or
453 "aes-sha1,aes-md5".
454 For RFC-5114 DH groups, use the "dh" keyword, eg "aes256-sha1;dh23"
456 The format for AH is AUTH followed by an optional PFSgroup. For
458 instance, "md5" or "sha1;modp1536".
459 AEAD algorithms such as AES-GCM and AES-CCM require null for the
461 authentication algorithm, for example phase2alg=aes_ccm-null or
462 phase2alg=aes_gcm-null. Note that the ike= syntax for aes_gcm does
463 not specify a null authentication but specifies the prf instead.
464 The supported key sizes are 128, 192 and 256, which are specified
465 similarly to plain aes, i.e. phase2alg=aes_gcm256. A subscript of
466 _c, _b or _a can be used to refer to the different ICV variants
467 where a means 8 bytes, b means 12 bytes and c means 16 bytes. The
468 default when not using a subscript is the 16 byte ICV, the
469 recommended value by RFC-4106. Therefor phase2alg=aes_gcm256-null
470 is equivalent to phase2alg=aes_gcm_c256-null. It is recommended to
471 migrate to the _c versions (without specifying _c), as support for
472 smaller ICV´s might be removed in the near future.
473 The supported algorithms depend on the libreswan version, OS and
475 kernel stack used. Possible ciphers are aes, 3des, aes_ctr,
476 aes_gcm, aes_ccm, camellia, serpent and twofish.
477 Note that openswan and versions of libreswan up to 3.6 require
479 manually adding the salt size to the key size. Therefor, to
480 configure an older version of openswan or libreswan, use:
481 "phase2alg=aes_ccm_c-280-null" to interop with a new libreswan
482 using "phase2alg=aes_ccm256". For CCM, the ´keysize´ needs to be
483 increased by 24, resulted in valid keysizes of 152, 215 and 280.
484 For GCM the ´keysize´ needs to be increased by 32, resulting valid
485 ´keysizes´ of 160, 224 and 288.
486 sha2-truncbug
488 The default ESP hash truncation for sha2_256 is 128 bits. Some
489 IPsec implementations (Linux before 2.6.33, some Cisco (2811?)
490 routers) implement the draft version which stated 96 bits. If a
491 draft implementation communicates with an RFC implementation, both
492 ends will reject encrypted packets from each other.
493 This option enables using the draft 96 bits version to interop with
495 those implementations. Currently the accepted values are no, (the
496 default) signifying default RFC truncation of 128 bits, or yes,
497 signifying the draft 96 bits truncation.
498 Another workaround is to switch from sha2_256 to sha2_128 or
500 sha2_512.
501 nat-ikev1-method
503 NAT Traversal in IKEv1 is negotiated via Vendor ID options as
504 specified in RFC 3947. However, many implementations only support
505 the draft version of the RFC. Libreswan sends both the RFC and the
506 most common draft versions (02, 02_n and 03) to maximize
507 interoperability. Unfortunately, there are known broken
508 implementations of RFC 3947, notably Cisco routers that have not
509 been updated to the latest firmware. As the NAT-T payload is sent
510 in the very first packet of the initiator, there is no method to
511 auto-detect this problem and initiate a workaround.
512 This option allows fine tuning which of the NAT-T payloads to
514 consider for sending and processing. Currently the accepted values
515 are drafts, rfc or both (the default). To interoperate with known
516 broken devices, use nat-ikev1-method=drafts.
517 esp
519 This option is obsolete. Please use phase2alg instead.
520 ah
522 AH authentication algorithm to be used for the connection, e.g
523 here. hmac-md5 The options must be suitable as a value of
524 ipsec_spi(8)´s --ah option. The default is not to use AH. If for
525 some (invalid) reason you still think you need AH, please use esp
526 with the null encryption cipher instead. Note also that not all
527 ciphers available to the kernel (eg through CryptoAPI) are
528 necessarily supported here.
529 fragmentation
531 Whether or not to allow IKE fragmentation. Valid values are are
532 yes, (the default), no or force.
533 IKEv1 fragmentation capabilities are negotiated via a well-known
535 private vendor id. IKEv2 fragmentation support is implemented using
536 RFC 7383. If pluto does not receive the fragmentation payload, no
537 IKE fragments will be sent, regardless of the fragmentation=
538 setting. When set to yes, IKE fragmentation will be attempted on
539 the first re-transmit of an IKE packet of a size larger then 576
540 bytes for IPv4 and 1280 bytes for IPv6. If fragmentation is set to
541 force, IKE fragmentation is used on initial transmits of such sized
542 packets as well. When we have received IKE fragments for a
543 connection, pluto behaves as if in force mode.
544 ikepad
546 Whether or not to pad IKEv1 messages to a multiple of 4 bytes.
547 Valid values are are yes, (the default) and no.
548 IKE padding is allowed in IKEv1 but it is known to cause
550 interoperability issues. The ikepad= option can be used to disable
551 IKEv1 padding. This is required for some devices (such as
552 Checkpoint in Aggressive Mode) that reject padded IKEv1 packets. In
553 IKEv2, no padding is allowed, and this option has no effect. If you
554 find a device that seems to require IKE padding in IKEv2, please
555 contact the libreswan developers. This option should almost never
556 be enabled.
557 ikev2
559 IKEv2 (RFC4309) settings to be used. Currently the accepted values
560 are permit, (the default) signifying no IKEv2 should be
561 transmitted, but will be accepted if the other ends initiates to us
562 with IKEv2; never or no signifying no IKEv2 negotiation should be
563 transmitted or accepted; propose or yes signifying that we permit
564 IKEv2, and also use it as the default to initiate; insist,
565 signifying we only accept and receive IKEv2 - IKEv1 negotiations
566 will be rejected.
567 If the ikev2= setting is set to permit or propose, Libreswan will
569 try and detect a "bid down" attack from IKEv2 to IKEv1. Since there
570 is no standard for transmitting the IKEv2 capability with IKEv1,
571 Libreswan uses a special Vendor ID "CAN-IKEv2". If a fall back from
572 IKEv2 to IKEv1 was detected, and the IKEv1 negotiation contains
573 Vendor ID "CAN-IKEv2", Libreswan will immediately attempt and IKEv2
574 rekey and refuse to use the IKEv1 connection. With an ikev2=
575 setting of insist, no IKEv1 negotiation is allowed, and no bid down
576 attack is possible.
577 narrowing
579 IKEv2 (RFC5996) Section 2.9 Traffic Selector narrowing options.
580 Currently the accepted values are no, (the default) signifying no
581 narrowing will be proposed or accepted, or yes, signifying IKEv2
582 negotiation may allow establishing an IPsec connection with
583 narrowed down traffic selectors. This option is ignored for IKEv1.
584 There are security implications in allowing narrowing down the
586 proposal. For one, what should be done with packets that we hoped
587 to tunnel, but cannot. Should these be dropped or send in the
588 clear? Second, this could cause thousands of narrowed down Child
589 SAs to be created if the conn has a broad policy (eg 0/0 to 0/0).
590 One possible good use case scenario is that a remote end (that you
591 fully trust) allows you to define a 0/0 to them, while adjusting
592 what traffic you route via them, and what traffic remains outside
593 the tunnel. However, it is always preferred to setup the exact
594 tunnel policy you want, as this will be much clearer to the user.
595 sareftrack
597 Set the method of tracking reply packets with SArefs when using an
598 SAref compatible stack. Currently only the mast stack supports
599 this. Acceptable values are yes (the default), no or conntrack.
600 This option is ignored when SArefs are not supported. This option
601 is passed as PLUTO_SAREF_TRACKING to the updown script which makes
602 the actual decisions whether to perform any iptables/ip_conntrack
603 manipulation. A value of yes means that an IPSEC mangle table will
604 be created. This table will be used to match reply packets. A value
605 of conntrack means that additionally, subsequent packets using this
606 connection will be marked as well, reducing the lookups needed to
607 find the proper SAref by using the ip_conntrack state. A value of
608 no means no IPSEC mangle table is created, and SAref tracking is
609 left to a third-party (kernel) module. In case of a third party
610 module, the SArefs can be relayed using the statsbin= notification
611 helper.
612 leftid
614 how the left participant should be identified for authentication;
615 defaults to left. Can be an IP address (in any ipsec_ttoaddr(3)
616 syntax) or a fully-qualified domain name which will be resolved. If
617 preceded by @, the value is used as a literal string and will not
618 be resolved. To support opaque identifiers (usually of type
619 ID_KEY_ID, such as used by Cisco to specify Group Name, use square
620 brackets, eg rightid=@[GroupName]. The magic value %fromcert causes
621 the ID to be set to a DN taken from a certificate that is loaded.
622 Prior to 2.5.16, this was the default if a certificate was
623 specified. The magic value %none sets the ID to no ID. This is
624 included for completeness, as the ID may have been set in the
625 default conn, and one wishes for it to default instead of being
626 explicitly set. The magic value %myid stands for the current
627 setting of myid. This is set in config setup or by ipsec_whack(8)),
628 or, if not set, it is the IP address in %defaultroute (if that is
629 supported by a TXT record in its reverse domain), or otherwise it
630 is the system´s hostname (if that is supported by a TXT record in
631 its forward domain), or otherwise it is undefined.
632 When using certificate based ID´s, one need to specify the full
634 RDN, optionally using wildcard matching (eg CN=´*´). If the RDN
635 contains a comma, this can be masked using a comma (eg OU=´Foo,,
636 Bar and associates´)
637 leftrsasigkey
639 the left participant´s public key for RSA signature authentication,
640 in RFC 2537 format using ipsec_ttodata(3) encoding. The magic value
641 %none means the same as not specifying a value (useful to override
642 a default). The value %dnsondemand (the default) means the key is
643 to be fetched from DNS at the time it is needed. The value
644 %dnsonload means the key is to be fetched from DNS at the time the
645 connection description is read from ipsec.conf; currently this will
646 be treated as %none if right=%any or right=%opportunistic. The
647 value %dns is currently treated as %dnsonload but will change to
648 %dnsondemand in the future. The identity used for the left
649 participant must be a specific host, not %any or another magic
650 value. The value %cert will load the information required from a
651 certificate defined in %leftcert and automatically define leftid
652 for you. Caution: if two connection descriptions specify different
653 public keys for the same leftid, confusion and madness will ensue.
654 leftrsasigkey2
656 if present, a second public key. Either key can authenticate the
657 signature, allowing for key rollover.
658 leftcert
660 If you are using leftrsasigkey=%cert this defines the certificate
661 nickname of your certificate in the NSS database. This can be on
662 software or hardware security device.
663 leftca
665 specifies the authorized Certificate Authority (CA) that signed the
666 certificate of the peer. If undefined, it defaults to the CA that
667 signed the certificate specified in leftcert. The special
668 rightca=%same is implied when not specifying a rightca and means
669 that only peers with certificates signed by the same CA as the
670 leftca will be allowed. This option is only useful in complex multi
671 CA certificate situations. When using a single CA, it can be safely
672 omitted for both left and right.
673 leftsendcert
675 This option configures when Libreswan will send X.509 certificates
676 to the remote host. Acceptable values are yes|always (signifying
677 that we should always send a certificate), sendifasked (signifying
678 that we should send a certificate if the remote end asks for it),
679 and no|never (signifying that we will never send a X.509
680 certificate). The default for this option is sendifasked which may
681 break compatibility with other vendor´s IPsec implementations, such
682 as Cisco and SafeNet. If you find that you are getting errors about
683 no ID/Key found, you likely need to set this to always. This
684 per-conn option replaces the obsolete global nocrsend option.
685 leftxauthserver
687 Left is an XAUTH server. This can use PAM for authentication or md5
688 passwords in /etc/ipsec.d/passwd. These are additional credentials
689 to verify the user identity, and should not be confused with the
690 XAUTH group secret, which is just a regular PSK defined in
691 ipsec.secrets. The other side of the connection should be
692 configured as rightxauthclient. XAUTH connections cannot rekey, so
693 rekey=no should be specified in this conn. For further details on
694 how to compile and use XAUTH, see README.XAUTH. Acceptable values
695 are yes or no (the default).
696 leftxauthclient
698 Left is an XAUTH client. The xauth connection will have to be
699 started interactively and cannot be configured using auto=start.
700 Instead, it has to be started from the commandline using ipsec auto
701 --up connname. You will then be prompted for the username and
702 password. To setup an XAUTH connection non-interactively, which
703 defeats the whole purpose of XAUTH, but is regularly requested by
704 users, it is possible to use a whack command - ipsec whack --name
705 baduser --ipsecgroup-xauth --xauthname badusername --xauthpass
706 password --initiate The other side of the connection should be
707 configured as rightxauthserver. Acceptable values are yes or no
708 (the default).
709 leftxauthusername
711 The XAUTH username associated with this XAUTH connection. The XAUTH
712 password can be configured in the ipsec.secrets file.
713 leftmodecfgserver
715 Left is a Mode Config server. It can push network configuration to
716 the client. Acceptable values are yes or no (the default).
717 leftmodecfgclient
719 Left is a Mode Config client. It can receive network configuration
720 from the server. Acceptable values are yes or no (the default).
721 xauthby
723 When IKEv1 XAUTH support is available, set the method used by XAUTH
724 to authenticate the user with IKEv1. The currently supported values
725 are file (the default), pam or alwaysok. The password file is
726 located at /etc/ipsec.d/passwd, and follows a syntax similar to the
727 Apache htpasswd file, except an additional connection name argument
728 (and optional static IP address) are also present:
729 username:password:conname:ipaddress
731 For supported password hashing methods, see crypt(3). If pluto is
733 running in FIPS mode, some hash methods, such as MD5, might not be
734 available. Threads are used to launch an xauth authentication
735 helper for file as well as PAM methods.
736 The alwaysok should only be used if the XAUTH user authentication
738 is not really used, but is required for interoperability, as it
739 defeats the whole point of XAUTH which is to rely on a secret only
740 known by a human. See also pam-authorize=yes
741 xauthfail
743 When XAUTH support is available, set the failure method desired
744 when authentication has failed. The currently supported values are
745 hard (the default) and soft. A soft failure means the IPsec SA is
746 allowed to be established, as if authentication had passed
747 successfully, but the XAUTH_FAILED environment variable will be set
748 to 1 for the updown script, which can then be used to redirect the
749 user into a walled garden, for example a payment portal.
750 pam-authorize
752 IKEv1 supports PAM authorization via XAUTH using xauthby=pam. IKEv2
753 does not support receiveing a plaintext username and password.
754 Libreswan does not yet support EAP authentication methods for IKE.
755 The pam-authorize=yes option performs an authorization call via
756 PAM, but only includes the remote ID (not username or password).
757 This allows for backends to disallow an ID based on non-password
758 situations, such as "user disabled" or "user over quota". See also
759 xauthby=pam
760 modecfgpull
762 Pull the Mode Config network information from the server.
763 Acceptable values are yes or no (the default).
764 modecfgdns1, modecfgdns2, modecfgdomain, modecfgbanner
766 When configured as modecfg server, specifying any of these options
767 will cause those options and values to be sent to the modecfg
768 client during the XAUTH+ModeCFG phase (phase 1.5).
769 When we are an XAUTH client, these options will be treated as
771 defaults. If the remote XAUTH server did not pass us one of these
772 options, the configured defaults are used to reconfigure the local
773 DNS setup.
774 The split tunneling directive will be sent automatically if the
776 xauth server side has configured a network other than 0.0.0.0/0
777 remote-peer-type
779 Set the remote peer type. This can enable additional processing
780 during the IKE negotiation. Acceptable values are cisco or ietf
781 (the default). When set to cisco, support for Cisco IPsec gateway
782 redirection and Cisco obtained DNS and domainname are enabled. This
783 includes automatically updating (and restoring) /etc/resolv.conf.
784 These options require that XAUTH is also enabled on this
785 connection.
786 nm-configured
788 Mark this connection as controlled by Network Manager. Acceptable
789 values are yes or no (the default). Currently, setting this to yes
790 will cause libreswan to skip reconfiguring resolv.conf when used
791 with XAUTH and ModeConfig.
792 forceencaps
794 In some cases, for example when ESP packets are filtered or when a
795 broken IPsec peer does not properly recognise NAT, it can be useful
796 to force RFC-3948 encapsulation. forceencaps=yes forces the NAT
797 detection code to lie and tell the remote peer that RFC-3948
798 encapsulation (ESP in UDP port 4500 packets) is required.
799 Acceptable values are yes or no (the default).
800 nat-keepalive
802 whether to send any NAT-T keep-alives. These one byte packets are
803 send to prevent the NAT router from closing its port when there is
804 not enough traffic on the IPsec connection. Acceptable values are:
805 yes (the default) and no.
806 initial-contact
808 whether to send an INITIAL_CONTACT payload to the peer we are
809 initiating to, if we currently have no IPsec SAs up with that peer.
810 Acceptable values are: no (the default) and yes. It is recommended
811 to leave this option unset, unless the remote peer requires it to
812 allow reconnects. The only known peer at this time is Cisco, which
813 will not allow a reconnect (despite authentication) to replace an
814 existing IPsec SA unless it receives an INITIAL_CONTACT payload.
815 Receiving this payload is ignored and the choice to replace or add
816 an IPsec SA when libreswan is a responder is purely based on the
817 uniqueids setting, which should be left enabled unless libreswan
818 acts as an XAUTH server using PSK ("group secret"). This option can
819 cause a few seconds of downtime on the IPsec tunnel between the
820 time the remote clears the old IPsec SA in response to our
821 INITIAL_CONTACT message, and the time we finish setting up the new
822 IPsec SA. If there is an XAUTH step in between, and especially when
823 XAUTH requires the use of some two-factor token, this downtime
824 could be even longer.
825 cisco-unity
827 whether to send a CISCO_UNITY payload to the peer. Acceptable
828 values are: no (the default) and yes. It is recommended to leave
829 this option unset, unless the remote peer (Cisco client or server)
830 requires it. This option does not modify local behaviour. It can be
831 needed to connect as a client to a Cisco server. It can also be
832 needed to act as a server for a Cisco client, which otherwise might
833 send back an error DEL_REASON_NON_UNITY_PEER.
834 send-vendorid
836 whether to send our Vendor ID during IKE. Acceptable values are: no
837 (the default) and yes. The vendor id sent can be configured using
838 the "config setup" option myvendorid=. It defaults to
839 OE-Libreswan-VERSION.
840 Vendor ID´s can be useful in tracking interoperability problems.
842 However, specific vendor identification and software versions can
843 be useful to an attacker when there are known vulnerabilities to a
844 specific vendor/version.
845 The prefix OE stands for "Opportunistic Encryption". This prefix
847 was historically used by The FreeS/WAN Project and The Openswan
848 Project (openswan up to version 2.6.38) and in one Xeleranized
849 openswan versions (2.6.39). Further Xeleranized openswan´s use the
850 prefix OSW.
851 overlapip
853 a boolean (yes/no) that determines, when *subnet=vhost: is used, if
854 the virtual IP claimed by this states created from this connection
855 can with states created from other connections.
856 Note that connection instances created by the Opportunistic
858 Encryption or PKIX (x.509) instantiation system are distinct
859 internally. They will inherit this policy bit.
860 The default is no.
862 This feature is only available with kernel drivers that support SAs
864 to overlapping conns. At present only the (klips) mast protocol
865 stack supports this feature.
866 reqid
868 a unique identifier used to match IPsec SAs using iptables with
869 NETKEY/XFRM. This identifier is normally automatically allocated in
870 groups of 4. It is exported to the _updown script as REQID. On
871 Linux, reqids are supported with IP Connection Tracking and NAT
872 (iptables). Automatically generated values use the range 16380 and
873 higher. Manually specified reqid values therefor must be between 1
874 and 16379.
875 Automatically generated reqids use a range of 0-3 (eg 16380-16383
877 for the first reqid). These are used depending on the exact policy
878 (AH, AH+ESP, IPCOMP, etc). Manually assigned reqids are all
879 identical. Instantiations of connections (those using %any
880 wildcards) will all use the same reqid.
881 For KLIPS, when using the MAST variant, a different mechanism
883 called SAref is in use. See overlapip and sareftrack.
884 dpddelay
886 Set the delay (in seconds) between Dead Peer Detection (RFC 3706)
887 keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this
888 connection (default 30 seconds). If dpddelay is set, dpdtimeout
889 also needs to be set.
890 dpdtimeout
892 Set the length of time (in seconds) we will idle without hearing
893 either an R_U_THERE poll from our peer, or an R_U_THERE_ACK reply.
894 After this period has elapsed with no response and no traffic, we
895 will declare the peer dead, and remove the SA (default 120
896 seconds). If dpdtimeout is set, dpdaction also needs to be set.
897 dpdaction
899 When a DPD enabled peer is declared dead, what action should be
900 taken. hold (default) means the eroute will be put into %hold
901 status, while clear means the eroute and SA with both be cleared.
902 restart means that ALL SAs to the dead peer will renegotiated.
903 dpdaction=clear is really only useful on the server of a Road
905 Warrior config.
906 The value restart_by_peer has been obsoleted and its functionality
908 moved into the regular restart action.
909 pfs
911 whether Perfect Forward Secrecy of keys is desired on the
912 connection´s keying channel (with PFS, penetration of the
913 key-exchange protocol does not compromise keys negotiated earlier);
914 Since there is no reason to ever refuse PFS, Libreswan will allow a
915 connection defined with pfs=no to use PFS anyway. Acceptable values
916 are yes (the default) and no.
917 pfsgroup
919 This option is obsoleted, please use phase2alg if you need the PFS
920 to be different from phase1 (the default) using:
921 phase2alg=aes128-md5;modp1024
922 aggrmode
924 Use IKEv1 Aggressive Mode instead of IKEv1 Main Mode. This option
925 has no effect when IKEv2 is used. Acceptable values are no (the
926 default) or yes. When this option is enabled, IKEv1 Main Mode will
927 no longer be allowed for this connection.
928 Aggressive Mode is less secure, and more vulnerable to Denial Of
930 Service attacks. It is also vulnerable to brute force attacks with
931 software such as ikecrack. It should not be used, and it should
932 especially not be used with XAUTH and group secrets (PSK). If the
933 remote system administrator insists on staying irresponsible,
934 enable this option.
935 Aggressive Mode is further limited to only proposals with one DH
937 group as there is no room to negotiate the DH group. Therefor it is
938 mandatory for Aggressive Mode connections that both ike= and
939 phase2alg= options are specified with only one fully specified
940 proposal using one DH group.
941 The KE payload is created in the first exchange packet when using
943 aggressive mode. The KE payload depends on the DH group used. This
944 is why there cannot be multiple DH groups in IKEv1 aggressive mode.
945 In IKEv2, which uses a similar method to IKEv1 Aggressive Mode,
946 there is an INVALID_KE response payload that can inform the
947 initiator of the responder´s desired DH group and so an IKEv2
948 connection can actually recover from picking the wrong DH group by
949 restarting its negotiation.
950 salifetime
952 how long a particular instance of a connection (a set of
953 encryption/authentication keys for user packets) should last, from
954 successful negotiation to expiry; acceptable values are an integer
955 optionally followed by s (a time in seconds) or a decimal number
956 followed by m, h, or d (a time in minutes, hours, or days
957 respectively) (default 8h, maximum 24h). Normally, the connection
958 is renegotiated (via the keying channel) before it expires. The two
959 ends need not exactly agree on salifetime, although if they do not,
960 there will be some clutter of superseded connections on the end
961 which thinks the lifetime is longer.
962 The keywords "keylife" and "lifetime" are obsoleted aliases for
964 "salifetime." Change your configs to use "salifetime" instead.
965 rekey
967 whether a connection should be renegotiated when it is about to
968 expire; acceptable values are yes (the default) and no. The two
969 ends need not agree, but while a value of no prevents Pluto from
970 requesting renegotiation, it does not prevent responding to
971 renegotiation requested from the other end, so no will be largely
972 ineffective unless both ends agree on it.
973 rekeymargin
975 how long before connection expiry or keying-channel expiry should
976 attempts to negotiate a replacement begin; acceptable values as for
977 salifetime (default 9m). Relevant only locally, other end need not
978 agree on it.
979 rekeyfuzz
981 maximum percentage by which rekeymargin should be randomly
982 increased to randomize rekeying intervals (important for hosts with
983 many connections); acceptable values are an integer, which may
984 exceed 100, followed by a `%´ (default set by ipsec_pluto(8),
985 currently 100%). The value of rekeymargin, after this random
986 increase, must not exceed salifetime. The value 0% will suppress
987 time randomization. Relevant only locally, other end need not agree
988 on it.
989 keyingtries
991 how many attempts (a whole number or %forever) should be made to
992 negotiate a connection, or a replacement for one, before giving up
993 (default %forever). The value %forever means “never give up”
994 (obsolete: this can be written 0). Relevant only locally, other end
995 need not agree on it.
996 ikelifetime
998 how long the keying channel of a connection (buzzphrase: “ISAKMP
999 SA”) should last before being renegotiated; acceptable values as
1000 for salifetime (default set by ipsec_pluto(8), currently 1h,
1001 maximum 24h). The two-ends-disagree case is similar to that of
1002 salifetime.
1003 retransmit-timeout
1005 how long a single packet, including retransmits of that packet, may
1006 take before the IKE attempt is aborted. If rekeying is enabled, a
1007 new IKE attempt is started. The default set by ipsec_pluto(8),
1008 currently is 60s. See also: retransmit-interval, rekey and
1009 keyingtries.
1010 retransmit-interval
1012 the initial interval time period, specified in msecs, that pluto
1013 waits before retransmitting an IKE packet. This interval is doubled
1014 for each attempt (exponential back-off). The default set by
1015 ipsec_pluto(8), currently is 500. See also: retransmit-timeout,
1016 rekey and keyingtries.
1017 compress
1019 whether IPComp compression of content is proposed on the connection
1020 (link-level compression does not work on encrypted data, so to be
1021 effective, compression must be done before encryption); acceptable
1022 values are yes and no (the default).
1023 As of libreswan 3.1, both ends must agree. In previous versions of
1025 libreswan, openswan and freeswan, compression was always accepted
1026 even if not configured. In light of the BEAST attacks on TLS, using
1027 compression and encryptions has come under more scrutiny, and it
1028 was decided that it should be possible for the local policy of an
1029 endpoint to disallow compression. A value of yes causes pluto to
1030 propose compression and reject proposals without it. A value of no
1031 prevents pluto from proposing compression; a proposal to compress
1032 will be rejected.
1033 metric
1035 Set the metric for the routes to the ipsecX or mastX interface.
1036 This makes it possible to do host failover from another interface
1037 to ipsec using route management. This value is passed to the
1038 _updown scripts as PLUTO_METRIC. This option is only available with
1039 KLIPS or MAST on Linux. Acceptable values are positive numbers,
1040 with the default being 1.
1041 mtu
1043 Set the MTU for the route(s) to the remote endpoint and/or subnets.
1044 This is sometimes required when the overhead of the IPsec
1045 encapsulation would cause the packet the become too big for a
1046 router on the path. Since IPsec cannot trust any unauthenticated
1047 ICMP messages, PATH MTU discovery does not work. This can also be
1048 needed when using "6to4" IPV6 deployments, which adds another
1049 header on the packet size. Acceptable values are positive numbers.
1050 There is no default.
1051 nflog
1053 If set, the NFLOG group number to log this connection´s pre-crypt
1054 and post-decrypt traffic to. The default value of 0 means no
1055 logging at all. This option is only available on linux kernel
1056 2.6.14 and later. It allows common network utilities such as
1057 tcpdump, wireshark and dumpcap, to use nflog:XXX pseudo interfaces
1058 where XXX is the nflog group number. During the updown phase of a
1059 connection, iptables will be used to add and remove the
1060 source/destination pair to the nflog group specified. The rules are
1061 setup with the nflog-prefix matching the connection name. See also
1062 the global nflog-all option.
1063 priority
1065 The priority in the kernel SPD/SAD database, when matching up
1066 packets. Each kernel (NETKEY, KLIPS, OSX, etc) has its own
1067 mechanism for setting the priority. Setting this option to non-zero
1068 passes the priority to the kernel stack unmodified. The maximum
1069 value depends on the stack. It is recommended not to exceed 65536
1070 KLIPS and NETKEY use a priority system based on "most specific
1072 match first". It uses an internal algorithm to calculate these
1073 based on network prefix length, protocol and port selectors. A
1074 lower value means a higher priority.
1075 Typical values are about the 2000 range. These can be seen on the
1077 NETKEY stack using ip xfrm policy when the connection is up. For
1078 "anonymous IPsec" or Opportunistic Encryption based connections, a
1079 much lower priority (65535) is used to ensure administrator
1080 configured IPsec always takes precedence over opportunistic IPsec.
1081 sendca
1083 How much of our available X.509 trust chain to send with the End
1084 certificate, excluding any root CA´s. Specifying issuer sends just
1085 the issuing intermediate CA, while
1086 all will send the entire chain of intermediate CA´s.none (the
1087 default) will not send any CA certs.
1088 disablearrivalcheck
1090 whether KLIPS´s normal tunnel-exit check (that a packet emerging
1091 from a tunnel has plausible addresses in its header) should be
1092 disabled; acceptable values are yes and no (the default).
1093 Tunnel-exit checks improve security and do not break any normal
1094 configuration. Relevant only locally, other end need not agree on
1095 it.
1096 labeled-ipsec
1098 Whether labeled IPsec should be enabled or not; acceptable values
1099 are no (the default) and yes. See also policy-label= and
1100 secctx-attr-type=
1101 policy-label
1103 The string representation of an access control security label that
1104 is interpreted by the LSM (e.g. SELinux) for use with Labeled
1105 IPsec. See also loopback=, labeled-ipsec= and secctx-attr-type=.
1106 For example,
1107 policy-label=system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023
1108 failureshunt
1110 what to do with packets when negotiation fails. The default is
1111 none: no shunt; passthrough, drop, and reject have the obvious
1112 meanings.
1113 negotiationshunt
1115 What to do with packets during the IKE negotiation. Valid options
1116 are hold (the default) or passthrough. This should almost always be
1117 left to the default hold value to avoid cleartext packet leaking.
1118 The only reason to set this to passthrough is if plaintext service
1119 availability is more important than service security or privacy, a
1120 scenario that also implies failureshunt=passthrough and most likely
1121 authby=%null using Opportunistic Encryption.
1122
1124 At present, the only config section known to the IPsec software is the
1125 one named setup, which contains information used when the software is
1126 being started (see ipsec_setup(8)). Here´s an example:
1127 config setup
1130 interfaces="ipsec0=eth1 ipsec1=ppp0"
1131 klipsdebug=none
1132 plutodebug=control
1133 protostack=auto
1134 Parameters are optional unless marked “(required)”.
1136 The currently-accepted parameter names in a config setup section are:
1138 myid
1140 the identity to be used for %myid. %myid is used in the implicit
1141 policy group conns and can be used as an identity in explicit
1142 conns. If unspecified, %myid is set to the IP address in
1143 %defaultroute (if that is supported by a TXT record in its reverse
1144 domain), or otherwise the system´s hostname (if that is supported
1145 by a TXT record in its forward domain), or otherwise it is
1146 undefined. An explicit value generally starts with ``@´´.
1147 protostack
1149 decide which protocol stack is going to be used. Valid values are
1150 "klips", "netkey" (the default) and "mast". The "mast" stack is a
1151 variation for the KLIPS stack. The value "auto" has been obsoleted.
1152 interfaces
1154 virtual and physical interfaces for IPsec to use: a single
1155 virtual=physical pair, a (quoted!) list of pairs separated by white
1156 space, or %none. One of the pairs may be written as %defaultroute,
1157 which means: find the interface d that the default route points to,
1158 and then act as if the value was ``ipsec0=d´´. %defaultroute is
1159 the default; %none must be used to denote no interfaces, or when
1160 using the NETKEY stack. If %defaultroute is used (implicitly or
1161 explicitly) information about the default route and its interface
1162 is noted for use by ipsec_auto(8).)
1163 listen
1165 IP address to listen on (default depends on interfaces= setting).
1166 Currently only accepts one IP address.
1167 ikeport
1169 The IKE port to listen on. The default value is 500. As IKE is an
1170 internet standard, changing this means pluto will no longer be able
1171 to interop with other devices, unless they have also been
1172 explicitly configured to use a non-standard IKE port. There might
1173 also be other subtle assumptions within the kernel that port 500 is
1174 used. Changing this port is strongly discouraged, and should
1175 probably only be done for testing or when required to circumvent
1176 VPN blocking technologies as employed by certain commercial
1177 companies and national governments. See also nat-ikeport.
1178 nflog-all
1180 If set, the NFLOG group number to log all pre-crypt and
1181 post-decrypt traffic to. The default value of 0 means no logging at
1182 all. This option is only available on linux kernel 2.6.14 and
1183 later. It allows common network utilities such as tcpdump,
1184 wireshark and dumpcap, to use nflog:XXX pseudo interfaces where XXX
1185 is the nflog group number. During startup and shutdown of the IPsec
1186 service, iptables commands will be used to add or remove the global
1187 NFLOG table rules. The rules are setup with the nflog-prefix
1188 all-ipsec. See also the per-connection nflog option.
1189 nat_traversal
1191 OBSOLETE. Support for NAT Traversal is always enabled.
1192 disable_port_floating
1194 OBSOLETE
1195 force_keepalive
1197 This option has been obsoleted since libreswan version 3.2. See the
1198 nat-keepalive option.
1199 nat-ikeport
1201 The IKE NAT Traversal floating port (see RFC-3947) to listen on.
1202 The default value is 4500. As IKE/NATT is an internet standard,
1203 changing this means pluto will no longer be able to interoperate
1204 with other devices, unless they have also been explicitly
1205 configured to use a non-standard IKE/NATT port. There might also be
1206 other subtle assumptions within the kernel that port 4500 is used.
1207 Changing this port is strongly discouraged, and should probably
1208 only be done for testing or when required to circumvent VPN
1209 blocking technologies as employed by certain commercial companies
1210 and national governments. See also ikeport.
1211 keep-alive
1213 The delay (in seconds) for NAT-T keep-alive packets, if these are
1214 enabled using nat-keepalive This parameter may eventually become
1215 per-connection.
1216 virtual-private
1218 contains the networks that are allowed as subnet= for the remote
1219 clients when using the vhost: or vnet: keywords in the subnet=
1220 parameters. In other words, the address ranges that may live behind
1221 a NAT router through which a client connects. This value is usually
1222 set to all the RFC-1918 address space, excluding the space used in
1223 the local subnet behind the NAT (An IP address cannot live at two
1224 places at once). IPv4 address ranges are denoted as %v4:a.b.c.d/mm
1225 and IPv6 is denoted as %v6:aaaa::bbbb:cccc:dddd:eeee/mm. One can
1226 exclude subnets by using the !. For example, if the VPN server is
1227 giving access to 192.168.1.0/24, this option should be set to:
1228 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.
1229 This parameter is only needed on the server side and not on the
1230 client side that resides behind the NAT router, as the client will
1231 just use its IP address for the inner IP setting. This parameter
1232 may eventually become per-connection. See also leftsubnet=
1233 Note: It seems that T-Mobile in the US and Rogers/Fido in Canada
1235 have started using 25.0.0.0/8 as their pre-NAT range. This range
1236 technically belongs to the Defence Interoperable Network Services
1237 Authority (DINSA), an agency of the Ministry of Defence of the
1238 United Kingdom. The network range seems to not have been announced
1239 for decades, which is probably why these organisations "borrowed"
1240 this range. To support roadwarriors on these 3G networks, you might
1241 have to add it to the virtual-private= line.
1242 myvendorid
1244 The string to use as our vendor id (VID) when send-vendorid=yes.
1245 The default is OE-Libreswan-VERSION.
1246 oe
1248 This option is ignored for now. It used to determine if
1249 Opportunistic Encryption will be enabled. Opportunistic Encryption
1250 is the term to describe using IPsec tunnels without prearrangement.
1251 It uses IPSECKEY or TXT records to announce public RSA keys for
1252 certain IP´s or identities. However, this feature is going to be
1253 moved outside of the pluto IKE daemon into a separate process, more
1254 closely tied with a local DNS(SEC) server. The default value used
1255 to be no, so this should not affect anyone. Contact the developers
1256 if you are interested in working on the re-implementation of OE.
1257 nhelpers
1259 how many pluto helpers are started to help with cryptographic
1260 operations. Pluto will start (n-1) of them, where n is the number
1261 of CPU´s you have (including hypherthreaded CPU´s). A value of 0
1262 forces pluto to do all operations in the main process. A value of
1263 -1 tells pluto to perform the above calculation. Any other value
1264 forces the number to that amount.
1265 seedbits
1267 Pluto uses the NSS crypto library as its random source. Some
1268 government Three Letter Agencies require that pluto reads
1269 additional bits from /dev/random and feed these into the NSS RNG
1270 before drawing random from the NSS library, despite the NSS library
1271 itself already seeding its internal state. This process can block
1272 pluto for an extended time during startup, depending on the entropy
1273 of the system. Therefor, the default is to not perform this
1274 redundant seeding. If specifying a value, it is recommended to
1275 specify at least 460 bits (for FIPS) or 440 bits (for BSI).
1276 secctx-attr-type
1278 The value for the IPsec SA security context attribute identifier
1279 which is used for Labeled IPsec. Defaults to the private use IANA
1280 value 32001 from the IPsec SA attributes registry. Old openswan
1281 versions might still be using the (stolen) value 10, which has
1282 since been assigned by IANA for something else. Other values are
1283 not recommended unless IANA assigns an actual value for this. See
1284 also labeled-ipsec=, loopback= and policy-label=
1285 plutofork
1287 Whetherpluto will turn into a daemon by forking in the background,
1288 or whether it will remain on the foreground. Valid options are yes
1289 (the default) or no. Older init systems, such as sysv initscripts,
1290 require that pluto forks into the background. Newer init systems,
1291 such as systemd or upstart prefer the process remains in the
1292 foreground. The current default reflects the fact that most systems
1293 are still based on sysv init scripts. Init systems can override
1294 this configuration option by starting pluto specifically with
1295 --nofork specified on the command line to start the pluto daemon
1296 after specifying the --config /etc/ipsec.conf option.
1297 crlcheckinterval
1299 interval expressed in second units, for example crlcheckinterval=60
1300 for 60 seconds, after which pluto will verify loaded X.509 CRL´s
1301 for expiration. If any of the CRL´s is expired, or if they
1302 previously failed to get updated, a new attempt at updating the CRL
1303 is made. The first attempt to update a CRL is started at two times
1304 the crlcheckinterval. If set to 0, which is also the default value
1305 if this option is not specified, CRL updating is disabled.
1306 crl-strict
1308 if not set, pluto is tolerant about missing or expired X.509
1309 Certificate Revocation Lists (CRL´s), and will allow peer
1310 certificates as long as they do not appear on an expired CRL. When
1311 this option is enabled, all connections with an expired or missing
1312 CRL will be denied. Active connections will be terminated at rekey
1313 time. This setup is more secure, but vulnerable to downtime if the
1314 CRL expires. Acceptable values are yes or no (the default). This
1315 option used to be called strictcrlpolicy.
1316 ocsp-enable
1318 Whether to perform Online Certificate Store Protocol ("OCSP")
1319 checks on those certificates that have an OCSP URI defined.
1320 Acceptable values are yes or no (the default).
1321 ocsp-strict
1323 if set to no, pluto is tolerant about failing to obtain an OCSP
1324 responses and a certificate is not rejected when the OCSP request
1325 fails, only when the OCSP request succeeds and lists the
1326 certificate as revoked. If set to yes, any failure on obtaining an
1327 OCSP status for a certificate will be fatal and the certificate
1328 will be rejected. Acceptable values are yes or no (the default).
1329 The strict mode refers to the NSS
1331 ocspMode_FailureIsVerificationFailure mode, while non-strict mode
1332 refers to the NSS ocspMode_FailureIsNotAVerificationFailure mode.
1333 ocsp-timeout
1335 The time until an OCSP request is aborted and considered failed.
1336 The default value is 2 seconds.
1337 ocsp-uri
1339 The URI to use for OCSP requests instead of the default OCSP URI
1340 listed in the CA certificate. This requires the ocsp-trustname
1341 option to be set to the nick (friendly name) of the OCSP server
1342 certificate, which needs to be present in the NSS database. These
1343 option combined with the next option sets the OCSP default
1344 responder.
1345 ocsp-trustname
1347 The nickname of the certificate that has been imported into the NSS
1348 database of the server handling the OCSP requests. This requires
1349 the ocsp-uri option to be set as well. This option and the previous
1350 options sets the OCSP default responder.
1351 forwardcontrol
1353 This option is obsolete and ignored. Please use
1354 net.ipv4.ip_forward = 0 in /etc/sysctl.conf instead to control the
1355 ip forwarding behaviour.
1356 rp_filter
1358 This option is obsolete and ignored. Please use the
1359 net.ipv4.conf/[iface]/rp_filter = 0 options in /etc/sysctl.conf
1360 instead. This option is badly documented; it must be 0 in many
1361 cases for ipsec to function.
1362 syslog
1364 the syslog(2) “facility” name and priority to use for
1365 startup/shutdown log messages, default daemon.error.
1366 klipsdebug
1368 how much KLIPS debugging output should be logged. An empty value,
1369 or the magic value none, means no debugging output (the default).
1370 The magic value all means full output. Otherwise only the specified
1371 types of output (a quoted list, names separated by white space) are
1372 enabled; for details on available debugging types, see
1373 ipsec_klipsdebug(8). This KLIPS option has no effect on NETKEY,
1374 Windows or BSD stacks.
1375 plutodebug
1377 how much Pluto debugging output should be logged. An empty value,
1378 or the magic value none, means no debugging output (the default).
1379 The magic value all means full output. Otherwise only the specified
1380 types of output (a quoted list, names without the --debug- prefix,
1381 separated by white space) are enabled; for details on available
1382 debugging types, see ipsec_pluto(8).
1383 uniqueids
1385 whether a particular participant ID should be kept unique, with any
1386 new (automatically keyed) connection using an ID from a different
1387 IP address deemed to replace all old ones using that ID. Acceptable
1388 values are yes (the default) and no. Participant IDs normally are
1389 unique, so a new (automatically-keyed) connection using the same ID
1390 is almost invariably intended to replace an old one.
1391 plutorestartoncrash
1393 prevent pluto from restarting after it crashed. This option should
1394 only be used by developers when debugging a crasher. It will
1395 prevent overwriting a core file on a new start, or a cascade of
1396 core files. This option is also required if used with
1397 plutostderrlog= to avoid clearing the logs of the crasher. Values
1398 can be yes (the default) or no.
1399 This option is ignored on modern init systems such as systemd(1)
1401 and upstart. For systemd, change the ipsec.service file to contain
1402 Restart=no. See systemd.service(5)
1403 logfile
1405 do not use syslog, but rather log to stderr, and direct stderr to
1406 the argument file. This option used to be called plutostderrlog=
1407 logappend
1409 If pluto is instructed to log to a file using logfile=, this option
1410 determines whether the log file should be appended to or
1411 overwritten. Valid options are yes (the default) to append and no
1412 to overwrite. Since on modern systems, pluto is restarted by other
1413 daemons, such as systemd, this option should be left at its default
1414 yes value to preserve the log entries of previous runs of pluto.
1415 The option is mainly of use for running the test suite, which needs
1416 to create new log files from scratch.
1417 logtime
1419 When pluto is directed to log to a file using logfile=, this option
1420 determines whether or not to log the current timestamp as prefix.
1421 Values are yes (the default) or no. The no value can be used to
1422 create logs without ephemeral timestamps, such as those created
1423 when running the test suite. This option used to be called
1424 plutostderrlogtime=
1425 force-busy
1427 This option has been obsoleted, please see ddos-mode.
1428 ddos-mode
1430 The startup mode of the DDOS defense mechanism. Acceptable values
1431 are busy, unlimited or auto (the default). This option can also be
1432 given to the IKE daemon while running, for example by issuing ipsec
1433 whack --ddos--busy. When in busy mode, pluto activates anti-DDoS
1434 counter measures. Currently, counter measures consist of requiring
1435 IKEv2 anti-DDoS cookies on new incoming IKE requests, and a more
1436 aggressive cleanup of partially established or AUTH_NULL
1437 connections.
1438 ddos-ike-treshold
1440 The number of half-open IKE SAs before the pluto IKE daemon will be
1441 placed in busy mode. When in busy mode, pluto activates anti-DDoS
1442 counter measures. The default is 25000. See also ddos-mode and
1443 ipsec whack --ddos-XXX.
1444 max-halfopen-ike
1446 The number of half-open IKE SAs before the IKE daemon starts
1447 refusing all new IKE attempts. Established IKE peers are not
1448 affected. The default value is 50000.
1449 shuntlifetime
1451 The time until bare shunts (kernel policies not associated with
1452 connections) are deleted from the kernel. The default value is 15m.
1453 When using Opportunistic Encryption to a specific host fails, the
1454 system will either install a %pass or %hold shunt to let the
1455 traffic out clear text or block it. During the the shuntlifetime,
1456 no new Opportunistic Encryption attempt will be started, although
1457 the system will still respond to incoming OE requests from the
1458 remote IP. See also failureshunt and negotiationshunt
1459 xfrmlifetime
1461 The time in seconds until the NETKEY/XFRM acquire state times out.
1462 The default value is 300 seconds. For auto=ondemand connections and
1463 Opportunistic connections an IPsec policy is installed in the
1464 kernel. If an incoming or outgoing packet matches this policy, a
1465 state is created in the kernel and the kernel sends an ACQUIRE
1466 message to the IKE daemon pluto. While this state is in place, no
1467 new acquires will come in for this connection. The default should
1468 be fine for most people. One use case of shortening these is if
1469 opportunistc encryption is used towards cloud instances that can
1470 quickly re-use IP addresses. This value is only used during the
1471 libreswan startup process by the ipsec _stackmanager helper. See
1472 also failureshunt and negotiationshunt
1473 dumpdir
1475 in what directory should things started by setup (notably the Pluto
1476 daemon) be allowed to dump core? The default value is
1477 /var/run/pluto. When SELinux runs in enforced mode, changing this
1478 requires a similar change in the SELinux policy for the pluto
1479 daemon.
1480 statsbin
1482 This option specifies an optional external program to report tunnel
1483 state changes too. The default is not to report tunnel state
1484 changes. This program can be used to notify the user´s desktop
1485 (dbus, NetworkManager) or to report tunnel changes to a central
1486 logging server.
1487 ipsecdir
1489 in what directory the X509, NSS and OE related files should be
1490 stored. The default value is /etc/ipsec.d. When SELinux runs in
1491 enforced mode, changing this requires a similar change in the
1492 SELinux policy for the pluto daemon. Note that NSS generated db
1493 files contain their location within their files, so you cannot move
1494 this directory without re-creating the NSS files.
1495 secretsfile
1497 in which file the secret credentials such as preshared keys (PSKs)
1498 are stored. See man ipsec.secrets for the syntax. The default value
1499 is /etc/ipsec.secrets.
1500 perpeerlog
1502 if pluto should split the logs in a per-peer directory. Valid
1503 options are no(the default) and yes. When enabled, logging is split
1504 into directories based on IP address. When disabled, logging is
1505 done via syslog or a single log file, as defined by logfile=
1506 perpeerlogdir
1508 in what directory the per-peer log should be created, if enabled
1509 via the perpeerlog option. This will result in sub directories in
1510 the structure /192/0/2. The default value is /var/log/pluto/peer/.
1511 When SELinux runs in enforced mode, changing this requires a
1512 similar change in the SELinux policy for the pluto daemon.
1513 fragicmp
1515 whether a tunnel´s need to fragment a packet should be reported
1516 back with an ICMP message, in an attempt to make the sender lower
1517 his PMTU estimate; acceptable values are no (the default) and yes.
1518 This KLIPS option has no effect on NETKEY, Windows or BSD stacks.
1519 hidetos
1521 whether a tunnel packet´s TOS field should be set to 0 rather than
1522 copied from the user packet inside; acceptable values are yes (the
1523 default) and no. This KLIPS option has no effect on NETKEY, Windows
1524 or BSD stacks.
1525 overridemtu
1527 value that the MTU of the ipsecn interface(s) should be set to,
1528 overriding IPsec´s (large) default. This parameter is needed only
1529 in special situations. This KLIPS option has no effect on NETKEY,
1530 Windows or BSD stacks.
1531
1533 The system automatically defines several conns to implement default
1534 policy groups. Each can be overridden by explicitly defining a new conn
1535 with the same name. If the new conn has auto=ignore, the definition is
1536 suppressed.
1537 Here are the automatically supplied definitions.
1539 conn clear
1542 type=passthrough
1543 authby=never
1544 left=%defaultroute
1545 right=%group
1546 auto=route
1547 conn clear-or-private
1549 type=passthrough
1550 left=%defaultroute
1551 leftid=%myid
1552 right=%opportunisticgroup
1553 failureshunt=passthrough
1554 keyingtries=3
1555 ikelifetime=1h
1556 salifetime=1h
1557 rekey=no
1558 auto=route
1559 conn private-or-clear
1561 type=tunnel
1562 left=%defaultroute
1563 leftid=%myid
1564 right=%opportunisticgroup
1565 failureshunt=passthrough
1566 keyingtries=3
1567 ikelifetime=1h
1568 salifetime=1h
1569 rekey=no
1570 auto=route
1571 conn private
1573 type=tunnel
1574 left=%defaultroute
1575 leftid=%myid
1576 right=%opportunisticgroup
1577 failureshunt=drop
1578 keyingtries=3
1579 ikelifetime=1h
1580 salifetime=1h
1581 rekey=no
1582 auto=route
1583 conn block
1585 type=reject
1586 authby=never
1587 left=%defaultroute
1588 right=%group
1589 auto=route
1590 # default policy
1592 conn packetdefault
1593 type=tunnel
1594 left=%defaultroute
1595 leftid=%myid
1596 left=0.0.0.0/0
1597 right=%opportunistic
1598 failureshunt=passthrough
1599 keyingtries=3
1600 ikelifetime=1h
1601 salifetime=1h
1602 rekey=no
1603 auto=route
1604 These conns are not affected by anything in conn %default. They will
1606 only work if %defaultroute works. The leftid will be the interfaces IP
1607 address; this requires that reverse DNS records be set up properly.
1608 The implicit conns are defined after all others. It is appropriate and
1610 reasonable to use also=private-or-clear (for example) in any other
1611 opportunistic conn.
1612
1614 The optional files under /etc/ipsec.d/policy, including
1615 /etc/ipsec.d/policies/clear
1618 /etc/ipsec.d/policies/clear-or-private
1619 /etc/ipsec.d/policies/private-or-clear
1620 /etc/ipsec.d/policies/private
1621 /etc/ipsec.d/policies/block
1622 may contain policy group configuration information to supplement
1625 ipsec.conf. Their contents are not security-sensitive.
1626 These files are text files. Each consists of a list of CIDR blocks, one
1628 per line. White space followed by # followed by anything to the end of
1629 the line is a comment and is ignored, as are empty lines.
1630 A connection in ipsec.conf which has right=%group or
1632 right=%opportunisticgroup is a policy group connection. When a policy
1633 group file of the same name is loaded, with
1634 ipsec auto --rereadgroups
1636 or at system start, the connection is instantiated such that each CIDR
1638 block serves as an instance´s right value. The system treats the
1639 resulting instances as normal connections.
1640 For example, given a suitable connection definition private, and the
1642 file /etc/ipsec.d/policy/private with an entry 192.0.2.3, the system
1643 creates a connection instance private#192.0.2.3. This connection
1644 inherits all details from private, except that its right client is
1645 192.0.2.3.
1646
1648 The standard Libreswan install includes several policy groups which
1649 provide a way of classifying possible peers into IPsec security
1650 classes: private (talk encrypted only), private-or-clear (prefer
1651 encryption), clear-or-private (respond to requests for encryption),
1652 clear and block. Implicit policy groups apply to the local host only,
1653 and are implemented by the IMPLICIT CONNECTIONS described above.
1654
1656 Various options have recently been obsoleted and are ignored. The
1657 options prepluto= and plutopost= have been obsoleted because these were
1658 used by the (obsoleted) shell wrappers launching the pluto daemon. If
1659 this functionality is needed, look at your initsystem for support. For
1660 example, the systemd initsystem has the options ExecStartPre= and
1661 ExecStopPost= to accomplish the same. The option plutoopts= has also
1662 been obsoleted for this reason. A replacement can be found in the
1663 PLUTO_OPTS environment variable in the file /etc/sysconfig/pluto
1664 (Fedora/RHEL) or /etc/defaults/pluto (Debian/Ubuntu). The last two
1665 options obsoleted by the removal of the old shell scripts are pluto=
1666 and plutowait=.
1667 The following ipsec commands have been obsoleted: ipsec _confread,
1669 ipsec _include, ipsec _plutoload, ipsec _realsetup, ipsec _startklips
1670 and ipsec _startnetkey due to the new parsing and startup methods and
1671 ipsec copyright, ipsec lwdnsq, ipsec mailkey, ipsec policy, ipsec
1672 showdefaults and ipsec showpolicy because they were no longer needed or
1673 current.
1674
1676 When choosing a connection to apply to an outbound packet caught with a
1677 %trap, the system prefers the one with the most specific eroute that
1678 includes the packet´s source and destination IP addresses. Source
1679 subnets are examined before destination subnets. For initiating, only
1680 routed connections are considered. For responding, unrouted but added
1681 connections are considered.
1682 When choosing a connection to use to respond to a negotiation which
1684 doesn´t match an ordinary conn, an opportunistic connection may be
1685 instantiated. Eventually, its instance will be /32 -> /32, but for
1686 earlier stages of the negotiation, there will not be enough information
1687 about the client subnets to complete the instantiation.
1688
1690 /etc/ipsec.conf
1691 /etc/ipsec.d/policies/clear
1692 /etc/ipsec.d/policies/clear-or-private
1693 /etc/ipsec.d/policies/private-or-clear
1694 /etc/ipsec.d/policies/private
1695 /etc/ipsec.d/policies/block
1696
1698 ipsec(8), ipsec_ttoaddr(8), ipsec_auto(8), ipsec_rsasigkey(8)
1699
1701 Designed for the FreeS/WAN project <http://www.freeswan.org> by Henry
1702 Spencer.
1703
1705 Before reporting new bugs, please ensure you are using the latest
1706 version of Libreswan, and if not using KLIPS, please ensure you are
1707 using the latest kernel code for your IPsec stack.
1708 When type or failureshunt is set to drop or reject, Libreswan blocks
1710 outbound packets using eroutes, but assumes inbound blocking is handled
1711 by the firewall. Libreswan offers firewall hooks via an “updown”
1712 script. However, the default ipsec _updown provides no help in
1713 controlling a modern firewall.
1714 Including attributes of the keying channel (authentication methods,
1716 ikelifetime, etc.) as an attribute of a connection, rather than of a
1717 participant pair, is dubious and incurs limitations.
1718 The use of %any with the protoport= option is ambiguous. Should the SA
1720 permits any port through or should the SA negotiate any single port
1721 through? The first is a basic conn with a wildcard. The second is a
1722 template. The second is the current behaviour, and it´s wrong for quite
1723 a number of uses involving TCP. The keyword %one may be introduced in
1724 the future to separate these two cases.
1725 It would be good to have a line-continuation syntax, especially for the
1727 very long lines involved in RSA signature keys.
1728 First packet caching is only implemented for the KLIPS(NG) and MAST
1730 stacks. NETKEY returns POSIX-breaking responses, visible as connect:
1731 Resource temporarily unavailable errors. This affects Opportunistic
1732 Encryption and DPD. Functionality on the BSD and Windows stacks is
1733 unknown.
1734 Some state information is only available when using KLIPS, and will
1736 return errors on other IPsec stacks. These include ipsec eroute, ipsec
1737 spi and ipsec look.
1738 Multiple L2TP clients behind the same NAT router, and multiple L2TP
1740 clients behind different NAT routers using the same Virtual IP is
1741 currently only working for the KLIPSNG stack.
1742 The ability to specify different identities, authby, and public keys
1744 for different automatic-keyed connections between the same participants
1745 is misleading; this doesn´t work dependably because the identity of the
1746 participants is not known early enough. This is especially awkward for
1747 the “Road Warrior” case, where the remote IP address is specified as
1748 0.0.0.0, and that is considered to be the “participant” for such
1749 connections.
1750 In principle it might be necessary to control MTU on an
1752 interface-by-interface basis, rather than with the single global
1753 override that overridemtu provides. This feature is planned for a
1754 future release.
1755 If conns are to be added before DNS is available, left=FQDN,
1757 leftnextop=FQDN, and leftrsasigkey=%dnsonload will fail.
1758 ipsec_pluto(8) does not actually use the public key for our side of a
1759 conn but it isn´t generally known at a add-time which side is ours
1760 (Road Warrior and Opportunistic conns are currently exceptions).
1761 The myid option does not affect explicit
1763 ipsec auto --add or ipsec auto --replace commands for implicit conns.
1764
1766 Paul Wouters
1767 documenter
1768libreswan 10/04/2017 IPSEC.CONF(5)