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
43 accepts both IKEv1 and IKEv2 as responder, and initiates the
44 connection 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
144 encoded string specifying the Codepoint to set, as defined in
145 RFC 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
160 default 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
182 effect 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
198 accepted 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
252 retransmission 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
261 enforced. 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
297 exchange, but does not re-check associated credentials. It is
298 supported in IKEv2 only, IKEv1 performs a reauthentication pro‐
299 cedure 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
351 using the IKEv2 Mediation Extension. Mediation connections cre‐
352 ate 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
358 mediation connection. The mediation connection must have media‐
359 tion 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
391 authentication. The certificates may use a relative path from
392 the 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
428 authentication. 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
438 authentication using a private key associated to a usable cer‐
439 tificate. psk uses pre-shared key authentication. The IKEv1
440 specific 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
491 implicit 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
656 information 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
670 acceptable 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
722 integrity 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
731 derived from the IKE_SA's key material. So any DH group speci‐
732 fied here will only apply when the CHILD_SA is later rekeyed or
733 is 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,
783 except if the Cisco Unity extension plugin is used. This is due
784 to a limitation of the IKEv1 protocol, which only allows a sin‐
785 gle pair of selectors per CHILD_SA. So to tunnel traffic matched
786 by 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
817 before. 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. restart immedi‐
933 ately tries to re-negotiate the CHILD_SA under a fresh IKE_SA.
934 connections.<conn>.children.<child>.ipcomp [no]
937 Enable IPComp compression before encryption. If enabled, IKE
938 tries to negotiate IPComp compression to compress ESP payload
939 data prior to encryption.
940 connections.<conn>.children.<child>.inactivity [0s]
943 Timeout before closing CHILD_SA after inactivity. If no traffic
944 has been processed in either direction for the configured time‐
945 out, the CHILD_SA gets closed due to inactivity. The default
946 value of 0 disables inactivity checks.
947 connections.<conn>.children.<child>.reqid [0]
950 Fixed reqid to use for this CHILD_SA. This might be helpful in
951 some scenarios, but works only if each CHILD_SA configuration is
952 instantiated not more than once. The default of 0 uses dynamic
953 reqids, allocated incrementally.
954 connections.<conn>.children.<child>.priority [0]
957 Optional fixed priority for IPsec policies. This could be useful
958 to install high-priority drop policies. The default of 0 uses
959 dynamically calculated priorities based on the size of the traf‐
960 fic selectors.
961 connections.<conn>.children.<child>.interface []
964 Optional interface name to restrict IPsec policies.
965 connections.<conn>.children.<child>.mark_in [0/0x00000000]
968 Netfilter mark and mask for input traffic. On Linux, Netfilter
969 may require marks on each packet to match an SA/policy having
970 that option set. This allows installing duplicate policies and
971 enables Netfilter rules to select specific SAs/policies for
972 incoming traffic. Note that inbound marks are only set on poli‐
973 cies, by default, unless *mark_in_sa* is enabled. The special
974 value %unique sets a unique mark on each CHILD_SA instance,
975 beyond that the value %unique-dir assigns a different unique
976 mark for each CHILD_SA direction (in/out).
977 An additional mask may be appended to the mark, separated by /.
979 The default mask if omitted is 0xffffffff.
980 connections.<conn>.children.<child>.mark_in_sa [no]
983 Whether to set *mark_in* on the inbound SA. By default, the
984 inbound mark is only set on the inbound policy. The tuple desti‐
985 nation address, protocol and SPI is unique and the mark is not
986 required to find the correct SA, allowing to mark traffic after
987 decryption instead (where more specific selectors may be used)
988 to match different policies. Marking packets before decryption
989 is still possible, even if no mark is set on the SA.
990 connections.<conn>.children.<child>.mark_out [0/0x00000000]
993 Netfilter mark and mask for output traffic. On Linux, Netfilter
994 may require marks on each packet to match a policy/SA having
995 that option set. This allows installing duplicate policies and
996 enables Netfilter rules to select specific policies/SAs for out‐
997 going traffic. The special value %unique sets a unique mark on
998 each CHILD_SA instance, beyond that the value %unique-dir
999 assigns a different unique mark for each CHILD_SA direction
1000 (in/out).
1001 An additional mask may be appended to the mark, separated by /.
1003 The default mask if omitted is 0xffffffff.
1004 connections.<conn>.children.<child>.set_mark_in [0/0x00000000]
1007 Netfilter mark applied to packets after the inbound IPsec SA
1008 processed them. This way it's not necessary to mark packets via
1009 Netfilter before decryption or right afterwards to match poli‐
1010 cies or process them differently (e.g. via policy routing).
1011 An additional mask may be appended to the mark, separated by /.
1013 The default mask if omitted is 0xffffffff. The special value
1014 %same uses the value (but not the mask) from mark_in as mark
1015 value, which can be fixed, %unique or %unique-dir.
1016 Setting marks in XFRM input requires Linux 4.19 or higher.
1019 connections.<conn>.children.<child>.set_mark_out [0/0x00000000]
1022 Netfilter mark applied to packets after the outbound IPsec SA
1023 processed them. This allows processing ESP packets differently
1024 than the original traffic (e.g. via policy routing).
1025 An additional mask may be appended to the mark, separated by /.
1027 The default mask if omitted is 0xffffffff. The special value
1028 %same uses the value (but not the mask) from mark_out as mark
1029 value, which can be fixed, %unique or %unique-dir.
1030 Setting marks in XFRM output is supported since Linux 4.14. Set‐
1033 ting a mask requires at least Linux 4.19.
1034 connections.<conn>.children.<child>.if_id_in [0]
1037 XFRM interface ID set on inbound policies/SA. This allows
1038 installing duplicate policies/SAs and associates them with an
1039 interface with the same ID. The special value %unique sets a
1040 unique interface ID on each CHILD_SA instance, beyond that the
1041 value %unique-dir assigns a different unique interface ID for
1042 each CHILD_SA direction (in/out).
1043 connections.<conn>.children.<child>.if_id_out [0]
1046 XFRM interface ID set on outbound policies/SA. This allows
1047 installing duplicate policies/SAs and associates them with an
1048 interface with the same ID. The special value %unique sets a
1049 unique interface ID on each CHILD_SA instance, beyond that the
1050 value %unique-dir assigns a different unique interface ID for
1051 each CHILD_SA direction (in/out).
1052 The daemon will not install routes for CHILD_SAs that have this
1054 option set.
1055 connections.<conn>.children.<child>.tfc_padding [0]
1058 Pads ESP packets with additional data to have a consistent ESP
1059 packet size for improved Traffic Flow Confidentiality. The pad‐
1060 ding defines the minimum size of all ESP packets sent.
1061 The default value of 0 disables TFC padding, the special value
1063 mtu adds TFC padding to create a packet size equal to the Path
1064 Maximum Transfer Unit.
1065 connections.<conn>.children.<child>.replay_window [32]
1068 IPsec replay window to configure for this CHILD_SA. Larger val‐
1069 ues than the default of 32 are supported using the Netlink back‐
1070 end only, a value of 0 disables IPsec replay protection.
1071 connections.<conn>.children.<child>.hw_offload [no]
1074 Enable hardware offload for this CHILD_SA, if supported by the
1075 IPsec implementation. The value yes enforces offloading and the
1076 installation will fail if it's not supported by either kernel or
1077 device. The value auto enables offloading, if it's sup‐
1078 ported, but the installation does not fail otherwise.
1079 connections.<conn>.children.<child>.copy_df [yes]
1082 Whether to copy the DF bit to the outer IPv4 header in tunnel
1083 mode. This effectively disables Path MTU discovery (PMTUD).
1084 Controlling this behavior is not supported by all kernel inter‐
1085 faces.
1086 connections.<conn>.children.<child>.copy_ecn [yes]
1089 Whether to copy the ECN (Explicit Congestion Notification)
1090 header field to/from the outer IP header in tunnel mode. Con‐
1091 trolling this behavior is not supported by all kernel inter‐
1092 faces.
1093 connections.<conn>.children.<child>.copy_dscp [out]
1096 Whether to copy the DSCP (Differentiated Services Field Code‐
1097 point) header field to/from the outer IP header in tunnel mode.
1098 The value out only copies the field from the inner to the outer
1099 header, the value in does the opposite and only copies the field
1100 from the outer to the inner header when decapsulating, the value
1101 yes copies the field in both directions, and the value no dis‐
1102 ables copying the field altogether. Setting this to yes or in
1103 could allow an attacker to adversely affect other traffic at the
1104 receiver, which is why the default is out. Controlling this
1105 behavior is not supported by all kernel interfaces.
1106 connections.<conn>.children.<child>.start_action [none]
1109 Action to perform after loading the configuration. The default
1110 of none loads the connection only, which then can be manually
1111 initiated or used as a responder configuration.
1112 The value trap installs a trap policy, which triggers the tunnel
1114 as soon as matching traffic has been detected. The value start
1115 initiates the connection actively.
1116 When unloading or replacing a CHILD_SA configuration having a
1118 start_action different from none, the inverse action is per‐
1119 formed. Configurations with start get closed, while such with
1120 trap get uninstalled.
1121 connections.<conn>.children.<child>.close_action [none]
1124 Action to perform after a CHILD_SA gets closed by the peer. The
1125 default of none does not take any action, trap installs a trap
1126 policy for the CHILD_SA. start tries to re-create the CHILD_SA.
1127 close_action does not provide any guarantee that the CHILD_SA is
1129 kept alive. It acts on explicit close messages only, but not on
1130 negotiation failures. Use trap policies to reliably re-create
1131 failed CHILD_SAs.
1132 secrets
1135 Section defining secrets for IKE/EAP/XAuth authentication and
1136 private key decryption. The secrets section takes sub-sections
1137 having a specific prefix which defines the secret type.
1138 It is not recommended to define any private key decryption
1140 passphrases, as then there is no real security benefit in having
1141 encrypted keys. Either store the key unencrypted or enter the
1142 keys manually when loading credentials.
1143 secrets.eap<suffix>
1146 EAP secret section for a specific secret. Each EAP secret is
1147 defined in a unique section having the eap prefix. EAP secrets
1148 are used for XAuth authentication as well.
1149 secrets.eap<suffix>.secret []
1152 Value of the EAP/XAuth secret. It may either be an ASCII string,
1153 a hex encoded string if it has a 0x prefix or a Base64 encoded
1154 string if it has a 0s prefix in its value.
1155 secrets.eap<suffix>.id<suffix> []
1158 Identity the EAP/XAuth secret belongs to. Multiple unique iden‐
1159 tities may be specified, each having an id prefix, if a secret
1160 is shared between multiple users.
1161 secrets.xauth<suffix>
1164 XAuth secret section for a specific secret. xauth is just an
1165 alias for eap, secrets under both section prefixes are used for
1166 both EAP and XAuth authentication.
1167 secrets.ntlm<suffix>
1170 NTLM secret section for a specific secret. Each NTLM secret is
1171 defined in a unique section having the ntlm prefix. NTLM secrets
1172 may only be used for EAP-MSCHAPv2 authentication.
1173 secrets.ntlm<suffix>.secret []
1176 Value of the NTLM secret, which is the NT Hash of the actual
1177 secret, that is, MD4(UTF-16LE(secret)). The resulting 16-byte
1178 value may either be given as a hex encoded string with a 0x pre‐
1179 fix or as a Base64 encoded string with a 0s prefix.
1180 secrets.ntlm<suffix>.id<suffix> []
1183 Identity the NTLM secret belongs to. Multiple unique identities
1184 may be specified, each having an id prefix, if a secret is
1185 shared between multiple users.
1186 secrets.ike<suffix>
1189 IKE preshared secret section for a specific secret. Each IKE PSK
1190 is defined in a unique section having the ike prefix.
1191 secrets.ike<suffix>.secret []
1194 Value of the IKE preshared secret. It may either be an ASCII
1195 string, a hex encoded string if it has a 0x prefix or a Base64
1196 encoded string if it has a 0s prefix in its value.
1197 secrets.ike<suffix>.id<suffix> []
1200 IKE identity the IKE preshared secret belongs to. Multiple
1201 unique identities may be specified, each having an id prefix, if
1202 a secret is shared between multiple peers.
1203 secrets.ppk<suffix>
1206 Postquantum Preshared Key (PPK) section for a specific secret.
1207 Each PPK is defined in a unique section having the ppk pre‐
1208 fix.
1209 secrets.ppk<suffix>.secret []
1212 Value of the PPK. It may either be an ASCII string, a hex
1213 encoded string if it has a 0x prefix or a Base64 encoded string
1214 if it has a 0s prefix in its value. Should have at least 256
1215 bits of entropy for 128-bit security.
1216 secrets.ppk<suffix>.id<suffix> []
1219 PPK identity the PPK belongs to. Multiple unique identities may
1220 be specified, each having an id prefix, if a secret is shared
1221 between multiple peers.
1222 secrets.private<suffix>
1225 Private key decryption passphrase for a key in the private
1226 folder.
1227 secrets.private<suffix>.file []
1230 File name in the private folder for which this passphrase should
1231 be used.
1232 secrets.private<suffix>.secret []
1235 Value of decryption passphrase for private key.
1236 secrets.rsa<suffix>
1239 Private key decryption passphrase for a key in the rsa folder.
1240 secrets.rsa<suffix>.file []
1243 File name in the rsa folder for which this passphrase should be
1244 used.
1245 secrets.rsa<suffix>.secret []
1248 Value of decryption passphrase for RSA key.
1249 secrets.ecdsa<suffix>
1252 Private key decryption passphrase for a key in the ecdsa folder.
1253 secrets.ecdsa<suffix>.file []
1256 File name in the ecdsa folder for which this passphrase should
1257 be used.
1258 secrets.ecdsa<suffix>.secret []
1261 Value of decryption passphrase for ECDSA key.
1262 secrets.pkcs8<suffix>
1265 Private key decryption passphrase for a key in the pkcs8 folder.
1266 secrets.pkcs8<suffix>.file []
1269 File name in the pkcs8 folder for which this passphrase should
1270 be used.
1271 secrets.pkcs8<suffix>.secret []
1274 Value of decryption passphrase for PKCS#8 key.
1275 secrets.pkcs12<suffix>
1278 PKCS#12 decryption passphrase for a container in the pkcs12
1279 folder.
1280 secrets.pkcs12<suffix>.file []
1283 File name in the pkcs12 folder for which this passphrase should
1284 be used.
1285 secrets.pkcs12<suffix>.secret []
1288 Value of decryption passphrase for PKCS#12 container.
1289 secrets.token<suffix>
1292 Definition for a private key that's stored on a token/smartcard.
1293 secrets.token<suffix>.handle []
1296 Hex-encoded CKA_ID of the private key on the token.
1297 secrets.token<suffix>.slot []
1300 Optional slot number to access the token.
1301 secrets.token<suffix>.module []
1304 Optional PKCS#11 module name to access the token.
1305 secrets.token<suffix>.pin []
1308 Optional PIN required to access the key on the token. If none is
1309 provided the user is prompted during an interactive --load-creds
1310 call.
1311 pools
1314 Section defining named pools. Named pools may be referenced by
1315 connections with the pools option to assign virtual IPs and
1316 other configuration attributes.
1317 pools.<name>
1320 Section defining a single pool with a unique name.
1321 pools.<name>.addrs []
1324 Subnet or range defining addresses allocated in pool. Accepts a
1325 single CIDR subnet defining the pool to allocate addresses from
1326 or an address range (<from>-<to>). Pools must be unique and
1327 non-overlapping.
1328 pools.<name>.<attr> []
1331 Comma separated list of additional attributes of type <attr>.
1332 The attribute type may be one of dns, nbns, dhcp, netmask,
1333 server, subnet, split_include and split_exclude to define
1334 addresses or CIDR subnets for the corresponding attribute types.
1335 Alternatively, <attr> can be a numerical identifier, for which
1336 string attribute values are accepted as well.
1337 authorities
1340 Section defining attributes of certification authorities.
1341 authorities.<name>
1344 Section defining a certification authority with a unique name.
1345 authorities.<name>.cacert []
1348 CA certificate belonging to the certification authority. The
1349 certificates may use a relative path from the swanctl x509ca
1350 directory or an absolute path.
1351 Configure one of cacert, file, or handle per section.
1353 authorities.<name>.file []
1356 Absolute path to the certificate to load. Passed as-is to the
1357 daemon, so it must be readable by it.
1358 Configure one of cacert, file, or handle per section.
1360 authorities.<name>.handle []
1363 Hex-encoded CKA_ID of the CA certificate on a token.
1364 Configure one of cacert, file, or handle per section.
1366 authorities.<name>.slot []
1369 Optional slot number of the token that stores the CA certifi‐
1370 cate.
1371 authorities.<name>.module []
1374 Optional PKCS#11 module name.
1375 authorities.<name>.crl_uris []
1378 Comma-separated list of CRL distribution points (ldap, http, or
1379 file URI).
1380 authorities.<name>.ocsp_uris []
1383 Comma-separated list of OCSP URIs.
1384 authorities.<name>.cert_uri_base []
1387 Defines the base URI for the Hash and URL feature supported by
1388 IKEv2. Instead of exchanging complete certificates, IKEv2 allows
1389 one to send an URI that resolves to the DER encoded certificate.
1390 The certificate URIs are built by appending the SHA1 hash of the
1391 DER encoded certificates to this base URI.
1392
1395 /etc/swanctl/swanctl.conf configuration file
1396
1398 swanctl(8)
13995.9.1 SWANCTL.CONF(5)