Annotation of embedaddon/strongswan/src/swanctl/swanctl.opt, revision 1.1.1.1
1.1 misho 1: connections { # }
2: Section defining IKE connection configurations.
3:
4: Section defining IKE connection configurations.
5:
6: The connections section defines IKE connection configurations, each in
7: its own subsections. In the keyword description below, the connection
8: is named _<conn>_, but an arbitrary yet unique connection name can be
9: chosen for each connection subsection.
10:
11: connections.<conn> { # }
12: Section for an IKE connection named <conn>.
13:
14: connections.<conn>.version = 0
15: IKE major version to use for connection.
16:
17: IKE major version to use for connection. _1_ uses IKEv1 aka ISAKMP, _2_
18: uses IKEv2. A connection using the default of _0_ accepts both IKEv1
19: and IKEv2 as responder, and initiates the connection actively with IKEv2.
20:
21: connections.<conn>.local_addrs = %any
22: Local address(es) to use for IKE communication, comma separated.
23:
24: Local address(es) to use for IKE communication, comma separated. Takes
25: single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges.
26:
27: As initiator, the first non-range/non-subnet is used to initiate the
28: connection from. As responder, the local destination address must match at
29: least to one of the specified addresses, subnets or ranges.
30:
31: If FQDNs are assigned they are resolved every time a configuration lookup
32: is done. If DNS resolution times out, the lookup is delayed for that time.
33:
34: connections.<conn>.remote_addrs = %any
35: Remote address(es) to use for IKE communication, comma separated.
36:
37: Remote address(es) to use for IKE communication, comma separated. Takes
38: single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges.
39:
40: As initiator, the first non-range/non-subnet is used to initiate the
41: connection to. As responder, the initiator source address must match at
42: least to one of the specified addresses, subnets or ranges.
43:
44: If FQDNs are assigned they are resolved every time a configuration lookup
45: is done. If DNS resolution times out, the lookup is delayed for that time.
46:
47: To initiate a connection, at least one specific address or DNS name must
48: be specified.
49:
50: connections.<conn>.local_port = 500
51: Local UDP port for IKE communication.
52:
53: Local UDP port for IKE communication. By default the port of the socket
54: backend is used, which is usually _500_. If port _500_ is used, automatic
55: IKE port floating to port 4500 is used to work around NAT issues.
56:
57: Using a non-default local IKE port requires support from the socket backend
58: in use (socket-dynamic).
59:
60: connections.<conn>.remote_port = 500
61: Remote UDP port for IKE communication.
62:
63: Remote UDP port for IKE communication. If the default of port _500_ is used,
64: automatic IKE port floating to port 4500 is used to work around NAT issues.
65:
66: connections.<conn>.proposals = default
67: Comma separated proposals to accept for IKE.
68:
69: A proposal is a set of algorithms. For non-AEAD algorithms, this includes
70: for IKE an encryption algorithm, an integrity algorithm, a pseudo random
71: function and a Diffie-Hellman group. For AEAD algorithms, instead of
72: encryption and integrity algorithms, a combined algorithm is used.
73:
74: In IKEv2, multiple algorithms of the same kind can be specified in a single
75: proposal, from which one gets selected. In IKEv1, only one algorithm per
76: kind is allowed per proposal, more algorithms get implicitly stripped. Use
77: multiple proposals to offer different algorithms combinations in IKEv1.
78:
79: Algorithm keywords get separated using dashes. Multiple proposals may be
80: separated by commas. The special value _default_ forms a default proposal
81: of supported algorithms considered safe, and is usually a good choice
82: for interoperability.
83:
84: connections.<conn>.vips =
85: Virtual IPs to request in configuration payload / Mode Config.
86:
87: Comma separated list of virtual IPs to request in IKEv2 configuration
88: payloads or IKEv1 Mode Config. The wildcard addresses _0.0.0.0_ and _::_
89: request an arbitrary address, specific addresses may be defined. The
90: responder may return a different address, though, or none at all.
91:
92: connections.<conn>.aggressive = no
93: Use Aggressive Mode in IKEv1.
94:
95: Enables Aggressive Mode instead of Main Mode with Identity Protection.
96: Aggressive Mode is considered less secure, because the ID and HASH
97: payloads are exchanged unprotected. This allows a passive attacker to
98: snoop peer identities, and even worse, start dictionary attacks on the
99: Preshared Key.
100:
101: connections.<conn>.pull = yes
102: Set the Mode Config mode to use.
103:
104: If the default of _yes_ is used, Mode Config works in pull mode, where
105: the initiator actively requests a virtual IP. With _no_, push mode is used,
106: where the responder pushes down a virtual IP to the initiating peer.
107:
108: Push mode is currently supported for IKEv1, but not in IKEv2. It is used
109: by a few implementations only, pull mode is recommended.
110:
111: connections.<conn>.dscp = 000000
112: Differentiated Services Field Codepoint to set on outgoing IKE packets (six
113: binary digits).
114:
115: Differentiated Services Field Codepoint to set on outgoing IKE packets for
116: this connection. The value is a six digit binary encoded string specifying
117: the Codepoint to set, as defined in RFC 2474.
118:
119: connections.<conn>.encap = no
120: Enforce UDP encapsulation by faking NAT-D payloads.
121:
122: To enforce UDP encapsulation of ESP packets, the IKE daemon can fake the
123: NAT detection payloads. This makes the peer believe that NAT takes
124: place on the path, forcing it to encapsulate ESP packets in UDP.
125:
126: Usually this is not required, but it can help to work around connectivity
127: issues with too restrictive intermediary firewalls.
128:
129: connections.<conn>.mobike = yes
130: Enables MOBIKE on IKEv2 connections.
131:
132: Enables MOBIKE on IKEv2 connections. MOBIKE is enabled by default on IKEv2
133: connections, and allows mobility of clients and multi-homing on servers by
134: migrating active IPsec tunnels.
135:
136: Usually keeping MOBIKE enabled is unproblematic, as it is not used if the
137: peer does not indicate support for it. However, due to the design of MOBIKE,
138: IKEv2 always floats to port 4500 starting from the second exchange. Some
139: implementations don't like this behavior, hence it can be disabled.
140:
141: connections.<conn>.dpd_delay = 0s
142: Interval of liveness checks (DPD).
143:
144: Interval to check the liveness of a peer actively using IKEv2 INFORMATIONAL
145: exchanges or IKEv1 R_U_THERE messages. Active DPD checking is only enforced
146: if no IKE or ESP/AH packet has been received for the configured DPD delay.
147:
148: connections.<conn>.dpd_timeout = 0s
149: Timeout for DPD checks (IKEV1 only).
150:
151: Charon by default uses the normal retransmission mechanism and timeouts to
152: check the liveness of a peer, as all messages are used for liveness
153: checking. For compatibility reasons, with IKEv1 a custom interval may be
154: specified; this option has no effect on connections using IKE2.
155:
156: connections.<conn>.fragmentation = yes
157: Use IKE UDP datagram fragmentation (_yes_, _accept_, _no_ or _force_).
158:
159: Use IKE fragmentation (proprietary IKEv1 extension or RFC 7383 IKEv2
160: fragmentation). Acceptable values are _yes_ (the default), _accept_,
161: _force_ and _no_. If set to _yes_, and the peer supports it, oversized IKE
162: messages will be sent in fragments. If set to _accept_, support for
163: fragmentation is announced to the peer but the daemon does not send its own
164: messages in fragments. If set to _force_ (only supported for IKEv1) the
165: initial IKE message will already be fragmented if required. Finally, setting
166: the option to _no_ will disable announcing support for this feature.
167:
168: Note that fragmented IKE messages sent by a peer are always accepted
169: irrespective of the value of this option (even when set to _no_).
170:
171: connections.<conn>.childless = allow
172: Use childless IKE_SA initiation (_allow_, _force_ or _never_).
173:
174: Use childless IKE_SA initiation (RFC 6023) for IKEv2. Acceptable values
175: are _allow_ (the default), _force_ and _never_. If set to _allow_,
176: responders will accept childless IKE_SAs (as indicated via notify in the
177: IKE_SA_INIT response) while initiators continue to create regular IKE_SAs
178: with the first CHILD_SA created during IKE_AUTH, unless the IKE_SA is
179: initiated explicitly without any children (which will fail if the responder
180: does not support or has disabled this extension). If set to _force_, only
181: childless initiation is accepted and the first CHILD_SA is created with a
182: separate CREATE_CHILD_SA exchange (e.g. to use an independent DH exchange
183: for all CHILD_SAs). Finally, setting the option to _never_ disables support
184: for childless IKE_SAs as responder.
185:
186: connections.<conn>.send_certreq = yes
187: Send certificate requests payloads (_yes_ or _no_).
188:
189: Send certificate request payloads to offer trusted root CA certificates
190: to the peer. Certificate requests help the peer to choose an appropriate
191: certificate/private key for authentication and are enabled by default.
192:
193: Disabling certificate requests can be useful if too many trusted root CA
194: certificates are installed, as each certificate request increases the size
195: of the initial IKE packets.
196:
197: connections.<conn>.send_cert = ifasked
198: Send certificate payloads (_always_, _never_ or _ifasked_).
199:
200: Send certificate payloads when using certificate authentication. With the
201: default of _ifasked_ the daemon sends certificate payloads only if
202: certificate requests have been received. _never_ disables sending of
203: certificate payloads altogether, _always_ causes certificate payloads to be
204: sent unconditionally whenever certificate authentication is used.
205:
206: connections.<conn>.ppk_id =
207: String identifying the Postquantum Preshared Key (PPK) to be used.
208:
209: connections.<conn>.ppk_required = no
210: Whether a Postquantum Preshared Key (PPK) is required for this connection.
211:
212: connections.<conn>.keyingtries = 1
213: Number of retransmission sequences to perform during initial connect.
214:
215: Number of retransmission sequences to perform during initial connect.
216: Instead of giving up initiation after the first retransmission sequence with
217: the default value of _1_, additional sequences may be started according to
218: the configured value. A value of _0_ initiates a new sequence until the
219: connection establishes or fails with a permanent error.
220:
221: connections.<conn>.unique = no
222: Connection uniqueness policy (_never_, _no_, _keep_ or _replace_).
223:
224: Connection uniqueness policy to enforce. To avoid multiple connections
225: from the same user, a uniqueness policy can be enforced. The value _never_
226: does never enforce such a policy, even if a peer included INITIAL_CONTACT
227: notification messages, whereas _no_ replaces existing connections for the
228: same identity if a new one has the INITIAL_CONTACT notify. _keep_ rejects
229: new connection attempts if the same user already has an active connection,
230: _replace_ deletes any existing connection if a new one for the same user
231: gets established.
232:
233: To compare connections for uniqueness, the remote IKE identity is used. If
234: EAP or XAuth authentication is involved, the EAP-Identity or XAuth username
235: is used to enforce the uniqueness policy instead.
236:
237: On initiators this setting specifies whether an INITIAL_CONTACT notify is
238: sent during IKE_AUTH if no existing connection is found with the remote
239: peer (determined by the identities of the first authentication round).
240: Unless set to _never_ the client will send a notify.
241:
242: connections.<conn>.reauth_time = 0s
243: Time to schedule IKE reauthentication.
244:
245: Time to schedule IKE reauthentication. IKE reauthentication recreates the
246: IKE/ISAKMP SA from scratch and re-evaluates the credentials. In asymmetric
247: configurations (with EAP or configuration payloads) it might not be possible
248: to actively reauthenticate as responder. The IKEv2 reauthentication lifetime
249: negotiation can instruct the client to perform reauthentication.
250:
251: Reauthentication is disabled by default. Enabling it usually may lead
252: to small connection interruptions, as strongSwan uses a break-before-make
253: policy with IKEv2 to avoid any conflicts with associated tunnel resources.
254:
255: connections.<conn>.rekey_time = 4h
256: Time to schedule IKE rekeying.
257:
258: IKE rekeying refreshes key material using a Diffie-Hellman exchange, but
259: does not re-check associated credentials. It is supported in IKEv2 only,
260: IKEv1 performs a reauthentication procedure instead.
261:
262: With the default value IKE rekeying is scheduled every 4 hours, minus the
263: configured **rand_time**. If a **reauth_time** is configured, **rekey_time**
264: defaults to zero disabling rekeying; explicitly set both to enforce
265: rekeying and reauthentication.
266:
267: connections.<conn>.over_time = 10% of rekey_time/reauth_time
268: Hard IKE_SA lifetime if rekey/reauth does not complete, as time.
269:
270: Hard IKE_SA lifetime if rekey/reauth does not complete, as time.
271: To avoid having an IKE/ISAKMP kept alive if IKE reauthentication or rekeying
272: fails perpetually, a maximum hard lifetime may be specified. If the
273: IKE_SA fails to rekey or reauthenticate within the specified time, the
274: IKE_SA gets closed.
275:
276: In contrast to CHILD_SA rekeying, **over_time** is relative in time to the
277: **rekey_time** _and_ **reauth_time** values, as it applies to both.
278:
279: The default is 10% of the longer of **rekey_time** and **reauth_time**.
280:
281: connections.<conn>.rand_time = over_time
282: Range of random time to subtract from rekey/reauth times.
283:
284: Time range from which to choose a random value to subtract from
285: rekey/reauth times. To avoid having both peers initiating the rekey/reauth
286: procedure simultaneously, a random time gets subtracted from the
287: rekey/reauth times.
288:
289: The default is equal to the configured **over_time**.
290:
291: connections.<conn>.pools =
292: Comma separated list of named IP pools.
293:
294: Comma separated list of named IP pools to allocate virtual IP addresses and
295: other configuration attributes from. Each name references a pool by name
296: from either the **pools** section or an external pool.
297:
298: connections.<conn>.if_id_in = 0
299: Default inbound XFRM interface ID for children.
300:
301: XFRM interface ID set on inbound policies/SA, can be overridden by child
302: config, see there for details.
303:
304: connections.<conn>.if_id_out = 0
305: Default outbound XFRM interface ID for children.
306:
307: XFRM interface ID set on outbound policies/SA, can be overridden by child
308: config, see there for details.
309:
310: connections.<conn>.mediation = no
311: Whether this connection is a mediation connection.
312:
313: Whether this connection is a mediation connection, that is, whether this
314: connection is used to mediate other connections using the IKEv2 Mediation
315: Extension. Mediation connections create no CHILD_SA.
316:
317: connections.<conn>.mediated_by =
318: The name of the connection to mediate this connection through.
319:
320: The name of the connection to mediate this connection through. If given, the
321: connection will be mediated through the named mediation connection.
322: The mediation connection must have **mediation** enabled.
323:
324: connections.<conn>.mediation_peer =
325: Identity under which the peer is registered at the mediation server.
326:
327: Identity under which the peer is registered at the mediation server, that
328: is, the IKE identity the other end of this connection uses as its local
329: identity on its connection to the mediation server. This is the identity we
330: request the mediation server to mediate us with. Only relevant on
331: connections that set **mediated_by**. If it is not given, the remote IKE
332: identity of the first authentication round of this connection will be used.
333:
334: connections.<conn>.local<suffix> {}
335: Section for a local authentication round.
336:
337: Section for a local authentication round. A local authentication round
338: defines the rules how authentication is performed for the local peer.
339: Multiple rounds may be defined to use IKEv2 RFC 4739 Multiple Authentication
340: or IKEv1 XAuth.
341:
342: Each round is defined in a section having _local_ as prefix, and an optional
343: unique suffix. To define a single authentication round, the suffix may be
344: omitted.
345:
346: connections.<conn>.local<suffix>.round = 0
347: Optional numeric identifier by which authentication rounds are sorted. If
348: not specified rounds are ordered by their position in the config file/VICI
349: message.
350:
351: connections.<conn>.local<suffix>.certs =
352: Comma separated list of certificate candidates to use for authentication.
353:
354: Comma separated list of certificate candidates to use for authentication.
355: The certificates may use a relative path from the **swanctl** _x509_
356: directory or an absolute path.
357:
358: The certificate used for authentication is selected based on the received
359: certificate request payloads. If no appropriate CA can be located, the
360: first certificate is used.
361:
362: connections.<conn>.local<suffix>.cert<suffix> =
363: Section for a certificate candidate to use for authentication.
364:
365: Section for a certificate candidate to use for authentication. Certificates
366: in _certs_ are transmitted as binary blobs, these sections offer more
367: flexibility.
368:
369: connections.<conn>.local<suffix>.cert<suffix>.file =
370: Absolute path to the certificate to load.
371:
372: Absolute path to the certificate to load. Passed as-is to the daemon, so it
373: must be readable by it.
374:
375: Configure either this or _handle_, but not both, in one section.
376:
377: connections.<conn>.local<suffix>.cert<suffix>.handle =
378: Hex-encoded CKA_ID of the certificate on a token.
379:
380: Hex-encoded CKA_ID of the certificate on a token.
381:
382: Configure either this or _file_, but not both, in one section.
383:
384: connections.<conn>.local<suffix>.cert<suffix>.slot =
385: Optional slot number of the token that stores the certificate.
386:
387: connections.<conn>.local<suffix>.cert<suffix>.module =
388: Optional PKCS#11 module name.
389:
390: connections.<conn>.local<suffix>.pubkeys =
391: Comma separated list of raw public key candidates to use for authentication.
392:
393: Comma separated list of raw public key candidates to use for authentication.
394: The public keys may use a relative path from the **swanctl** _pubkey_
395: directory or an absolute path.
396:
397: Even though multiple local public keys could be defined in principle, only
398: the first public key in the list is used for authentication.
399:
400: connections.<conn>.local<suffix>.auth = pubkey
401: Authentication to perform locally (_pubkey_, _psk_, _xauth[-backend]_ or
402: _eap[-method]_).
403:
404: Authentication to perform locally. _pubkey_ uses public key authentication
405: using a private key associated to a usable certificate. _psk_ uses
406: pre-shared key authentication. The IKEv1 specific _xauth_ is used for
407: XAuth or Hybrid authentication, while the IKEv2 specific _eap_ keyword
408: defines EAP authentication.
409:
410: For _xauth_, a specific backend name may be appended, separated by a dash.
411: The appropriate _xauth_ backend is selected to perform the XAuth exchange.
412: For traditional XAuth, the _xauth_ method is usually defined in the second
413: authentication round following an initial _pubkey_ (or _psk_) round. Using
414: _xauth_ in the first round performs Hybrid Mode client authentication.
415:
416: For _eap_, a specific EAP method name may be appended, separated by a dash.
417: An EAP module implementing the appropriate method is selected to perform
418: the EAP conversation.
419:
420: If both peers support RFC 7427 ("Signature Authentication in IKEv2")
421: specific hash algorithms to be used during IKEv2 authentication may be
422: configured. To do so use _ike:_ followed by a trust chain signature scheme
423: constraint (see description of the **remote** section's **auth** keyword).
424: For example, with _ike:pubkey-sha384-sha256_ a public key signature scheme
425: with either SHA-384 or SHA-256 would get used for authentication, in that
426: order and depending on the hash algorithms supported by the peer. If no
427: specific hash algorithms are configured, the default is to prefer an
428: algorithm that matches or exceeds the strength of the signature key.
429: If no constraints with _ike:_ prefix are configured any signature scheme
430: constraint (without _ike:_ prefix) will also apply to IKEv2 authentication,
431: unless this is disabled in **strongswan.conf**(5). To use RSASSA-PSS
432: signatures use _rsa/pss_ instead of _pubkey_ or _rsa_ as in e.g.
433: _ike:rsa/pss-sha256_. If _pubkey_ or _rsa_ constraints are configured
434: RSASSA-PSS signatures will only be used if enabled in
435: **strongswan.conf**(5).
436:
437: connections.<conn>.local<suffix>.id =
438: IKE identity to use for authentication round.
439:
440: IKE identity to use for authentication round. When using certificate
441: authentication, the IKE identity must be contained in the certificate,
442: either as subject or as subjectAltName.
443:
444: The identity can be an IP address, a fully-qualified domain name, an email
445: address or a Distinguished Name for which the ID type is determined
446: automatically and the string is converted to the appropriate encoding. To
447: enforce a specific identity type, a prefix may be used, followed by a colon
448: (:). If the number sign (#) follows the colon, the remaining data is
449: interpreted as hex encoding, otherwise the string is used as-is as the
450: identification data. Note that this implies that no conversion is performed
451: for non-string identities. For example, _ipv4:10.0.0.1_ does not create a
452: valid ID_IPV4_ADDR IKE identity, as it does not get converted to binary
453: 0x0a000001. Instead, one could use _ipv4:#0a000001_ to get a valid identity,
454: but just using the implicit type with automatic conversion is usually
455: simpler. The same applies to the ASN1 encoded types. The following prefixes
456: are known: _ipv4_, _ipv6_, _rfc822_, _email_, _userfqdn_, _fqdn_, _dns_,
457: _asn1dn_, _asn1gn_ and _keyid_. Custom type prefixes may be specified by
458: surrounding the numerical type value by curly brackets.
459:
460: connections.<conn>.local<suffix>.eap_id = id
461: Client EAP-Identity to use in EAP-Identity exchange and the EAP method.
462:
463: connections.<conn>.local<suffix>.aaa_id = remote-id
464: Server side EAP-Identity to expect in the EAP method.
465:
466: Server side EAP-Identity to expect in the EAP method. Some EAP methods, such
467: as EAP-TLS, use an identity for the server to perform mutual authentication.
468: This identity may differ from the IKE identity, especially when EAP
469: authentication is delegated from the IKE responder to an AAA backend.
470:
471: For EAP-(T)TLS, this defines the identity for which the server must provide
472: a certificate in the TLS exchange.
473:
474: connections.<conn>.local<suffix>.xauth_id = id
475: Client XAuth username used in the XAuth exchange.
476:
477: connections.<conn>.remote<suffix> {}
478: Section for a remote authentication round.
479:
480: Section for a remote authentication round. A remote authentication round
481: defines the constraints how the peers must authenticate to use this
482: connection. Multiple rounds may be defined to use IKEv2 RFC 4739 Multiple
483: Authentication or IKEv1 XAuth.
484:
485: Each round is defined in a section having _remote_ as prefix, and an
486: optional unique suffix. To define a single authentication round, the suffix
487: may be omitted.
488:
489: connections.<conn>.remote<suffix>.round = 0
490: Optional numeric identifier by which authentication rounds are sorted. If
491: not specified rounds are ordered by their position in the config file/VICI
492: message.
493:
494: connections.<conn>.remote<suffix>.id = %any
495: IKE identity to expect for authentication round.
496:
497: IKE identity to expect for authentication round. Refer to the **local**
498: section's **id** keyword for details.
499:
500: It's possible to use wildcards to match remote identities (e.g.
501: _*@strongswan.org_, _*.strongswan.org_, or _C=CH,O=strongSwan,CN=*_).
502: Connections with exact matches are preferred. When using distinguished names
503: with wildcards, the _charon.rdn_matching_ option in **strongswan.conf**(5)
504: specifies how RDNs are matched.
505:
506: connections.<conn>.remote<suffix>.eap_id = id
507: Identity to use as peer identity during EAP authentication.
508:
509: Identity to use as peer identity during EAP authentication. If set to _%any_
510: the EAP-Identity method will be used to ask the client for an identity.
511:
512: connections.<conn>.remote<suffix>.groups =
513: Authorization group memberships to require.
514:
515: Comma separated authorization group memberships to require. The peer must
516: prove membership to at least one of the specified groups. Group membership
517: can be certified by different means, for example by appropriate Attribute
518: Certificates or by an AAA backend involved in the authentication.
519:
520: connections.<conn>.remote<suffix>.cert_policy =
521: Certificate policy OIDs the peer's certificate must have.
522:
523: Comma separated list of certificate policy OIDs the peer's certificate must
524: have. OIDs are specified using the numerical dotted representation.
525:
526: connections.<conn>.remote<suffix>.certs =
527: Comma separated list of certificate to accept for authentication.
528:
529: Comma separated list of certificates to accept for authentication.
530: The certificates may use a relative path from the **swanctl** _x509_
531: directory or an absolute path.
532:
533: connections.<conn>.remote<suffix>.cert<suffix> =
534: Section for a certificate to accept for authentication.
535:
536: Section for a certificate to accept for authentication. Certificates
537: in _certs_ are transmitted as binary blobs, these sections offer more
538: flexibility.
539:
540: connections.<conn>.remote<suffix>.cert<suffix>.file =
541: Absolute path to the certificate to load.
542:
543: Absolute path to the certificate to load. Passed as-is to the daemon, so it
544: must be readable by it.
545:
546: Configure either this or _handle_, but not both, in one section.
547:
548: connections.<conn>.remote<suffix>.cert<suffix>.handle =
549: Hex-encoded CKA_ID of the certificate on a token.
550:
551: Hex-encoded CKA_ID of the certificate on a token.
552:
553: Configure either this or _file_, but not both, in one section.
554:
555: connections.<conn>.remote<suffix>.cert<suffix>.slot =
556: Optional slot number of the token that stores the certificate.
557:
558: connections.<conn>.remote<suffix>.cert<suffix>.module =
559: Optional PKCS#11 module name.
560:
561: connections.<conn>.remote<suffix>.cacerts =
562: Comma separated list of CA certificates to accept for authentication.
563:
564: Comma separated list of CA certificates to accept for authentication.
565: The certificates may use a relative path from the **swanctl** _x509ca_
566: directory or an absolute path.
567:
568: connections.<conn>.remote<suffix>.cacert<suffix> =
569: Section for a CA certificate to accept for authentication.
570:
571: Section for a CA certificate to accept for authentication. Certificates
572: in _cacerts_ are transmitted as binary blobs, these sections offer more
573: flexibility.
574:
575: connections.<conn>.remote<suffix>.cacert<suffix>.file =
576: Absolute path to the certificate to load.
577:
578: Absolute path to the certificate to load. Passed as-is to the daemon, so it
579: must be readable by it.
580:
581: Configure either this or _handle_, but not both, in one section.
582:
583: connections.<conn>.remote<suffix>.cacert<suffix>.handle =
584: Hex-encoded CKA_ID of the CA certificate on a token.
585:
586: Hex-encoded CKA_ID of the CA certificate on a token.
587:
588: Configure either this or _file_, but not both, in one section.
589:
590: connections.<conn>.remote<suffix>.cacert<suffix>.slot =
591: Optional slot number of the token that stores the CA certificate.
592:
593: connections.<conn>.remote<suffix>.cacert<suffix>.module =
594: Optional PKCS#11 module name.
595:
596: connections.<conn>.remote<suffix>.ca_id =
597: Identity in CA certificate to accept for authentication.
598:
599: The specified identity must be contained in one (intermediate) CA
600: of the remote peer trustchain, either as subject or as subjectAltName.
601: This has the same effect as specifying _cacerts_ to force clients under
602: a CA to specific connections; it does not require the CA certificate to
603: be available locally, and can be received from the peer during the
604: IKE exchange.
605:
606: connections.<conn>.remote<suffix>.pubkeys =
607: Comma separated list of raw public keys to accept for authentication.
608:
609: Comma separated list of raw public keys to accept for authentication.
610: The public keys may use a relative path from the **swanctl** _pubkey_
611: directory or an absolute path.
612:
613: connections.<conn>.remote<suffix>.revocation = relaxed
614: Certificate revocation policy, (_strict_, _ifuri_ or _relaxed_).
615:
616: Certificate revocation policy for CRL or OCSP revocation.
617:
618: A _strict_ revocation policy fails if no revocation information is
619: available, i.e. the certificate is not known to be unrevoked.
620:
621: _ifuri_ fails only if a CRL/OCSP URI is available, but certificate
622: revocation checking fails, i.e. there should be revocation information
623: available, but it could not be obtained.
624:
625: The default revocation policy _relaxed_ fails only if a certificate
626: is revoked, i.e. it is explicitly known that it is bad.
627:
628: connections.<conn>.remote<suffix>.auth = pubkey
629: Authentication to expect from remote (_pubkey_, _psk_, _xauth[-backend]_ or
630: _eap[-method]_).
631:
632: Authentication to expect from remote. See the **local** section's **auth**
633: keyword description about the details of supported mechanisms.
634:
635: To require a trustchain public key strength for the remote side, specify the
636: key type followed by the minimum strength in bits (for example _ecdsa-384_
637: or _rsa-2048-ecdsa-256_). To limit the acceptable set of hashing algorithms
638: for trustchain validation, append hash algorithms to _pubkey_ or a key
639: strength definition (for example _pubkey-sha256-sha512_,
640: _rsa-2048-sha256-sha384-sha512_ or
641: _rsa-2048-sha256-ecdsa-256-sha256-sha384_).
642: Unless disabled in **strongswan.conf**(5), or explicit IKEv2 signature
643: constraints are configured (refer to the description of the **local**
644: section's **auth** keyword for details), such key types and hash algorithms
645: are also applied as constraints against IKEv2 signature authentication
646: schemes used by the remote side. To require RSASSA-PSS signatures use
647: _rsa/pss_ instead of _pubkey_ or _rsa_ as in e.g. _rsa/pss-sha256_. If
648: _pubkey_ or _rsa_ constraints are configured RSASSA-PSS signatures will only
649: be accepted if enabled in **strongswan.conf**(5).
650:
651: To specify trust chain constraints for EAP-(T)TLS, append a colon to the
652: EAP method, followed by the key type/size and hash algorithm as discussed
653: above (e.g. _eap-tls:ecdsa-384-sha384_).
654:
655: connections.<conn>.children.<child> {}
656: CHILD_SA configuration sub-section.
657:
658: CHILD_SA configuration sub-section. Each connection definition may have
659: one or more sections in its _children_ subsection. The section name
660: defines the name of the CHILD_SA configuration, which must be unique within
661: the connection.
662:
663: connections.<conn>.children.<child>.ah_proposals =
664: AH proposals to offer for the CHILD_SA.
665:
666: AH proposals to offer for the CHILD_SA. A proposal is a set of algorithms.
667: For AH, this includes an integrity algorithm and an optional Diffie-Hellman
668: group. If a DH group is specified, CHILD_SA/Quick Mode rekeying and initial
669: negotiation uses a separate Diffie-Hellman exchange using the specified
670: group (refer to _esp_proposals_ for details).
671:
672: In IKEv2, multiple algorithms of the same kind can be specified in a single
673: proposal, from which one gets selected. In IKEv1, only one algorithm per
674: kind is allowed per proposal, more algorithms get implicitly stripped. Use
675: multiple proposals to offer different algorithms combinations in IKEv1.
676:
677: Algorithm keywords get separated using dashes. Multiple proposals may be
678: separated by commas. The special value _default_ forms a default proposal
679: of supported algorithms considered safe, and is usually a good choice
680: for interoperability. By default no AH proposals are included, instead ESP
681: is proposed.
682:
683: connections.<conn>.children.<child>.esp_proposals = default
684: ESP proposals to offer for the CHILD_SA.
685:
686: ESP proposals to offer for the CHILD_SA. A proposal is a set of algorithms.
687: For ESP non-AEAD proposals, this includes an integrity algorithm, an
688: encryption algorithm, an optional Diffie-Hellman group and an optional
689: Extended Sequence Number Mode indicator. For AEAD proposals, a combined
690: mode algorithm is used instead of the separate encryption/integrity
691: algorithms.
692:
693: If a DH group is specified, CHILD_SA/Quick Mode rekeying and initial
694: negotiation use a separate Diffie-Hellman exchange using the specified
695: group. However, for IKEv2, the keys of the CHILD_SA created implicitly with
696: the IKE_SA will always be derived from the IKE_SA's key material. So any DH
697: group specified here will only apply when the CHILD_SA is later rekeyed or
698: is created with a separate CREATE_CHILD_SA exchange. A proposal mismatch
699: might, therefore, not immediately be noticed when the SA is established, but
700: may later cause rekeying to fail.
701:
702: Extended Sequence Number support may be indicated with the _esn_ and _noesn_
703: values, both may be included to indicate support for both modes. If omitted,
704: _noesn_ is assumed.
705:
706: In IKEv2, multiple algorithms of the same kind can be specified in a single
707: proposal, from which one gets selected. In IKEv1, only one algorithm per
708: kind is allowed per proposal, more algorithms get implicitly stripped. Use
709: multiple proposals to offer different algorithms combinations in IKEv1.
710:
711: Algorithm keywords get separated using dashes. Multiple proposals may be
712: separated by commas. The special value _default_ forms a default proposal
713: of supported algorithms considered safe, and is usually a good choice
714: for interoperability. If no algorithms are specified for AH nor ESP,
715: the _default_ set of algorithms for ESP is included.
716:
717: connections.<conn>.children.<child>.sha256_96 = no
718: Use incorrect 96-bit truncation for HMAC-SHA-256.
719:
720: HMAC-SHA-256 is used with 128-bit truncation with IPsec. For compatibility
721: with implementations that incorrectly use 96-bit truncation this option may
722: be enabled to configure the shorter truncation length in the kernel. This
723: is not negotiated, so this only works with peers that use the incorrect
724: truncation length (or have this option enabled).
725:
726: connections.<conn>.children.<child>.local_ts = dynamic
727: Local traffic selectors to include in CHILD_SA.
728:
729: Comma separated list of local traffic selectors to include in CHILD_SA.
730: Each selector is a CIDR subnet definition, followed by an optional
731: proto/port selector. The special value _dynamic_ may be used instead of a
732: subnet definition, which gets replaced by the tunnel outer address or the
733: virtual IP, if negotiated. This is the default.
734:
735: A protocol/port selector is surrounded by opening and closing square
736: brackets. Between these brackets, a numeric or **getservent**(3) protocol
737: name may be specified. After the optional protocol restriction, an optional
738: port restriction may be specified, separated by a slash. The port
739: restriction may be numeric, a **getservent**(3) service name, or the special
740: value _opaque_ for RFC 4301 OPAQUE selectors. Port ranges may be specified
741: as well, none of the kernel backends currently support port ranges, though.
742:
743: When IKEv1 is used only the first selector is interpreted, except if
744: the Cisco Unity extension plugin is used. This is due to a limitation of the
745: IKEv1 protocol, which only allows a single pair of selectors per CHILD_SA.
746: So to tunnel traffic matched by several pairs of selectors when using IKEv1
747: several children (CHILD_SAs) have to be defined that cover the selectors.
748:
749: The IKE daemon uses traffic selector narrowing for IKEv1, the same way it is
750: standardized and implemented for IKEv2. However, this may lead to problems
751: with other implementations. To avoid that, configure identical selectors in
752: such scenarios.
753:
754: connections.<conn>.children.<child>.remote_ts = dynamic
755: Remote selectors to include in CHILD_SA.
756:
757: Comma separated list of remote selectors to include in CHILD_SA. See
758: **local_ts** for a description of the selector syntax.
759:
760: connections.<conn>.children.<child>.rekey_time = 1h
761: Time to schedule CHILD_SA rekeying.
762:
763: Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes key
764: material, optionally using a Diffie-Hellman exchange if a group is
765: specified in the proposal.
766:
767: To avoid rekey collisions initiated by both ends simultaneously, a value
768: in the range of **rand_time** gets subtracted to form the effective soft
769: lifetime.
770:
771: By default CHILD_SA rekeying is scheduled every hour, minus **rand_time**.
772:
773: connections.<conn>.children.<child>.life_time = rekey_time + 10%
774: Maximum lifetime before CHILD_SA gets closed, as time.
775:
776: Maximum lifetime before CHILD_SA gets closed. Usually this hard lifetime
777: is never reached, because the CHILD_SA gets rekeyed before.
778: If that fails for whatever reason, this limit closes the CHILD_SA.
779:
780: The default is 10% more than the **rekey_time**.
781:
782: connections.<conn>.children.<child>.rand_time = life_time - rekey_time
783: Range of random time to subtract from **rekey_time**.
784:
785: Time range from which to choose a random value to subtract from
786: **rekey_time**. The default is the difference between **life_time** and
787: **rekey_time**.
788:
789: connections.<conn>.children.<child>.rekey_bytes = 0
790: Number of bytes processed before initiating CHILD_SA rekeying.
791:
792: Number of bytes processed before initiating CHILD_SA rekeying. CHILD_SA
793: rekeying refreshes key material, optionally using a Diffie-Hellman exchange
794: if a group is specified in the proposal.
795:
796: To avoid rekey collisions initiated by both ends simultaneously, a value
797: in the range of **rand_bytes** gets subtracted to form the effective soft
798: volume limit.
799:
800: Volume based CHILD_SA rekeying is disabled by default.
801:
802: connections.<conn>.children.<child>.life_bytes = rekey_bytes + 10%
803: Maximum bytes processed before CHILD_SA gets closed.
804:
805: Maximum bytes processed before CHILD_SA gets closed. Usually this hard
806: volume limit is never reached, because the CHILD_SA gets rekeyed before.
807: If that fails for whatever reason, this limit closes the CHILD_SA.
808:
809: The default is 10% more than **rekey_bytes**.
810:
811: connections.<conn>.children.<child>.rand_bytes = life_bytes - rekey_bytes
812: Range of random bytes to subtract from **rekey_bytes**.
813:
814: Byte range from which to choose a random value to subtract from
815: **rekey_bytes**. The default is the difference between **life_bytes** and
816: **rekey_bytes**.
817:
818: connections.<conn>.children.<child>.rekey_packets = 0
819: Number of packets processed before initiating CHILD_SA rekeying.
820:
821: Number of packets processed before initiating CHILD_SA rekeying. CHILD_SA
822: rekeying refreshes key material, optionally using a Diffie-Hellman exchange
823: if a group is specified in the proposal.
824:
825: To avoid rekey collisions initiated by both ends simultaneously, a value
826: in the range of **rand_packets** gets subtracted to form the effective soft
827: packet count limit.
828:
829: Packet count based CHILD_SA rekeying is disabled by default.
830:
831: connections.<conn>.children.<child>.life_packets = rekey_packets + 10%
832: Maximum number of packets processed before CHILD_SA gets closed.
833:
834: Maximum number of packets processed before CHILD_SA gets closed. Usually
835: this hard packets limit is never reached, because the CHILD_SA gets rekeyed
836: before. If that fails for whatever reason, this limit closes the CHILD_SA.
837:
838: The default is 10% more than **rekey_bytes**.
839:
840: connections.<conn>.children.<child>.rand_packets = life_packets - rekey_packets
841: Range of random packets to subtract from **packets_bytes**.
842:
843: Packet range from which to choose a random value to subtract from
844: **rekey_packets**. The default is the difference between **life_packets**
845: and **rekey_packets**.
846:
847: connections.<conn>.children.<child>.updown =
848: Updown script to invoke on CHILD_SA up and down events.
849:
850: connections.<conn>.children.<child>.hostaccess = no
851: Hostaccess variable to pass to **updown** script.
852:
853: connections.<conn>.children.<child>.mode = tunnel
854: IPsec Mode to establish (_tunnel_, _transport_, _transport_proxy_, _beet_,
855: _pass_ or _drop_).
856:
857: IPsec Mode to establish CHILD_SA with. _tunnel_ negotiates the CHILD_SA
858: in IPsec Tunnel Mode, whereas _transport_ uses IPsec Transport Mode.
859: _transport_proxy_ signifying the special Mobile IPv6 Transport Proxy Mode.
860: _beet_ is the Bound End to End Tunnel mixture mode, working with fixed inner
861: addresses without the need to include them in each packet.
862:
863: Both _transport_ and _beet_ modes are subject to mode negotiation; _tunnel_
864: mode is negotiated if the preferred mode is not available.
865:
866: _pass_ and _drop_ are used to install shunt policies which explicitly
867: bypass the defined traffic from IPsec processing or drop it, respectively.
868:
869: connections.<conn>.children.<child>.policies = yes
870: Whether to install IPsec policies or not.
871:
872: Whether to install IPsec policies or not. Disabling this can be useful in
873: some scenarios e.g. MIPv6, where policies are not managed by the IKE daemon.
874:
875: connections.<conn>.children.<child>.policies_fwd_out = no
876: Whether to install outbound FWD IPsec policies or not.
877:
878: Whether to install outbound FWD IPsec policies or not. Enabling this is
879: required in case there is a drop policy that would match and block forwarded
880: traffic for this CHILD_SA.
881:
882: connections.<conn>.children.<child>.dpd_action = clear
883: Action to perform on DPD timeout (_clear_, _trap_ or _restart_).
884:
885: Action to perform for this CHILD_SA on DPD timeout. The default _clear_
886: closes the CHILD_SA and does not take further action. _trap_ installs
887: a trap policy, which will catch matching traffic and tries to re-negotiate
888: the tunnel on-demand. _restart_ immediately tries to re-negotiate the
889: CHILD_SA under a fresh IKE_SA.
890:
891: connections.<conn>.children.<child>.ipcomp = no
892: Enable IPComp compression before encryption.
893:
894: Enable IPComp compression before encryption. If enabled, IKE tries to
895: negotiate IPComp compression to compress ESP payload data prior to
896: encryption.
897:
898: connections.<conn>.children.<child>.inactivity = 0s
899: Timeout before closing CHILD_SA after inactivity.
900:
901: Timeout before closing CHILD_SA after inactivity. If no traffic has
902: been processed in either direction for the configured timeout, the CHILD_SA
903: gets closed due to inactivity. The default value of _0_ disables inactivity
904: checks.
905:
906: connections.<conn>.children.<child>.reqid = 0
907: Fixed reqid to use for this CHILD_SA.
908:
909: Fixed reqid to use for this CHILD_SA. This might be helpful in some
910: scenarios, but works only if each CHILD_SA configuration is instantiated
911: not more than once. The default of _0_ uses dynamic reqids, allocated
912: incrementally.
913:
914: connections.<conn>.children.<child>.priority = 0
915: Optional fixed priority for IPsec policies.
916:
917: Optional fixed priority for IPsec policies. This could be useful to install
918: high-priority drop policies. The default of _0_ uses dynamically calculated
919: priorities based on the size of the traffic selectors.
920:
921: connections.<conn>.children.<child>.interface =
922: Optional interface name to restrict IPsec policies.
923:
924: connections.<conn>.children.<child>.mark_in = 0/0x00000000
925: Netfilter mark and mask for input traffic.
926:
927: Netfilter mark and mask for input traffic. On Linux, Netfilter may require
928: marks on each packet to match an SA/policy having that option set. This
929: allows installing duplicate policies and enables Netfilter rules to select
930: specific SAs/policies for incoming traffic. Note that inbound marks are
931: only set on policies, by default, unless *mark_in_sa* is enabled. The
932: special value _%unique_ sets a unique mark on each CHILD_SA instance, beyond
933: that the value _%unique-dir_ assigns a different unique mark for each
934: CHILD_SA direction (in/out).
935:
936: An additional mask may be appended to the mark, separated by _/_. The
937: default mask if omitted is 0xffffffff.
938:
939: connections.<conn>.children.<child>.mark_in_sa = no
940: Whether to set *mark_in* on the inbound SA.
941:
942: Whether to set *mark_in* on the inbound SA. By default, the inbound mark is
943: only set on the inbound policy. The tuple destination address, protocol and
944: SPI is unique and the mark is not required to find the correct SA, allowing
945: to mark traffic after decryption instead (where more specific selectors may
946: be used) to match different policies. Marking packets before decryption is
947: still possible, even if no mark is set on the SA.
948:
949: connections.<conn>.children.<child>.mark_out = 0/0x00000000
950: Netfilter mark and mask for output traffic.
951:
952: Netfilter mark and mask for output traffic. On Linux, Netfilter may require
953: marks on each packet to match a policy/SA having that option set. This
954: allows installing duplicate policies and enables Netfilter rules to select
955: specific policies/SAs for outgoing traffic. The special value _%unique_ sets
956: a unique mark on each CHILD_SA instance, beyond that the value _%unique-dir_
957: assigns a different unique mark for each CHILD_SA direction (in/out).
958:
959: An additional mask may be appended to the mark, separated by _/_. The
960: default mask if omitted is 0xffffffff.
961:
962: connections.<conn>.children.<child>.set_mark_in = 0/0x00000000
963: Netfilter mark applied to packets after the inbound IPsec SA processed them.
964:
965: Netfilter mark applied to packets after the inbound IPsec SA processed them.
966: This way it's not necessary to mark packets via Netfilter before decryption
967: or right afterwards to match policies or process them differently (e.g. via
968: policy routing).
969:
970: An additional mask may be appended to the mark, separated by _/_. The
971: default mask if omitted is 0xffffffff. The special value _%same_ uses
972: the value (but not the mask) from **mark_in** as mark value, which can be
973: fixed, _%unique_ or _%unique-dir_.
974:
975: Setting marks in XFRM input requires Linux 4.19 or higher.
976:
977: connections.<conn>.children.<child>.set_mark_out = 0/0x00000000
978: Netfilter mark applied to packets after the outbound IPsec SA processed
979: them.
980:
981: Netfilter mark applied to packets after the outbound IPsec SA processed
982: them. This allows processing ESP packets differently than the original
983: traffic (e.g. via policy routing).
984:
985: An additional mask may be appended to the mark, separated by _/_. The
986: default mask if omitted is 0xffffffff. The special value _%same_ uses
987: the value (but not the mask) from **mark_out** as mark value, which can be
988: fixed, _%unique_ or _%unique-dir_.
989:
990: Setting marks in XFRM output is supported since Linux 4.14. Setting a mask
991: requires at least Linux 4.19.
992:
993: connections.<conn>.children.<child>.if_id_in = 0
994: Inbound XFRM interface ID.
995:
996: XFRM interface ID set on inbound policies/SA. This allows installing
997: duplicate policies/SAs and associates them with an interface with the same
998: ID. The special value _%unique_ sets a unique interface ID on each CHILD_SA
999: instance, beyond that the value _%unique-dir_ assigns a different unique
1000: interface ID for each CHILD_SA direction (in/out).
1001:
1002: connections.<conn>.children.<child>.if_id_out = 0
1003: Outbound XFRM interface ID.
1004:
1005: XFRM interface ID set on outbound policies/SA. This allows installing
1006: duplicate policies/SAs and associates them with an interface with the same
1007: ID. The special value _%unique_ sets a unique interface ID on each CHILD_SA
1008: instance, beyond that the value _%unique-dir_ assigns a different unique
1009: interface ID for each CHILD_SA direction (in/out).
1010:
1011: The daemon will not install routes for CHILD_SAs that have this option set.
1012:
1013: connections.<conn>.children.<child>.tfc_padding = 0
1014: Traffic Flow Confidentiality padding.
1015:
1016: Pads ESP packets with additional data to have a consistent ESP packet size
1017: for improved Traffic Flow Confidentiality. The padding defines the minimum
1018: size of all ESP packets sent.
1019:
1020: The default value of 0 disables TFC padding, the special value _mtu_ adds
1021: TFC padding to create a packet size equal to the Path Maximum Transfer Unit.
1022:
1023: connections.<conn>.children.<child>.replay_window = 32
1024: IPsec replay window to configure for this CHILD_SA.
1025:
1026: IPsec replay window to configure for this CHILD_SA. Larger values than the
1027: default of 32 are supported using the Netlink backend only, a value of 0
1028: disables IPsec replay protection.
1029:
1030: connections.<conn>.children.<child>.hw_offload = no
1031: Enable hardware offload for this CHILD_SA, if supported by the IPsec
1032: implementation.
1033:
1034: Enable hardware offload for this CHILD_SA, if supported by the IPsec
1035: implementation. The value _yes_ enforces offloading and the installation
1036: will fail if it's not supported by either kernel or device. The value _auto_
1037: enables offloading, if it's supported, but the installation does not fail
1038: otherwise.
1039:
1040: connections.<conn>.children.<child>.copy_df = yes
1041: Whether to copy the DF bit to the outer IPv4 header in tunnel mode.
1042:
1043: Whether to copy the DF bit to the outer IPv4 header in tunnel mode. This
1044: effectively disables Path MTU discovery (PMTUD). Controlling this behavior
1045: is not supported by all kernel interfaces.
1046:
1047: connections.<conn>.children.<child>.copy_ecn = yes
1048: Whether to copy the ECN header field to/from the outer IP header in tunnel
1049: mode.
1050:
1051: Whether to copy the ECN (Explicit Congestion Notification) header field
1052: to/from the outer IP header in tunnel mode. Controlling this behavior is not
1053: supported by all kernel interfaces.
1054:
1055: connections.<conn>.children.<child>.copy_dscp = out
1056: Whether to copy the DSCP header field to/from the outer IP header in tunnel
1057: mode.
1058:
1059: Whether to copy the DSCP (Differentiated Services Field Codepoint) header
1060: field to/from the outer IP header in tunnel mode. The value _out_ only
1061: copies the field from the inner to the outer header, the value _in_ does the
1062: opposite and only copies the field from the outer to the inner header when
1063: decapsulating, the value _yes_ copies the field in both directions, and the
1064: value _no_ disables copying the field altogether. Setting this to _yes_ or
1065: _in_ could allow an attacker to adversely affect other traffic at the
1066: receiver, which is why the default is _out_. Controlling this behavior is
1067: not supported by all kernel interfaces.
1068:
1069: connections.<conn>.children.<child>.start_action = none
1070: Action to perform after loading the configuration (_none_, _trap_, _start_).
1071:
1072: Action to perform after loading the configuration. The default of _none_
1073: loads the connection only, which then can be manually initiated or used as
1074: a responder configuration.
1075:
1076: The value _trap_ installs a trap policy, which triggers the tunnel as soon
1077: as matching traffic has been detected. The value _start_ initiates
1078: the connection actively.
1079:
1080: When unloading or replacing a CHILD_SA configuration having a
1081: **start_action** different from _none_, the inverse action is performed.
1082: Configurations with _start_ get closed, while such with _trap_ get
1083: uninstalled.
1084:
1085: connections.<conn>.children.<child>.close_action = none
1086: Action to perform after a CHILD_SA gets closed (_none_, _trap_, _start_).
1087:
1088: Action to perform after a CHILD_SA gets closed by the peer. The default of
1089: _none_ does not take any action, _trap_ installs a trap policy for the
1090: CHILD_SA. _start_ tries to re-create the CHILD_SA.
1091:
1092: **close_action** does not provide any guarantee that the CHILD_SA is kept
1093: alive. It acts on explicit close messages only, but not on negotiation
1094: failures. Use trap policies to reliably re-create failed CHILD_SAs.
1095:
1096: secrets { # }
1097: Section defining secrets for IKE/EAP/XAuth authentication and private
1098: key decryption.
1099:
1100: Section defining secrets for IKE/EAP/XAuth authentication and private key
1101: decryption. The **secrets** section takes sub-sections having a specific
1102: prefix which defines the secret type.
1103:
1104: It is not recommended to define any private key decryption passphrases,
1105: as then there is no real security benefit in having encrypted keys. Either
1106: store the key unencrypted or enter the keys manually when loading
1107: credentials.
1108:
1109: secrets.eap<suffix> { # }
1110: EAP secret section for a specific secret.
1111:
1112: EAP secret section for a specific secret. Each EAP secret is defined in
1113: a unique section having the _eap_ prefix. EAP secrets are used for XAuth
1114: authentication as well.
1115:
1116: secrets.xauth<suffix> { # }
1117: XAuth secret section for a specific secret.
1118:
1119: XAuth secret section for a specific secret. **xauth** is just an alias
1120: for **eap**, secrets under both section prefixes are used for both EAP and
1121: XAuth authentication.
1122:
1123: secrets.eap<suffix>.secret =
1124: Value of the EAP/XAuth secret.
1125:
1126: Value of the EAP/XAuth secret. It may either be an ASCII string, a hex
1127: encoded string if it has a _0x_ prefix or a Base64 encoded string if it
1128: has a _0s_ prefix in its value.
1129:
1130: secrets.eap<suffix>.id<suffix> =
1131: Identity the EAP/XAuth secret belongs to.
1132:
1133: Identity the EAP/XAuth secret belongs to. Multiple unique identities may
1134: be specified, each having an _id_ prefix, if a secret is shared between
1135: multiple users.
1136:
1137: secrets.ntlm<suffix> { # }
1138: NTLM secret section for a specific secret.
1139:
1140: NTLM secret section for a specific secret. Each NTLM secret is defined in
1141: a unique section having the _ntlm_ prefix. NTLM secrets may only be used for
1142: EAP-MSCHAPv2 authentication.
1143:
1144: secrets.ntlm<suffix>.secret =
1145: Value of the NTLM secret.
1146:
1147: Value of the NTLM secret, which is the NT Hash of the actual secret, that
1148: is, MD4(UTF-16LE(secret)). The resulting 16-byte value may either be given
1149: as a hex encoded string with a _0x_ prefix or as a Base64 encoded string
1150: with a _0s_ prefix.
1151:
1152: secrets.ntlm<suffix>.id<suffix> =
1153: Identity the NTLM secret belongs to.
1154:
1155: Identity the NTLM secret belongs to. Multiple unique identities may
1156: be specified, each having an _id_ prefix, if a secret is shared between
1157: multiple users.
1158:
1159: secrets.ike<suffix> { # }
1160: IKE preshared secret section for a specific secret.
1161:
1162: IKE preshared secret section for a specific secret. Each IKE PSK is defined
1163: in a unique section having the _ike_ prefix.
1164:
1165: secrets.ike<suffix>.secret =
1166: Value of the IKE preshared secret.
1167:
1168: Value of the IKE preshared secret. It may either be an ASCII string,
1169: a hex encoded string if it has a _0x_ prefix or a Base64 encoded string if
1170: it has a _0s_ prefix in its value.
1171:
1172: secrets.ike<suffix>.id<suffix> =
1173: IKE identity the IKE preshared secret belongs to.
1174:
1175: IKE identity the IKE preshared secret belongs to. Multiple unique identities
1176: may be specified, each having an _id_ prefix, if a secret is shared between
1177: multiple peers.
1178:
1179: secrets.ppk<suffix> { # }
1180: Postquantum Preshared Key (PPK) section for a specific secret.
1181:
1182: Postquantum Preshared Key (PPK) section for a specific secret. Each PPK is
1183: defined in a unique section having the _ppk_ prefix.
1184:
1185: secrets.ppk<suffix>.secret =
1186: Value of the PPK.
1187:
1188: Value of the PPK. It may either be an ASCII string, a hex encoded string if
1189: it has a _0x_ prefix or a Base64 encoded string if it has a _0s_ prefix in
1190: its value. Should have at least 256 bits of entropy for 128-bit security.
1191:
1192: secrets.ppk<suffix>.id<suffix> =
1193: PPK identity the PPK belongs to.
1194:
1195: PPK identity the PPK belongs to. Multiple unique identities
1196: may be specified, each having an _id_ prefix, if a secret is shared between
1197: multiple peers.
1198:
1199: secrets.private<suffix> { # }
1200: Private key decryption passphrase for a key in the _private_ folder.
1201:
1202: secrets.private<suffix>.file =
1203: File name in the _private_ folder for which this passphrase should be used.
1204:
1205: secrets.private<suffix>.secret
1206: Value of decryption passphrase for private key.
1207:
1208: secrets.rsa<suffix> { # }
1209: Private key decryption passphrase for a key in the _rsa_ folder.
1210:
1211: secrets.rsa<suffix>.file =
1212: File name in the _rsa_ folder for which this passphrase should be used.
1213:
1214: secrets.rsa<suffix>.secret
1215: Value of decryption passphrase for RSA key.
1216:
1217: secrets.ecdsa<suffix> { # }
1218: Private key decryption passphrase for a key in the _ecdsa_ folder.
1219:
1220: secrets.ecdsa<suffix>.file =
1221: File name in the _ecdsa_ folder for which this passphrase should be used.
1222:
1223: secrets.ecdsa<suffix>.secret
1224: Value of decryption passphrase for ECDSA key.
1225:
1226: secrets.pkcs8<suffix> { # }
1227: Private key decryption passphrase for a key in the _pkcs8_ folder.
1228:
1229: secrets.pkcs8<suffix>.file =
1230: File name in the _pkcs8_ folder for which this passphrase should be used.
1231:
1232: secrets.pkcs8<suffix>.secret
1233: Value of decryption passphrase for PKCS#8 key.
1234:
1235: secrets.pkcs12<suffix> { # }
1236: PKCS#12 decryption passphrase for a container in the _pkcs12_ folder.
1237:
1238: secrets.pkcs12<suffix>.file =
1239: File name in the _pkcs12_ folder for which this passphrase should be used.
1240:
1241: secrets.pkcs12<suffix>.secret
1242: Value of decryption passphrase for PKCS#12 container.
1243:
1244: secrets.token<suffix> { # }
1245: Definition for a private key that's stored on a token/smartcard.
1246:
1247: secrets.token<suffix>.handle =
1248: Hex-encoded CKA_ID of the private key on the token.
1249:
1250: secrets.token<suffix>.slot =
1251: Optional slot number to access the token.
1252:
1253: secrets.token<suffix>.module =
1254: Optional PKCS#11 module name to access the token.
1255:
1256: secrets.token<suffix>.pin =
1257: Optional PIN required to access the key on the token. If none is provided
1258: the user is prompted during an interactive --load-creds call.
1259:
1260: pools { # }
1261: Section defining named pools.
1262:
1263: Section defining named pools. Named pools may be referenced by connections
1264: with the **pools** option to assign virtual IPs and other configuration
1265: attributes.
1266:
1267: pools.<name> { # }
1268: Section defining a single pool with a unique name.
1269:
1270: pools.<name>.addrs =
1271: Addresses allocated in pool.
1272:
1273: Subnet or range defining addresses allocated in pool. Accepts a single CIDR
1274: subnet defining the pool to allocate addresses from or an address range
1275: (<from>-<to>). Pools must be unique and non-overlapping.
1276:
1277: pools.<name>.<attr> =
1278: Comma separated list of additional attributes from type <attr>.
1279:
1280: Comma separated list of additional attributes of type **<attr>**. The
1281: attribute type may be one of _dns_, _nbns_, _dhcp_, _netmask_, _server_,
1282: _subnet_, _split_include_ and _split_exclude_ to define addresses or CIDR
1283: subnets for the corresponding attribute types. Alternatively, **<attr>** can
1284: be a numerical identifier, for which string attribute values are accepted
1285: as well.
1286:
1287: authorities { # }
1288: Section defining attributes of certification authorities.
1289:
1290: authorities.<name> { # }
1291: Section defining a certification authority with a unique name.
1292:
1293: authorities.<name>.cacert =
1294: CA certificate belonging to the certification authority.
1295:
1296: CA certificate belonging to the certification authority. The certificates
1297: may use a relative path from the **swanctl** _x509ca_ directory or an
1298: absolute path.
1299:
1300: Configure one of _cacert_, _file_, or _handle_ per section.
1301:
1302: authorities.<name>.file =
1303: Absolute path to the certificate to load.
1304:
1305: Absolute path to the certificate to load. Passed as-is to the daemon, so it
1306: must be readable by it.
1307:
1308: Configure one of _cacert_, _file_, or _handle_ per section.
1309:
1310: authorities.<name>.handle =
1311: Hex-encoded CKA_ID of the CA certificate on a token.
1312:
1313: Hex-encoded CKA_ID of the CA certificate on a token.
1314:
1315: Configure one of _cacert_, _file_, or _handle_ per section.
1316:
1317: authorities.<name>.slot =
1318: Optional slot number of the token that stores the CA certificate.
1319:
1320: authorities.<name>.module =
1321: Optional PKCS#11 module name.
1322:
1323: authorities.<name>.crl_uris =
1324: Comma-separated list of CRL distribution points.
1325:
1326: Comma-separated list of CRL distribution points (ldap, http, or file URI).
1327:
1328: authorities.<name>.ocsp_uris =
1329: Comma-separated list of OCSP URIs.
1330:
1331: authorities.<name>.cert_uri_base =
1332: Defines the base URI for the Hash and URL feature supported by IKEv2.
1333:
1334: Defines the base URI for the Hash and URL feature supported by IKEv2.
1335: Instead of exchanging complete certificates, IKEv2 allows one to send an
1336: URI that resolves to the DER encoded certificate. The certificate URIs are
1337: built by appending the SHA1 hash of the DER encoded certificates to this
1338: base URI.
1339:
1340: include conf.d/*.conf
1341: Include config snippets
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to swanctl.opt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / strongswan / src / swanctl