1SWANCTL.CONF(5) strongSwan SWANCTL.CONF(5)
2
6 swanctl.conf - swanctl configuration file
7
9 swanctl.conf is the configuration file used by the swanctl(8) tool to
10 load configurations and credentials into the strongSwan IKE daemon.
11 For a description of the basic file syntax, including number/time for‐
13 mats, or how to reference sections or split the configuration in multi‐
14 ple files by including other files, refer to strongswan.conf(5).
15
18 The following settings can be used to configure connections, creden‐
19 tials and pools.
20 connections
22 Section defining IKE connection configurations.
23 The connections section defines IKE connection configurations,
25 each in its own subsections. In the keyword description below,
26 the connection is named <conn>, but an arbitrary yet unique con‐
27 nection name can be chosen for each connection subsection.
28 connections.<conn>
31 Section for an IKE connection named <conn>.
32 connections.<conn>.version [0]
35 IKE major version to use for connection. 1 uses IKEv1 aka
36 ISAKMP, 2 uses IKEv2. A connection using the default of 0 ac‐
37 cepts both IKEv1 and IKEv2 as responder, and initiates the con‐
38 nection actively with IKEv2.
39 connections.<conn>.local_addrs [%any]
42 Local address(es) to use for IKE communication, comma separated.
43 Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP
44 address ranges.
45 As initiator, the first non-range/non-subnet is used to initiate
47 the connection from. As responder, the local destination address
48 must match at least to one of the specified addresses, subnets
49 or ranges.
50 If FQDNs are assigned they are resolved every time a configura‐
52 tion lookup is done. If DNS resolution times out, the lookup is
53 delayed for that time.
54 connections.<conn>.remote_addrs [%any]
57 Remote address(es) to use for IKE communication, comma sepa‐
58 rated. Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets
59 or IP address ranges.
60 As initiator, the first non-range/non-subnet is used to initiate
62 the connection to. As responder, the initiator source address
63 must match at least to one of the specified addresses, subnets
64 or ranges.
65 If FQDNs are assigned they are resolved every time a configura‐
67 tion lookup is done. If DNS resolution times out, the lookup is
68 delayed for that time.
69 To initiate a connection, at least one specific address or DNS
71 name must be specified.
72 connections.<conn>.local_port [500]
75 Local UDP port for IKE communication. By default the port of the
76 socket backend is used, which is usually 500. If port 500 is
77 used, automatic IKE port floating to port 4500 is used to work
78 around NAT issues.
79 Using a non-default local IKE port requires support from the
81 socket backend in use (socket-dynamic).
82 connections.<conn>.remote_port [500]
85 Remote UDP port for IKE communication. If the default of port
86 500 is used, automatic IKE port floating to port 4500 is used to
87 work around NAT issues.
88 connections.<conn>.proposals [default]
91 A proposal is a set of algorithms. For non-AEAD algorithms, this
92 includes for IKE an encryption algorithm, an integrity algo‐
93 rithm, a pseudo random function and a Diffie-Hellman group. For
94 AEAD algorithms, instead of encryption and integrity algorithms,
95 a combined algorithm is used.
96 In IKEv2, multiple algorithms of the same kind can be specified
98 in a single proposal, from which one gets selected. In IKEv1,
99 only one algorithm per kind is allowed per proposal, more algo‐
100 rithms get implicitly stripped. Use multiple proposals to offer
101 different algorithms combinations in IKEv1.
102 Algorithm keywords get separated using dashes. Multiple propos‐
104 als may be separated by commas. The special value default forms
105 a default proposal of supported algorithms considered safe, and
106 is usually a good choice for interoperability.
107 connections.<conn>.vips []
110 Comma separated list of virtual IPs to request in IKEv2 configu‐
111 ration payloads or IKEv1 Mode Config. The wildcard addresses
112 0.0.0.0 and :: request an arbitrary address, specific addresses
113 may be defined. The responder may return a different address,
114 though, or none at all.
115 connections.<conn>.aggressive [no]
118 Enables Aggressive Mode instead of Main Mode with Identity Pro‐
119 tection. Aggressive Mode is considered less secure, because the
120 ID and HASH payloads are exchanged unprotected. This allows a
121 passive attacker to snoop peer identities, and even worse, start
122 dictionary attacks on the Preshared Key.
123 connections.<conn>.pull [yes]
126 If the default of yes is used, Mode Config works in pull mode,
127 where the initiator actively requests a virtual IP. With no,
128 push mode is used, where the responder pushes down a virtual IP
129 to the initiating peer.
130 Push mode is currently supported for IKEv1, but not in IKEv2. It
132 is used by a few implementations only, pull mode is recommended.
133 connections.<conn>.dscp [000000]
136 Differentiated Services Field Codepoint to set on outgoing IKE
137 packets for this connection. The value is a six digit binary en‐
138 coded string specifying the Codepoint to set, as defined in RFC
139 2474.
140 connections.<conn>.encap [no]
143 To enforce UDP encapsulation of ESP packets, the IKE daemon can
144 fake the NAT detection payloads. This makes the peer believe
145 that NAT takes place on the path, forcing it to encapsulate ESP
146 packets in UDP.
147 Usually this is not required, but it can help to work around
149 connectivity issues with too restrictive intermediary firewalls.
150 connections.<conn>.mobike [yes]
153 Enables MOBIKE on IKEv2 connections. MOBIKE is enabled by de‐
154 fault on IKEv2 connections, and allows mobility of clients and
155 multi-homing on servers by migrating active IPsec tunnels.
156 Usually keeping MOBIKE enabled is unproblematic, as it is not
158 used if the peer does not indicate support for it. However, due
159 to the design of MOBIKE, IKEv2 always floats to port 4500 start‐
160 ing from the second exchange. Some implementations don't like
161 this behavior, hence it can be disabled.
162 connections.<conn>.dpd_delay [0s]
165 Interval to check the liveness of a peer actively using IKEv2
166 INFORMATIONAL exchanges or IKEv1 R_U_THERE messages. Active DPD
167 checking is only enforced if no IKE or ESP/AH packet has been
168 received for the configured DPD delay.
169 connections.<conn>.dpd_timeout [0s]
172 Charon by default uses the normal retransmission mechanism and
173 timeouts to check the liveness of a peer, as all messages are
174 used for liveness checking. For compatibility reasons, with
175 IKEv1 a custom interval may be specified; this option has no ef‐
176 fect on connections using IKE2.
177 connections.<conn>.fragmentation [yes]
180 Use IKE fragmentation (proprietary IKEv1 extension or RFC 7383
181 IKEv2 fragmentation). Acceptable values are yes (the
182 default), accept, force and no. If set to yes, and the peer
183 supports it, oversized IKE messages will be sent in fragments.
184 If set to accept, support for fragmentation is announced to the
185 peer but the daemon does not send its own messages in fragments.
186 If set to force (only supported for IKEv1) the initial IKE mes‐
187 sage will already be fragmented if required. Finally, setting
188 the option to no will disable announcing support for this fea‐
189 ture.
190 Note that fragmented IKE messages sent by a peer are always ac‐
192 cepted irrespective of the value of this option (even when set
193 to no).
194 connections.<conn>.childless [allow]
198 Use childless IKE_SA initiation (RFC 6023) for IKEv2, with the
199 first CHILD_SA created with a separate CREATE_CHILD_SA exchange
200 (e.g. to use an independent DH exchange for all CHILD_SAs). Ac‐
201 ceptable values are allow (the default), prefer, force and
202 never. If set to allow, responders will accept childless
203 IKE_SAs (as indicated via notify in the IKE_SA_INIT response)
204 while initiators continue to create regular IKE_SAs with the
205 first CHILD_SA created during IKE_AUTH, unless the IKE_SA is
206 initiated explicitly without any children (which will fail if
207 the responder does not support or has disabled this extension).
208 The effect of prefer is the same as allow on responders, but as
209 initiator a childless IKE_SA is initiated if the responder sup‐
210 ports it. If set to force, only childless initiation is accepted
211 in either role. Finally, setting the option to never disables
212 support for childless IKE_SAs as responder.
213 connections.<conn>.send_certreq [yes]
216 Send certificate request payloads to offer trusted root CA cer‐
217 tificates to the peer. Certificate requests help the peer to
218 choose an appropriate certificate/private key for authentication
219 and are enabled by default.
220 Disabling certificate requests can be useful if too many trusted
222 root CA certificates are installed, as each certificate request
223 increases the size of the initial IKE packets.
224 connections.<conn>.send_cert [ifasked]
227 Send certificate payloads when using certificate authentication.
228 With the default of ifasked the daemon sends certificate pay‐
229 loads only if certificate requests have been received. never
230 disables sending of certificate payloads altogether, always
231 causes certificate payloads to be sent unconditionally whenever
232 certificate authentication is used.
233 connections.<conn>.ppk_id []
236 String identifying the Postquantum Preshared Key (PPK) to be
237 used.
238 connections.<conn>.ppk_required [no]
241 Whether a Postquantum Preshared Key (PPK) is required for this
242 connection.
243 connections.<conn>.keyingtries [1]
246 Number of retransmission sequences to perform during initial
247 connect. Instead of giving up initiation after the first re‐
248 transmission sequence with the default value of 1, additional
249 sequences may be started according to the configured value. A
250 value of 0 initiates a new sequence until the connection estab‐
251 lishes or fails with a permanent error.
252 connections.<conn>.unique [no]
255 Connection uniqueness policy to enforce. To avoid multiple con‐
256 nections from the same user, a uniqueness policy can be en‐
257 forced. The value never does never enforce such a policy, even
258 if a peer included INITIAL_CONTACT notification messages,
259 whereas no replaces existing connections for the same identity
260 if a new one has the INITIAL_CONTACT notify. keep rejects new
261 connection attempts if the same user already has an active con‐
262 nection, replace deletes any existing connection if a new one
263 for the same user gets established.
264 To compare connections for uniqueness, the remote IKE identity
266 is used. If EAP or XAuth authentication is involved, the
267 EAP-Identity or XAuth username is used to enforce the uniqueness
268 policy instead.
269 On initiators this setting specifies whether an INITIAL_CONTACT
271 notify is sent during IKE_AUTH if no existing connection is
272 found with the remote peer (determined by the identities of the
273 first authentication round). Unless set to never the client will
274 send a notify.
275 connections.<conn>.reauth_time [0s]
278 Time to schedule IKE reauthentication. IKE reauthentication
279 recreates the IKE/ISAKMP SA from scratch and re-evaluates the
280 credentials. In asymmetric configurations (with EAP or configu‐
281 ration payloads) it might not be possible to actively reauthen‐
282 ticate as responder. The IKEv2 reauthentication lifetime negoti‐
283 ation can instruct the client to perform reauthentication.
284 Reauthentication is disabled by default. Enabling it usually may
286 lead to small connection interruptions, as strongSwan uses a
287 break-before-make policy with IKEv2 to avoid any conflicts with
288 associated tunnel resources.
289 connections.<conn>.rekey_time [4h]
292 IKE rekeying refreshes key material using a Diffie-Hellman ex‐
293 change, but does not re-check associated credentials. It is sup‐
294 ported in IKEv2 only, IKEv1 performs a reauthentication proce‐
295 dure instead.
296 With the default value IKE rekeying is scheduled every 4 hours,
298 minus the configured rand_time. If a reauth_time is configured,
299 rekey_time defaults to zero disabling rekeying; explicitly set
300 both to enforce rekeying and reauthentication.
301 connections.<conn>.over_time [10% of rekey_time/reauth_time]
304 Hard IKE_SA lifetime if rekey/reauth does not complete, as time.
305 To avoid having an IKE/ISAKMP kept alive if IKE reauthentication
306 or rekeying fails perpetually, a maximum hard lifetime may be
307 specified. If the IKE_SA fails to rekey or reauthenticate within
308 the specified time, the IKE_SA gets closed.
309 In contrast to CHILD_SA rekeying, over_time is relative in time
311 to the rekey_time and reauth_time values, as it applies to both.
312 The default is 10% of the longer of rekey_time and reauth_time.
314 connections.<conn>.rand_time [over_time]
318 Time range from which to choose a random value to subtract from
319 rekey/reauth times. To avoid having both peers initiating the
320 rekey/reauth procedure simultaneously, a random time gets sub‐
321 tracted from the rekey/reauth times.
322 The default is equal to the configured over_time.
324 connections.<conn>.pools []
328 Comma separated list of named IP pools to allocate virtual IP
329 addresses and other configuration attributes from. Each name
330 references a pool by name from either the pools section or an
331 external pool.
332 connections.<conn>.if_id_in [0]
335 XFRM interface ID set on inbound policies/SA, can be overridden
336 by child config, see there for details.
337 The special value %unique allocates a unique interface ID per
339 IKE_SA, which is inherited by all its CHILD_SAs (unless overrid‐
340 den there), beyond that the value %unique-dir assigns a differ‐
341 ent unique interface ID for each direction (in/out).
342 connections.<conn>.if_id_out [0]
345 XFRM interface ID set on outbound policies/SA, can be overridden
346 by child config, see there for details.
347 The special value %unique allocates a unique interface ID per
349 IKE_SA, which is inherited by all its CHILD_SAs (unless overrid‐
350 den there), beyond that the value %unique-dir assigns a differ‐
351 ent unique interface ID for each direction (in/out).
352 connections.<conn>.mediation [no]
355 Whether this connection is a mediation connection, that is,
356 whether this connection is used to mediate other connections us‐
357 ing the IKEv2 Mediation Extension. Mediation connections create
358 no CHILD_SA.
359 connections.<conn>.mediated_by []
362 The name of the connection to mediate this connection through.
363 If given, the connection will be mediated through the named me‐
364 diation connection. The mediation connection must have mediation
365 enabled.
366 connections.<conn>.mediation_peer []
369 Identity under which the peer is registered at the mediation
370 server, that is, the IKE identity the other end of this connec‐
371 tion uses as its local identity on its connection to the media‐
372 tion server. This is the identity we request the mediation
373 server to mediate us with. Only relevant on connections that set
374 mediated_by. If it is not given, the remote IKE identity of the
375 first authentication round of this connection will be used.
376 connections.<conn>.local<suffix>
379 Section for a local authentication round. A local authentication
380 round defines the rules how authentication is performed for the
381 local peer. Multiple rounds may be defined to use IKEv2 RFC 4739
382 Multiple Authentication or IKEv1 XAuth.
383 Each round is defined in a section having local as prefix, and
385 an optional unique suffix. To define a single authentication
386 round, the suffix may be omitted.
387 connections.<conn>.local<suffix>.round [0]
390 Optional numeric identifier by which authentication rounds are
391 sorted. If not specified rounds are ordered by their position
392 in the config file/VICI message.
393 connections.<conn>.local<suffix>.certs []
396 Comma separated list of certificate candidates to use for au‐
397 thentication. The certificates may use a relative path from the
398 swanctl x509 directory or an absolute path.
399 The certificate used for authentication is selected based on the
401 received certificate request payloads. If no appropriate CA can
402 be located, the first certificate is used.
403 connections.<conn>.local<suffix>.cert<suffix> []
406 Section for a certificate candidate to use for authentication.
407 Certificates in certs are transmitted as binary blobs, these
408 sections offer more flexibility.
409 connections.<conn>.local<suffix>.cert<suffix>.file []
412 Absolute path to the certificate to load. Passed as-is to the
413 daemon, so it must be readable by it.
414 Configure either this or handle, but not both, in one section.
416 connections.<conn>.local<suffix>.cert<suffix>.handle []
419 Hex-encoded CKA_ID of the certificate on a token.
420 Configure either this or file, but not both, in one section.
422 connections.<conn>.local<suffix>.cert<suffix>.slot []
425 Optional slot number of the token that stores the certificate.
426 connections.<conn>.local<suffix>.cert<suffix>.module []
429 Optional PKCS#11 module name.
430 connections.<conn>.local<suffix>.pubkeys []
433 Comma separated list of raw public key candidates to use for au‐
434 thentication. The public keys may use a relative path from the
435 swanctl pubkey directory or an absolute path.
436 Even though multiple local public keys could be defined in prin‐
438 ciple, only the first public key in the list is used for authen‐
439 tication.
440 connections.<conn>.local<suffix>.auth [pubkey]
443 Authentication to perform locally. pubkey uses public key au‐
444 thentication using a private key associated to a usable certifi‐
445 cate. psk uses pre-shared key authentication. The IKEv1 spe‐
446 cific xauth is used for XAuth or Hybrid authentication, while
447 the IKEv2 specific eap keyword defines EAP authentication.
448 For xauth, a specific backend name may be appended, separated by
450 a dash. The appropriate xauth backend is selected to perform the
451 XAuth exchange. For traditional XAuth, the xauth method is usu‐
452 ally defined in the second authentication round following an
453 initial pubkey (or psk) round. Using xauth in the first round
454 performs Hybrid Mode client authentication.
455 For eap, a specific EAP method name may be appended, separated
457 by a dash. An EAP module implementing the appropriate method is
458 selected to perform the EAP conversation.
459 If both peers support RFC 7427 ("Signature Authentication in
461 IKEv2") specific hash algorithms to be used during IKEv2 authen‐
462 tication may be configured. To do so use ike: followed by a
463 trust chain signature scheme constraint (see description of the
464 remote section's auth keyword). For example, with ike:pub‐
465 key-sha384-sha256 a public key signature scheme with either
466 SHA-384 or SHA-256 would get used for authentication, in that
467 order and depending on the hash algorithms supported by the
468 peer. If no specific hash algorithms are configured, the default
469 is to prefer an algorithm that matches or exceeds the strength
470 of the signature key. If no constraints with ike: prefix are
471 configured any signature scheme constraint (without ike: prefix)
472 will also apply to IKEv2 authentication, unless this is disabled
473 in strongswan.conf(5). To use RSASSA-PSS signatures use rsa/pss
474 instead of pubkey or rsa as in e.g. ike:rsa/pss-sha256. If
475 pubkey or rsa constraints are configured RSASSA-PSS signatures
476 will only be used if enabled in strongswan.conf(5).
477 connections.<conn>.local<suffix>.id []
481 IKE identity to use for authentication round. When using cer‐
482 tificate authentication, the IKE identity must be contained in
483 the certificate, either as subject or as subjectAltName.
484 The identity can be an IP address, a fully-qualified domain
486 name, an email address or a Distinguished Name for which the ID
487 type is determined automatically and the string is converted to
488 the appropriate encoding. To enforce a specific identity type, a
489 prefix may be used, followed by a colon (:). If the number sign
490 (#) follows the colon, the remaining data is interpreted as hex
491 encoding, otherwise the string is used as-is as the identifica‐
492 tion data. Note that this implies that no conversion is per‐
493 formed for non-string identities. For example, ipv4:10.0.0.1
494 does not create a valid ID_IPV4_ADDR IKE identity, as it does
495 not get converted to binary 0x0a000001. Instead, one could use
496 ipv4:#0a000001 to get a valid identity, but just using the im‐
497 plicit type with automatic conversion is usually simpler. The
498 same applies to the ASN1 encoded types. The following prefixes
499 are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns,
500 asn1dn, asn1gn and keyid. Custom type prefixes may be specified
501 by surrounding the numerical type value by curly brackets.
502 connections.<conn>.local<suffix>.eap_id [id]
505 Client EAP-Identity to use in EAP-Identity exchange and the EAP
506 method.
507 connections.<conn>.local<suffix>.aaa_id [remote-id]
510 Server side EAP-Identity to expect in the EAP method. Some EAP
511 methods, such as EAP-TLS, use an identity for the server to per‐
512 form mutual authentication. This identity may differ from the
513 IKE identity, especially when EAP authentication is delegated
514 from the IKE responder to an AAA backend.
515 For EAP-(T)TLS, this defines the identity for which the server
517 must provide a certificate in the TLS exchange.
518 connections.<conn>.local<suffix>.xauth_id [id]
521 Client XAuth username used in the XAuth exchange.
522 connections.<conn>.remote<suffix>
525 Section for a remote authentication round. A remote authentica‐
526 tion round defines the constraints how the peers must authenti‐
527 cate to use this connection. Multiple rounds may be defined to
528 use IKEv2 RFC 4739 Multiple Authentication or IKEv1 XAuth.
529 Each round is defined in a section having remote as prefix, and
531 an optional unique suffix. To define a single authentication
532 round, the suffix may be omitted.
533 connections.<conn>.remote<suffix>.round [0]
536 Optional numeric identifier by which authentication rounds are
537 sorted. If not specified rounds are ordered by their position
538 in the config file/VICI message.
539 connections.<conn>.remote<suffix>.id [%any]
542 IKE identity to expect for authentication round. Refer to the
543 local section's id keyword for details.
544 It's possible to use wildcards to match remote identities (e.g.
546 *@strongswan.org, *.strongswan.org, or C=CH,O=strongSwan,CN=*).
547 Connections with exact matches are preferred. When using distin‐
548 guished names with wildcards, the charon.rdn_matching option in
549 strongswan.conf(5) specifies how RDNs are matched.
550 connections.<conn>.remote<suffix>.eap_id [id]
553 Identity to use as peer identity during EAP authentication. If
554 set to %any the EAP-Identity method will be used to ask the
555 client for an identity.
556 connections.<conn>.remote<suffix>.groups []
559 Comma separated authorization group memberships to require. The
560 peer must prove membership to at least one of the specified
561 groups. Group membership can be certified by different means,
562 for example by appropriate Attribute Certificates or by an AAA
563 backend involved in the authentication.
564 connections.<conn>.remote<suffix>.cert_policy []
567 Comma separated list of certificate policy OIDs the peer's cer‐
568 tificate must have. OIDs are specified using the numerical dot‐
569 ted representation.
570 connections.<conn>.remote<suffix>.certs []
573 Comma separated list of certificates to accept for authentica‐
574 tion. The certificates may use a relative path from the swanctl
575 x509 directory or an absolute path.
576 connections.<conn>.remote<suffix>.cert<suffix> []
579 Section for a certificate to accept for authentication. Certifi‐
580 cates in certs are transmitted as binary blobs, these sections
581 offer more flexibility.
582 connections.<conn>.remote<suffix>.cert<suffix>.file []
585 Absolute path to the certificate to load. Passed as-is to the
586 daemon, so it must be readable by it.
587 Configure either this or handle, but not both, in one section.
589 connections.<conn>.remote<suffix>.cert<suffix>.handle []
592 Hex-encoded CKA_ID of the certificate on a token.
593 Configure either this or file, but not both, in one section.
595 connections.<conn>.remote<suffix>.cert<suffix>.slot []
598 Optional slot number of the token that stores the certificate.
599 connections.<conn>.remote<suffix>.cert<suffix>.module []
602 Optional PKCS#11 module name.
603 connections.<conn>.remote<suffix>.cacerts []
606 Comma separated list of CA certificates to accept for authenti‐
607 cation. The certificates may use a relative path from the
608 swanctl x509ca directory or an absolute path.
609 connections.<conn>.remote<suffix>.cacert<suffix> []
612 Section for a CA certificate to accept for authentication. Cer‐
613 tificates in cacerts are transmitted as binary blobs, these sec‐
614 tions offer more flexibility.
615 connections.<conn>.remote<suffix>.cacert<suffix>.file []
618 Absolute path to the certificate to load. Passed as-is to the
619 daemon, so it must be readable by it.
620 Configure either this or handle, but not both, in one section.
622 connections.<conn>.remote<suffix>.cacert<suffix>.handle []
625 Hex-encoded CKA_ID of the CA certificate on a token.
626 Configure either this or file, but not both, in one section.
628 connections.<conn>.remote<suffix>.cacert<suffix>.slot []
631 Optional slot number of the token that stores the CA certifi‐
632 cate.
633 connections.<conn>.remote<suffix>.cacert<suffix>.module []
636 Optional PKCS#11 module name.
637 connections.<conn>.remote<suffix>.ca_id []
640 The specified identity must be contained in one (intermediate)
641 CA of the remote peer trustchain, either as subject or as sub‐
642 jectAltName. This has the same effect as specifying cacerts to
643 force clients under a CA to specific connections; it does not
644 require the CA certificate to be available locally, and can be
645 received from the peer during the IKE exchange.
646 connections.<conn>.remote<suffix>.pubkeys []
649 Comma separated list of raw public keys to accept for authenti‐
650 cation. The public keys may use a relative path from the swanctl
651 pubkey directory or an absolute path.
652 connections.<conn>.remote<suffix>.revocation [relaxed]
655 Certificate revocation policy for CRL or OCSP revocation.
656 A strict revocation policy fails if no revocation information is
658 available, i.e. the certificate is not known to be unrevoked.
659 ifuri fails only if a CRL/OCSP URI is available, but certificate
661 revocation checking fails, i.e. there should be revocation in‐
662 formation available, but it could not be obtained.
663 The default revocation policy relaxed fails only if a certifi‐
665 cate is revoked, i.e. it is explicitly known that it is bad.
666 connections.<conn>.remote<suffix>.auth [pubkey]
669 Authentication to expect from remote. See the local section's
670 auth keyword description about the details of supported mecha‐
671 nisms.
672 To require a trustchain public key strength for the remote side,
674 specify the key type followed by the minimum strength in bits
675 (for example ecdsa-384 or rsa-2048-ecdsa-256). To limit the ac‐
676 ceptable set of hashing algorithms for trustchain validation,
677 append hash algorithms to pubkey or a key strength definition
678 (for example pubkey-sha256-sha512, rsa-2048-sha256-sha384-sha512
679 or rsa-2048-sha256-ecdsa-256-sha256-sha384). Unless disabled in
680 strongswan.conf(5), or explicit IKEv2 signature constraints are
681 configured (refer to the description of the local section's auth
682 keyword for details), such key types and hash algorithms are
683 also applied as constraints against IKEv2 signature authentica‐
684 tion schemes used by the remote side. To require RSASSA-PSS sig‐
685 natures use rsa/pss instead of pubkey or rsa as in e.g.
686 rsa/pss-sha256. If pubkey or rsa constraints are configured
687 RSASSA-PSS signatures will only be accepted if enabled in
688 strongswan.conf(5).
689 To specify trust chain constraints for EAP-(T)TLS, append a
692 colon to the EAP method, followed by the key type/size and hash
693 algorithm as discussed above (e.g. eap-tls:ecdsa-384-sha384).
694 connections.<conn>.children.<child>
698 CHILD_SA configuration sub-section. Each connection definition
699 may have one or more sections in its children subsection. The
700 section name defines the name of the CHILD_SA configuration,
701 which must be unique within the connection.
702 connections.<conn>.children.<child>.ah_proposals []
705 AH proposals to offer for the CHILD_SA. A proposal is a set of
706 algorithms. For AH, this includes an integrity algorithm and an
707 optional Diffie-Hellman group. If a DH group is specified,
708 CHILD_SA/Quick Mode rekeying and initial negotiation uses a sep‐
709 arate Diffie-Hellman exchange using the specified group (refer
710 to esp_proposals for details).
711 In IKEv2, multiple algorithms of the same kind can be specified
713 in a single proposal, from which one gets selected. In IKEv1,
714 only one algorithm per kind is allowed per proposal, more algo‐
715 rithms get implicitly stripped. Use multiple proposals to offer
716 different algorithms combinations in IKEv1.
717 Algorithm keywords get separated using dashes. Multiple propos‐
719 als may be separated by commas. The special value default forms
720 a default proposal of supported algorithms considered safe, and
721 is usually a good choice for interoperability. By default no AH
722 proposals are included, instead ESP is proposed.
723 connections.<conn>.children.<child>.esp_proposals [default]
726 ESP proposals to offer for the CHILD_SA. A proposal is a set of
727 algorithms. For ESP non-AEAD proposals, this includes an integ‐
728 rity algorithm, an encryption algorithm, an optional
729 Diffie-Hellman group and an optional Extended Sequence Number
730 Mode indicator. For AEAD proposals, a combined mode algorithm is
731 used instead of the separate encryption/integrity algorithms.
732 If a DH group is specified, CHILD_SA/Quick Mode rekeying and
734 initial negotiation use a separate Diffie-Hellman exchange using
735 the specified group. However, for IKEv2, the keys of the
736 CHILD_SA created implicitly with the IKE_SA will always be de‐
737 rived from the IKE_SA's key material. So any DH group specified
738 here will only apply when the CHILD_SA is later rekeyed or is
739 created with a separate CREATE_CHILD_SA exchange. A proposal
740 mismatch might, therefore, not immediately be noticed when the
741 SA is established, but may later cause rekeying to fail.
742 Extended Sequence Number support may be indicated with the esn
744 and noesn values, both may be included to indicate support for
745 both modes. If omitted, noesn is assumed.
746 In IKEv2, multiple algorithms of the same kind can be specified
748 in a single proposal, from which one gets selected. In IKEv1,
749 only one algorithm per kind is allowed per proposal, more algo‐
750 rithms get implicitly stripped. Use multiple proposals to offer
751 different algorithms combinations in IKEv1.
752 Algorithm keywords get separated using dashes. Multiple propos‐
754 als may be separated by commas. The special value default forms
755 a default proposal of supported algorithms considered safe, and
756 is usually a good choice for interoperability. If no algorithms
757 are specified for AH nor ESP, the default set of algorithms for
758 ESP is included.
759 connections.<conn>.children.<child>.sha256_96 [no]
762 HMAC-SHA-256 is used with 128-bit truncation with IPsec. For
763 compatibility with implementations that incorrectly use 96-bit
764 truncation this option may be enabled to configure the shorter
765 truncation length in the kernel. This is not negotiated, so
766 this only works with peers that use the incorrect truncation
767 length (or have this option enabled).
768 connections.<conn>.children.<child>.local_ts [dynamic]
771 Comma separated list of local traffic selectors to include in
772 CHILD_SA. Each selector is a CIDR subnet definition, followed by
773 an optional proto/port selector. The special value dynamic may
774 be used instead of a subnet definition, which gets replaced by
775 the tunnel outer address or the virtual IP, if negotiated. This
776 is the default.
777 A protocol/port selector is surrounded by opening and closing
779 square brackets. Between these brackets, a numeric or getser‐
780 vent(3) protocol name may be specified. After the optional pro‐
781 tocol restriction, an optional port restriction may be speci‐
782 fied, separated by a slash. The port restriction may be numeric,
783 a getservent(3) service name, or the special value opaque for
784 RFC 4301 OPAQUE selectors. Port ranges may be specified as well,
785 none of the kernel backends currently support port ranges,
786 though.
787 When IKEv1 is used only the first selector is interpreted, ex‐
789 cept if the Cisco Unity extension plugin is used. This is due to
790 a limitation of the IKEv1 protocol, which only allows a single
791 pair of selectors per CHILD_SA. So to tunnel traffic matched by
792 several pairs of selectors when using IKEv1 several children
793 (CHILD_SAs) have to be defined that cover the selectors.
794 The IKE daemon uses traffic selector narrowing for IKEv1, the
796 same way it is standardized and implemented for IKEv2. However,
797 this may lead to problems with other implementations. To avoid
798 that, configure identical selectors in such scenarios.
799 connections.<conn>.children.<child>.remote_ts [dynamic]
802 Comma separated list of remote selectors to include in CHILD_SA.
803 See local_ts for a description of the selector syntax.
804 connections.<conn>.children.<child>.rekey_time [1h]
807 Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes
808 key material, optionally using a Diffie-Hellman exchange if a
809 group is specified in the proposal.
810 To avoid rekey collisions initiated by both ends simultaneously,
812 a value in the range of rand_time gets subtracted to form the
813 effective soft lifetime.
814 By default CHILD_SA rekeying is scheduled every hour, minus
816 rand_time.
817 connections.<conn>.children.<child>.life_time [rekey_time + 10%]
821 Maximum lifetime before CHILD_SA gets closed. Usually this hard
822 lifetime is never reached, because the CHILD_SA gets rekeyed be‐
823 fore. If that fails for whatever reason, this limit closes the
824 CHILD_SA.
825 The default is 10% more than the rekey_time.
827 connections.<conn>.children.<child>.rand_time [life_time - rekey_time]
831 Time range from which to choose a random value to subtract from
832 rekey_time. The default is the difference between life_time and
833 rekey_time.
834 connections.<conn>.children.<child>.rekey_bytes [0]
838 Number of bytes processed before initiating CHILD_SA rekeying.
839 CHILD_SA rekeying refreshes key material, optionally using a
840 Diffie-Hellman exchange if a group is specified in the proposal.
841 To avoid rekey collisions initiated by both ends simultaneously,
843 a value in the range of rand_bytes gets subtracted to form the
844 effective soft volume limit.
845 Volume based CHILD_SA rekeying is disabled by default.
847 connections.<conn>.children.<child>.life_bytes [rekey_bytes + 10%]
850 Maximum bytes processed before CHILD_SA gets closed. Usually
851 this hard volume limit is never reached, because the CHILD_SA
852 gets rekeyed before. If that fails for whatever reason, this
853 limit closes the CHILD_SA.
854 The default is 10% more than rekey_bytes.
856 connections.<conn>.children.<child>.rand_bytes [life_bytes -
860 rekey_bytes]
861 Byte range from which to choose a random value to subtract from
862 rekey_bytes. The default is the difference between life_bytes
863 and rekey_bytes.
864 connections.<conn>.children.<child>.rekey_packets [0]
868 Number of packets processed before initiating CHILD_SA rekeying.
869 CHILD_SA rekeying refreshes key material, optionally using a
870 Diffie-Hellman exchange if a group is specified in the proposal.
871 To avoid rekey collisions initiated by both ends simultaneously,
873 a value in the range of rand_packets gets subtracted to form the
874 effective soft packet count limit.
875 Packet count based CHILD_SA rekeying is disabled by default.
877 connections.<conn>.children.<child>.life_packets [rekey_packets + 10%]
880 Maximum number of packets processed before CHILD_SA gets closed.
881 Usually this hard packets limit is never reached, because the
882 CHILD_SA gets rekeyed before. If that fails for whatever rea‐
883 son, this limit closes the CHILD_SA.
884 The default is 10% more than rekey_bytes.
886 connections.<conn>.children.<child>.rand_packets [life_packets -
890 rekey_packets]
891 Packet range from which to choose a random value to subtract
892 from rekey_packets. The default is the difference between
893 life_packets and rekey_packets.
894 connections.<conn>.children.<child>.updown []
898 Updown script to invoke on CHILD_SA up and down events.
899 connections.<conn>.children.<child>.hostaccess [no]
902 Hostaccess variable to pass to updown script.
903 connections.<conn>.children.<child>.mode [tunnel]
906 IPsec Mode to establish CHILD_SA with. tunnel negotiates the
907 CHILD_SA in IPsec Tunnel Mode, whereas transport uses IPsec
908 Transport Mode. transport_proxy signifying the special Mobile
909 IPv6 Transport Proxy Mode. beet is the Bound End to End Tunnel
910 mixture mode, working with fixed inner addresses without the
911 need to include them in each packet.
912 Both transport and beet modes are subject to mode negotiation;
914 tunnel mode is negotiated if the preferred mode is not avail‐
915 able.
916 pass and drop are used to install shunt policies which explic‐
918 itly bypass the defined traffic from IPsec processing or drop
919 it, respectively.
920 connections.<conn>.children.<child>.policies [yes]
923 Whether to install IPsec policies or not. Disabling this can be
924 useful in some scenarios e.g. MIPv6, where policies are not man‐
925 aged by the IKE daemon.
926 connections.<conn>.children.<child>.policies_fwd_out [no]
929 Whether to install outbound FWD IPsec policies or not. Enabling
930 this is required in case there is a drop policy that would match
931 and block forwarded traffic for this CHILD_SA.
932 connections.<conn>.children.<child>.dpd_action [clear]
935 Action to perform for this CHILD_SA on DPD timeout. The default
936 clear closes the CHILD_SA and does not take further action.
937 trap installs a trap policy, which will catch matching traffic
938 and tries to re-negotiate the tunnel on-demand (note that this
939 is redundant if start_action includes trap). restart immedi‐
940 ately tries to re-negotiate the CHILD_SA under a fresh IKE_SA.
941 connections.<conn>.children.<child>.ipcomp [no]
944 Enable IPComp compression before encryption. If enabled, IKE
945 tries to negotiate IPComp compression to compress ESP payload
946 data prior to encryption.
947 connections.<conn>.children.<child>.inactivity [0s]
950 Timeout before closing CHILD_SA after inactivity. If no traffic
951 has been processed in either direction for the configured time‐
952 out, the CHILD_SA gets closed due to inactivity. The default
953 value of 0 disables inactivity checks.
954 connections.<conn>.children.<child>.reqid [0]
957 Fixed reqid to use for this CHILD_SA. This might be helpful in
958 some scenarios, but works only if each CHILD_SA configuration is
959 instantiated not more than once. The default of 0 uses dynamic
960 reqids, allocated incrementally.
961 connections.<conn>.children.<child>.priority [0]
964 Optional fixed priority for IPsec policies. This could be useful
965 to install high-priority drop policies. The default of 0 uses
966 dynamically calculated priorities based on the size of the traf‐
967 fic selectors.
968 connections.<conn>.children.<child>.interface []
971 Optional interface name to restrict IPsec policies.
972 connections.<conn>.children.<child>.mark_in [0/0x00000000]
975 Netfilter mark and mask for input traffic. On Linux, Netfilter
976 may require marks on each packet to match an SA/policy having
977 that option set. This allows installing duplicate policies and
978 enables Netfilter rules to select specific SAs/policies for in‐
979 coming traffic. Note that inbound marks are only set on poli‐
980 cies, by default, unless *mark_in_sa* is enabled. The special
981 value %unique sets a unique mark on each CHILD_SA instance, be‐
982 yond that the value %unique-dir assigns a different unique mark
983 for each CHILD_SA direction (in/out).
984 An additional mask may be appended to the mark, separated by /.
986 The default mask if omitted is 0xffffffff.
987 connections.<conn>.children.<child>.mark_in_sa [no]
990 Whether to set *mark_in* on the inbound SA. By default, the in‐
991 bound mark is only set on the inbound policy. The tuple destina‐
992 tion address, protocol and SPI is unique and the mark is not re‐
993 quired to find the correct SA, allowing to mark traffic after
994 decryption instead (where more specific selectors may be used)
995 to match different policies. Marking packets before decryption
996 is still possible, even if no mark is set on the SA.
997 connections.<conn>.children.<child>.mark_out [0/0x00000000]
1000 Netfilter mark and mask for output traffic. On Linux, Netfilter
1001 may require marks on each packet to match a policy/SA having
1002 that option set. This allows installing duplicate policies and
1003 enables Netfilter rules to select specific policies/SAs for out‐
1004 going traffic. The special value %unique sets a unique mark on
1005 each CHILD_SA instance, beyond that the value %unique-dir as‐
1006 signs a different unique mark for each CHILD_SA direction
1007 (in/out).
1008 An additional mask may be appended to the mark, separated by /.
1010 The default mask if omitted is 0xffffffff.
1011 connections.<conn>.children.<child>.set_mark_in [0/0x00000000]
1014 Netfilter mark applied to packets after the inbound IPsec SA
1015 processed them. This way it's not necessary to mark packets via
1016 Netfilter before decryption or right afterwards to match poli‐
1017 cies or process them differently (e.g. via policy routing).
1018 An additional mask may be appended to the mark, separated by /.
1020 The default mask if omitted is 0xffffffff. The special value
1021 %same uses the value (but not the mask) from mark_in as mark
1022 value, which can be fixed, %unique or %unique-dir.
1023 Setting marks in XFRM input requires Linux 4.19 or higher.
1026 connections.<conn>.children.<child>.set_mark_out [0/0x00000000]
1029 Netfilter mark applied to packets after the outbound IPsec SA
1030 processed them. This allows processing ESP packets differently
1031 than the original traffic (e.g. via policy routing).
1032 An additional mask may be appended to the mark, separated by /.
1034 The default mask if omitted is 0xffffffff. The special value
1035 %same uses the value (but not the mask) from mark_out as mark
1036 value, which can be fixed, %unique or %unique-dir.
1037 Setting marks in XFRM output is supported since Linux 4.14. Set‐
1040 ting a mask requires at least Linux 4.19.
1041 connections.<conn>.children.<child>.if_id_in [0]
1044 XFRM interface ID set on inbound policies/SA. This allows in‐
1045 stalling duplicate policies/SAs and associates them with an in‐
1046 terface with the same ID. The special value %unique sets a
1047 unique interface ID on each CHILD_SA instance, beyond that the
1048 value %unique-dir assigns a different unique interface ID for
1049 each CHILD_SA direction (in/out).
1050 connections.<conn>.children.<child>.if_id_out [0]
1053 XFRM interface ID set on outbound policies/SA. This allows in‐
1054 stalling duplicate policies/SAs and associates them with an in‐
1055 terface with the same ID. The special value %unique sets a
1056 unique interface ID on each CHILD_SA instance, beyond that the
1057 value %unique-dir assigns a different unique interface ID for
1058 each CHILD_SA direction (in/out).
1059 The daemon will not install routes for CHILD_SAs that have this
1061 option set.
1062 connections.<conn>.children.<child>.label []
1065 Optional security label (e.g. SELinux context), IKEv2 only. Re‐
1066 fer to label_mode for details on how labels are processed.
1067 connections.<conn>.children.<child>.label_mode [system]
1070 Defines the mode in which the configured security label is used.
1071 The default value of system selects selinux if strongSwan was
1072 built with SELinux support and SELinux is enabled by the kernel,
1073 otherwise, simple will be selected.
1074 If set to simple, the label will be used as is as an additional
1076 identifier/selector on the IKEv2 level when negotiating
1077 CHILD_SAs and selecting configs, labels are not installed in the
1078 kernel and received labels have to match exactly.
1079 If set to selinux, which is only allowed if SELinux is usable on
1081 the system, the configured label is expected to be a generic
1082 context (e.g. system_u:object_r:ipsec_spd_t:s0) for which
1083 flows, whose context match it via association:polmatch, will
1084 trigger an acquire if no SA exists yet for the flow's specific
1085 context. The configured label is installed on (trap) policies,
1086 so this should generally be combined with trap in start_action.
1087 However, if the connection is initiated directly, without ac‐
1088 quire, a childless IKE_SA is established and appropriate trap
1089 policies are installed on both ends. Labels received from peers
1090 are accepted if they match the configured label via associa‐
1091 tion:polmatch.
1092 connections.<conn>.children.<child>.tfc_padding [0]
1095 Pads ESP packets with additional data to have a consistent ESP
1096 packet size for improved Traffic Flow Confidentiality. The pad‐
1097 ding defines the minimum size of all ESP packets sent.
1098 The default value of 0 disables TFC padding, the special value
1100 mtu adds TFC padding to create a packet size equal to the Path
1101 Maximum Transfer Unit.
1102 connections.<conn>.children.<child>.replay_window [32]
1105 IPsec replay window to configure for this CHILD_SA. Larger val‐
1106 ues than the default of 32 are supported using the Netlink back‐
1107 end only, a value of 0 disables IPsec replay protection.
1108 connections.<conn>.children.<child>.hw_offload [no]
1111 Enable hardware offload for this CHILD_SA, if supported by the
1112 IPsec implementation. The values crypto or packet enforce crypto
1113 or full packet offloading and the installation will fail if the
1114 selected mode is not supported by either kernel or device. On
1115 Linux, packet also offloads policies, including trap policies.
1116 The value auto enables full packet or crypto offloading, if ei‐
1117 ther is supported, but the installation does not fail otherwise.
1118 connections.<conn>.children.<child>.copy_df [yes]
1121 Whether to copy the DF bit to the outer IPv4 header in tunnel
1122 mode. This effectively disables Path MTU discovery (PMTUD).
1123 Controlling this behavior is not supported by all kernel inter‐
1124 faces.
1125 connections.<conn>.children.<child>.copy_ecn [yes]
1128 Whether to copy the ECN (Explicit Congestion Notification)
1129 header field to/from the outer IP header in tunnel mode. Con‐
1130 trolling this behavior is not supported by all kernel inter‐
1131 faces.
1132 connections.<conn>.children.<child>.copy_dscp [out]
1135 Whether to copy the DSCP (Differentiated Services Field Code‐
1136 point) header field to/from the outer IP header in tunnel mode.
1137 The value out only copies the field from the inner to the outer
1138 header, the value in does the opposite and only copies the field
1139 from the outer to the inner header when decapsulating, the value
1140 yes copies the field in both directions, and the value no dis‐
1141 ables copying the field altogether. Setting this to yes or in
1142 could allow an attacker to adversely affect other traffic at the
1143 receiver, which is why the default is out. Controlling this be‐
1144 havior is not supported by all kernel interfaces.
1145 connections.<conn>.children.<child>.start_action [none]
1148 Action to perform after loading the configuration. The default
1149 of none loads the connection only, which then can be manually
1150 initiated or used as a responder configuration.
1151 The value trap installs a trap policy, which triggers the tunnel
1153 as soon as matching traffic has been detected. The value start
1154 initiates the connection actively. These two modes can be com‐
1155 bined with trap|start, to immediately initiate a connection for
1156 which trap policies have been installed.
1157 When unloading or replacing a CHILD_SA configuration having a
1159 start_action different from none, the inverse action is per‐
1160 formed. Configurations with start get closed, while such with
1161 trap get uninstalled (both happens for connections with
1162 trap|start).
1163 connections.<conn>.children.<child>.close_action [none]
1167 Action to perform after a CHILD_SA gets closed by the peer. The
1168 default of none does not take any action, trap installs a trap
1169 policy for the CHILD_SA (note that this is redundant if
1170 start_action includes trap). start tries to immediately re-cre‐
1171 ate the CHILD_SA.
1172 close_action does not provide any guarantee that the CHILD_SA is
1174 kept alive. It acts on explicit close messages only, but not on
1175 negotiation failures. Use trap policies to reliably re-create
1176 failed CHILD_SAs.
1177 secrets
1180 Section defining secrets for IKE/EAP/XAuth authentication and
1181 private key decryption. The secrets section takes sub-sections
1182 having a specific prefix which defines the secret type.
1183 It is not recommended to define any private key decryption
1185 passphrases, as then there is no real security benefit in having
1186 encrypted keys. Either store the key unencrypted or enter the
1187 keys manually when loading credentials.
1188 secrets.eap<suffix>
1191 EAP secret section for a specific secret. Each EAP secret is de‐
1192 fined in a unique section having the eap prefix. EAP secrets are
1193 used for XAuth authentication as well.
1194 secrets.eap<suffix>.secret []
1197 Value of the EAP/XAuth secret. It may either be an ASCII string,
1198 a hex encoded string if it has a 0x prefix or a Base64 encoded
1199 string if it has a 0s prefix in its value.
1200 secrets.eap<suffix>.id<suffix> []
1203 Identity the EAP/XAuth secret belongs to. Multiple unique iden‐
1204 tities may be specified, each having an id prefix, if a secret
1205 is shared between multiple users.
1206 secrets.xauth<suffix>
1209 XAuth secret section for a specific secret. xauth is just an
1210 alias for eap, secrets under both section prefixes are used for
1211 both EAP and XAuth authentication.
1212 secrets.ntlm<suffix>
1215 NTLM secret section for a specific secret. Each NTLM secret is
1216 defined in a unique section having the ntlm prefix. NTLM secrets
1217 may only be used for EAP-MSCHAPv2 authentication.
1218 secrets.ntlm<suffix>.secret []
1221 Value of the NTLM secret, which is the NT Hash of the actual se‐
1222 cret, that is, MD4(UTF-16LE(secret)). The resulting 16-byte
1223 value may either be given as a hex encoded string with a 0x pre‐
1224 fix or as a Base64 encoded string with a 0s prefix.
1225 secrets.ntlm<suffix>.id<suffix> []
1228 Identity the NTLM secret belongs to. Multiple unique identities
1229 may be specified, each having an id prefix, if a secret is
1230 shared between multiple users.
1231 secrets.ike<suffix>
1234 IKE preshared secret section for a specific secret. Each IKE PSK
1235 is defined in a unique section having the ike prefix.
1236 secrets.ike<suffix>.secret []
1239 Value of the IKE preshared secret. It may either be an ASCII
1240 string, a hex encoded string if it has a 0x prefix or a Base64
1241 encoded string if it has a 0s prefix in its value.
1242 secrets.ike<suffix>.id<suffix> []
1245 IKE identity the IKE preshared secret belongs to. Multiple
1246 unique identities may be specified, each having an id prefix, if
1247 a secret is shared between multiple peers.
1248 secrets.ppk<suffix>
1251 Postquantum Preshared Key (PPK) section for a specific secret.
1252 Each PPK is defined in a unique section having the ppk pre‐
1253 fix.
1254 secrets.ppk<suffix>.secret []
1257 Value of the PPK. It may either be an ASCII string, a hex
1258 encoded string if it has a 0x prefix or a Base64 encoded string
1259 if it has a 0s prefix in its value. Should have at least 256
1260 bits of entropy for 128-bit security.
1261 secrets.ppk<suffix>.id<suffix> []
1264 PPK identity the PPK belongs to. Multiple unique identities may
1265 be specified, each having an id prefix, if a secret is shared
1266 between multiple peers.
1267 secrets.private<suffix>
1270 Private key decryption passphrase for a key in the private
1271 folder.
1272 secrets.private<suffix>.file []
1275 File name in the private folder for which this passphrase should
1276 be used.
1277 secrets.private<suffix>.secret []
1280 Value of decryption passphrase for private key.
1281 secrets.rsa<suffix>
1284 Private key decryption passphrase for a key in the rsa folder.
1285 secrets.rsa<suffix>.file []
1288 File name in the rsa folder for which this passphrase should be
1289 used.
1290 secrets.rsa<suffix>.secret []
1293 Value of decryption passphrase for RSA key.
1294 secrets.ecdsa<suffix>
1297 Private key decryption passphrase for a key in the ecdsa folder.
1298 secrets.ecdsa<suffix>.file []
1301 File name in the ecdsa folder for which this passphrase should
1302 be used.
1303 secrets.ecdsa<suffix>.secret []
1306 Value of decryption passphrase for ECDSA key.
1307 secrets.pkcs8<suffix>
1310 Private key decryption passphrase for a key in the pkcs8 folder.
1311 secrets.pkcs8<suffix>.file []
1314 File name in the pkcs8 folder for which this passphrase should
1315 be used.
1316 secrets.pkcs8<suffix>.secret []
1319 Value of decryption passphrase for PKCS#8 key.
1320 secrets.pkcs12<suffix>
1323 PKCS#12 decryption passphrase for a container in the pkcs12
1324 folder.
1325 secrets.pkcs12<suffix>.file []
1328 File name in the pkcs12 folder for which this passphrase should
1329 be used.
1330 secrets.pkcs12<suffix>.secret []
1333 Value of decryption passphrase for PKCS#12 container.
1334 secrets.token<suffix>
1337 Definition for a private key that's stored on a token/smartcard.
1338 secrets.token<suffix>.handle []
1341 Hex-encoded CKA_ID of the private key on the token.
1342 secrets.token<suffix>.slot []
1345 Optional slot number to access the token.
1346 secrets.token<suffix>.module []
1349 Optional PKCS#11 module name to access the token.
1350 secrets.token<suffix>.pin []
1353 Optional PIN required to access the key on the token. If none is
1354 provided the user is prompted during an interactive --load-creds
1355 call.
1356 pools
1359 Section defining named pools. Named pools may be referenced by
1360 connections with the pools option to assign virtual IPs and
1361 other configuration attributes.
1362 pools.<name>
1365 Section defining a single pool with a unique name.
1366 pools.<name>.addrs []
1369 Subnet or range defining addresses allocated in pool. Accepts a
1370 single CIDR subnet defining the pool to allocate addresses from
1371 or an address range (<from>-<to>). Pools must be unique and
1372 non-overlapping.
1373 pools.<name>.<attr> []
1376 Comma separated list of additional attributes of type <attr>.
1377 The attribute type may be one of dns, nbns, dhcp, netmask,
1378 server, subnet, split_include and split_exclude to define ad‐
1379 dresses or CIDR subnets for the corresponding attribute types.
1380 Alternatively, <attr> can be a numerical identifier, for which
1381 string attribute values are accepted as well.
1382 authorities
1385 Section defining attributes of certification authorities.
1386 authorities.<name>
1389 Section defining a certification authority with a unique name.
1390 authorities.<name>.cacert []
1393 CA certificate belonging to the certification authority. The
1394 certificates may use a relative path from the swanctl x509ca di‐
1395 rectory or an absolute path.
1396 Configure one of cacert, file, or handle per section.
1398 authorities.<name>.file []
1401 Absolute path to the certificate to load. Passed as-is to the
1402 daemon, so it must be readable by it.
1403 Configure one of cacert, file, or handle per section.
1405 authorities.<name>.handle []
1408 Hex-encoded CKA_ID of the CA certificate on a token.
1409 Configure one of cacert, file, or handle per section.
1411 authorities.<name>.slot []
1414 Optional slot number of the token that stores the CA certifi‐
1415 cate.
1416 authorities.<name>.module []
1419 Optional PKCS#11 module name.
1420 authorities.<name>.crl_uris []
1423 Comma-separated list of CRL distribution points (ldap, http, or
1424 file URI).
1425 authorities.<name>.ocsp_uris []
1428 Comma-separated list of OCSP URIs.
1429 authorities.<name>.cert_uri_base []
1432 Defines the base URI for the Hash and URL feature supported by
1433 IKEv2. Instead of exchanging complete certificates, IKEv2 allows
1434 one to send an URI that resolves to the DER encoded certificate.
1435 The certificate URIs are built by appending the SHA1 hash of the
1436 DER encoded certificates to this base URI.
1437
1440 /etc/strongswan/swanctl/swanctl.conf configuration file
1441
1443 swanctl(8)
14445.9.11 SWANCTL.CONF(5)