STRONGSWAN.CONF(5)

NAME
strongswan.conf - strongSwan configuration file

DESCRIPTION
While the ipsec.conf(5) configuration file is well suited to define IPsec related configuration parameters, it is not useful for other strongSwan applications to read options from this file. The file is hard to parse and only ipsec starter is capable of doing so. As the number of components of the strongSwan project is continually growing, a more flexible configuration file was needed, one that is easy to extend and can be used by all components. With strongSwan 4.2.1 strongswan.conf(5) was introduced which meets these requirements.

SYNTAX
The format of the strongswan.conf file consists of hierarchical sections and a list of key/value pairs in each section. Each section has a name, followed by C-Style curly brackets defining the section body. Each section body contains a set of subsections and key/value pairs:

    	settings := (section|keyvalue)*
    	section  := name { settings }
    	keyvalue := key = value\n

Values must be terminated by a newline.

Comments are possible using the #-character, but be careful: The parser implementation is currently limited and does not like brackets in comments.

Section names and keys may contain any printable character except:

    	. { } # \n \t space

An example file in this format might look like this:

    	a = b
    	section-one {
    		somevalue = asdf
    		subsection {
    			othervalue = xxx
    		}
    		# yei, a comment
    		yetanother = zz
    	}
    	section-two {
    		x = 12
    	}

Indentation is optional, you may use tabs or spaces.

INCLUDING FILES
Using the include statement it is possible to include other files into strongswan.conf, e.g.

    	include /some/path/*.conf

If the file name is not an absolute path, it is considered to be relative to the directory of the file containing the include statement. The file name may include shell wildcards (see sh(1)). Also, such inclusions can be nested.

Sections loaded from included files extend previously loaded sections; already existing values are replaced. It is important to note that settings are added relative to the section the include statement is in.

As an example, the following three files result in the same final config as the one given above:

    	a = b
    	section-one {
    		somevalue = before include
    		include include.conf
    	}
    	include other.conf

    include.conf:
    	# settings loaded from this file are added to section-one
    	# the following replaces the previous value
    	somevalue = asdf
    	subsection {
    		othervalue = yyy
    	}
    	yetanother = zz

    other.conf:
    	# this extends section-one and subsection
    	section-one {
    		subsection {
    			# this replaces the previous value
    			othervalue = xxx
    		}
    	}
    	section-two {
    		x = 12
    	}

READING VALUES
Values are accessed using a dot-separated section list and a key. With reference to the example above, accessing section-one.subsection.othervalue will return xxx.

DEFINED KEYS
The following keys are currently defined (using dot notation). The default value (if any) is listed in brackets after the key.

  charon section

charon.block_threshold [5]
    Maximum number of half-open IKE_SAs for a single peer IP

charon.close_ike_on_child_failure [no]
    Close the IKE_SA if setup of the CHILD_SA along with IKE_AUTH failed

charon.cookie_threshold [10]
    Number of half-open IKE_SAs that activate the cookie mechanism

charon.dns1
charon.dns2
    DNS servers assigned to peer via configuration payload (CP)

charon.dos_protection [yes]
    Enable Denial of Service protection using cookies and aggressiveness checks

charon.filelog
    Section to define file loggers, see LOGGER CONFIGURATION

charon.flush_auth_cfg [no]

charon.half_open_timeout [30]
    Timeout in seconds for connecting IKE_SAs (also see IKE_SA_INIT DROPPING).

charon.hash_and_url [no]
    Enable hash and URL support

charon.ignore_routing_tables
    A list of routing tables to be excluded from route lookup

charon.ikesa_table_segments [1]
    Number of exclusively locked segments in the hash table

charon.ikesa_table_size [1]
    Size of the IKE_SA hash table

charon.inactivity_close_ike [no]
    Whether to close IKE_SA if the only CHILD_SA closed due to inactivity

charon.init_limit_half_open [0]
    Limit new connections based on the current number of half open IKE_SAs (see IKE_SA_INIT DROPPING).

charon.init_limit_job_load [0]
    Limit new connections based on the number of jobs currently queued for processing (see IKE_SA_INIT DROPPING).

charon.install_routes [yes]
    Install routes into a separate routing table for established IPsec tunnels

charon.install_virtual_ip [yes]
    Install virtual IP addresses

charon.keep_alive [20s]
    NAT keep alive interval

charon.load
    Plugins to load in the IKEv2 daemon charon

charon.max_packet [10000]
    Maximum packet size accepted by charon

charon.multiple_authentication [yes]
    Enable multiple authentication exchanges (RFC 4739)

charon.nbns1
charon.nbns2
    WINS servers assigned to peer via configuration payload (CP)

charon.process_route [yes]
    Process RTM_NEWROUTE and RTM_DELROUTE events

charon.receive_delay [0]
    Delay for receiving packets, to simulate larger RTT

charon.receive_delay_response [yes]
    Delay response messages

charon.receive_delay_request [yes]
    Delay request messages

charon.receive_delay_type [0]
    Specific IKEv2 message type to delay, 0 for any

charon.replay_window [32]
    Size of the AH/ESP replay window, in packets.

charon.retransmit_base [1.8]
    Base to use for calculating exponential back off, see IKEv2 RETRANSMISSION

charon.retransmit_timeout [4.0]
    Timeout in seconds before sending first retransmit

charon.retransmit_tries [5]
    Number of times to retransmit a packet before giving up

charon.reuse_ikesa [yes]
    Initiate CHILD_SA within existing IKE_SAs

charon.routing_table
    Numerical routing table to install routes to

charon.routing_table_prio
    Priority of the routing table

charon.send_delay [0]
    Delay for sending packets, to simulate larger RTT

charon.send_delay_response [yes]
    Delay response messages

charon.send_delay_request [yes]
    Delay request messages

charon.send_delay_type [0]
    Specific IKEv2 message type to delay, 0 for any

charon.send_vendor_id [no]
    Send strongSwan vendor ID payload

charon.syslog
    Section to define syslog loggers, see LOGGER CONFIGURATION

charon.threads [16]
    Number of worker threads in charon

  charon.plugins subsection

charon.plugins.android.loglevel [1]
    Loglevel for logging to Android specific logger

charon.plugins.attr
    Section to specify arbitrary attributes that are assigned to a peer via configuration payload (CP)

charon.plugins.dhcp.identity_lease [no]
    Derive user-defined MAC address from hash of IKEv2 identity

charon.plugins.dhcp.server [255.255.255.255]
    DHCP server unicast or broadcast IP address

charon.plugins.duplicheck.enable [yes]
    enable loaded duplicheck plugin

charon.plugins.eap-aka.request_identity [yes]

charon.plugins.eap-aka-3ggp2.seq_check

charon.plugins.eap-gtc.pam_service [login]
    PAM service to be used for authentication

charon.plugins.eap-peap.fragment_size [1024]
    Maximum size of an EAP-PEAP packet

charon.plugins.eap-peap.max_message_count [32]
    Maximum number of processed EAP-PEAP packets

charon.plugins.eap-peap.include_length [no]
    Include length in non-fragmented EAP-PEAP packets

charon.plugins.eap-peap.phase2_method [mschapv2]
    Phase2 EAP client authentication method

charon.plugins.eap-peap.phase2_piggyback [no]
    Phase2 EAP Identity request piggybacked by server onto TLS Finished message

charon.plugins.eap-peap.phase2_tnc [no]
    Start phase2 EAP TNC protocol after successful client authentication

charon.plugins.eap-peap.request_peer_auth [no]
    Request peer authentication based on a client certificate

charon.plugins.eap-radius.class_group [no]
    Use the class attribute sent in the RADIUS-Accept message as group membership information that is compared to the groups specified in the rightgroups option in ipsec.conf (5).

charon.plugins.eap-radius.eap_start [no]
    Send EAP-Start instead of EAP-Identity to start RADIUS conversation

charon.plugins.eap-radius.filter_id [no]
    If the RADIUS tunnel_type attribute with value ESP is received, use the filter_id attribute sent in the RADIUS-Accept message as group membership information that is compared to the groups specified in the rightgroups option in ipsec.conf (5).

charon.plugins.eap-radius.id_prefix
    Prefix to EAP-Identity, some AAA servers use a IMSI prefix to select the EAP method

charon.plugins.eap-radius.nas_identifier [strongSwan]
    NAS-Identifier to include in RADIUS messages

charon.plugins.eap-radius.port [1812]
    Port of RADIUS server (authentication)

charon.plugins.eap-radius.secret
    Shared secret between RADIUS and NAS

charon.plugins.eap-radius.server
    IP/Hostname of RADIUS server

charon.plugins.eap-radius.servers
    Section to specify multiple RADIUS servers. The nas_identifier, secret, sockets and port options can be specified for each server. A server's IP/Hostname can be configured using the address option. For each RADIUS server a priority can be specified using the preference [0] option.

charon.plugins.eap-radius.sockets [1]
    Number of sockets (ports) to use, increase for high load

charon.plugins.eap-sim.request_identity [yes]

charon.plugins.eap-simaka-sql.database

charon.plugins.eap-simaka-sql.remove_used

charon.plugins.eap-tls.fragment_size [1024]
    Maximum size of an EAP-TLS packet

charon.plugins.eap-tls.max_message_count [32]
    Maximum number of processed EAP-TLS packets

charon.plugins.eap-tls.include_length [yes]
    Include length in non-fragmented EAP-TLS packets

charon.plugins.eap-tnc.fragment_size [50000]
    Maximum size of an EAP-TNC packet

charon.plugins.eap-tnc.max_message_count [10]
    Maximum number of processed EAP-TNC packets

charon.plugins.eap-tnc.include_length [yes]
    Include length in non-fragmented EAP-TNC packets

charon.plugins.eap-ttls.fragment_size [1024]
    Maximum size of an EAP-TTLS packet

charon.plugins.eap-ttls.max_message_count [32]
    Maximum number of processed EAP-TTLS packets

charon.plugins.eap-ttls.include_length [yes]
    Include length in non-fragmented EAP-TTLS packets

charon.plugins.eap-ttls.phase2_method [md5]
    Phase2 EAP client authentication method

charon.plugins.eap-ttls.phase2_piggyback [no]
    Phase2 EAP Identity request piggybacked by server onto TLS Finished message

charon.plugins.eap-ttls.phase2_tnc [no]
    Start phase2 EAP TNC protocol after successful client authentication

charon.plugins.eap-ttls.request_peer_auth [no]
    Request peer authentication based on a client certificate

charon.plugins.ha.fifo_interface [yes]

charon.plugins.ha.heartbeat_delay [1000]

charon.plugins.ha.heartbeat_timeout [2100]

charon.plugins.ha.local

charon.plugins.ha.monitor [yes]

charon.plugins.ha.pools

charon.plugins.ha.remote

charon.plugins.ha.resync [yes]

charon.plugins.ha.secret

charon.plugins.ha.segment_count [1]

charon.plugins.led.activity_led

charon.plugins.led.blink_time [50]

charon.plugins.kernel-klips.ipsec_dev_count [4]
    Number of ipsecN devices

charon.plugins.kernel-klips.ipsec_dev_mtu [0]
    Set MTU of ipsecN device

charon.plugins.load-tester
    Section to configure the load-tester plugin, see LOAD TESTS

charon.plugins.resolve.file [/etc/resolv.conf]
    File where to add DNS server entries

charon.plugins.sql.database
    Database URI for charons SQL plugin

charon.plugins.sql.loglevel [-1]
    Loglevel for logging to SQL database

charon.plugins.tnc-imc.preferred_language [en]
    Preferred language for TNC recommendations

charon.plugins.tnc-imc.tnc_config [/etc/tnc_config]
    TNC IMC configuration directory

charon.plugins.tnc-imv.tnc_config [/etc/tnc_config]
    TNC IMV configuration directory

charon.plugins.whitelist.enable [yes]
    enable loaded whitelist plugin

  libstrongswan section

libstrongswan.crypto_test.bench [no]

libstrongswan.crypto_test.bench_size [1024]

libstrongswan.crypto_test.bench_time [50]

libstrongswan.crypto_test.on_add [no]
    Test crypto algorithms during registration

libstrongswan.crypto_test.on_create [no]
    Test crypto algorithms on each crypto primitive instantiation

libstrongswan.crypto_test.required [no]
    Strictly require at least one test vector to enable an algorithm

libstrongswan.crypto_test.rng_true [no]
    Whether to test RNG with TRUE quality; requires a lot of entropy

libstrongswan.dh_exponent_ansi_x9_42 [yes]
    Use ANSI X9.42 DH exponent size or optimum size matched to cryptographical strength

libstrongswan.ecp_x_coordinate_only [yes]
    Compliance with the errata for RFC 4753

libstrongswan.integrity_test [no]
    Check daemon, libstrongswan and plugin integrity at startup

libstrongswan.leak_detective.detailed [yes]
    Includes source file names and line numbers in leak detective output

libstrongswan.processor.priority_threads
    Subsection to configure the number of reserved threads per priority class see JOB PRIORITY MANAGEMENT

libstrongswan.x509.enforce_critical [yes]
    Discard certificates with unsupported or unknown critical extensions

  libstrongswan.plugins subsection

libstrongswan.plugins.attr-sql.database
    Database URI for attr-sql plugin used by charon and pluto

libstrongswan.plugins.attr-sql.lease_history [yes]
    Enable logging of SQL IP pool leases

libstrongswan.plugins.gcrypt.quick_random [no]
    Use faster random numbers in gcrypt; for testing only, produces weak keys!

libstrongswan.plugins.openssl.engine_id [pkcs11]
    ENGINE ID to use in the OpenSSL plugin

libstrongswan.plugins.pkcs11.modules
    List of available PKCS#11 modules

libstrongswan.plugins.pkcs11.use_hasher [no]
    Whether the PKCS#11 modules should be used to hash data

  libimcv section

libimcv.debug_level [1]
    Debug level for a stand-alone libimcv library

libimcv.stderr_quiet [no]
    Disable output to stderr with a stand-alone libimcv library

  libimcv plugins section

libimcv.plugins.imc_test.command [none]
    Command to be sent to the Test IMV

libimcv.plugins.imc_test.retry [no]
    Do a handshake retry

libimcv.plugins.imc_test.retry_command
    Command to be sent to the Test IMV in the handshake retry

libimcv.plugins.imv_test.rounds [0]
    Number of IMC-IMV retry rounds

libimcv.plugins.imv_scanner.closed_port_policy [yes]
    By default all ports must be closed (yes) or can be open (no)

libimcv.plugins.imv_scanner.tcp_ports
    List of TCP ports that can be open or must be closed

libimcv.plugins.imv_scanner.udp_ports
    List of UDP ports that can be open or must be closed

  libtls section

libtls.cipher
    List of TLS encryption ciphers

libtls.key_exchange
    List of TLS key exchange methods

libtls.mac
    List of TLS MAC algorithms

libtls.suites
    List of TLS cipher suites

  manager section

manager.database
    Credential database URI for manager

manager.debug [no]
    Enable debugging in manager

manager.load
    Plugins to load in manager

manager.socket
    FastCGI socket of manager, to run it statically

manager.threads [10]
    Threads to use for request handling

manager.timeout [15m]
    Session timeout for manager

  mediation client section

medcli.database
    Mediation client database URI

medcli.dpd [5m]
    DPD timeout to use in mediation client plugin

medcli.rekey [20m]
    Rekeying time on mediation connections in mediation client plugin

  mediation server section

medsrv.database
    Mediation server database URI

medsrv.debug [no]
    Debugging in mediation server web application

medsrv.dpd [5m]
    DPD timeout to use in mediation server plugin

medsrv.load
    Plugins to load in mediation server plugin

medsrv.password_length [6]
    Minimum password length required for mediation server user accounts

medsrv.rekey [20m]
    Rekeying time on mediation connections in mediation server plugin

medsrv.socket
    Run Mediation server web application statically on socket

medsrv.threads [5]
    Number of thread for mediation service web application

medsrv.timeout [15m]
    Session timeout for mediation service

  openac section

openac.load
    Plugins to load in ipsec openac tool

  pki section

pki.load
    Plugins to load in ipsec pki tool

  pluto section

pluto.dns1
pluto.dns2
    DNS servers assigned to peer via Mode Config

pluto.load
    Plugins to load in IKEv1 pluto daemon

pluto.nbns1
pluto.nbns2
    WINS servers assigned to peer via Mode Config

pluto.threads [4]
    Number of worker threads in pluto

  pluto.plugins section

pluto.plugins.attr
    Section to specify arbitrary attributes that are assigned to a peer via Mode Config

charon.plugins.kernel-klips.ipsec_dev_count [4]
    Number of ipsecN devices

charon.plugins.kernel-klips.ipsec_dev_mtu [0]
    Set MTU of ipsecN device

  pool section

pool.load
    Plugins to load in ipsec pool tool

  scepclient section

scepclient.load
    Plugins to load in ipsec scepclient tool

  starter section

starter.load_warning [yes]
    Disable charon/pluto plugin load option warning

LOGGER CONFIGURATION
The options described below provide a much more flexible way to configure loggers for the IKEv2 daemon charon than using the charondebug option in ipsec.conf(5).

Please note that if any loggers are specified in strongswan.conf, charondebug does not have any effect.

There are currently two types of loggers defined:

File loggers
    Log directly to a file and are defined by specifying the full path to the file as subsection in the charon.filelog section. To log to the console the two special filenames stdout and stderr can be used.

Syslog loggers
    Log into a syslog facility and are defined by specifying the facility to log to as the name of a subsection in the charon.syslog section. The following facilities are currently supported: daemon and auth.

Multiple loggers can be defined for each type with different log verbosity for the different subsystems of the daemon.

  Options

charon.filelog.<filename>.default [1]
charon.syslog.<facility>.default
    Specifies the default loglevel to be used for subsystems for which no specific loglevel is defined.

charon.filelog.<filename>.<subsystem> [<default>]
charon.syslog.<facility>.<subsystem>
    Specifies the loglevel for the given subsystem.

charon.filelog.<filename>.append [yes]
    If this option is enabled log entries are appended to the existing file.

charon.filelog.<filename>.flush_line [no]
    Enabling this option disables block buffering and enables line buffering.

charon.filelog.<filename>.ike_name [no]
charon.syslog.<facility>.ike_name
    Prefix each log entry with the connection name and a unique numerical identifier for each IKE_SA.

charon.filelog.<filename>.time_format
    Prefix each log entry with a timestamp. The option accepts a format string as passed to strftime(3).

  Subsystems

dmn Main daemon setup/cleanup/signal handling

mgr IKE_SA manager, handling synchronization for IKE_SA access

ike IKE_SA

chd CHILD_SA

job Jobs queueing/processing and thread pool management

cfg Configuration management and plugins

knl IPsec/Networking kernel interface

net IKE network communication

enc Packet encoding/decoding encryption/decryption operations

tls libtls library messages

lib libstrongwan library messages

tnc Trusted Network Connect

imc Integrity Measurement Collector

imv Integrity Measurement Verifier

  Loglevels

-1  Absolutely silent

0   Very basic auditing logs, (e.g. SA up/SA down)

1   Generic control flow with errors, a good default to see whats going on

2   More detailed debugging control flow

3   Including RAW data dumps in Hex

4   Also include sensitive material in dumps, e.g. keys

  Example

    	charon {
    		filelog {
    			/var/log/charon.log {
    				time_format = %b %e %T
    				append = no
    				default = 1
    			}
    			stderr {
    				ike = 2
    				knl = 3
    				ike_name = yes
    			}
    		}
    		syslog {
    			# enable logging to LOG_DAEMON, use defaults
    			daemon {
    			}
    			# minimalistic IKE auditing logging to LOG_AUTHPRIV
    			auth {
    				default = -1
    				ike = 0
    			}
    		}
    	}

JOB PRIORITY MANAGEMENT
Some operations in the IKEv2 daemon charon are currently implemented synchronously and blocking. Two examples for such operations are communication with a RADIUS server via EAP-RADIUS, or fetching CRL/OCSP information during certificate chain verification. Under high load conditions, the thread pool may run out of available threads, and some more important jobs, such as liveness checking, may not get executed in time.

To prevent thread starvation in such situations job priorities were introduced. The job processor will reserve some threads for higher priority jobs, these threads are not available for lower priority, locking jobs.

  Implementation
Currently 4 priorities have been defined, and they are used in charon as follows:

CRITICAL
    Priority for long-running dispatcher jobs.

HIGH
    INFORMATIONAL exchanges, as used by liveness checking (DPD).

MEDIUM
    Everything not HIGH/LOW, including IKE_SA_INIT processing.

LOW IKE_AUTH message processing. RADIUS and CRL fetching block here

Although IKE_SA_INIT processing is computationally expensive, it is explicitly assigned to the MEDIUM class. This allows charon to do the DH exchange while other threads are blocked in IKE_AUTH. To prevent the daemon from accepting more IKE_SA_INIT requests than it can handle, use IKE_SA_INIT DROPPING.

The thread pool processes jobs strictly by priority, meaning it will consume all higher priority jobs before looking for ones with lower priority. Further, it reserves threads for certain priorities. A priority class having reserved n threads will always have n threads available for this class (either currently processing a job, or waiting for one).

  Configuration
To ensure that there are always enough threads available for higher priority tasks, threads must be reserved for each priority class.

libstrongswan.processor.priority_threads.critical [0]
    Threads reserved for CRITICAL priority class jobs

libstrongswan.processor.priority_threads.high [0]
    Threads reserved for HIGH priority class jobs

libstrongswan.processor.priority_threads.medium [0]
    Threads reserved for MEDIUM priority class jobs

libstrongswan.processor.priority_threads.low [0]
    Threads reserved for LOW priority class jobs

Let's consider the following configuration:

    	libstrongswan {
    		processor {
    			priority_threads {
    				high = 1
    				medium = 4
    			}
    		}
    	}

With this configuration, one thread is reserved for HIGH priority tasks. As currently only liveness checking and stroke message processing is done with high priority, one or two threads should be sufficient.

The MEDIUM class mostly processes non-blocking jobs. Unless your setup is experiencing many blocks in locks while accessing shared resources, threads for one or two times the number of CPU cores is fine.

It is usually not required to reserve threads for CRITICAL jobs. Jobs in this class rarely return and do not release their thread to the pool.

The remaining threads are available for LOW priority jobs. Reserving threads does not make sense (until we have an even lower priority).

  Monitoring
To see what the threads are actually doing, invoke ipsec statusall. Under high load, something like this will show up:

    	worker threads: 2 or 32 idle, 5/1/2/22 working,
    		job queue: 0/0/1/149, scheduled: 198

From 32 worker threads,

2   are currently idle.

5   are running CRITICAL priority jobs (dispatching from sockets, etc.).

1   is currently handling a HIGH priority job. This is actually the thread currently providing this information via stroke.

2   are handling MEDIUM priority jobs, likely IKE_SA_INIT or CREATE_CHILD_SA messages.

22  are handling LOW priority jobs, probably waiting for an EAP-RADIUS response while processing IKE_AUTH messages.

The job queue load shows how many jobs are queued for each priority, ready for execution. The single MEDIUM priority job will get executed immediately, as we have two spare threads reserved for MEDIUM class jobs.

IKE_SA_INIT DROPPING
If a responder receives more connection requests per seconds than it can handle, it does not make sense to accept more IKE_SA_INIT messages. And if they are queued but can't get processed in time, an answer might be sent after the client has already given up and restarted its connection setup. This additionally increases the load on the responder.

To limit the responder load resulting from new connection attempts, the daemon can drop IKE_SA_INIT messages just after reception. There are two mechanisms to decide if this should happen, configured with the following options:

charon.init_limit_half_open [0]
    Limit based on the number of half open IKE_SAs. Half open IKE_SAs are SAs in connecting state, but not yet established.

charon.init_limit_job_load [0]
    Limit based on the number of jobs currently queued for processing (sum over all job priorities).

The second limit includes load from other jobs, such as rekeying. Choosing a good value is difficult and depends on the hardware and expected load.

The first limit is simpler to calculate, but includes the load from new connections only. If your responder is capable of negotiating 100 tunnels/s, you might set this limit to 1000. The daemon will then drop new connection attempts if generating a response would require more than 10 seconds. If you are allowing for a maximum response time of more than 30 seconds, consider adjusting the timeout for connecting IKE_SAs (charon.half_open_timeout). A responder, by default, deletes an IKE_SA if the initiator does not establish it within 30 seconds. Under high load, a higher value might be required.

LOAD TESTS
To do stability testing and performance optimizations, the IKEv2 daemon charon provides the load-tester plugin. This plugin allows to setup thousands of tunnels concurrently against the daemon itself or a remote host.

WARNING: Never enable the load-testing plugin on productive systems. It provides preconfigured credentials and allows an attacker to authenticate as any user.

  Options

charon.plugins.load-tester.child_rekey [600]
    Seconds to start CHILD_SA rekeying after setup

charon.plugins.load-tester.delay [0]
    Delay between initiatons for each thread

charon.plugins.load-tester.delete_after_established [no]
    Delete an IKE_SA as soon as it has been established

charon.plugins.load-tester.dpd_delay [0]
    DPD delay to use in load test

charon.plugins.load-tester.dynamic_port [0]
    Base port to be used for requests (each client uses a different port)

charon.plugins.load-tester.eap_password [default-pwd]
    EAP secret to use in load test

charon.plugins.load-tester.enable [no]
    Enable the load testing plugin

charon.plugins.load-tester.fake_kernel [no]
    Fake the kernel interface to allow load-testing against self

charon.plugins.load-tester.ike_rekey [0]
    Seconds to start IKE_SA rekeying after setup

charon.plugins.load-tester.init_limit [0]
    Global limit of concurrently established SAs during load test

charon.plugins.load-tester.initiators [0]
    Number of concurrent initiator threads to use in load test

charon.plugins.load-tester.initiator_auth [pubkey]
    Authentication method(s) the intiator uses

charon.plugins.load-tester.initiator_id
    Initiator ID used in load test

charon.plugins.load-tester.iterations [1]
    Number of IKE_SAs to initate by each initiator in load test

charon.plugins.load-tester.pool
    Provide INTERNAL_IPV4_ADDRs from a named pool

charon.plugins.load-tester.preshared_key [default-psk]
    Preshared key to use in load test

charon.plugins.load-tester.proposal [aes128-sha1-modp768]
    IKE proposal to use in load test

charon.plugins.load-tester.remote [127.0.0.1]
    Address to initiation connections to

charon.plugins.load-tester.responder_auth [pubkey]
    Authentication method(s) the responder uses

charon.plugins.load-tester.responder_id
    Responder ID used in load test

charon.plugins.load-tester.request_virtual_ip [no]
    Request an INTERNAL_IPV4_ADDR from the server

charon.plugins.load-tester.shutdown_when_complete [no]
    Shutdown the daemon after all IKE_SAs have been established

  Configuration details
For public key authentication, the responder uses the "CN=srv, OU=load-test, O=strongSwan" identity. For the initiator, each connection attempt uses a different identity in the form "CN=c1-r1, OU=load-test, O=strongSwan", where the first number inidicates the client number, the second the authentication round (if multiple authentication is used).

For PSK authentication, FQDN identities are used. The server uses srv.strongswan.org, the client uses an identity in the form c1-r1.strongswan.org.

For EAP authentication, the client uses a NAI in the form 100000000010001@strongswan.org.

To configure multiple authentication, concatenate multiple methods using, e.g.
    	initiator_auth = pubkey|psk|eap-md5|eap-aka

The responder uses a hardcoded certificate based on a 1024-bit RSA key. This certificate additionally serves as CA certificate. A peer uses the same private key, but generates client certificates on demand signed by the CA certificate. Install the Responder/CA certificate on the remote host to authenticate all clients.

To speed up testing, the load tester plugin implements a special Diffie-Hellman implementation called modpnull. By setting
    	proposal = aes128-sha1-modpnull
this wicked fast DH implementation is used. It does not provide any security at all, but allows to run tests without DH calculation overhead.

  Examples

In the simplest case, the daemon initiates IKE_SAs against itself using the loopback interface. This will actually establish double the number of IKE_SAs, as the daemon is initiator and responder for each IKE_SA at the same time. Installation of IPsec SAs would fails, as each SA gets installed twice. To simulate the correct behavior, a fake kernel interface can be enabled which does not install the IPsec SAs at the kernel level.

A simple loopback configuration might look like this:

    	charon {
    		# create new IKE_SAs for each CHILD_SA to simulate
    		# different clients
    		reuse_ikesa = no
    		# turn off denial of service protection
    		dos_protection = no

    		plugins {
    			load-tester {
    				# enable the plugin
    				enable = yes
    				# use 4 threads to initiate connections
    				# simultaneously
    				initiators = 4
    				# each thread initiates 1000 connections
    				iterations = 1000
    				# delay each initiation in each thread by 20ms
    				delay = 20
    				# enable the fake kernel interface to
    				# avoid SA conflicts
    				fake_kernel = yes
    			}
    		}
    	}

This will initiate 4000 IKE_SAs within 20 seconds. You may increase the delay value if your box can not handle that much load, or decrease it to put more load on it. If the daemon starts retransmitting messages your box probably can not handle all connection attempts.

The plugin also allows to test against a remote host. This might help to test against a real world configuration. A connection setup to do stress testing of a gateway might look like this:

    	charon {
    		reuse_ikesa = no
    		threads = 32

    		plugins {
    			load-tester {
    				enable = yes
    				# 10000 connections, ten in parallel
    				initiators = 10
    				iterations = 1000
    				# use a delay of 100ms, overall time is:
    				# iterations * delay = 100s
    				delay = 100
    				# address of the gateway
    				remote = 1.2.3.4
    				# IKE-proposal to use
    				proposal = aes128-sha1-modp1024
    				# use faster PSK authentication instead
    				# of 1024bit RSA
    				initiator_auth = psk
    				responder_auth = psk
    				# request a virtual IP using configuration
    				# payloads
    				request_virtual_ip = yes
    				# enable CHILD_SA every 60s
    				child_rekey = 60
    			}
    		}
    	}

IKEv2 RETRANSMISSION
Retransmission timeouts in the IKEv2 daemon charon can be configured globally using the three keys listed below:

    charon.retransmit_base [1.8]
    charon.retransmit_timeout [4.0]
    charon.retransmit_tries [5]

The following algorithm is used to calculate the timeout:

    	relative timeout = retransmit_timeout * retransmit_base ^ (n-1)

Where n is the current retransmission count.

Using the default values, packets are retransmitted in:

Retransmission | Relative Timeout | Absolute Timeout
1 | 4s | 4s
2 | 7s | 11s
3 | 13s | 24s
4 | 23s | 47s
5 | 42s | 89s
giving up | 76s | 165s

FILES
/etc/strongswan.conf

SEE ALSO
ipsec.conf(5), ipsec.secrets(5), ipsec(8)

HISTORY
Written for the strongSwan project (http://www.strongswan.org) by Tobias Brunner, Andreas Steffen and Martin Willi.