1SWANCTL.CONF(5)                   strongSwan                   SWANCTL.CONF(5)
2
3
4

NAME

6       swanctl.conf - swanctl configuration file
7

DESCRIPTION

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
12       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
16

TIME FORMATS

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
22

SETTINGS

24       The following settings can be used to  configure  connections,  creden‐
25       tials and pools.
26
27       connections
28              Section defining IKE connection configurations.
29
30              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
35
36       connections.<conn>
37              Section for an IKE connection named <conn>.
38
39
40       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
46
47       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
52              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
57              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
61
62       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
67              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
72              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
76              To  initiate  a connection, at least one specific address or DNS
77              name must be specified.
78
79
80       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
86              Using  a  non-default  local  IKE port requires support from the
87              socket backend in use (socket-dynamic).
88
89
90       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
95
96       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
103              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
109              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
114
115       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
122
123       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
130
131       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
137              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
140
141       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
147
148       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
154              Usually  this  is  not  required, but it can help to work around
155              connectivity issues with too restrictive intermediary firewalls.
156
157
158       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
163              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
169
170       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
176
177       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
184
185       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
197              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
201
202
203       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
218
219       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
225              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
229
230       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
238
239       connections.<conn>.ppk_id []
240              String identifying the Postquantum Preshared  Key  (PPK)  to  be
241              used.
242
243
244       connections.<conn>.ppk_required [no]
245              Whether  a  Postquantum Preshared Key (PPK) is required for this
246              connection.
247
248
249       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
257
258       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
269              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
274              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
280
281       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
289              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
294
295       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
301              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
306
307       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
314              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
317              The default is 10% of the longer of rekey_time and reauth_time.
318
319
320
321       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
327              The default is equal to the configured over_time.
328
329
330
331       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
337
338       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
342
343       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
347
348       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
354
355       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
361
362       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
371
372       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
378              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
382
383       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
388
389       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
394              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
398
399       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
404
405       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
409              Configure either this or handle, but not both, in one section.
410
411
412       connections.<conn>.local<suffix>.cert<suffix>.handle []
413              Hex-encoded CKA_ID of the certificate on a token.
414
415              Configure either this or file, but not both, in one section.
416
417
418       connections.<conn>.local<suffix>.cert<suffix>.slot []
419              Optional slot number of the token that stores the certificate.
420
421
422       connections.<conn>.local<suffix>.cert<suffix>.module []
423              Optional PKCS#11 module name.
424
425
426       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
431              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
435
436       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
443              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
450              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
454              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
472
473
474       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
479              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
497
498       connections.<conn>.local<suffix>.eap_id [id]
499              Client EAP-Identity to use in EAP-Identity exchange and the  EAP
500              method.
501
502
503       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
510              For  EAP-(T)TLS,  this defines the identity for which the server
511              must provide a certificate in the TLS exchange.
512
513
514       connections.<conn>.local<suffix>.xauth_id [id]
515              Client XAuth username used in the XAuth exchange.
516
517
518       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
524              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
528
529       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
534
535       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
539              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
545
546       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
551
552       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
559
560       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
565
566       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
571
572       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
577
578       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
582              Configure either this or handle, but not both, in one section.
583
584
585       connections.<conn>.remote<suffix>.cert<suffix>.handle []
586              Hex-encoded CKA_ID of the certificate on a token.
587
588              Configure either this or file, but not both, in one section.
589
590
591       connections.<conn>.remote<suffix>.cert<suffix>.slot []
592              Optional slot number of the token that stores the certificate.
593
594
595       connections.<conn>.remote<suffix>.cert<suffix>.module []
596              Optional PKCS#11 module name.
597
598
599       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
604
605       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
610
611       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
615              Configure either this or handle, but not both, in one section.
616
617
618       connections.<conn>.remote<suffix>.cacert<suffix>.handle []
619              Hex-encoded CKA_ID of the CA certificate on a token.
620
621              Configure either this or file, but not both, in one section.
622
623
624       connections.<conn>.remote<suffix>.cacert<suffix>.slot []
625              Optional slot number of the token that stores  the  CA  certifi‐
626              cate.
627
628
629       connections.<conn>.remote<suffix>.cacert<suffix>.module []
630              Optional PKCS#11 module name.
631
632
633       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
641
642       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
647
648       connections.<conn>.remote<suffix>.revocation [relaxed]
649              Certificate revocation policy for CRL or OCSP revocation.
650
651              A strict revocation policy fails if no revocation information is
652              available, i.e. the certificate is not known to be unrevoked.
653
654              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
658              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
661
662       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
667              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
684
685              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
689
690
691       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
697
698       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
706              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
712              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
718
719       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
727              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
737              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
741              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
747              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
754
755       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
763
764       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
772              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
782              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
789              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
794
795       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
799
800       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
805              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
809              By default CHILD_SA rekeying  is  scheduled  every  hour,  minus
810              rand_time.
811
812
813
814       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
820              The default is 10% more than the rekey_time.
821
822
823
824       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
829
830
831       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
836              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
840              Volume based CHILD_SA rekeying is disabled by default.
841
842
843       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
849              The default is 10% more than rekey_bytes.
850
851
852
853       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
859
860
861       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
866              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
870              Packet count based CHILD_SA rekeying is disabled by default.
871
872
873       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
879              The default is 10% more than rekey_bytes.
880
881
882
883       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
889
890
891       connections.<conn>.children.<child>.updown []
892              Updown script to invoke on CHILD_SA up and down events.
893
894
895       connections.<conn>.children.<child>.hostaccess [no]
896              Hostaccess variable to pass to updown script.
897
898
899       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
907              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
911              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
915
916       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
921
922       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
927
928       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
935
936       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
941
942       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
948
949       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
955
956       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
962
963       connections.<conn>.children.<child>.interface []
964              Optional interface name to restrict IPsec policies.
965
966
967       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
978              An additional mask may be appended to the mark, separated by  /.
979              The default mask if omitted is 0xffffffff.
980
981
982       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
991
992       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
1002              An additional mask may be appended to the mark, separated by  /.
1003              The default mask if omitted is 0xffffffff.
1004
1005
1006       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
1012              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
1017
1018              Setting marks in XFRM input requires Linux 4.19 or higher.
1019
1020
1021       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
1026              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
1031
1032              Setting marks in XFRM output is supported since Linux 4.14. Set‐
1033              ting a mask requires at least Linux 4.19.
1034
1035
1036       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
1044
1045       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
1053              The  daemon will not install routes for CHILD_SAs that have this
1054              option set.
1055
1056
1057       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
1062              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
1066
1067       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
1072
1073       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
1080
1081       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
1087
1088       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
1094
1095       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
1107
1108       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
1113              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
1117              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
1122
1123       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
1128              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
1133
1134       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
1139              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
1144
1145       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
1150
1151       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
1156
1157       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
1162
1163       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
1168
1169       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
1174
1175       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
1181
1182       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
1187
1188       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
1192
1193       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
1198
1199       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
1204
1205       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
1210
1211       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
1217
1218       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
1223
1224       secrets.private<suffix>
1225              Private  key  decryption  passphrase  for  a  key in the private
1226              folder.
1227
1228
1229       secrets.private<suffix>.file []
1230              File name in the private folder for which this passphrase should
1231              be used.
1232
1233
1234       secrets.private<suffix>.secret []
1235              Value of decryption passphrase for private key.
1236
1237
1238       secrets.rsa<suffix>
1239              Private key decryption passphrase for a key in the rsa folder.
1240
1241
1242       secrets.rsa<suffix>.file []
1243              File  name in the rsa folder for which this passphrase should be
1244              used.
1245
1246
1247       secrets.rsa<suffix>.secret []
1248              Value of decryption passphrase for RSA key.
1249
1250
1251       secrets.ecdsa<suffix>
1252              Private key decryption passphrase for a key in the ecdsa folder.
1253
1254
1255       secrets.ecdsa<suffix>.file []
1256              File name in the ecdsa folder for which this  passphrase  should
1257              be used.
1258
1259
1260       secrets.ecdsa<suffix>.secret []
1261              Value of decryption passphrase for ECDSA key.
1262
1263
1264       secrets.pkcs8<suffix>
1265              Private key decryption passphrase for a key in the pkcs8 folder.
1266
1267
1268       secrets.pkcs8<suffix>.file []
1269              File  name  in the pkcs8 folder for which this passphrase should
1270              be used.
1271
1272
1273       secrets.pkcs8<suffix>.secret []
1274              Value of decryption passphrase for PKCS#8 key.
1275
1276
1277       secrets.pkcs12<suffix>
1278              PKCS#12 decryption passphrase for  a  container  in  the  pkcs12
1279              folder.
1280
1281
1282       secrets.pkcs12<suffix>.file []
1283              File  name in the pkcs12 folder for which this passphrase should
1284              be used.
1285
1286
1287       secrets.pkcs12<suffix>.secret []
1288              Value of decryption passphrase for PKCS#12 container.
1289
1290
1291       secrets.token<suffix>
1292              Definition for a private key that's stored on a token/smartcard.
1293
1294
1295       secrets.token<suffix>.handle []
1296              Hex-encoded CKA_ID of the private key on the token.
1297
1298
1299       secrets.token<suffix>.slot []
1300              Optional slot number to access the token.
1301
1302
1303       secrets.token<suffix>.module []
1304              Optional PKCS#11 module name to access the token.
1305
1306
1307       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
1312
1313       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
1318
1319       pools.<name>
1320              Section defining a single pool with a unique name.
1321
1322
1323       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
1329
1330       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
1338
1339       authorities
1340              Section defining attributes of certification authorities.
1341
1342
1343       authorities.<name>
1344              Section defining a certification authority with a unique name.
1345
1346
1347       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
1352              Configure one of cacert, file, or handle per section.
1353
1354
1355       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
1359              Configure one of cacert, file, or handle per section.
1360
1361
1362       authorities.<name>.handle []
1363              Hex-encoded CKA_ID of the CA certificate on a token.
1364
1365              Configure one of cacert, file, or handle per section.
1366
1367
1368       authorities.<name>.slot []
1369              Optional  slot  number  of the token that stores the CA certifi‐
1370              cate.
1371
1372
1373       authorities.<name>.module []
1374              Optional PKCS#11 module name.
1375
1376
1377       authorities.<name>.crl_uris []
1378              Comma-separated list of CRL distribution points (ldap, http,  or
1379              file URI).
1380
1381
1382       authorities.<name>.ocsp_uris []
1383              Comma-separated list of OCSP URIs.
1384
1385
1386       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
1393

FILES

1395       /etc/swanctl/swanctl.conf       configuration file
1396

SEE ALSO

1398       swanctl(8)
1399
1400
1401
14025.9.1                                                          SWANCTL.CONF(5)
Impressum