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. Accept‐
199 able values are allow (the default), force and never. If set to
200 allow, responders will accept childless IKE_SAs (as indicated
201 via notify in the IKE_SA_INIT response) while initiators con‐
202 tinue to create regular IKE_SAs with the first CHILD_SA created
203 during IKE_AUTH, unless the IKE_SA is initiated explicitly with‐
204 out any children (which will fail if the responder does not sup‐
205 port or has disabled this extension). If set to force, only
206 childless initiation is accepted and the first CHILD_SA is cre‐
207 ated with a separate CREATE_CHILD_SA exchange (e.g. to use an
208 independent DH exchange for all CHILD_SAs). Finally, setting
209 the option to never disables support for childless IKE_SAs as
210 responder.
211 connections.<conn>.send_certreq [yes]
214 Send certificate request payloads to offer trusted root CA cer‐
215 tificates to the peer. Certificate requests help the peer to
216 choose an appropriate certificate/private key for authentication
217 and are enabled by default.
218 Disabling certificate requests can be useful if too many trusted
220 root CA certificates are installed, as each certificate request
221 increases the size of the initial IKE packets.
222 connections.<conn>.send_cert [ifasked]
225 Send certificate payloads when using certificate authentication.
226 With the default of ifasked the daemon sends certificate pay‐
227 loads only if certificate requests have been received. never
228 disables sending of certificate payloads altogether, always
229 causes certificate payloads to be sent unconditionally whenever
230 certificate authentication is used.
231 connections.<conn>.ppk_id []
234 String identifying the Postquantum Preshared Key (PPK) to be
235 used.
236 connections.<conn>.ppk_required [no]
239 Whether a Postquantum Preshared Key (PPK) is required for this
240 connection.
241 connections.<conn>.keyingtries [1]
244 Number of retransmission sequences to perform during initial
245 connect. Instead of giving up initiation after the first re‐
246 transmission sequence with the default value of 1, additional
247 sequences may be started according to the configured value. A
248 value of 0 initiates a new sequence until the connection estab‐
249 lishes or fails with a permanent error.
250 connections.<conn>.unique [no]
253 Connection uniqueness policy to enforce. To avoid multiple con‐
254 nections from the same user, a uniqueness policy can be en‐
255 forced. The value never does never enforce such a policy, even
256 if a peer included INITIAL_CONTACT notification messages,
257 whereas no replaces existing connections for the same identity
258 if a new one has the INITIAL_CONTACT notify. keep rejects new
259 connection attempts if the same user already has an active con‐
260 nection, replace deletes any existing connection if a new one
261 for the same user gets established.
262 To compare connections for uniqueness, the remote IKE identity
264 is used. If EAP or XAuth authentication is involved, the
265 EAP-Identity or XAuth username is used to enforce the uniqueness
266 policy instead.
267 On initiators this setting specifies whether an INITIAL_CONTACT
269 notify is sent during IKE_AUTH if no existing connection is
270 found with the remote peer (determined by the identities of the
271 first authentication round). Unless set to never the client will
272 send a notify.
273 connections.<conn>.reauth_time [0s]
276 Time to schedule IKE reauthentication. IKE reauthentication
277 recreates the IKE/ISAKMP SA from scratch and re-evaluates the
278 credentials. In asymmetric configurations (with EAP or configu‐
279 ration payloads) it might not be possible to actively reauthen‐
280 ticate as responder. The IKEv2 reauthentication lifetime negoti‐
281 ation can instruct the client to perform reauthentication.
282 Reauthentication is disabled by default. Enabling it usually may
284 lead to small connection interruptions, as strongSwan uses a
285 break-before-make policy with IKEv2 to avoid any conflicts with
286 associated tunnel resources.
287 connections.<conn>.rekey_time [4h]
290 IKE rekeying refreshes key material using a Diffie-Hellman ex‐
291 change, but does not re-check associated credentials. It is sup‐
292 ported in IKEv2 only, IKEv1 performs a reauthentication proce‐
293 dure instead.
294 With the default value IKE rekeying is scheduled every 4 hours,
296 minus the configured rand_time. If a reauth_time is configured,
297 rekey_time defaults to zero disabling rekeying; explicitly set
298 both to enforce rekeying and reauthentication.
299 connections.<conn>.over_time [10% of rekey_time/reauth_time]
302 Hard IKE_SA lifetime if rekey/reauth does not complete, as time.
303 To avoid having an IKE/ISAKMP kept alive if IKE reauthentication
304 or rekeying fails perpetually, a maximum hard lifetime may be
305 specified. If the IKE_SA fails to rekey or reauthenticate within
306 the specified time, the IKE_SA gets closed.
307 In contrast to CHILD_SA rekeying, over_time is relative in time
309 to the rekey_time and reauth_time values, as it applies to both.
310 The default is 10% of the longer of rekey_time and reauth_time.
312 connections.<conn>.rand_time [over_time]
316 Time range from which to choose a random value to subtract from
317 rekey/reauth times. To avoid having both peers initiating the
318 rekey/reauth procedure simultaneously, a random time gets sub‐
319 tracted from the rekey/reauth times.
320 The default is equal to the configured over_time.
322 connections.<conn>.pools []
326 Comma separated list of named IP pools to allocate virtual IP
327 addresses and other configuration attributes from. Each name
328 references a pool by name from either the pools section or an
329 external pool.
330 connections.<conn>.if_id_in [0]
333 XFRM interface ID set on inbound policies/SA, can be overridden
334 by child config, see there for details.
335 The special value %unique allocates a unique interface ID per
337 IKE_SA, which is inherited by all its CHILD_SAs (unless overrid‐
338 den there), beyond that the value %unique-dir assigns a differ‐
339 ent unique interface ID for each direction (in/out).
340 connections.<conn>.if_id_out [0]
343 XFRM interface ID set on outbound policies/SA, can be overridden
344 by child config, see there for details.
345 The special value %unique allocates a unique interface ID per
347 IKE_SA, which is inherited by all its CHILD_SAs (unless overrid‐
348 den there), beyond that the value %unique-dir assigns a differ‐
349 ent unique interface ID for each direction (in/out).
350 connections.<conn>.mediation [no]
353 Whether this connection is a mediation connection, that is,
354 whether this connection is used to mediate other connections us‐
355 ing the IKEv2 Mediation Extension. Mediation connections create
356 no CHILD_SA.
357 connections.<conn>.mediated_by []
360 The name of the connection to mediate this connection through.
361 If given, the connection will be mediated through the named me‐
362 diation connection. The mediation connection must have mediation
363 enabled.
364 connections.<conn>.mediation_peer []
367 Identity under which the peer is registered at the mediation
368 server, that is, the IKE identity the other end of this connec‐
369 tion uses as its local identity on its connection to the media‐
370 tion server. This is the identity we request the mediation
371 server to mediate us with. Only relevant on connections that set
372 mediated_by. If it is not given, the remote IKE identity of the
373 first authentication round of this connection will be used.
374 connections.<conn>.local<suffix>
377 Section for a local authentication round. A local authentication
378 round defines the rules how authentication is performed for the
379 local peer. Multiple rounds may be defined to use IKEv2 RFC 4739
380 Multiple Authentication or IKEv1 XAuth.
381 Each round is defined in a section having local as prefix, and
383 an optional unique suffix. To define a single authentication
384 round, the suffix may be omitted.
385 connections.<conn>.local<suffix>.round [0]
388 Optional numeric identifier by which authentication rounds are
389 sorted. If not specified rounds are ordered by their position
390 in the config file/VICI message.
391 connections.<conn>.local<suffix>.certs []
394 Comma separated list of certificate candidates to use for au‐
395 thentication. The certificates may use a relative path from the
396 swanctl x509 directory or an absolute path.
397 The certificate used for authentication is selected based on the
399 received certificate request payloads. If no appropriate CA can
400 be located, the first certificate is used.
401 connections.<conn>.local<suffix>.cert<suffix> []
404 Section for a certificate candidate to use for authentication.
405 Certificates in certs are transmitted as binary blobs, these
406 sections offer more flexibility.
407 connections.<conn>.local<suffix>.cert<suffix>.file []
410 Absolute path to the certificate to load. Passed as-is to the
411 daemon, so it must be readable by it.
412 Configure either this or handle, but not both, in one section.
414 connections.<conn>.local<suffix>.cert<suffix>.handle []
417 Hex-encoded CKA_ID of the certificate on a token.
418 Configure either this or file, but not both, in one section.
420 connections.<conn>.local<suffix>.cert<suffix>.slot []
423 Optional slot number of the token that stores the certificate.
424 connections.<conn>.local<suffix>.cert<suffix>.module []
427 Optional PKCS#11 module name.
428 connections.<conn>.local<suffix>.pubkeys []
431 Comma separated list of raw public key candidates to use for au‐
432 thentication. The public keys may use a relative path from the
433 swanctl pubkey directory or an absolute path.
434 Even though multiple local public keys could be defined in prin‐
436 ciple, only the first public key in the list is used for authen‐
437 tication.
438 connections.<conn>.local<suffix>.auth [pubkey]
441 Authentication to perform locally. pubkey uses public key au‐
442 thentication using a private key associated to a usable certifi‐
443 cate. psk uses pre-shared key authentication. The IKEv1 spe‐
444 cific xauth is used for XAuth or Hybrid authentication, while
445 the IKEv2 specific eap keyword defines EAP authentication.
446 For xauth, a specific backend name may be appended, separated by
448 a dash. The appropriate xauth backend is selected to perform the
449 XAuth exchange. For traditional XAuth, the xauth method is usu‐
450 ally defined in the second authentication round following an
451 initial pubkey (or psk) round. Using xauth in the first round
452 performs Hybrid Mode client authentication.
453 For eap, a specific EAP method name may be appended, separated
455 by a dash. An EAP module implementing the appropriate method is
456 selected to perform the EAP conversation.
457 If both peers support RFC 7427 ("Signature Authentication in
459 IKEv2") specific hash algorithms to be used during IKEv2 authen‐
460 tication may be configured. To do so use ike: followed by a
461 trust chain signature scheme constraint (see description of the
462 remote section's auth keyword). For example, with ike:pub‐
463 key-sha384-sha256 a public key signature scheme with either
464 SHA-384 or SHA-256 would get used for authentication, in that
465 order and depending on the hash algorithms supported by the
466 peer. If no specific hash algorithms are configured, the default
467 is to prefer an algorithm that matches or exceeds the strength
468 of the signature key. If no constraints with ike: prefix are
469 configured any signature scheme constraint (without ike: prefix)
470 will also apply to IKEv2 authentication, unless this is disabled
471 in strongswan.conf(5). To use RSASSA-PSS signatures use rsa/pss
472 instead of pubkey or rsa as in e.g. ike:rsa/pss-sha256. If
473 pubkey or rsa constraints are configured RSASSA-PSS signatures
474 will only be used if enabled in strongswan.conf(5).
475 connections.<conn>.local<suffix>.id []
479 IKE identity to use for authentication round. When using cer‐
480 tificate authentication, the IKE identity must be contained in
481 the certificate, either as subject or as subjectAltName.
482 The identity can be an IP address, a fully-qualified domain
484 name, an email address or a Distinguished Name for which the ID
485 type is determined automatically and the string is converted to
486 the appropriate encoding. To enforce a specific identity type, a
487 prefix may be used, followed by a colon (:). If the number sign
488 (#) follows the colon, the remaining data is interpreted as hex
489 encoding, otherwise the string is used as-is as the identifica‐
490 tion data. Note that this implies that no conversion is per‐
491 formed for non-string identities. For example, ipv4:10.0.0.1
492 does not create a valid ID_IPV4_ADDR IKE identity, as it does
493 not get converted to binary 0x0a000001. Instead, one could use
494 ipv4:#0a000001 to get a valid identity, but just using the im‐
495 plicit type with automatic conversion is usually simpler. The
496 same applies to the ASN1 encoded types. The following prefixes
497 are known: ipv4, ipv6, rfc822, email, userfqdn, fqdn, dns,
498 asn1dn, asn1gn and keyid. Custom type prefixes may be specified
499 by surrounding the numerical type value by curly brackets.
500 connections.<conn>.local<suffix>.eap_id [id]
503 Client EAP-Identity to use in EAP-Identity exchange and the EAP
504 method.
505 connections.<conn>.local<suffix>.aaa_id [remote-id]
508 Server side EAP-Identity to expect in the EAP method. Some EAP
509 methods, such as EAP-TLS, use an identity for the server to per‐
510 form mutual authentication. This identity may differ from the
511 IKE identity, especially when EAP authentication is delegated
512 from the IKE responder to an AAA backend.
513 For EAP-(T)TLS, this defines the identity for which the server
515 must provide a certificate in the TLS exchange.
516 connections.<conn>.local<suffix>.xauth_id [id]
519 Client XAuth username used in the XAuth exchange.
520 connections.<conn>.remote<suffix>
523 Section for a remote authentication round. A remote authentica‐
524 tion round defines the constraints how the peers must authenti‐
525 cate to use this connection. Multiple rounds may be defined to
526 use IKEv2 RFC 4739 Multiple Authentication or IKEv1 XAuth.
527 Each round is defined in a section having remote as prefix, and
529 an optional unique suffix. To define a single authentication
530 round, the suffix may be omitted.
531 connections.<conn>.remote<suffix>.round [0]
534 Optional numeric identifier by which authentication rounds are
535 sorted. If not specified rounds are ordered by their position
536 in the config file/VICI message.
537 connections.<conn>.remote<suffix>.id [%any]
540 IKE identity to expect for authentication round. Refer to the
541 local section's id keyword for details.
542 It's possible to use wildcards to match remote identities (e.g.
544 *@strongswan.org, *.strongswan.org, or C=CH,O=strongSwan,CN=*).
545 Connections with exact matches are preferred. When using distin‐
546 guished names with wildcards, the charon.rdn_matching option in
547 strongswan.conf(5) specifies how RDNs are matched.
548 connections.<conn>.remote<suffix>.eap_id [id]
551 Identity to use as peer identity during EAP authentication. If
552 set to %any the EAP-Identity method will be used to ask the
553 client for an identity.
554 connections.<conn>.remote<suffix>.groups []
557 Comma separated authorization group memberships to require. The
558 peer must prove membership to at least one of the specified
559 groups. Group membership can be certified by different means,
560 for example by appropriate Attribute Certificates or by an AAA
561 backend involved in the authentication.
562 connections.<conn>.remote<suffix>.cert_policy []
565 Comma separated list of certificate policy OIDs the peer's cer‐
566 tificate must have. OIDs are specified using the numerical dot‐
567 ted representation.
568 connections.<conn>.remote<suffix>.certs []
571 Comma separated list of certificates to accept for authentica‐
572 tion. The certificates may use a relative path from the swanctl
573 x509 directory or an absolute path.
574 connections.<conn>.remote<suffix>.cert<suffix> []
577 Section for a certificate to accept for authentication. Certifi‐
578 cates in certs are transmitted as binary blobs, these sections
579 offer more flexibility.
580 connections.<conn>.remote<suffix>.cert<suffix>.file []
583 Absolute path to the certificate to load. Passed as-is to the
584 daemon, so it must be readable by it.
585 Configure either this or handle, but not both, in one section.
587 connections.<conn>.remote<suffix>.cert<suffix>.handle []
590 Hex-encoded CKA_ID of the certificate on a token.
591 Configure either this or file, but not both, in one section.
593 connections.<conn>.remote<suffix>.cert<suffix>.slot []
596 Optional slot number of the token that stores the certificate.
597 connections.<conn>.remote<suffix>.cert<suffix>.module []
600 Optional PKCS#11 module name.
601 connections.<conn>.remote<suffix>.cacerts []
604 Comma separated list of CA certificates to accept for authenti‐
605 cation. The certificates may use a relative path from the
606 swanctl x509ca directory or an absolute path.
607 connections.<conn>.remote<suffix>.cacert<suffix> []
610 Section for a CA certificate to accept for authentication. Cer‐
611 tificates in cacerts are transmitted as binary blobs, these sec‐
612 tions offer more flexibility.
613 connections.<conn>.remote<suffix>.cacert<suffix>.file []
616 Absolute path to the certificate to load. Passed as-is to the
617 daemon, so it must be readable by it.
618 Configure either this or handle, but not both, in one section.
620 connections.<conn>.remote<suffix>.cacert<suffix>.handle []
623 Hex-encoded CKA_ID of the CA certificate on a token.
624 Configure either this or file, but not both, in one section.
626 connections.<conn>.remote<suffix>.cacert<suffix>.slot []
629 Optional slot number of the token that stores the CA certifi‐
630 cate.
631 connections.<conn>.remote<suffix>.cacert<suffix>.module []
634 Optional PKCS#11 module name.
635 connections.<conn>.remote<suffix>.ca_id []
638 The specified identity must be contained in one (intermediate)
639 CA of the remote peer trustchain, either as subject or as sub‐
640 jectAltName. This has the same effect as specifying cacerts to
641 force clients under a CA to specific connections; it does not
642 require the CA certificate to be available locally, and can be
643 received from the peer during the IKE exchange.
644 connections.<conn>.remote<suffix>.pubkeys []
647 Comma separated list of raw public keys to accept for authenti‐
648 cation. The public keys may use a relative path from the swanctl
649 pubkey directory or an absolute path.
650 connections.<conn>.remote<suffix>.revocation [relaxed]
653 Certificate revocation policy for CRL or OCSP revocation.
654 A strict revocation policy fails if no revocation information is
656 available, i.e. the certificate is not known to be unrevoked.
657 ifuri fails only if a CRL/OCSP URI is available, but certificate
659 revocation checking fails, i.e. there should be revocation in‐
660 formation available, but it could not be obtained.
661 The default revocation policy relaxed fails only if a certifi‐
663 cate is revoked, i.e. it is explicitly known that it is bad.
664 connections.<conn>.remote<suffix>.auth [pubkey]
667 Authentication to expect from remote. See the local section's
668 auth keyword description about the details of supported mecha‐
669 nisms.
670 To require a trustchain public key strength for the remote side,
672 specify the key type followed by the minimum strength in bits
673 (for example ecdsa-384 or rsa-2048-ecdsa-256). To limit the ac‐
674 ceptable set of hashing algorithms for trustchain validation,
675 append hash algorithms to pubkey or a key strength definition
676 (for example pubkey-sha256-sha512, rsa-2048-sha256-sha384-sha512
677 or rsa-2048-sha256-ecdsa-256-sha256-sha384). Unless disabled in
678 strongswan.conf(5), or explicit IKEv2 signature constraints are
679 configured (refer to the description of the local section's auth
680 keyword for details), such key types and hash algorithms are
681 also applied as constraints against IKEv2 signature authentica‐
682 tion schemes used by the remote side. To require RSASSA-PSS sig‐
683 natures use rsa/pss instead of pubkey or rsa as in e.g.
684 rsa/pss-sha256. If pubkey or rsa constraints are configured
685 RSASSA-PSS signatures will only be accepted if enabled in
686 strongswan.conf(5).
687 To specify trust chain constraints for EAP-(T)TLS, append a
690 colon to the EAP method, followed by the key type/size and hash
691 algorithm as discussed above (e.g. eap-tls:ecdsa-384-sha384).
692 connections.<conn>.children.<child>
696 CHILD_SA configuration sub-section. Each connection definition
697 may have one or more sections in its children subsection. The
698 section name defines the name of the CHILD_SA configuration,
699 which must be unique within the connection.
700 connections.<conn>.children.<child>.ah_proposals []
703 AH proposals to offer for the CHILD_SA. A proposal is a set of
704 algorithms. For AH, this includes an integrity algorithm and an
705 optional Diffie-Hellman group. If a DH group is specified,
706 CHILD_SA/Quick Mode rekeying and initial negotiation uses a sep‐
707 arate Diffie-Hellman exchange using the specified group (refer
708 to esp_proposals for details).
709 In IKEv2, multiple algorithms of the same kind can be specified
711 in a single proposal, from which one gets selected. In IKEv1,
712 only one algorithm per kind is allowed per proposal, more algo‐
713 rithms get implicitly stripped. Use multiple proposals to offer
714 different algorithms combinations in IKEv1.
715 Algorithm keywords get separated using dashes. Multiple propos‐
717 als may be separated by commas. The special value default forms
718 a default proposal of supported algorithms considered safe, and
719 is usually a good choice for interoperability. By default no AH
720 proposals are included, instead ESP is proposed.
721 connections.<conn>.children.<child>.esp_proposals [default]
724 ESP proposals to offer for the CHILD_SA. A proposal is a set of
725 algorithms. For ESP non-AEAD proposals, this includes an integ‐
726 rity algorithm, an encryption algorithm, an optional
727 Diffie-Hellman group and an optional Extended Sequence Number
728 Mode indicator. For AEAD proposals, a combined mode algorithm is
729 used instead of the separate encryption/integrity algorithms.
730 If a DH group is specified, CHILD_SA/Quick Mode rekeying and
732 initial negotiation use a separate Diffie-Hellman exchange using
733 the specified group. However, for IKEv2, the keys of the
734 CHILD_SA created implicitly with the IKE_SA will always be de‐
735 rived from the IKE_SA's key material. So any DH group specified
736 here will only apply when the CHILD_SA is later rekeyed or is
737 created with a separate CREATE_CHILD_SA exchange. A proposal
738 mismatch might, therefore, not immediately be noticed when the
739 SA is established, but may later cause rekeying to fail.
740 Extended Sequence Number support may be indicated with the esn
742 and noesn values, both may be included to indicate support for
743 both modes. If omitted, noesn is assumed.
744 In IKEv2, multiple algorithms of the same kind can be specified
746 in a single proposal, from which one gets selected. In IKEv1,
747 only one algorithm per kind is allowed per proposal, more algo‐
748 rithms get implicitly stripped. Use multiple proposals to offer
749 different algorithms combinations in IKEv1.
750 Algorithm keywords get separated using dashes. Multiple propos‐
752 als may be separated by commas. The special value default forms
753 a default proposal of supported algorithms considered safe, and
754 is usually a good choice for interoperability. If no algorithms
755 are specified for AH nor ESP, the default set of algorithms for
756 ESP is included.
757 connections.<conn>.children.<child>.sha256_96 [no]
760 HMAC-SHA-256 is used with 128-bit truncation with IPsec. For
761 compatibility with implementations that incorrectly use 96-bit
762 truncation this option may be enabled to configure the shorter
763 truncation length in the kernel. This is not negotiated, so
764 this only works with peers that use the incorrect truncation
765 length (or have this option enabled).
766 connections.<conn>.children.<child>.local_ts [dynamic]
769 Comma separated list of local traffic selectors to include in
770 CHILD_SA. Each selector is a CIDR subnet definition, followed by
771 an optional proto/port selector. The special value dynamic may
772 be used instead of a subnet definition, which gets replaced by
773 the tunnel outer address or the virtual IP, if negotiated. This
774 is the default.
775 A protocol/port selector is surrounded by opening and closing
777 square brackets. Between these brackets, a numeric or getser‐
778 vent(3) protocol name may be specified. After the optional pro‐
779 tocol restriction, an optional port restriction may be speci‐
780 fied, separated by a slash. The port restriction may be numeric,
781 a getservent(3) service name, or the special value opaque for
782 RFC 4301 OPAQUE selectors. Port ranges may be specified as well,
783 none of the kernel backends currently support port ranges,
784 though.
785 When IKEv1 is used only the first selector is interpreted, ex‐
787 cept if the Cisco Unity extension plugin is used. This is due to
788 a limitation of the IKEv1 protocol, which only allows a single
789 pair of selectors per CHILD_SA. So to tunnel traffic matched by
790 several pairs of selectors when using IKEv1 several children
791 (CHILD_SAs) have to be defined that cover the selectors.
792 The IKE daemon uses traffic selector narrowing for IKEv1, the
794 same way it is standardized and implemented for IKEv2. However,
795 this may lead to problems with other implementations. To avoid
796 that, configure identical selectors in such scenarios.
797 connections.<conn>.children.<child>.remote_ts [dynamic]
800 Comma separated list of remote selectors to include in CHILD_SA.
801 See local_ts for a description of the selector syntax.
802 connections.<conn>.children.<child>.rekey_time [1h]
805 Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes
806 key material, optionally using a Diffie-Hellman exchange if a
807 group is specified in the proposal.
808 To avoid rekey collisions initiated by both ends simultaneously,
810 a value in the range of rand_time gets subtracted to form the
811 effective soft lifetime.
812 By default CHILD_SA rekeying is scheduled every hour, minus
814 rand_time.
815 connections.<conn>.children.<child>.life_time [rekey_time + 10%]
819 Maximum lifetime before CHILD_SA gets closed. Usually this hard
820 lifetime is never reached, because the CHILD_SA gets rekeyed be‐
821 fore. If that fails for whatever reason, this limit closes the
822 CHILD_SA.
823 The default is 10% more than the rekey_time.
825 connections.<conn>.children.<child>.rand_time [life_time - rekey_time]
829 Time range from which to choose a random value to subtract from
830 rekey_time. The default is the difference between life_time and
831 rekey_time.
832 connections.<conn>.children.<child>.rekey_bytes [0]
836 Number of bytes processed before initiating CHILD_SA rekeying.
837 CHILD_SA rekeying refreshes key material, optionally using a
838 Diffie-Hellman exchange if a group is specified in the proposal.
839 To avoid rekey collisions initiated by both ends simultaneously,
841 a value in the range of rand_bytes gets subtracted to form the
842 effective soft volume limit.
843 Volume based CHILD_SA rekeying is disabled by default.
845 connections.<conn>.children.<child>.life_bytes [rekey_bytes + 10%]
848 Maximum bytes processed before CHILD_SA gets closed. Usually
849 this hard volume limit is never reached, because the CHILD_SA
850 gets rekeyed before. If that fails for whatever reason, this
851 limit closes the CHILD_SA.
852 The default is 10% more than rekey_bytes.
854 connections.<conn>.children.<child>.rand_bytes [life_bytes -
858 rekey_bytes]
859 Byte range from which to choose a random value to subtract from
860 rekey_bytes. The default is the difference between life_bytes
861 and rekey_bytes.
862 connections.<conn>.children.<child>.rekey_packets [0]
866 Number of packets processed before initiating CHILD_SA rekeying.
867 CHILD_SA rekeying refreshes key material, optionally using a
868 Diffie-Hellman exchange if a group is specified in the proposal.
869 To avoid rekey collisions initiated by both ends simultaneously,
871 a value in the range of rand_packets gets subtracted to form the
872 effective soft packet count limit.
873 Packet count based CHILD_SA rekeying is disabled by default.
875 connections.<conn>.children.<child>.life_packets [rekey_packets + 10%]
878 Maximum number of packets processed before CHILD_SA gets closed.
879 Usually this hard packets limit is never reached, because the
880 CHILD_SA gets rekeyed before. If that fails for whatever rea‐
881 son, this limit closes the CHILD_SA.
882 The default is 10% more than rekey_bytes.
884 connections.<conn>.children.<child>.rand_packets [life_packets -
888 rekey_packets]
889 Packet range from which to choose a random value to subtract
890 from rekey_packets. The default is the difference between
891 life_packets and rekey_packets.
892 connections.<conn>.children.<child>.updown []
896 Updown script to invoke on CHILD_SA up and down events.
897 connections.<conn>.children.<child>.hostaccess [no]
900 Hostaccess variable to pass to updown script.
901 connections.<conn>.children.<child>.mode [tunnel]
904 IPsec Mode to establish CHILD_SA with. tunnel negotiates the
905 CHILD_SA in IPsec Tunnel Mode, whereas transport uses IPsec
906 Transport Mode. transport_proxy signifying the special Mobile
907 IPv6 Transport Proxy Mode. beet is the Bound End to End Tunnel
908 mixture mode, working with fixed inner addresses without the
909 need to include them in each packet.
910 Both transport and beet modes are subject to mode negotiation;
912 tunnel mode is negotiated if the preferred mode is not avail‐
913 able.
914 pass and drop are used to install shunt policies which explic‐
916 itly bypass the defined traffic from IPsec processing or drop
917 it, respectively.
918 connections.<conn>.children.<child>.policies [yes]
921 Whether to install IPsec policies or not. Disabling this can be
922 useful in some scenarios e.g. MIPv6, where policies are not man‐
923 aged by the IKE daemon.
924 connections.<conn>.children.<child>.policies_fwd_out [no]
927 Whether to install outbound FWD IPsec policies or not. Enabling
928 this is required in case there is a drop policy that would match
929 and block forwarded traffic for this CHILD_SA.
930 connections.<conn>.children.<child>.dpd_action [clear]
933 Action to perform for this CHILD_SA on DPD timeout. The default
934 clear closes the CHILD_SA and does not take further action.
935 trap installs a trap policy, which will catch matching traffic
936 and tries to re-negotiate the tunnel on-demand (note that this
937 is redundant if start_action includes trap). restart immedi‐
938 ately tries to re-negotiate the CHILD_SA under a fresh IKE_SA.
939 connections.<conn>.children.<child>.ipcomp [no]
942 Enable IPComp compression before encryption. If enabled, IKE
943 tries to negotiate IPComp compression to compress ESP payload
944 data prior to encryption.
945 connections.<conn>.children.<child>.inactivity [0s]
948 Timeout before closing CHILD_SA after inactivity. If no traffic
949 has been processed in either direction for the configured time‐
950 out, the CHILD_SA gets closed due to inactivity. The default
951 value of 0 disables inactivity checks.
952 connections.<conn>.children.<child>.reqid [0]
955 Fixed reqid to use for this CHILD_SA. This might be helpful in
956 some scenarios, but works only if each CHILD_SA configuration is
957 instantiated not more than once. The default of 0 uses dynamic
958 reqids, allocated incrementally.
959 connections.<conn>.children.<child>.priority [0]
962 Optional fixed priority for IPsec policies. This could be useful
963 to install high-priority drop policies. The default of 0 uses
964 dynamically calculated priorities based on the size of the traf‐
965 fic selectors.
966 connections.<conn>.children.<child>.interface []
969 Optional interface name to restrict IPsec policies.
970 connections.<conn>.children.<child>.mark_in [0/0x00000000]
973 Netfilter mark and mask for input traffic. On Linux, Netfilter
974 may require marks on each packet to match an SA/policy having
975 that option set. This allows installing duplicate policies and
976 enables Netfilter rules to select specific SAs/policies for in‐
977 coming traffic. Note that inbound marks are only set on poli‐
978 cies, by default, unless *mark_in_sa* is enabled. The special
979 value %unique sets a unique mark on each CHILD_SA instance, be‐
980 yond that the value %unique-dir assigns a different unique mark
981 for each CHILD_SA direction (in/out).
982 An additional mask may be appended to the mark, separated by /.
984 The default mask if omitted is 0xffffffff.
985 connections.<conn>.children.<child>.mark_in_sa [no]
988 Whether to set *mark_in* on the inbound SA. By default, the in‐
989 bound mark is only set on the inbound policy. The tuple destina‐
990 tion address, protocol and SPI is unique and the mark is not re‐
991 quired to find the correct SA, allowing to mark traffic after
992 decryption instead (where more specific selectors may be used)
993 to match different policies. Marking packets before decryption
994 is still possible, even if no mark is set on the SA.
995 connections.<conn>.children.<child>.mark_out [0/0x00000000]
998 Netfilter mark and mask for output traffic. On Linux, Netfilter
999 may require marks on each packet to match a policy/SA having
1000 that option set. This allows installing duplicate policies and
1001 enables Netfilter rules to select specific policies/SAs for out‐
1002 going traffic. The special value %unique sets a unique mark on
1003 each CHILD_SA instance, beyond that the value %unique-dir as‐
1004 signs a different unique mark for each CHILD_SA direction
1005 (in/out).
1006 An additional mask may be appended to the mark, separated by /.
1008 The default mask if omitted is 0xffffffff.
1009 connections.<conn>.children.<child>.set_mark_in [0/0x00000000]
1012 Netfilter mark applied to packets after the inbound IPsec SA
1013 processed them. This way it's not necessary to mark packets via
1014 Netfilter before decryption or right afterwards to match poli‐
1015 cies or process them differently (e.g. via policy routing).
1016 An additional mask may be appended to the mark, separated by /.
1018 The default mask if omitted is 0xffffffff. The special value
1019 %same uses the value (but not the mask) from mark_in as mark
1020 value, which can be fixed, %unique or %unique-dir.
1021 Setting marks in XFRM input requires Linux 4.19 or higher.
1024 connections.<conn>.children.<child>.set_mark_out [0/0x00000000]
1027 Netfilter mark applied to packets after the outbound IPsec SA
1028 processed them. This allows processing ESP packets differently
1029 than the original traffic (e.g. via policy routing).
1030 An additional mask may be appended to the mark, separated by /.
1032 The default mask if omitted is 0xffffffff. The special value
1033 %same uses the value (but not the mask) from mark_out as mark
1034 value, which can be fixed, %unique or %unique-dir.
1035 Setting marks in XFRM output is supported since Linux 4.14. Set‐
1038 ting a mask requires at least Linux 4.19.
1039 connections.<conn>.children.<child>.if_id_in [0]
1042 XFRM interface ID set on inbound policies/SA. This allows in‐
1043 stalling duplicate policies/SAs and associates them with an in‐
1044 terface with the same ID. The special value %unique sets a
1045 unique interface ID on each CHILD_SA instance, beyond that the
1046 value %unique-dir assigns a different unique interface ID for
1047 each CHILD_SA direction (in/out).
1048 connections.<conn>.children.<child>.if_id_out [0]
1051 XFRM interface ID set on outbound policies/SA. This allows in‐
1052 stalling duplicate policies/SAs and associates them with an in‐
1053 terface with the same ID. The special value %unique sets a
1054 unique interface ID on each CHILD_SA instance, beyond that the
1055 value %unique-dir assigns a different unique interface ID for
1056 each CHILD_SA direction (in/out).
1057 The daemon will not install routes for CHILD_SAs that have this
1059 option set.
1060 connections.<conn>.children.<child>.label []
1063 Optional security label (e.g. SELinux context), IKEv2 only. Re‐
1064 fer to label_mode for details on how labels are processed.
1065 connections.<conn>.children.<child>.label_mode [system]
1068 Defines the mode in which the configured security label is used.
1069 The default value of system selects selinux if strongSwan was
1070 built with SELinux support and SELinux is enabled by the kernel,
1071 otherwise, simple will be selected.
1072 If set to simple, the label will be used as is as an additional
1074 identifier/selector on the IKEv2 level when negotiating
1075 CHILD_SAs and selecting configs, labels are not installed in the
1076 kernel and received labels have to match exactly.
1077 If set to selinux, which is only allowed if SELinux is usable on
1079 the system, the configured label is expected to be a generic
1080 context (e.g. system_u:object_r:ipsec_spd_t:s0) for which
1081 flows, whose context match it via association:polmatch, will
1082 trigger an acquire if no SA exists yet for the flow's specific
1083 context. The configured label is installed on (trap) policies,
1084 so this should generally be combined with trap in start_action.
1085 However, if the connection is initiated directly, without ac‐
1086 quire, a childless IKE_SA is established and appropriate trap
1087 policies are installed on both ends. Labels received from peers
1088 are accepted if they match the configured label via associa‐
1089 tion:polmatch.
1090 connections.<conn>.children.<child>.tfc_padding [0]
1093 Pads ESP packets with additional data to have a consistent ESP
1094 packet size for improved Traffic Flow Confidentiality. The pad‐
1095 ding defines the minimum size of all ESP packets sent.
1096 The default value of 0 disables TFC padding, the special value
1098 mtu adds TFC padding to create a packet size equal to the Path
1099 Maximum Transfer Unit.
1100 connections.<conn>.children.<child>.replay_window [32]
1103 IPsec replay window to configure for this CHILD_SA. Larger val‐
1104 ues than the default of 32 are supported using the Netlink back‐
1105 end only, a value of 0 disables IPsec replay protection.
1106 connections.<conn>.children.<child>.hw_offload [no]
1109 Enable hardware offload for this CHILD_SA, if supported by the
1110 IPsec implementation. The value yes enforces offloading and the
1111 installation will fail if it's not supported by either kernel or
1112 device. The value auto enables offloading, if it's sup‐
1113 ported, but the installation does not fail otherwise.
1114 connections.<conn>.children.<child>.copy_df [yes]
1117 Whether to copy the DF bit to the outer IPv4 header in tunnel
1118 mode. This effectively disables Path MTU discovery (PMTUD).
1119 Controlling this behavior is not supported by all kernel inter‐
1120 faces.
1121 connections.<conn>.children.<child>.copy_ecn [yes]
1124 Whether to copy the ECN (Explicit Congestion Notification)
1125 header field to/from the outer IP header in tunnel mode. Con‐
1126 trolling this behavior is not supported by all kernel inter‐
1127 faces.
1128 connections.<conn>.children.<child>.copy_dscp [out]
1131 Whether to copy the DSCP (Differentiated Services Field Code‐
1132 point) header field to/from the outer IP header in tunnel mode.
1133 The value out only copies the field from the inner to the outer
1134 header, the value in does the opposite and only copies the field
1135 from the outer to the inner header when decapsulating, the value
1136 yes copies the field in both directions, and the value no dis‐
1137 ables copying the field altogether. Setting this to yes or in
1138 could allow an attacker to adversely affect other traffic at the
1139 receiver, which is why the default is out. Controlling this be‐
1140 havior is not supported by all kernel interfaces.
1141 connections.<conn>.children.<child>.start_action [none]
1144 Action to perform after loading the configuration. The default
1145 of none loads the connection only, which then can be manually
1146 initiated or used as a responder configuration.
1147 The value trap installs a trap policy, which triggers the tunnel
1149 as soon as matching traffic has been detected. The value start
1150 initiates the connection actively. These two modes can be com‐
1151 bined with trap|start, to immediately initiate a connection for
1152 which trap policies have been installed.
1153 When unloading or replacing a CHILD_SA configuration having a
1155 start_action different from none, the inverse action is per‐
1156 formed. Configurations with start get closed, while such with
1157 trap get uninstalled (both happens for connections with
1158 trap|start).
1159 connections.<conn>.children.<child>.close_action [none]
1163 Action to perform after a CHILD_SA gets closed by the peer. The
1164 default of none does not take any action, trap installs a trap
1165 policy for the CHILD_SA (note that this is redundant if
1166 start_action includes trap). start tries to immediately re-cre‐
1167 ate the CHILD_SA.
1168 close_action does not provide any guarantee that the CHILD_SA is
1170 kept alive. It acts on explicit close messages only, but not on
1171 negotiation failures. Use trap policies to reliably re-create
1172 failed CHILD_SAs.
1173 secrets
1176 Section defining secrets for IKE/EAP/XAuth authentication and
1177 private key decryption. The secrets section takes sub-sections
1178 having a specific prefix which defines the secret type.
1179 It is not recommended to define any private key decryption
1181 passphrases, as then there is no real security benefit in having
1182 encrypted keys. Either store the key unencrypted or enter the
1183 keys manually when loading credentials.
1184 secrets.eap<suffix>
1187 EAP secret section for a specific secret. Each EAP secret is de‐
1188 fined in a unique section having the eap prefix. EAP secrets are
1189 used for XAuth authentication as well.
1190 secrets.eap<suffix>.secret []
1193 Value of the EAP/XAuth secret. It may either be an ASCII string,
1194 a hex encoded string if it has a 0x prefix or a Base64 encoded
1195 string if it has a 0s prefix in its value.
1196 secrets.eap<suffix>.id<suffix> []
1199 Identity the EAP/XAuth secret belongs to. Multiple unique iden‐
1200 tities may be specified, each having an id prefix, if a secret
1201 is shared between multiple users.
1202 secrets.xauth<suffix>
1205 XAuth secret section for a specific secret. xauth is just an
1206 alias for eap, secrets under both section prefixes are used for
1207 both EAP and XAuth authentication.
1208 secrets.ntlm<suffix>
1211 NTLM secret section for a specific secret. Each NTLM secret is
1212 defined in a unique section having the ntlm prefix. NTLM secrets
1213 may only be used for EAP-MSCHAPv2 authentication.
1214 secrets.ntlm<suffix>.secret []
1217 Value of the NTLM secret, which is the NT Hash of the actual se‐
1218 cret, that is, MD4(UTF-16LE(secret)). The resulting 16-byte
1219 value may either be given as a hex encoded string with a 0x pre‐
1220 fix or as a Base64 encoded string with a 0s prefix.
1221 secrets.ntlm<suffix>.id<suffix> []
1224 Identity the NTLM secret belongs to. Multiple unique identities
1225 may be specified, each having an id prefix, if a secret is
1226 shared between multiple users.
1227 secrets.ike<suffix>
1230 IKE preshared secret section for a specific secret. Each IKE PSK
1231 is defined in a unique section having the ike prefix.
1232 secrets.ike<suffix>.secret []
1235 Value of the IKE preshared secret. It may either be an ASCII
1236 string, a hex encoded string if it has a 0x prefix or a Base64
1237 encoded string if it has a 0s prefix in its value.
1238 secrets.ike<suffix>.id<suffix> []
1241 IKE identity the IKE preshared secret belongs to. Multiple
1242 unique identities may be specified, each having an id prefix, if
1243 a secret is shared between multiple peers.
1244 secrets.ppk<suffix>
1247 Postquantum Preshared Key (PPK) section for a specific secret.
1248 Each PPK is defined in a unique section having the ppk pre‐
1249 fix.
1250 secrets.ppk<suffix>.secret []
1253 Value of the PPK. It may either be an ASCII string, a hex
1254 encoded string if it has a 0x prefix or a Base64 encoded string
1255 if it has a 0s prefix in its value. Should have at least 256
1256 bits of entropy for 128-bit security.
1257 secrets.ppk<suffix>.id<suffix> []
1260 PPK identity the PPK belongs to. Multiple unique identities may
1261 be specified, each having an id prefix, if a secret is shared
1262 between multiple peers.
1263 secrets.private<suffix>
1266 Private key decryption passphrase for a key in the private
1267 folder.
1268 secrets.private<suffix>.file []
1271 File name in the private folder for which this passphrase should
1272 be used.
1273 secrets.private<suffix>.secret []
1276 Value of decryption passphrase for private key.
1277 secrets.rsa<suffix>
1280 Private key decryption passphrase for a key in the rsa folder.
1281 secrets.rsa<suffix>.file []
1284 File name in the rsa folder for which this passphrase should be
1285 used.
1286 secrets.rsa<suffix>.secret []
1289 Value of decryption passphrase for RSA key.
1290 secrets.ecdsa<suffix>
1293 Private key decryption passphrase for a key in the ecdsa folder.
1294 secrets.ecdsa<suffix>.file []
1297 File name in the ecdsa folder for which this passphrase should
1298 be used.
1299 secrets.ecdsa<suffix>.secret []
1302 Value of decryption passphrase for ECDSA key.
1303 secrets.pkcs8<suffix>
1306 Private key decryption passphrase for a key in the pkcs8 folder.
1307 secrets.pkcs8<suffix>.file []
1310 File name in the pkcs8 folder for which this passphrase should
1311 be used.
1312 secrets.pkcs8<suffix>.secret []
1315 Value of decryption passphrase for PKCS#8 key.
1316 secrets.pkcs12<suffix>
1319 PKCS#12 decryption passphrase for a container in the pkcs12
1320 folder.
1321 secrets.pkcs12<suffix>.file []
1324 File name in the pkcs12 folder for which this passphrase should
1325 be used.
1326 secrets.pkcs12<suffix>.secret []
1329 Value of decryption passphrase for PKCS#12 container.
1330 secrets.token<suffix>
1333 Definition for a private key that's stored on a token/smartcard.
1334 secrets.token<suffix>.handle []
1337 Hex-encoded CKA_ID of the private key on the token.
1338 secrets.token<suffix>.slot []
1341 Optional slot number to access the token.
1342 secrets.token<suffix>.module []
1345 Optional PKCS#11 module name to access the token.
1346 secrets.token<suffix>.pin []
1349 Optional PIN required to access the key on the token. If none is
1350 provided the user is prompted during an interactive --load-creds
1351 call.
1352 pools
1355 Section defining named pools. Named pools may be referenced by
1356 connections with the pools option to assign virtual IPs and
1357 other configuration attributes.
1358 pools.<name>
1361 Section defining a single pool with a unique name.
1362 pools.<name>.addrs []
1365 Subnet or range defining addresses allocated in pool. Accepts a
1366 single CIDR subnet defining the pool to allocate addresses from
1367 or an address range (<from>-<to>). Pools must be unique and
1368 non-overlapping.
1369 pools.<name>.<attr> []
1372 Comma separated list of additional attributes of type <attr>.
1373 The attribute type may be one of dns, nbns, dhcp, netmask,
1374 server, subnet, split_include and split_exclude to define ad‐
1375 dresses or CIDR subnets for the corresponding attribute types.
1376 Alternatively, <attr> can be a numerical identifier, for which
1377 string attribute values are accepted as well.
1378 authorities
1381 Section defining attributes of certification authorities.
1382 authorities.<name>
1385 Section defining a certification authority with a unique name.
1386 authorities.<name>.cacert []
1389 CA certificate belonging to the certification authority. The
1390 certificates may use a relative path from the swanctl x509ca di‐
1391 rectory or an absolute path.
1392 Configure one of cacert, file, or handle per section.
1394 authorities.<name>.file []
1397 Absolute path to the certificate to load. Passed as-is to the
1398 daemon, so it must be readable by it.
1399 Configure one of cacert, file, or handle per section.
1401 authorities.<name>.handle []
1404 Hex-encoded CKA_ID of the CA certificate on a token.
1405 Configure one of cacert, file, or handle per section.
1407 authorities.<name>.slot []
1410 Optional slot number of the token that stores the CA certifi‐
1411 cate.
1412 authorities.<name>.module []
1415 Optional PKCS#11 module name.
1416 authorities.<name>.crl_uris []
1419 Comma-separated list of CRL distribution points (ldap, http, or
1420 file URI).
1421 authorities.<name>.ocsp_uris []
1424 Comma-separated list of OCSP URIs.
1425 authorities.<name>.cert_uri_base []
1428 Defines the base URI for the Hash and URL feature supported by
1429 IKEv2. Instead of exchanging complete certificates, IKEv2 allows
1430 one to send an URI that resolves to the DER encoded certificate.
1431 The certificate URIs are built by appending the SHA1 hash of the
1432 DER encoded certificates to this base URI.
1433
1436 /etc/strongswan/swanctl/swanctl.conf configuration file
1437
1439 swanctl(8)
14405.9.9 SWANCTL.CONF(5)