.TP .B connections .br Section defining IKE connection configurations. The connections section defines IKE connection configurations, each in its own subsections. In the keyword description below, the connection is named .RI "" "" "," but an arbitrary yet unique connection name can be chosen for each connection subsection. .TP .B connections. .br Section for an IKE connection named . .TP .BR connections..version " [0]" IKE major version to use for connection. .RI "" "1" "" uses IKEv1 aka ISAKMP, .RI "" "2" "" uses IKEv2. A connection using the default of .RI "" "0" "" accepts both IKEv1 and IKEv2 as responder, and initiates the connection actively with IKEv2. .TP .BR connections..local_addrs " [%any]" Local address(es) to use for IKE communication, comma separated. Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges. As initiator, the first non\-range/non\-subnet is used to initiate the connection from. As responder, the local destination address must match at least to one of the specified addresses, subnets or ranges. .TP .BR connections..remote_addrs " [%any]" Remote address(es) to use for IKE communication, comma separated. Takes single IPv4/IPv6 addresses, DNS names, CIDR subnets or IP address ranges. As initiator, the first non\-range/non\-subnet is used to initiate the connection to. As responder, the initiator source address must match at least to one of the specified addresses, subnets or ranges. To initiate a connection, at least one specific address or DNS name must be specified. .TP .BR connections..local_port " [500]" Local UPD port for IKE communication. By default the port of the socket backend is used, which is usually .RI "" "500" "." If port .RI "" "500" "" is used, automatic IKE port floating to port 4500 is used to work around NAT issues. Using a non\-default local IKE port requires support from the socket backend in use (socket\-dynamic). .TP .BR connections..remote_port " [500]" Remote UPD port for IKE communication. If the default of port .RI "" "500" "" is used, automatic IKE port floating to port 4500 is used to work around NAT issues. .TP .BR connections..proposals " [default]" A proposal is a set of algorithms. For non\-AEAD algorithms, this includes for IKE an encryption algorithm, an integrity algorithm, a pseudo random function and a Diffie\-Hellman group. For AEAD algorithms, instead of encryption and integrity algorithms, a combined algorithm is used. In IKEv2, multiple algorithms of the same kind can be specified in a single proposal, from which one gets selected. In IKEv1, only one algorithm per kind is allowed per proposal, more algorithms get implicitly stripped. Use multiple proposals to offer different algorithms combinations in IKEv1. Algorithm keywords get separated using dashes. Multiple proposals may be separated by commas. The special value .RI "" "default" "" forms a default proposal of supported algorithms considered safe, and is usually a good choice for interoperability. .TP .BR connections..vips " []" Comma separated list of virtual IPs to request in IKEv2 configuration payloads or IKEv1 Mode Config. The wildcard addresses .RI "" "0.0.0.0" "" and .RI "" "::" "" request an arbitrary address, specific addresses may be defined. The responder may return a different address, though, or none at all. .TP .BR connections..aggressive " [no]" Enables Aggressive Mode instead of Main Mode with Identity Protection. Aggressive Mode is considered less secure, because the ID and HASH payloads are exchanged unprotected. This allows a passive attacker to snoop peer identities, and even worse, start dictionary attacks on the Preshared Key. .TP .BR connections..pull " [yes]" If the default of .RI "" "yes" "" is used, Mode Config works in pull mode, where the initiator actively requests a virtual IP. With .RI "" "no" "," push mode is used, where the responder pushes down a virtual IP to the initiating peer. Push mode is currently supported for IKEv1, but not in IKEv2. It is used by a few implementations only, pull mode is recommended. .TP .BR connections..encap " [no]" To enforce UDP encapsulation of ESP packets, the IKE daemon can fake the NAT detection payloads. This makes the peer believe that NAT takes place on the path, forcing it to encapsulate ESP packets in UDP. Usually this is not required, but it can help to work around connectivity issues with too restrictive intermediary firewalls. .TP .BR connections..mobike " [yes]" Enables MOBIKE on IKEv2 connections. MOBIKE is enabled by default on IKEv2 connections, and allows mobility of clients and multi\-homing on servers by migrating active IPsec tunnels. Usually keeping MOBIKE enabled is unproblematic, as it is not used if the peer does not indicate support for it. However, due to the design of MOBIKE, IKEv2 always floats to port 4500 starting from the second exchange. Some implementations don't like this behavior, hence it can be disabled. .TP .BR connections..dpd_delay " [0s]" Interval to check the liveness of a peer actively using IKEv2 INFORMATIONAL exchanges or IKEv1 R_U_THERE messages. Active DPD checking is only enforced if no IKE or ESP/AH packet has been received for the configured DPD delay. .TP .BR connections..dpd_timeout " [0s]" Charon by default uses the normal retransmission mechanism and timeouts to check the liveness of a peer, as all messages are used for liveness checking. For compatibility reasons, with IKEv1 a custom interval may be specified; this option has no effect on connections using IKE2. .TP .BR connections..fragmentation " [no]" The default of .RI "" "no" "" disables IKEv1 fragmentation mechanism, .RI "" "yes" "" enables it if support has been indicated by the peer. .RI "" "force" "" enforces fragmentation if required even before the peer had a chance to indicate support for it. IKE fragmentation is currently not supported with IKEv2. .TP .BR connections..send_certreq " [yes]" Send certificate request payloads to offer trusted root CA certificates to the peer. Certificate requests help the peer to choose an appropriate certificate/private key for authentication and are enabled by default. Disabling certificate requests can be useful if too many trusted root CA certificates are installed, as each certificate request increases the size of the initial IKE packets. .TP .BR connections..send_cert " [ifasked]" Send certificate payloads when using certificate authentication. With the default of .RI "" "ifasked" "" the daemon sends certificate payloads only if certificate requests have been received. .RI "" "no" "" disables sending of certificate payloads, .RI "" "yes" "" always sends certificate payloads whenever certificate authentication is used. .TP .BR connections..keyingtries " [1]" Number of retransmission sequences to perform during initial connect. Instead of giving up initiation after the first retransmission sequence with the default value of .RI "" "1" "," additional sequences may be started according to the configured value. A value of .RI "" "0" "" initiates a new sequence until the connection establishes or fails with a permanent error. .TP .BR connections..unique " [no]" Connection uniqueness policy to enforce. To avoid multiple connections from the same user, a uniqueness policy can be enforced. The value .RI "" "never" "" does never enforce such a policy, even if a peer included INITIAL_CONTACT notification messages, whereas .RI "" "no" "" replaces existing connections for the same identity if a new one has the INITIAL_CONTACT notify. .RI "" "keep" "" rejects new connection attempts if the same user already has an active connection, .RI "" "replace" "" deletes any existing connection if a new one for the same user gets established. To compare connections for uniqueness, the remote IKE identity is used. If EAP or XAuth authentication is involved, the EAP\-Identity or XAuth username is used to enforce the uniqueness policy instead. .TP .BR connections..reauth_time " [0s]" Time to schedule IKE reauthentication. IKE reauthentication recreates the IKE/ISAKMP SA from scratch and re\-evaluates the credentials. In asymmetric configurations (with EAP or configuration payloads) it might not be possible to actively reauthenticate as responder. The IKEv2 reauthentication lifetime negotiation can instruct the client to perform reauthentication. Reauthentication is disabled by default. Enabling it usually may lead to small connection interruptions, as strongSwan uses a break\-before\-make policy with IKEv2 to avoid any conflicts with associated tunnel resources. .TP .BR connections..rekey_time " [4h]" IKE rekeying refreshes key material using a Diffie\-Hellman exchange, but does not re\-check associated credentials. It is supported in IKEv2 only, IKEv1 performs a reauthentication procedure instead. With the default value IKE rekeying is scheduled every 4 hours, minus the configured .RB "" "rand_time" "." .TP .BR connections..over_time " [10% of rekey_time/reauth_time]" Hard IKE_SA lifetime if rekey/reauth does not complete, as time. To avoid having an IKE/ISAKMP kept alive if IKE reauthentication or rekeying fails perpetually, a maximum hard lifetime may be specified. If the IKE_SA fails to rekey or reauthenticate within the specified time, the IKE_SA gets closed. In contrast to CHILD_SA rekeying, .RB "" "over_time" "" is relative in time to the .RB "" "rekey_time" "" .RI "" "and" "" .RB "" "reauth_time" "" values, as it applies to both. The default is 10% of the longer of .RB "" "rekey_time" "" and .RB "" "reauth_time" "." .TP .BR connections..rand_time " [over_time]" Time range from which to choose a random value to subtract from rekey/reauth times. To avoid having both peers initiating the rekey/reauth procedure simultaneously, a random time gets subtracted from the rekey/reauth times. The default is equal to the configured .RB "" "over_time" "." .TP .BR connections..pools " []" Comma separated list of named IP pools to allocate virtual IP addresses and other configuration attributes from. Each name references a pool by name from either the .RB "" "pools" "" section or an external pool. .TP .B connections..local .br Section for a local authentication round. A local authentication round defines the rules how authentication is performed for the local peer. Multiple rounds may be defined to use IKEv2 RFC 4739 Multiple Authentication or IKEv1 XAuth. Each round is defined in a section having .RI "" "local" "" as prefix, and an optional unique suffix. To define a single authentication round, the suffix may be omitted. .TP .BR connections..local.certs " []" Comma separated list of certificate candidates to use for authentication. The certificates may use a relative path from the .RB "" "swanctl" "" .RI "" "x509" "" directory, or an absolute path. The certificate used for authentication is selected based on the received certificate request payloads. If no appropriate CA can be located, the first certificate is used. .TP .BR connections..local.auth " [pubkey]" Authentication to perform locally. .RI "" "pubkey" "" uses public key authentication using a private key associated to a usable certificate. .RI "" "psk" "" uses pre\-shared key authentication. The IKEv1 specific .RI "" "xauth" "" is used for XAuth or Hybrid authentication, while the IKEv2 specific .RI "" "eap" "" keyword defines EAP authentication. For .RI "" "xauth" "," a specific backend name may be appended, separated by a dash. The appropriate .RI "" "xauth" "" backend is selected to perform the XAuth exchange. For traditional XAuth, the .RI "" "xauth" "" method is usually defined in the second authentication round following an initial .RI "" "pubkey" "" (or .RI "" "psk" ")" round. Using .RI "" "xauth" "" in the first round performs Hybrid Mode client authentication. For .RI "" "eap" "," a specific EAP method name may be appended, separated by a dash. An EAP module implementing the appropriate method is selected to perform the EAP conversation. .TP .BR connections..local.id " []" IKE identity to use for authentication round. When using certificate authentication, the IKE identity must be contained in the certificate, either as subject or as subjectAltName. .TP .BR connections..local.eap_id " [id]" Client EAP\-Identity to use in EAP\-Identity exchange and the EAP method. .TP .BR connections..local.aaa_id " [remote-id]" Server side EAP\-Identity to expect in the EAP method. Some EAP methods, such as EAP\-TLS, use an identity for the server to perform mutual authentication. This identity may differ from the IKE identity, especially when EAP authentication is delegated from the IKE responder to an AAA backend. For EAP\-(T)TLS, this defines the identity for which the server must provide a certificate in the TLS exchange. .TP .BR connections..local.xauth_id " [id]" Client XAuth username used in the XAuth exchange. .TP .B connections..remote .br Section for a remote authentication round. A remote authentication round defines the constraints how the peers must authenticate to use this connection. Multiple rounds may be defined to use IKEv2 RFC 4739 Multiple Authentication or IKEv1 XAuth. Each round is defined in a section having .RI "" "remote" "" as prefix, and an optional unique suffix. To define a single authentication round, the suffix may be omitted. .TP .BR connections..remote.id " [%any]" IKE identity to expect for authentication round. When using certificate authentication, the IKE identity must be contained in the certificate, either as subject or as subjectAltName. .TP .BR connections..remote.groups " []" Comma separated authorization group memberships to require. The peer must prove membership to at least one of the specified groups. Group membership can be certified by different means, for example by appropriate Attribute Certificates or by an AAA backend involved in the authentication. .TP .BR connections..remote.certs " []" Comma separated list of certificates to accept for authentication. The certificates may use a relative path from the .RB "" "swanctl" "" .RI "" "x509" "" directory, or an absolute path. .TP .BR connections..remote.cacert " []" Comma separated list of CA certificates to accept for authentication. The certificates may use a relative path from the .RB "" "swanctl" "" .RI "" "x509ca" "" directory, or an absolute path. .TP .BR connections..remote.revocation " [relaxed]" Certificate revocation policy for CRL or OCSP revocation. A .RI "" "strict" "" revocation policy fails if no revocation information is available, i.e. the certificate is not known to be unrevoked. .RI "" "ifuri" "" fails only if a CRL/OCSP URI is available, but certificate revocation checking fails, i.e. there should be revocation information available, but it could not be obtained. The default revocation policy .RI "" "relaxed" "" fails only if a certificate is revoked, i.e. it is explicitly known that it is bad. .TP .BR connections..remote.auth " [pubkey]" Authentication to expect from remote. See the .RB "" "local" "" sections .RB "" "auth" "" keyword description about the details of supported mechanisms. .TP .B connections..children. .br CHILD_SA configuration sub\-section. Each connection definition may have one or more sections in its .RI "" "children" "" subsection. The section name defines the name of the CHILD_SA configuration, which must be unique within the connection. .TP .BR connections..children..ah_proposals " []" AH proposals to offer for the CHILD_SA. A proposal is a set of algorithms. For AH, this includes an integrity algorithm and an optional Diffie\-Hellman group. If a DH group is specified, CHILD_SA/Quick Mode rekeying and initial negotiation uses a separate Diffie\-Hellman exchange using the specified group. In IKEv2, multiple algorithms of the same kind can be specified in a single proposal, from which one gets selected. In IKEv1, only one algorithm per kind is allowed per proposal, more algorithms get implicitly stripped. Use multiple proposals to offer different algorithms combinations in IKEv1. Algorithm keywords get separated using dashes. Multiple proposals may be separated by commas. The special value .RI "" "default" "" forms a default proposal of supported algorithms considered safe, and is usually a good choice for interoperability. By default no AH proposals are included, instead ESP is proposed. .TP .BR connections..children..esp_proposals " [default]" ESP proposals to offer for the CHILD_SA. A proposal is a set of algorithms. For ESP non\-AEAD proposals, this includes an integrity algorithm, an encryption algorithm, an optional Diffie\-Hellman group and an optional Extended Sequence Number Mode indicator. For AEAD proposals, a combined mode algorithm is used instead of the separate encryption/integrity algorithms. If a DH group is specified, CHILD_SA/Quick Mode rekeying and initial (non IKE_AUTH piggybacked) negotiation uses a separate Diffie\-Hellman exchange using the specified group. Extended Sequence Number support may be indicated with the .RI "" "esn" "" and .RI "" "noesn" "" values, both may be included to indicate support for both modes. If omitted, .RI "" "noesn" "" is assumed. In IKEv2, multiple algorithms of the same kind can be specified in a single proposal, from which one gets selected. In IKEv1, only one algorithm per kind is allowed per proposal, more algorithms get implicitly stripped. Use multiple proposals to offer different algorithms combinations in IKEv1. Algorithm keywords get separated using dashes. Multiple proposals may be separated by commas. The special value .RI "" "default" "" forms a default proposal of supported algorithms considered safe, and is usually a good choice for interoperability. If no algorithms are specified for AH nor ESP, the .RI "" "default" "" set of algorithms for ESP is included. .TP .BR connections..children..local_ts " [dynamic]" Comma separated list of local traffic selectors to include in CHILD_SA. Each selector is a CIDR subnet definition, followed by an optional proto/port selector. The special value .RI "" "dynamic" "" may be used instead of a subnet definition, which gets replaced by the tunnel outer address or the virtual IP, if negotiated. This is the default. A protocol/port selector is surrounded by opening and closing square brackets. Between these brackets, a numeric or .RB "" "getservent" "(3)" protocol name may be specified. After the optional protocol restriction, an optional port restriction may be specified, separated by a slash. The port restriction may be numeric, a .RB "" "getservent" "(3)" service name, or the special value .RI "" "opaque" "" for RFC 4301 OPAQUE selectors. Port ranges may be specified as well, none of the kernel backends currently support port ranges, though. Unless the Unity extension is used, IKEv1 supports the first specified selector only. IKEv1 uses very similar traffic selector narrowing as it is supported in the IKEv2 protocol. .TP .BR connections..children..remote_ts " [dynamic]" Comma separated list of remote selectors to include in CHILD_SA. See .RB "" "local_ts" "" for a description of the selector syntax. .TP .BR connections..children..rekey_time " [1h]" Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie\-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of .RB "" "rand_time" "" gets subtracted to form the effective soft lifetime. By default CHILD_SA rekeying is scheduled every hour, minus .RB "" "rand_time" "." .TP .BR connections..children..life_time " [rekey_time + 10%]" Maximum lifetime before CHILD_SA gets closed. Usually this hard lifetime is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than the .RB "" "rekey_time" "." .TP .BR connections..children..rand_time " [life_time - rekey_time]" Time range from which to choose a random value to subtract from .RB "" "rekey_time" "." The default is the difference between .RB "" "life_time" "" and .RB "" "rekey_time" "." .TP .BR connections..children..rekey_bytes " [0]" Number of bytes processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie\-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of .RB "" "rand_bytes" "" gets subtracted to form the effective soft volume limit. Volume based CHILD_SA rekeying is disabled by default. .TP .BR connections..children..life_bytes " [rekey_bytes + 10%]" Maximum bytes processed before CHILD_SA gets closed. Usually this hard volume limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than .RB "" "rekey_bytes" "." .TP .BR connections..children..rand_bytes " [life_bytes - rekey_bytes]" Byte range from which to choose a random value to subtract from .RB "" "rekey_bytes" "." The default is the difference between .RB "" "life_bytes" "" and .RB "" "rekey_bytes" "." .TP .BR connections..children..rekey_packets " [0]" Number of packets processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie\-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of .RB "" "rand_packets" "" gets subtracted to form the effective soft packet count limit. Packet count based CHILD_SA rekeying is disabled by default. .TP .BR connections..children..life_packets " [rekey_packets + 10%]" Maximum number of packets processed before CHILD_SA gets closed. Usually this hard packets limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than .RB "" "rekey_bytes" "." .TP .BR connections..children..rand_packets " [life_packets - rekey_packets]" Packet range from which to choose a random value to subtract from .RB "" "rekey_packets" "." The default is the difference between .RB "" "life_packets" "" and .RB "" "rekey_packets" "." .TP .BR connections..children..updown " []" Updown script to invoke on CHILD_SA up and down events. .TP .BR connections..children..hostaccess " [yes]" Hostaccess variable to pass to .RB "" "updown" "" script. .TP .BR connections..children..mode " [tunnel]" IPsec Mode to establish CHILD_SA with. .RI "" "tunnel" "" negotiates the CHILD_SA in IPsec Tunnel Mode, whereas .RI "" "transport" "" uses IPsec Transport Mode. .RI "" "beet" "" is the Bound End to End Tunnel mixture mode, working with fixed inner addresses without the need to include them in each packet. Both .RI "" "transport" "" and .RI "" "beet" "" modes are subject to mode negotiation; .RI "" "tunnel" "" mode is negotiated if the preferred mode is not available. .RI "" "pass" "" and .RI "" "drop" "" are used to install shunt policies, which explicitly bypass the defined traffic from IPsec processing, or drop it, respectively. .TP .BR connections..children..dpd_action " [clear]" Action to perform for this CHILD_SA on DPD timeout. The default .RI "" "clear" "" closes the CHILD_SA and does not take further action. .RI "" "trap" "" installs a trap policy, which will catch matching traffic and tries to re\-negotiate the tunnel on\-demand. .RI "" "restart" "" immediately tries to re\-negotiate the CHILD_SA under a fresh IKE_SA. .TP .BR connections..children..ipcomp " [no]" Enable IPComp compression before encryption. If enabled, IKE tries to negotiate IPComp compression to compress ESP payload data prior to encryption. .TP .BR connections..children..inactivity " [0s]" Timeout before closing CHILD_SA after inactivity. If no traffic has been processed in either direction for the configured timeout, the CHILD_SA gets closed due to inactivity. The default value of .RI "" "0" "" disables inactivity checks. .TP .BR connections..children..reqid " [0]" Fixed reqid to use for this CHILD_SA. This might be helpful in some scenarios, but works only if each CHILD_SA configuration is instantiated not more than once. The default of .RI "" "0" "" uses dynamic reqids, allocated incrementally. .TP .BR connections..children..mark_in " [0/0x00000000]" Netfilter mark and mask for input traffic. On Linux Netfilter may apply marks to each packet coming from a tunnel having that option set. The mark may then be used by Netfilter to match rules. An additional mask may be appended to the mark, separated by _/_. The default mask if omitted is 0xffffffff. .TP .BR connections..children..mark_out " [0/0x00000000]" Netfilter mark and mask for output traffic. On Linux Netfilter may require marks on each packet to match a policy having that option set. This allows Netfilter rules to select specific tunnels for outgoing traffic. An additional mask may be appended to the mark, separated by _/_. The default mask if omitted is 0xffffffff. .TP .BR connections..children..tfc_padding " [0]" Pads ESP packets with additional data to have a consistent ESP packet size for improved Traffic Flow Confidentiality. The padding defines the minimum size of all ESP packets sent. The default value of 0 disables TFC padding, the special value .RI "" "mtu" "" adds TFC padding to create a packet size equal to the Path Maximum Transfer Unit. .TP .BR connections..children..replay_window " [32]" IPsec replay window to configure for this CHILD_SA. Larger values than the default of 32 are supported using the Netlink backend only, a value of 0 disables IPsec replay protection. .TP .BR connections..children..start_action " [none]" Action to perform after loading the configuration. The default of .RI "" "none" "" loads the connection only, which then can be manually initiated or used as a responder configuration. The value .RI "" "trap" "" installs a trap policy, which triggers the tunnel as soon as matching traffic has been detected. The value .RI "" "start" "" initiates the connection actively. When unloading or replacing a CHILD_SA configuration having a .RB "" "start_action" "" different from .RI "" "none" "," the inverse action is performed. Configurations with .RI "" "start" "" get closed, while such with .RI "" "trap" "" get uninstalled. .TP .BR connections..children..close_action " [none]" Action to perform after a CHILD_SA gets closed by the peer. The default of .RI "" "none" "" does not take any action, .RI "" "trap" "" installs a trap policy for the CHILD_SA. .RI "" "start" "" tries to re\-create the CHILD_SA. .RB "" "close_action" "" does not provide any guarantee that the CHILD_SA is kept alive. It acts on explicit close messages only, but not on negotiation failures. Use trap policies to reliably re\-create failed CHILD_SAs. .TP .B secrets .br Section defining secrets for IKE/EAP/XAuth authentication and private key decryption. The .RB "" "secrets" "" section takes sub\-sections having a specific prefix which defines the secret type. It is not recommended to define any private key decryption passphrases, as then there is no real security benefit in having encrypted keys. Either store the key unencrypted, or enter the keys manually when loading credentials. .TP .B secrets.eap .br EAP secret section for a specific secret. Each EAP secret is defined in a unique section having the .RI "" "eap" "" prefix. EAP secrets are used for XAuth authentication as well. .TP .BR secrets.eap.secret " []" Value of the EAP/XAuth secret. It may either be an ASCII string, a hex encoded string if it has a .RI "" "0x" "" prefix, or a Base64 encoded string if it has a .RI "" "0s" "" prefix in its value. .TP .BR secrets.eap.id " []" Identity the EAP/XAuth secret belongs to. Multiple unique identities may be specified, each having an .RI "" "id" "" prefix, if a secret is shared between multiple users. .TP .B secrets.xauth .br XAuth secret section for a specific secret. .RB "" "xauth" "" is just an alias for .RB "" "eap" "," secrets under both section prefixes are used for both EAP and XAuth authentication. .TP .B secrets.ike .br IKE preshared secret section for a specific secret. Each IKE PSK is defined in a unique section having the .RI "" "ike" "" prefix. .TP .BR secrets.ike.secret " []" Value of the IKE preshared secret. It may either be an ASCII string, a hex encoded string if it has a .RI "" "0x" "" prefix, or a Base64 encoded string if it has a .RI "" "0s" "" prefix in its value. .TP .BR secrets.ike.id " []" IKE identity the IKE preshared secret belongs to. Multiple unique identities may be specified, each having an .RI "" "id" "" prefix, if a secret is shared between multiple peers. .TP .B secrets.rsa .br Private key decryption passphrase for a key in the .RI "" "rsa" "" folder. .TP .BR secrets.rsa.file " []" File name in the .RI "" "rsa" "" folder for which this passphrase should be used. .TP .BR secrets.rsa.secret " []" Value of decryption passphrase for RSA key. .TP .B secrets.ecdsa .br Private key decryption passphrase for a key in the .RI "" "ecdsa" "" folder. .TP .BR secrets.ecdsa.file " []" File name in the .RI "" "ecdsa" "" folder for which this passphrase should be used. .TP .BR secrets.ecdsa.secret " []" Value of decryption passphrase for ECDSA key. .TP .B secrets.pkcs8 .br Private key decryption passphrase for a key in the .RI "" "pkcs8" "" folder. .TP .BR secrets.pkcs8.file " []" File name in the .RI "" "pkcs8" "" folder for which this passphrase should be used. .TP .BR secrets.pkcs8.secret " []" Value of decryption passphrase for PKCS#8 key. .TP .B pools .br Section defining named pools. Named pools may be referenced by connections with the .RB "" "pools" "" option to assign virtual IPs and other configuration attributes. .TP .B pools. .br Section defining a single pool with a unique name. .TP .BR pools..addrs " []" Subnet defining addresses allocated in pool. Accepts a single CIDR subnet defining the pool to allocate addresses from. Pools must be unique and non\-overlapping. .TP .BR pools.. " []" Comma separated list of additional attributes of type .RB "" "" "." The attribute type may be one of .RI "" "dns" "," .RI "" "nbns" "," .RI "" "dhcp" "," .RI "" "netmask" "," .RI "" "server" "," .RI "" "subnet" "," .RI "" "split_include" "" and .RI "" "split_exclude" "" to define addresses or CIDR subnets for the corresponding attribute types. Alternatively, .RB "" "" "" can be a numerical identifier, for which string attribute values are accepted as well.