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 how to reference
13 sections or split the configuration in multiple files by including
14 other files, refer to strongswan.conf(5).
15
18 For all options that define a time, the time is specified in seconds.
19 The s, m, h and d suffixes explicitly define the units for seconds,
20 minutes, hours and days, respectively.
21
24 The following settings can be used to configure connections, creden‐
25 tials and pools.
26 connections
28 Section defining IKE connection configurations.
29 The connections section defines IKE connection configurations,
31 each in its own subsections. In the keyword description below,
32 the connection is named <conn>, but an arbitrary yet unique con‐
33 nection name can be chosen for each connection subsection.
34 connections.<conn>
37 Section for an IKE connection named <conn>.
38 connections.<conn>.version [0]
41 IKE major version to use for connection. 1 uses IKEv1 aka
42 ISAKMP, 2 uses IKEv2. A connection using the default of 0 ac‐
43 cepts both IKEv1 and IKEv2 as responder, and initiates the con‐
44 nection actively with IKEv2.
45 connections.<conn>.local_addrs [%any]
48 Local address(es) to use for IKE communication, comma separated.
49 Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP
50 address ranges.
51 As initiator, the first non-range/non-subnet is used to initiate
53 the connection from. As responder, the local destination address
54 must match at least to one of the specified addresses, subnets
55 or ranges.
56 If FQDNs are assigned they are resolved every time a configura‐
58 tion lookup is done. If DNS resolution times out, the lookup is
59 delayed for that time.
60 connections.<conn>.remote_addrs [%any]
63 Remote address(es) to use for IKE communication, comma sepa‐
64 rated. Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets
65 or IP address ranges.
66 As initiator, the first non-range/non-subnet is used to initiate
68 the connection to. As responder, the initiator source address
69 must match at least to one of the specified addresses, subnets
70 or ranges.
71 If FQDNs are assigned they are resolved every time a configura‐
73 tion lookup is done. If DNS resolution times out, the lookup is
74 delayed for that time.
75 To initiate a connection, at least one specific address or DNS
77 name must be specified.
78 connections.<conn>.local_port [500]
81 Local UDP port for IKE communication. By default the port of the
82 socket backend is used, which is usually 500. If port 500 is
83 used, automatic IKE port floating to port 4500 is used to work
84 around NAT issues.
85 Using a non-default local IKE port requires support from the
87 socket backend in use (socket-dynamic).
88 connections.<conn>.remote_port [500]
91 Remote UDP port for IKE communication. If the default of port
92 500 is used, automatic IKE port floating to port 4500 is used to
93 work around NAT issues.
94 connections.<conn>.proposals [default]
97 A proposal is a set of algorithms. For non-AEAD algorithms, this
98 includes for IKE an encryption algorithm, an integrity algo‐
99 rithm, a pseudo random function and a Diffie-Hellman group. For
100 AEAD algorithms, instead of encryption and integrity algorithms,
101 a combined algorithm is used.
102 In IKEv2, multiple algorithms of the same kind can be specified
104 in a single proposal, from which one gets selected. In IKEv1,
105 only one algorithm per kind is allowed per proposal, more algo‐
106 rithms get implicitly stripped. Use multiple proposals to offer
107 different algorithms combinations in IKEv1.
108 Algorithm keywords get separated using dashes. Multiple propos‐
110 als may be separated by commas. The special value default forms
111 a default proposal of supported algorithms considered safe, and
112 is usually a good choice for interoperability.
113 connections.<conn>.vips []
116 Comma separated list of virtual IPs to request in IKEv2 configu‐
117 ration payloads or IKEv1 Mode Config. The wildcard addresses
118 0.0.0.0 and :: request an arbitrary address, specific addresses
119 may be defined. The responder may return a different address,
120 though, or none at all.
121 connections.<conn>.aggressive [no]
124 Enables Aggressive Mode instead of Main Mode with Identity Pro‐
125 tection. Aggressive Mode is considered less secure, because the
126 ID and HASH payloads are exchanged unprotected. This allows a
127 passive attacker to snoop peer identities, and even worse, start
128 dictionary attacks on the Preshared Key.
129 connections.<conn>.pull [yes]
132 If the default of yes is used, Mode Config works in pull mode,
133 where the initiator actively requests a virtual IP. With no,
134 push mode is used, where the responder pushes down a virtual IP
135 to the initiating peer.
136 Push mode is currently supported for IKEv1, but not in IKEv2. It
138 is used by a few implementations only, pull mode is recommended.
139 connections.<conn>.dscp [000000]
142 Differentiated Services Field Codepoint to set on outgoing IKE
143 packets for this connection. The value is a six digit binary en‐
144 coded string specifying the Codepoint to set, as defined in RFC
145 2474.
146 connections.<conn>.encap [no]
149 To enforce UDP encapsulation of ESP packets, the IKE daemon can
150 fake the NAT detection payloads. This makes the peer believe
151 that NAT takes place on the path, forcing it to encapsulate ESP
152 packets in UDP.
153 Usually this is not required, but it can help to work around
155 connectivity issues with too restrictive intermediary firewalls.
156 connections.<conn>.mobike [yes]
159 Enables MOBIKE on IKEv2 connections. MOBIKE is enabled by de‐
160 fault on IKEv2 connections, and allows mobility of clients and
161 multi-homing on servers by migrating active IPsec tunnels.
162 Usually keeping MOBIKE enabled is unproblematic, as it is not
164 used if the peer does not indicate support for it. However, due
165 to the design of MOBIKE, IKEv2 always floats to port 4500 start‐
166 ing from the second exchange. Some implementations don't like
167 this behavior, hence it can be disabled.
168 connections.<conn>.dpd_delay [0s]
171 Interval to check the liveness of a peer actively using IKEv2
172 INFORMATIONAL exchanges or IKEv1 R_U_THERE messages. Active DPD
173 checking is only enforced if no IKE or ESP/AH packet has been
174 received for the configured DPD delay.
175 connections.<conn>.dpd_timeout [0s]
178 Charon by default uses the normal retransmission mechanism and
179 timeouts to check the liveness of a peer, as all messages are
180 used for liveness checking. For compatibility reasons, with
181 IKEv1 a custom interval may be specified; this option has no ef‐
182 fect on connections using IKE2.
183 connections.<conn>.fragmentation [yes]
186 Use IKE fragmentation (proprietary IKEv1 extension or RFC 7383
187 IKEv2 fragmentation). Acceptable values are yes (the
188 default), accept, force and no. If set to yes, and the peer
189 supports it, oversized IKE messages will be sent in fragments.
190 If set to accept, support for fragmentation is announced to the
191 peer but the daemon does not send its own messages in fragments.
192 If set to force (only supported for IKEv1) the initial IKE mes‐
193 sage will already be fragmented if required. Finally, setting
194 the option to no will disable announcing support for this fea‐
195 ture.
196 Note that fragmented IKE messages sent by a peer are always ac‐
198 cepted irrespective of the value of this option (even when set
199 to no).
200 connections.<conn>.childless [allow]
204 Use childless IKE_SA initiation (RFC 6023) for IKEv2. Accept‐
205 able values are allow (the default), force and never. If set to
206 allow, responders will accept childless IKE_SAs (as indicated
207 via notify in the IKE_SA_INIT response) while initiators con‐
208 tinue to create regular IKE_SAs with the first CHILD_SA created
209 during IKE_AUTH, unless the IKE_SA is initiated explicitly with‐
210 out any children (which will fail if the responder does not sup‐
211 port or has disabled this extension). If set to force, only
212 childless initiation is accepted and the first CHILD_SA is cre‐
213 ated with a separate CREATE_CHILD_SA exchange (e.g. to use an
214 independent DH exchange for all CHILD_SAs). Finally, setting
215 the option to never disables support for childless IKE_SAs as
216 responder.
217 connections.<conn>.send_certreq [yes]
220 Send certificate request payloads to offer trusted root CA cer‐
221 tificates to the peer. Certificate requests help the peer to
222 choose an appropriate certificate/private key for authentication
223 and are enabled by default.
224 Disabling certificate requests can be useful if too many trusted
226 root CA certificates are installed, as each certificate request
227 increases the size of the initial IKE packets.
228 connections.<conn>.send_cert [ifasked]
231 Send certificate payloads when using certificate authentication.
232 With the default of ifasked the daemon sends certificate pay‐
233 loads only if certificate requests have been received. never
234 disables sending of certificate payloads altogether, always
235 causes certificate payloads to be sent unconditionally whenever
236 certificate authentication is used.
237 connections.<conn>.ppk_id []
240 String identifying the Postquantum Preshared Key (PPK) to be
241 used.
242 connections.<conn>.ppk_required [no]
245 Whether a Postquantum Preshared Key (PPK) is required for this
246 connection.
247 connections.<conn>.keyingtries [1]
250 Number of retransmission sequences to perform during initial
251 connect. Instead of giving up initiation after the first re‐
252 transmission sequence with the default value of 1, additional
253 sequences may be started according to the configured value. A
254 value of 0 initiates a new sequence until the connection estab‐
255 lishes or fails with a permanent error.
256 connections.<conn>.unique [no]
259 Connection uniqueness policy to enforce. To avoid multiple con‐
260 nections from the same user, a uniqueness policy can be en‐
261 forced. The value never does never enforce such a policy, even
262 if a peer included INITIAL_CONTACT notification messages,
263 whereas no replaces existing connections for the same identity
264 if a new one has the INITIAL_CONTACT notify. keep rejects new
265 connection attempts if the same user already has an active con‐
266 nection, replace deletes any existing connection if a new one
267 for the same user gets established.
268 To compare connections for uniqueness, the remote IKE identity
270 is used. If EAP or XAuth authentication is involved, the
271 EAP-Identity or XAuth username is used to enforce the uniqueness
272 policy instead.
273 On initiators this setting specifies whether an INITIAL_CONTACT
275 notify is sent during IKE_AUTH if no existing connection is
276 found with the remote peer (determined by the identities of the
277 first authentication round). Unless set to never the client will
278 send a notify.
279 connections.<conn>.reauth_time [0s]
282 Time to schedule IKE reauthentication. IKE reauthentication
283 recreates the IKE/ISAKMP SA from scratch and re-evaluates the
284 credentials. In asymmetric configurations (with EAP or configu‐
285 ration payloads) it might not be possible to actively reauthen‐
286 ticate as responder. The IKEv2 reauthentication lifetime negoti‐
287 ation can instruct the client to perform reauthentication.
288 Reauthentication is disabled by default. Enabling it usually may
290 lead to small connection interruptions, as strongSwan uses a
291 break-before-make policy with IKEv2 to avoid any conflicts with
292 associated tunnel resources.
293 connections.<conn>.rekey_time [4h]
296 IKE rekeying refreshes key material using a Diffie-Hellman ex‐
297 change, but does not re-check associated credentials. It is sup‐
298 ported in IKEv2 only, IKEv1 performs a reauthentication proce‐
299 dure instead.
300 With the default value IKE rekeying is scheduled every 4 hours,
302 minus the configured rand_time. If a reauth_time is configured,
303 rekey_time defaults to zero disabling rekeying; explicitly set
304 both to enforce rekeying and reauthentication.
305 connections.<conn>.over_time [10% of rekey_time/reauth_time]
308 Hard IKE_SA lifetime if rekey/reauth does not complete, as time.
309 To avoid having an IKE/ISAKMP kept alive if IKE reauthentication
310 or rekeying fails perpetually, a maximum hard lifetime may be
311 specified. If the IKE_SA fails to rekey or reauthenticate within
312 the specified time, the IKE_SA gets closed.
313 In contrast to CHILD_SA rekeying, over_time is relative in time
315 to the rekey_time and reauth_time values, as it applies to both.
316 The default is 10% of the longer of rekey_time and reauth_time.
318 connections.<conn>.rand_time [over_time]
322 Time range from which to choose a random value to subtract from
323 rekey/reauth times. To avoid having both peers initiating the
324 rekey/reauth procedure simultaneously, a random time gets sub‐
325 tracted from the rekey/reauth times.
326 The default is equal to the configured over_time.
328 connections.<conn>.pools []
332 Comma separated list of named IP pools to allocate virtual IP
333 addresses and other configuration attributes from. Each name
334 references a pool by name from either the pools section or an
335 external pool.
336 connections.<conn>.if_id_in [0]
339 XFRM interface ID set on inbound policies/SA, can be overridden
340 by child config, see there for details.
341 connections.<conn>.if_id_out [0]
344 XFRM interface ID set on outbound policies/SA, can be overridden
345 by child config, see there for details.
346 connections.<conn>.mediation [no]
349 Whether this connection is a mediation connection, that is,
350 whether this connection is used to mediate other connections us‐
351 ing the IKEv2 Mediation Extension. Mediation connections create
352 no CHILD_SA.
353 connections.<conn>.mediated_by []
356 The name of the connection to mediate this connection through.
357 If given, the connection will be mediated through the named me‐
358 diation connection. The mediation connection must have mediation
359 enabled.
360 connections.<conn>.mediation_peer []
363 Identity under which the peer is registered at the mediation
364 server, that is, the IKE identity the other end of this connec‐
365 tion uses as its local identity on its connection to the media‐
366 tion server. This is the identity we request the mediation
367 server to mediate us with. Only relevant on connections that set
368 mediated_by. If it is not given, the remote IKE identity of the
369 first authentication round of this connection will be used.
370 connections.<conn>.local<suffix>
373 Section for a local authentication round. A local authentication
374 round defines the rules how authentication is performed for the
375 local peer. Multiple rounds may be defined to use IKEv2 RFC 4739
376 Multiple Authentication or IKEv1 XAuth.
377 Each round is defined in a section having local as prefix, and
379 an optional unique suffix. To define a single authentication
380 round, the suffix may be omitted.
381 connections.<conn>.local<suffix>.round [0]
384 Optional numeric identifier by which authentication rounds are
385 sorted. If not specified rounds are ordered by their position
386 in the config file/VICI message.
387 connections.<conn>.local<suffix>.certs []
390 Comma separated list of certificate candidates to use for au‐
391 thentication. The certificates may use a relative path from the
392 swanctl x509 directory or an absolute path.
393 The certificate used for authentication is selected based on the
395 received certificate request payloads. If no appropriate CA can
396 be located, the first certificate is used.
397 connections.<conn>.local<suffix>.cert<suffix> []
400 Section for a certificate candidate to use for authentication.
401 Certificates in certs are transmitted as binary blobs, these
402 sections offer more flexibility.
403 connections.<conn>.local<suffix>.cert<suffix>.file []
406 Absolute path to the certificate to load. Passed as-is to the
407 daemon, so it must be readable by it.
408 Configure either this or handle, but not both, in one section.
410 connections.<conn>.local<suffix>.cert<suffix>.handle []
413 Hex-encoded CKA_ID of the certificate on a token.
414 Configure either this or file, but not both, in one section.
416 connections.<conn>.local<suffix>.cert<suffix>.slot []
419 Optional slot number of the token that stores the certificate.
420 connections.<conn>.local<suffix>.cert<suffix>.module []
423 Optional PKCS#11 module name.
424 connections.<conn>.local<suffix>.pubkeys []
427 Comma separated list of raw public key candidates to use for au‐
428 thentication. The public keys may use a relative path from the
429 swanctl pubkey directory or an absolute path.
430 Even though multiple local public keys could be defined in prin‐
432 ciple, only the first public key in the list is used for authen‐
433 tication.
434 connections.<conn>.local<suffix>.auth [pubkey]
437 Authentication to perform locally. pubkey uses public key au‐
438 thentication using a private key associated to a usable certifi‐
439 cate. psk uses pre-shared key authentication. The IKEv1 spe‐
440 cific xauth is used for XAuth or Hybrid authentication, while
441 the IKEv2 specific eap keyword defines EAP authentication.
442 For xauth, a specific backend name may be appended, separated by
444 a dash. The appropriate xauth backend is selected to perform the
445 XAuth exchange. For traditional XAuth, the xauth method is usu‐
446 ally defined in the second authentication round following an
447 initial pubkey (or psk) round. Using xauth in the first round
448 performs Hybrid Mode client authentication.
449 For eap, a specific EAP method name may be appended, separated
451 by a dash. An EAP module implementing the appropriate method is
452 selected to perform the EAP conversation.
453 If both peers support RFC 7427 ("Signature Authentication in
455 IKEv2") specific hash algorithms to be used during IKEv2 authen‐
456 tication may be configured. To do so use ike: followed by a
457 trust chain signature scheme constraint (see description of the
458 remote section's auth keyword). For example, with ike:pub‐
459 key-sha384-sha256 a public key signature scheme with either
460 SHA-384 or SHA-256 would get used for authentication, in that
461 order and depending on the hash algorithms supported by the
462 peer. If no specific hash algorithms are configured, the default
463 is to prefer an algorithm that matches or exceeds the strength
464 of the signature key. If no constraints with ike: prefix are
465 configured any signature scheme constraint (without ike: prefix)
466 will also apply to IKEv2 authentication, unless this is disabled
467 in strongswan.conf(5). To use RSASSA-PSS signatures use rsa/pss
468 instead of pubkey or rsa as in e.g. ike:rsa/pss-sha256. If
469 pubkey or rsa constraints are configured RSASSA-PSS signatures
470 will only be used if enabled in strongswan.conf(5).
471 connections.<conn>.local<suffix>.id []
475 IKE identity to use for authentication round. When using cer‐
476 tificate authentication, the IKE identity must be contained in
477 the certificate, either as subject or as subjectAltName.
478 The identity can be an IP address, a fully-qualified domain
480 name, an email address or a Distinguished Name for which the ID
481 type is determined automatically and the string is converted to
482 the appropriate encoding. To enforce a specific identity type, a
483 prefix may be used, followed by a colon (:). If the number sign
484 (#) follows the colon, the remaining data is interpreted as hex
485 encoding, otherwise the string is used as-is as the identifica‐
486 tion data. Note that this implies that no conversion is per‐
487 formed for non-string identities. For example, ipv4:10.0.0.1
488 does not create a valid ID_IPV4_ADDR IKE identity, as it does
489 not get converted to binary 0x0a000001. Instead, one could use
490 ipv4:#0a000001 to get a valid identity, but just using the im‐
491 plicit type with automatic conversion is usually simpler. The
492 same applies to the ASN1 encoded types. The following prefixes
493 are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns,
494 asn1dn, asn1gn and keyid. Custom type prefixes may be specified
495 by surrounding the numerical type value by curly brackets.
496 connections.<conn>.local<suffix>.eap_id [id]
499 Client EAP-Identity to use in EAP-Identity exchange and the EAP
500 method.
501 connections.<conn>.local<suffix>.aaa_id [remote-id]
504 Server side EAP-Identity to expect in the EAP method. Some EAP
505 methods, such as EAP-TLS, use an identity for the server to per‐
506 form mutual authentication. This identity may differ from the
507 IKE identity, especially when EAP authentication is delegated
508 from the IKE responder to an AAA backend.
509 For EAP-(T)TLS, this defines the identity for which the server
511 must provide a certificate in the TLS exchange.
512 connections.<conn>.local<suffix>.xauth_id [id]
515 Client XAuth username used in the XAuth exchange.
516 connections.<conn>.remote<suffix>
519 Section for a remote authentication round. A remote authentica‐
520 tion round defines the constraints how the peers must authenti‐
521 cate to use this connection. Multiple rounds may be defined to
522 use IKEv2 RFC 4739 Multiple Authentication or IKEv1 XAuth.
523 Each round is defined in a section having remote as prefix, and
525 an optional unique suffix. To define a single authentication
526 round, the suffix may be omitted.
527 connections.<conn>.remote<suffix>.round [0]
530 Optional numeric identifier by which authentication rounds are
531 sorted. If not specified rounds are ordered by their position
532 in the config file/VICI message.
533 connections.<conn>.remote<suffix>.id [%any]
536 IKE identity to expect for authentication round. Refer to the
537 local section's id keyword for details.
538 It's possible to use wildcards to match remote identities (e.g.
540 *@strongswan.org, *.strongswan.org, or C=CH,O=strongSwan,CN=*).
541 Connections with exact matches are preferred. When using distin‐
542 guished names with wildcards, the charon.rdn_matching option in
543 strongswan.conf(5) specifies how RDNs are matched.
544 connections.<conn>.remote<suffix>.eap_id [id]
547 Identity to use as peer identity during EAP authentication. If
548 set to %any the EAP-Identity method will be used to ask the
549 client for an identity.
550 connections.<conn>.remote<suffix>.groups []
553 Comma separated authorization group memberships to require. The
554 peer must prove membership to at least one of the specified
555 groups. Group membership can be certified by different means,
556 for example by appropriate Attribute Certificates or by an AAA
557 backend involved in the authentication.
558 connections.<conn>.remote<suffix>.cert_policy []
561 Comma separated list of certificate policy OIDs the peer's cer‐
562 tificate must have. OIDs are specified using the numerical dot‐
563 ted representation.
564 connections.<conn>.remote<suffix>.certs []
567 Comma separated list of certificates to accept for authentica‐
568 tion. The certificates may use a relative path from the swanctl
569 x509 directory or an absolute path.
570 connections.<conn>.remote<suffix>.cert<suffix> []
573 Section for a certificate to accept for authentication. Certifi‐
574 cates in certs are transmitted as binary blobs, these sections
575 offer more flexibility.
576 connections.<conn>.remote<suffix>.cert<suffix>.file []
579 Absolute path to the certificate to load. Passed as-is to the
580 daemon, so it must be readable by it.
581 Configure either this or handle, but not both, in one section.
583 connections.<conn>.remote<suffix>.cert<suffix>.handle []
586 Hex-encoded CKA_ID of the certificate on a token.
587 Configure either this or file, but not both, in one section.
589 connections.<conn>.remote<suffix>.cert<suffix>.slot []
592 Optional slot number of the token that stores the certificate.
593 connections.<conn>.remote<suffix>.cert<suffix>.module []
596 Optional PKCS#11 module name.
597 connections.<conn>.remote<suffix>.cacerts []
600 Comma separated list of CA certificates to accept for authenti‐
601 cation. The certificates may use a relative path from the
602 swanctl x509ca directory or an absolute path.
603 connections.<conn>.remote<suffix>.cacert<suffix> []
606 Section for a CA certificate to accept for authentication. Cer‐
607 tificates in cacerts are transmitted as binary blobs, these sec‐
608 tions offer more flexibility.
609 connections.<conn>.remote<suffix>.cacert<suffix>.file []
612 Absolute path to the certificate to load. Passed as-is to the
613 daemon, so it must be readable by it.
614 Configure either this or handle, but not both, in one section.
616 connections.<conn>.remote<suffix>.cacert<suffix>.handle []
619 Hex-encoded CKA_ID of the CA certificate on a token.
620 Configure either this or file, but not both, in one section.
622 connections.<conn>.remote<suffix>.cacert<suffix>.slot []
625 Optional slot number of the token that stores the CA certifi‐
626 cate.
627 connections.<conn>.remote<suffix>.cacert<suffix>.module []
630 Optional PKCS#11 module name.
631 connections.<conn>.remote<suffix>.ca_id []
634 The specified identity must be contained in one (intermediate)
635 CA of the remote peer trustchain, either as subject or as sub‐
636 jectAltName. This has the same effect as specifying cacerts to
637 force clients under a CA to specific connections; it does not
638 require the CA certificate to be available locally, and can be
639 received from the peer during the IKE exchange.
640 connections.<conn>.remote<suffix>.pubkeys []
643 Comma separated list of raw public keys to accept for authenti‐
644 cation. The public keys may use a relative path from the swanctl
645 pubkey directory or an absolute path.
646 connections.<conn>.remote<suffix>.revocation [relaxed]
649 Certificate revocation policy for CRL or OCSP revocation.
650 A strict revocation policy fails if no revocation information is
652 available, i.e. the certificate is not known to be unrevoked.
653 ifuri fails only if a CRL/OCSP URI is available, but certificate
655 revocation checking fails, i.e. there should be revocation in‐
656 formation available, but it could not be obtained.
657 The default revocation policy relaxed fails only if a certifi‐
659 cate is revoked, i.e. it is explicitly known that it is bad.
660 connections.<conn>.remote<suffix>.auth [pubkey]
663 Authentication to expect from remote. See the local section's
664 auth keyword description about the details of supported mecha‐
665 nisms.
666 To require a trustchain public key strength for the remote side,
668 specify the key type followed by the minimum strength in bits
669 (for example ecdsa-384 or rsa-2048-ecdsa-256). To limit the ac‐
670 ceptable set of hashing algorithms for trustchain validation,
671 append hash algorithms to pubkey or a key strength definition
672 (for example pubkey-sha256-sha512, rsa-2048-sha256-sha384-sha512
673 or rsa-2048-sha256-ecdsa-256-sha256-sha384). Unless disabled in
674 strongswan.conf(5), or explicit IKEv2 signature constraints are
675 configured (refer to the description of the local section's auth
676 keyword for details), such key types and hash algorithms are
677 also applied as constraints against IKEv2 signature authentica‐
678 tion schemes used by the remote side. To require RSASSA-PSS sig‐
679 natures use rsa/pss instead of pubkey or rsa as in e.g.
680 rsa/pss-sha256. If pubkey or rsa constraints are configured
681 RSASSA-PSS signatures will only be accepted if enabled in
682 strongswan.conf(5).
683 To specify trust chain constraints for EAP-(T)TLS, append a
686 colon to the EAP method, followed by the key type/size and hash
687 algorithm as discussed above (e.g. eap-tls:ecdsa-384-sha384).
688 connections.<conn>.children.<child>
692 CHILD_SA configuration sub-section. Each connection definition
693 may have one or more sections in its children subsection. The
694 section name defines the name of the CHILD_SA configuration,
695 which must be unique within the connection.
696 connections.<conn>.children.<child>.ah_proposals []
699 AH proposals to offer for the CHILD_SA. A proposal is a set of
700 algorithms. For AH, this includes an integrity algorithm and an
701 optional Diffie-Hellman group. If a DH group is specified,
702 CHILD_SA/Quick Mode rekeying and initial negotiation uses a sep‐
703 arate Diffie-Hellman exchange using the specified group (refer
704 to esp_proposals for details).
705 In IKEv2, multiple algorithms of the same kind can be specified
707 in a single proposal, from which one gets selected. In IKEv1,
708 only one algorithm per kind is allowed per proposal, more algo‐
709 rithms get implicitly stripped. Use multiple proposals to offer
710 different algorithms combinations in IKEv1.
711 Algorithm keywords get separated using dashes. Multiple propos‐
713 als may be separated by commas. The special value default forms
714 a default proposal of supported algorithms considered safe, and
715 is usually a good choice for interoperability. By default no AH
716 proposals are included, instead ESP is proposed.
717 connections.<conn>.children.<child>.esp_proposals [default]
720 ESP proposals to offer for the CHILD_SA. A proposal is a set of
721 algorithms. For ESP non-AEAD proposals, this includes an integ‐
722 rity algorithm, an encryption algorithm, an optional
723 Diffie-Hellman group and an optional Extended Sequence Number
724 Mode indicator. For AEAD proposals, a combined mode algorithm is
725 used instead of the separate encryption/integrity algorithms.
726 If a DH group is specified, CHILD_SA/Quick Mode rekeying and
728 initial negotiation use a separate Diffie-Hellman exchange using
729 the specified group. However, for IKEv2, the keys of the
730 CHILD_SA created implicitly with the IKE_SA will always be de‐
731 rived from the IKE_SA's key material. So any DH group specified
732 here will only apply when the CHILD_SA is later rekeyed or is
733 created with a separate CREATE_CHILD_SA exchange. A proposal
734 mismatch might, therefore, not immediately be noticed when the
735 SA is established, but may later cause rekeying to fail.
736 Extended Sequence Number support may be indicated with the esn
738 and noesn values, both may be included to indicate support for
739 both modes. If omitted, noesn is assumed.
740 In IKEv2, multiple algorithms of the same kind can be specified
742 in a single proposal, from which one gets selected. In IKEv1,
743 only one algorithm per kind is allowed per proposal, more algo‐
744 rithms get implicitly stripped. Use multiple proposals to offer
745 different algorithms combinations in IKEv1.
746 Algorithm keywords get separated using dashes. Multiple propos‐
748 als may be separated by commas. The special value default forms
749 a default proposal of supported algorithms considered safe, and
750 is usually a good choice for interoperability. If no algorithms
751 are specified for AH nor ESP, the default set of algorithms for
752 ESP is included.
753 connections.<conn>.children.<child>.sha256_96 [no]
756 HMAC-SHA-256 is used with 128-bit truncation with IPsec. For
757 compatibility with implementations that incorrectly use 96-bit
758 truncation this option may be enabled to configure the shorter
759 truncation length in the kernel. This is not negotiated, so
760 this only works with peers that use the incorrect truncation
761 length (or have this option enabled).
762 connections.<conn>.children.<child>.local_ts [dynamic]
765 Comma separated list of local traffic selectors to include in
766 CHILD_SA. Each selector is a CIDR subnet definition, followed by
767 an optional proto/port selector. The special value dynamic may
768 be used instead of a subnet definition, which gets replaced by
769 the tunnel outer address or the virtual IP, if negotiated. This
770 is the default.
771 A protocol/port selector is surrounded by opening and closing
773 square brackets. Between these brackets, a numeric or getser‐
774 vent(3) protocol name may be specified. After the optional pro‐
775 tocol restriction, an optional port restriction may be speci‐
776 fied, separated by a slash. The port restriction may be numeric,
777 a getservent(3) service name, or the special value opaque for
778 RFC 4301 OPAQUE selectors. Port ranges may be specified as well,
779 none of the kernel backends currently support port ranges,
780 though.
781 When IKEv1 is used only the first selector is interpreted, ex‐
783 cept if the Cisco Unity extension plugin is used. This is due to
784 a limitation of the IKEv1 protocol, which only allows a single
785 pair of selectors per CHILD_SA. So to tunnel traffic matched by
786 several pairs of selectors when using IKEv1 several children
787 (CHILD_SAs) have to be defined that cover the selectors.
788 The IKE daemon uses traffic selector narrowing for IKEv1, the
790 same way it is standardized and implemented for IKEv2. However,
791 this may lead to problems with other implementations. To avoid
792 that, configure identical selectors in such scenarios.
793 connections.<conn>.children.<child>.remote_ts [dynamic]
796 Comma separated list of remote selectors to include in CHILD_SA.
797 See local_ts for a description of the selector syntax.
798 connections.<conn>.children.<child>.rekey_time [1h]
801 Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes
802 key material, optionally using a Diffie-Hellman exchange if a
803 group is specified in the proposal.
804 To avoid rekey collisions initiated by both ends simultaneously,
806 a value in the range of rand_time gets subtracted to form the
807 effective soft lifetime.
808 By default CHILD_SA rekeying is scheduled every hour, minus
810 rand_time.
811 connections.<conn>.children.<child>.life_time [rekey_time + 10%]
815 Maximum lifetime before CHILD_SA gets closed. Usually this hard
816 lifetime is never reached, because the CHILD_SA gets rekeyed be‐
817 fore. If that fails for whatever reason, this limit closes the
818 CHILD_SA.
819 The default is 10% more than the rekey_time.
821 connections.<conn>.children.<child>.rand_time [life_time - rekey_time]
825 Time range from which to choose a random value to subtract from
826 rekey_time. The default is the difference between life_time and
827 rekey_time.
828 connections.<conn>.children.<child>.rekey_bytes [0]
832 Number of bytes processed before initiating CHILD_SA rekeying.
833 CHILD_SA rekeying refreshes key material, optionally using a
834 Diffie-Hellman exchange if a group is specified in the proposal.
835 To avoid rekey collisions initiated by both ends simultaneously,
837 a value in the range of rand_bytes gets subtracted to form the
838 effective soft volume limit.
839 Volume based CHILD_SA rekeying is disabled by default.
841 connections.<conn>.children.<child>.life_bytes [rekey_bytes + 10%]
844 Maximum bytes processed before CHILD_SA gets closed. Usually
845 this hard volume limit is never reached, because the CHILD_SA
846 gets rekeyed before. If that fails for whatever reason, this
847 limit closes the CHILD_SA.
848 The default is 10% more than rekey_bytes.
850 connections.<conn>.children.<child>.rand_bytes [life_bytes -
854 rekey_bytes]
855 Byte range from which to choose a random value to subtract from
856 rekey_bytes. The default is the difference between life_bytes
857 and rekey_bytes.
858 connections.<conn>.children.<child>.rekey_packets [0]
862 Number of packets processed before initiating CHILD_SA rekeying.
863 CHILD_SA rekeying refreshes key material, optionally using a
864 Diffie-Hellman exchange if a group is specified in the proposal.
865 To avoid rekey collisions initiated by both ends simultaneously,
867 a value in the range of rand_packets gets subtracted to form the
868 effective soft packet count limit.
869 Packet count based CHILD_SA rekeying is disabled by default.
871 connections.<conn>.children.<child>.life_packets [rekey_packets + 10%]
874 Maximum number of packets processed before CHILD_SA gets closed.
875 Usually this hard packets limit is never reached, because the
876 CHILD_SA gets rekeyed before. If that fails for whatever rea‐
877 son, this limit closes the CHILD_SA.
878 The default is 10% more than rekey_bytes.
880 connections.<conn>.children.<child>.rand_packets [life_packets -
884 rekey_packets]
885 Packet range from which to choose a random value to subtract
886 from rekey_packets. The default is the difference between
887 life_packets and rekey_packets.
888 connections.<conn>.children.<child>.updown []
892 Updown script to invoke on CHILD_SA up and down events.
893 connections.<conn>.children.<child>.hostaccess [no]
896 Hostaccess variable to pass to updown script.
897 connections.<conn>.children.<child>.mode [tunnel]
900 IPsec Mode to establish CHILD_SA with. tunnel negotiates the
901 CHILD_SA in IPsec Tunnel Mode, whereas transport uses IPsec
902 Transport Mode. transport_proxy signifying the special Mobile
903 IPv6 Transport Proxy Mode. beet is the Bound End to End Tunnel
904 mixture mode, working with fixed inner addresses without the
905 need to include them in each packet.
906 Both transport and beet modes are subject to mode negotiation;
908 tunnel mode is negotiated if the preferred mode is not avail‐
909 able.
910 pass and drop are used to install shunt policies which explic‐
912 itly bypass the defined traffic from IPsec processing or drop
913 it, respectively.
914 connections.<conn>.children.<child>.policies [yes]
917 Whether to install IPsec policies or not. Disabling this can be
918 useful in some scenarios e.g. MIPv6, where policies are not man‐
919 aged by the IKE daemon.
920 connections.<conn>.children.<child>.policies_fwd_out [no]
923 Whether to install outbound FWD IPsec policies or not. Enabling
924 this is required in case there is a drop policy that would match
925 and block forwarded traffic for this CHILD_SA.
926 connections.<conn>.children.<child>.dpd_action [clear]
929 Action to perform for this CHILD_SA on DPD timeout. The default
930 clear closes the CHILD_SA and does not take further action.
931 trap installs a trap policy, which will catch matching traffic
932 and tries to re-negotiate the tunnel on-demand (note that this
933 is redundant if start_action includes trap). restart immedi‐
934 ately tries to re-negotiate the CHILD_SA under a fresh IKE_SA.
935 connections.<conn>.children.<child>.ipcomp [no]
938 Enable IPComp compression before encryption. If enabled, IKE
939 tries to negotiate IPComp compression to compress ESP payload
940 data prior to encryption.
941 connections.<conn>.children.<child>.inactivity [0s]
944 Timeout before closing CHILD_SA after inactivity. If no traffic
945 has been processed in either direction for the configured time‐
946 out, the CHILD_SA gets closed due to inactivity. The default
947 value of 0 disables inactivity checks.
948 connections.<conn>.children.<child>.reqid [0]
951 Fixed reqid to use for this CHILD_SA. This might be helpful in
952 some scenarios, but works only if each CHILD_SA configuration is
953 instantiated not more than once. The default of 0 uses dynamic
954 reqids, allocated incrementally.
955 connections.<conn>.children.<child>.priority [0]
958 Optional fixed priority for IPsec policies. This could be useful
959 to install high-priority drop policies. The default of 0 uses
960 dynamically calculated priorities based on the size of the traf‐
961 fic selectors.
962 connections.<conn>.children.<child>.interface []
965 Optional interface name to restrict IPsec policies.
966 connections.<conn>.children.<child>.mark_in [0/0x00000000]
969 Netfilter mark and mask for input traffic. On Linux, Netfilter
970 may require marks on each packet to match an SA/policy having
971 that option set. This allows installing duplicate policies and
972 enables Netfilter rules to select specific SAs/policies for in‐
973 coming traffic. Note that inbound marks are only set on poli‐
974 cies, by default, unless *mark_in_sa* is enabled. The special
975 value %unique sets a unique mark on each CHILD_SA instance, be‐
976 yond that the value %unique-dir assigns a different unique mark
977 for each CHILD_SA direction (in/out).
978 An additional mask may be appended to the mark, separated by /.
980 The default mask if omitted is 0xffffffff.
981 connections.<conn>.children.<child>.mark_in_sa [no]
984 Whether to set *mark_in* on the inbound SA. By default, the in‐
985 bound mark is only set on the inbound policy. The tuple destina‐
986 tion address, protocol and SPI is unique and the mark is not re‐
987 quired to find the correct SA, allowing to mark traffic after
988 decryption instead (where more specific selectors may be used)
989 to match different policies. Marking packets before decryption
990 is still possible, even if no mark is set on the SA.
991 connections.<conn>.children.<child>.mark_out [0/0x00000000]
994 Netfilter mark and mask for output traffic. On Linux, Netfilter
995 may require marks on each packet to match a policy/SA having
996 that option set. This allows installing duplicate policies and
997 enables Netfilter rules to select specific policies/SAs for out‐
998 going traffic. The special value %unique sets a unique mark on
999 each CHILD_SA instance, beyond that the value %unique-dir as‐
1000 signs a different unique mark for each CHILD_SA direction
1001 (in/out).
1002 An additional mask may be appended to the mark, separated by /.
1004 The default mask if omitted is 0xffffffff.
1005 connections.<conn>.children.<child>.set_mark_in [0/0x00000000]
1008 Netfilter mark applied to packets after the inbound IPsec SA
1009 processed them. This way it's not necessary to mark packets via
1010 Netfilter before decryption or right afterwards to match poli‐
1011 cies or process them differently (e.g. via policy routing).
1012 An additional mask may be appended to the mark, separated by /.
1014 The default mask if omitted is 0xffffffff. The special value
1015 %same uses the value (but not the mask) from mark_in as mark
1016 value, which can be fixed, %unique or %unique-dir.
1017 Setting marks in XFRM input requires Linux 4.19 or higher.
1020 connections.<conn>.children.<child>.set_mark_out [0/0x00000000]
1023 Netfilter mark applied to packets after the outbound IPsec SA
1024 processed them. This allows processing ESP packets differently
1025 than the original traffic (e.g. via policy routing).
1026 An additional mask may be appended to the mark, separated by /.
1028 The default mask if omitted is 0xffffffff. The special value
1029 %same uses the value (but not the mask) from mark_out as mark
1030 value, which can be fixed, %unique or %unique-dir.
1031 Setting marks in XFRM output is supported since Linux 4.14. Set‐
1034 ting a mask requires at least Linux 4.19.
1035 connections.<conn>.children.<child>.if_id_in [0]
1038 XFRM interface ID set on inbound policies/SA. This allows in‐
1039 stalling duplicate policies/SAs and associates them with an in‐
1040 terface with the same ID. The special value %unique sets a
1041 unique interface ID on each CHILD_SA instance, beyond that the
1042 value %unique-dir assigns a different unique interface ID for
1043 each CHILD_SA direction (in/out).
1044 connections.<conn>.children.<child>.if_id_out [0]
1047 XFRM interface ID set on outbound policies/SA. This allows in‐
1048 stalling duplicate policies/SAs and associates them with an in‐
1049 terface with the same ID. The special value %unique sets a
1050 unique interface ID on each CHILD_SA instance, beyond that the
1051 value %unique-dir assigns a different unique interface ID for
1052 each CHILD_SA direction (in/out).
1053 The daemon will not install routes for CHILD_SAs that have this
1055 option set.
1056 connections.<conn>.children.<child>.label []
1059 Optional security label (e.g. SELinux context), IKEv2 only. Re‐
1060 fer to label_mode for details on how labels are processed.
1061 connections.<conn>.children.<child>.label_mode [system]
1064 Defines the mode in which the configured security label is used.
1065 The default value of system selects selinux if strongSwan was
1066 built with SELinux support and SELinux is enabled by the kernel,
1067 otherwise, simple will be selected.
1068 If set to simple, the label will be used as is as an additional
1070 identifier/selector on the IKEv2 level when negotiating
1071 CHILD_SAs and selecting configs, labels are not installed in the
1072 kernel and received labels have to match exactly.
1073 If set to selinux, which is only allowed if SELinux is usable on
1075 the system, the configured label is expected to be a generic
1076 context (e.g. system_u:object_r:ipsec_spd_t:s0) for which
1077 flows, whose context match it via association:polmatch, will
1078 trigger an acquire if no SA exists yet for the flow's specific
1079 context. The configured label is installed on (trap) policies,
1080 so this should generally be combined with trap in start_action.
1081 However, if the connection is initiated directly, without ac‐
1082 quire, a childless IKE_SA is established and appropriate trap
1083 policies are installed on both ends. Labels received from peers
1084 are accepted if they match the configured label via associa‐
1085 tion:polmatch.
1086 connections.<conn>.children.<child>.tfc_padding [0]
1089 Pads ESP packets with additional data to have a consistent ESP
1090 packet size for improved Traffic Flow Confidentiality. The pad‐
1091 ding defines the minimum size of all ESP packets sent.
1092 The default value of 0 disables TFC padding, the special value
1094 mtu adds TFC padding to create a packet size equal to the Path
1095 Maximum Transfer Unit.
1096 connections.<conn>.children.<child>.replay_window [32]
1099 IPsec replay window to configure for this CHILD_SA. Larger val‐
1100 ues than the default of 32 are supported using the Netlink back‐
1101 end only, a value of 0 disables IPsec replay protection.
1102 connections.<conn>.children.<child>.hw_offload [no]
1105 Enable hardware offload for this CHILD_SA, if supported by the
1106 IPsec implementation. The value yes enforces offloading and the
1107 installation will fail if it's not supported by either kernel or
1108 device. The value auto enables offloading, if it's sup‐
1109 ported, but the installation does not fail otherwise.
1110 connections.<conn>.children.<child>.copy_df [yes]
1113 Whether to copy the DF bit to the outer IPv4 header in tunnel
1114 mode. This effectively disables Path MTU discovery (PMTUD).
1115 Controlling this behavior is not supported by all kernel inter‐
1116 faces.
1117 connections.<conn>.children.<child>.copy_ecn [yes]
1120 Whether to copy the ECN (Explicit Congestion Notification)
1121 header field to/from the outer IP header in tunnel mode. Con‐
1122 trolling this behavior is not supported by all kernel inter‐
1123 faces.
1124 connections.<conn>.children.<child>.copy_dscp [out]
1127 Whether to copy the DSCP (Differentiated Services Field Code‐
1128 point) header field to/from the outer IP header in tunnel mode.
1129 The value out only copies the field from the inner to the outer
1130 header, the value in does the opposite and only copies the field
1131 from the outer to the inner header when decapsulating, the value
1132 yes copies the field in both directions, and the value no dis‐
1133 ables copying the field altogether. Setting this to yes or in
1134 could allow an attacker to adversely affect other traffic at the
1135 receiver, which is why the default is out. Controlling this be‐
1136 havior is not supported by all kernel interfaces.
1137 connections.<conn>.children.<child>.start_action [none]
1140 Action to perform after loading the configuration. The default
1141 of none loads the connection only, which then can be manually
1142 initiated or used as a responder configuration.
1143 The value trap installs a trap policy, which triggers the tunnel
1145 as soon as matching traffic has been detected. The value start
1146 initiates the connection actively. These two modes can be com‐
1147 bined with trap|start, to immediately initiate a connection for
1148 which trap policies have been installed.
1149 When unloading or replacing a CHILD_SA configuration having a
1151 start_action different from none, the inverse action is per‐
1152 formed. Configurations with start get closed, while such with
1153 trap get uninstalled (both happens for connections with
1154 trap|start).
1155 connections.<conn>.children.<child>.close_action [none]
1159 Action to perform after a CHILD_SA gets closed by the peer. The
1160 default of none does not take any action, trap installs a trap
1161 policy for the CHILD_SA (note that this is redundant if
1162 start_action includes trap). start tries to immediately re-cre‐
1163 ate the CHILD_SA.
1164 close_action does not provide any guarantee that the CHILD_SA is
1166 kept alive. It acts on explicit close messages only, but not on
1167 negotiation failures. Use trap policies to reliably re-create
1168 failed CHILD_SAs.
1169 secrets
1172 Section defining secrets for IKE/EAP/XAuth authentication and
1173 private key decryption. The secrets section takes sub-sections
1174 having a specific prefix which defines the secret type.
1175 It is not recommended to define any private key decryption
1177 passphrases, as then there is no real security benefit in having
1178 encrypted keys. Either store the key unencrypted or enter the
1179 keys manually when loading credentials.
1180 secrets.eap<suffix>
1183 EAP secret section for a specific secret. Each EAP secret is de‐
1184 fined in a unique section having the eap prefix. EAP secrets are
1185 used for XAuth authentication as well.
1186 secrets.eap<suffix>.secret []
1189 Value of the EAP/XAuth secret. It may either be an ASCII string,
1190 a hex encoded string if it has a 0x prefix or a Base64 encoded
1191 string if it has a 0s prefix in its value.
1192 secrets.eap<suffix>.id<suffix> []
1195 Identity the EAP/XAuth secret belongs to. Multiple unique iden‐
1196 tities may be specified, each having an id prefix, if a secret
1197 is shared between multiple users.
1198 secrets.xauth<suffix>
1201 XAuth secret section for a specific secret. xauth is just an
1202 alias for eap, secrets under both section prefixes are used for
1203 both EAP and XAuth authentication.
1204 secrets.ntlm<suffix>
1207 NTLM secret section for a specific secret. Each NTLM secret is
1208 defined in a unique section having the ntlm prefix. NTLM secrets
1209 may only be used for EAP-MSCHAPv2 authentication.
1210 secrets.ntlm<suffix>.secret []
1213 Value of the NTLM secret, which is the NT Hash of the actual se‐
1214 cret, that is, MD4(UTF-16LE(secret)). The resulting 16-byte
1215 value may either be given as a hex encoded string with a 0x pre‐
1216 fix or as a Base64 encoded string with a 0s prefix.
1217 secrets.ntlm<suffix>.id<suffix> []
1220 Identity the NTLM secret belongs to. Multiple unique identities
1221 may be specified, each having an id prefix, if a secret is
1222 shared between multiple users.
1223 secrets.ike<suffix>
1226 IKE preshared secret section for a specific secret. Each IKE PSK
1227 is defined in a unique section having the ike prefix.
1228 secrets.ike<suffix>.secret []
1231 Value of the IKE preshared secret. It may either be an ASCII
1232 string, a hex encoded string if it has a 0x prefix or a Base64
1233 encoded string if it has a 0s prefix in its value.
1234 secrets.ike<suffix>.id<suffix> []
1237 IKE identity the IKE preshared secret belongs to. Multiple
1238 unique identities may be specified, each having an id prefix, if
1239 a secret is shared between multiple peers.
1240 secrets.ppk<suffix>
1243 Postquantum Preshared Key (PPK) section for a specific secret.
1244 Each PPK is defined in a unique section having the ppk pre‐
1245 fix.
1246 secrets.ppk<suffix>.secret []
1249 Value of the PPK. It may either be an ASCII string, a hex
1250 encoded string if it has a 0x prefix or a Base64 encoded string
1251 if it has a 0s prefix in its value. Should have at least 256
1252 bits of entropy for 128-bit security.
1253 secrets.ppk<suffix>.id<suffix> []
1256 PPK identity the PPK belongs to. Multiple unique identities may
1257 be specified, each having an id prefix, if a secret is shared
1258 between multiple peers.
1259 secrets.private<suffix>
1262 Private key decryption passphrase for a key in the private
1263 folder.
1264 secrets.private<suffix>.file []
1267 File name in the private folder for which this passphrase should
1268 be used.
1269 secrets.private<suffix>.secret []
1272 Value of decryption passphrase for private key.
1273 secrets.rsa<suffix>
1276 Private key decryption passphrase for a key in the rsa folder.
1277 secrets.rsa<suffix>.file []
1280 File name in the rsa folder for which this passphrase should be
1281 used.
1282 secrets.rsa<suffix>.secret []
1285 Value of decryption passphrase for RSA key.
1286 secrets.ecdsa<suffix>
1289 Private key decryption passphrase for a key in the ecdsa folder.
1290 secrets.ecdsa<suffix>.file []
1293 File name in the ecdsa folder for which this passphrase should
1294 be used.
1295 secrets.ecdsa<suffix>.secret []
1298 Value of decryption passphrase for ECDSA key.
1299 secrets.pkcs8<suffix>
1302 Private key decryption passphrase for a key in the pkcs8 folder.
1303 secrets.pkcs8<suffix>.file []
1306 File name in the pkcs8 folder for which this passphrase should
1307 be used.
1308 secrets.pkcs8<suffix>.secret []
1311 Value of decryption passphrase for PKCS#8 key.
1312 secrets.pkcs12<suffix>
1315 PKCS#12 decryption passphrase for a container in the pkcs12
1316 folder.
1317 secrets.pkcs12<suffix>.file []
1320 File name in the pkcs12 folder for which this passphrase should
1321 be used.
1322 secrets.pkcs12<suffix>.secret []
1325 Value of decryption passphrase for PKCS#12 container.
1326 secrets.token<suffix>
1329 Definition for a private key that's stored on a token/smartcard.
1330 secrets.token<suffix>.handle []
1333 Hex-encoded CKA_ID of the private key on the token.
1334 secrets.token<suffix>.slot []
1337 Optional slot number to access the token.
1338 secrets.token<suffix>.module []
1341 Optional PKCS#11 module name to access the token.
1342 secrets.token<suffix>.pin []
1345 Optional PIN required to access the key on the token. If none is
1346 provided the user is prompted during an interactive --load-creds
1347 call.
1348 pools
1351 Section defining named pools. Named pools may be referenced by
1352 connections with the pools option to assign virtual IPs and
1353 other configuration attributes.
1354 pools.<name>
1357 Section defining a single pool with a unique name.
1358 pools.<name>.addrs []
1361 Subnet or range defining addresses allocated in pool. Accepts a
1362 single CIDR subnet defining the pool to allocate addresses from
1363 or an address range (<from>-<to>). Pools must be unique and
1364 non-overlapping.
1365 pools.<name>.<attr> []
1368 Comma separated list of additional attributes of type <attr>.
1369 The attribute type may be one of dns, nbns, dhcp, netmask,
1370 server, subnet, split_include and split_exclude to define ad‐
1371 dresses or CIDR subnets for the corresponding attribute types.
1372 Alternatively, <attr> can be a numerical identifier, for which
1373 string attribute values are accepted as well.
1374 authorities
1377 Section defining attributes of certification authorities.
1378 authorities.<name>
1381 Section defining a certification authority with a unique name.
1382 authorities.<name>.cacert []
1385 CA certificate belonging to the certification authority. The
1386 certificates may use a relative path from the swanctl x509ca di‐
1387 rectory or an absolute path.
1388 Configure one of cacert, file, or handle per section.
1390 authorities.<name>.file []
1393 Absolute path to the certificate to load. Passed as-is to the
1394 daemon, so it must be readable by it.
1395 Configure one of cacert, file, or handle per section.
1397 authorities.<name>.handle []
1400 Hex-encoded CKA_ID of the CA certificate on a token.
1401 Configure one of cacert, file, or handle per section.
1403 authorities.<name>.slot []
1406 Optional slot number of the token that stores the CA certifi‐
1407 cate.
1408 authorities.<name>.module []
1411 Optional PKCS#11 module name.
1412 authorities.<name>.crl_uris []
1415 Comma-separated list of CRL distribution points (ldap, http, or
1416 file URI).
1417 authorities.<name>.ocsp_uris []
1420 Comma-separated list of OCSP URIs.
1421 authorities.<name>.cert_uri_base []
1424 Defines the base URI for the Hash and URL feature supported by
1425 IKEv2. Instead of exchanging complete certificates, IKEv2 allows
1426 one to send an URI that resolves to the DER encoded certificate.
1427 The certificate URIs are built by appending the SHA1 hash of the
1428 DER encoded certificates to this base URI.
1429
1432 /etc/swanctl/swanctl.conf configuration file
1433
1435 swanctl(8)
14365.9.6 SWANCTL.CONF(5)