Annotation of embedaddon/strongswan/conf/strongswan.conf.5.tail.in, revision 1.1
1.1 ! misho 1: .SH LOGGER CONFIGURATION
! 2: Options in
! 3: .BR strongswan.conf (5)
! 4: provide a much more flexible way to configure loggers for the IKE daemon charon
! 5: than using the
! 6: .B charondebug
! 7: option in
! 8: .BR ipsec.conf (5).
! 9: .PP
! 10: .BR Note :
! 11: If any loggers are specified in strongswan.conf,
! 12: .B charondebug
! 13: does not have any effect.
! 14: .PP
! 15: There are currently two types of loggers:
! 16: .TP
! 17: .B File loggers
! 18: Log directly to a file and are defined by specifying an arbitrarily named
! 19: subsection in the
! 20: .B charon.filelog
! 21: section. The full path to the file is configured in the \fIpath\fR setting of
! 22: that subsection, however, if it only contains characters permitted in section
! 23: names, the setting may also be omitted and the path specified as name of the
! 24: subsection. To log to the console the two special filenames
! 25: .BR stdout " and " stderr
! 26: may be used.
! 27: .TP
! 28: .B Syslog loggers
! 29: Log into a syslog facility and are defined by specifying the facility to log to
! 30: as the name of a subsection in the
! 31: .B charon.syslog
! 32: section. The following facilities are currently supported:
! 33: .BR daemon " and " auth .
! 34: .PP
! 35: Multiple loggers can be defined for each type with different log verbosity for
! 36: the different subsystems of the daemon.
! 37:
! 38: .SS Subsystems
! 39: .TP
! 40: .B dmn
! 41: Main daemon setup/cleanup/signal handling
! 42: .TP
! 43: .B mgr
! 44: IKE_SA manager, handling synchronization for IKE_SA access
! 45: .TP
! 46: .B ike
! 47: IKE_SA
! 48: .TP
! 49: .B chd
! 50: CHILD_SA
! 51: .TP
! 52: .B job
! 53: Jobs queueing/processing and thread pool management
! 54: .TP
! 55: .B cfg
! 56: Configuration management and plugins
! 57: .TP
! 58: .B knl
! 59: IPsec/Networking kernel interface
! 60: .TP
! 61: .B net
! 62: IKE network communication
! 63: .TP
! 64: .B asn
! 65: Low-level encoding/decoding (ASN.1, X.509 etc.)
! 66: .TP
! 67: .B enc
! 68: Packet encoding/decoding encryption/decryption operations
! 69: .TP
! 70: .B tls
! 71: libtls library messages
! 72: .TP
! 73: .B esp
! 74: libipsec library messages
! 75: .TP
! 76: .B lib
! 77: libstrongswan library messages
! 78: .TP
! 79: .B tnc
! 80: Trusted Network Connect
! 81: .TP
! 82: .B imc
! 83: Integrity Measurement Collector
! 84: .TP
! 85: .B imv
! 86: Integrity Measurement Verifier
! 87: .TP
! 88: .B pts
! 89: Platform Trust Service
! 90: .SS Loglevels
! 91: .TP
! 92: .B -1
! 93: Absolutely silent
! 94: .TP
! 95: .B 0
! 96: Very basic auditing logs, (e.g. SA up/SA down)
! 97: .TP
! 98: .B 1
! 99: Generic control flow with errors, a good default to see what's going on
! 100: .TP
! 101: .B 2
! 102: More detailed debugging control flow
! 103: .TP
! 104: .B 3
! 105: Including RAW data dumps in Hex
! 106: .TP
! 107: .B 4
! 108: Also include sensitive material in dumps, e.g. keys
! 109: .SS Example
! 110: .PP
! 111: .EX
! 112: charon {
! 113: filelog {
! 114: charon {
! 115: path = /var/log/charon.log
! 116: time_format = %b %e %T
! 117: append = no
! 118: default = 1
! 119: }
! 120: stderr {
! 121: ike = 2
! 122: knl = 3
! 123: ike_name = yes
! 124: }
! 125: }
! 126: syslog {
! 127: # enable logging to LOG_DAEMON, use defaults
! 128: daemon {
! 129: }
! 130: # minimalistic IKE auditing logging to LOG_AUTHPRIV
! 131: auth {
! 132: default = -1
! 133: ike = 0
! 134: }
! 135: }
! 136: }
! 137: .EE
! 138:
! 139: .SH JOB PRIORITY MANAGEMENT
! 140: Some operations in the IKEv2 daemon charon are currently implemented
! 141: synchronously and blocking. Two examples for such operations are communication
! 142: with a RADIUS server via EAP-RADIUS, or fetching CRL/OCSP information during
! 143: certificate chain verification. Under high load conditions, the thread pool may
! 144: run out of available threads, and some more important jobs, such as liveness
! 145: checking, may not get executed in time.
! 146: .PP
! 147: To prevent thread starvation in such situations job priorities were introduced.
! 148: The job processor will reserve some threads for higher priority jobs, these
! 149: threads are not available for lower priority, locking jobs.
! 150: .SS Implementation
! 151: Currently 4 priorities have been defined, and they are used in charon as
! 152: follows:
! 153: .TP
! 154: .B CRITICAL
! 155: Priority for long-running dispatcher jobs.
! 156: .TP
! 157: .B HIGH
! 158: INFORMATIONAL exchanges, as used by liveness checking (DPD).
! 159: .TP
! 160: .B MEDIUM
! 161: Everything not HIGH/LOW, including IKE_SA_INIT processing.
! 162: .TP
! 163: .B LOW
! 164: IKE_AUTH message processing. RADIUS and CRL fetching block here
! 165: .PP
! 166: Although IKE_SA_INIT processing is computationally expensive, it is explicitly
! 167: assigned to the MEDIUM class. This allows charon to do the DH exchange while
! 168: other threads are blocked in IKE_AUTH. To prevent the daemon from accepting more
! 169: IKE_SA_INIT requests than it can handle, use IKE_SA_INIT DROPPING.
! 170: .PP
! 171: The thread pool processes jobs strictly by priority, meaning it will consume all
! 172: higher priority jobs before looking for ones with lower priority. Further, it
! 173: reserves threads for certain priorities. A priority class having reserved
! 174: .I n
! 175: threads will always have
! 176: .I n
! 177: threads available for this class (either currently processing a job, or waiting
! 178: for one).
! 179: .SS Configuration
! 180: To ensure that there are always enough threads available for higher priority
! 181: tasks, threads must be reserved for each priority class.
! 182: .TP
! 183: .BR charon.processor.priority_threads.critical " [0]"
! 184: Threads reserved for CRITICAL priority class jobs
! 185: .TP
! 186: .BR charon.processor.priority_threads.high " [0]"
! 187: Threads reserved for HIGH priority class jobs
! 188: .TP
! 189: .BR charon.processor.priority_threads.medium " [0]"
! 190: Threads reserved for MEDIUM priority class jobs
! 191: .TP
! 192: .BR charon.processor.priority_threads.low " [0]"
! 193: Threads reserved for LOW priority class jobs
! 194: .PP
! 195: Let's consider the following configuration:
! 196: .PP
! 197: .EX
! 198: charon {
! 199: processor {
! 200: priority_threads {
! 201: high = 1
! 202: medium = 4
! 203: }
! 204: }
! 205: }
! 206: .EE
! 207: .PP
! 208: With this configuration, one thread is reserved for HIGH priority tasks. As
! 209: currently only liveness checking and stroke message processing is done with
! 210: high priority, one or two threads should be sufficient.
! 211: .PP
! 212: The MEDIUM class mostly processes non-blocking jobs. Unless your setup is
! 213: experiencing many blocks in locks while accessing shared resources, threads for
! 214: one or two times the number of CPU cores is fine.
! 215: .PP
! 216: It is usually not required to reserve threads for CRITICAL jobs. Jobs in this
! 217: class rarely return and do not release their thread to the pool.
! 218: .PP
! 219: The remaining threads are available for LOW priority jobs. Reserving threads
! 220: does not make sense (until we have an even lower priority).
! 221: .SS Monitoring
! 222: To see what the threads are actually doing, invoke
! 223: .IR "ipsec statusall" .
! 224: Under high load, something like this will show up:
! 225: .PP
! 226: .EX
! 227: worker threads: 2 or 32 idle, 5/1/2/22 working,
! 228: job queue: 0/0/1/149, scheduled: 198
! 229: .EE
! 230: .PP
! 231: From 32 worker threads,
! 232: .IP 2
! 233: are currently idle.
! 234: .IP 5
! 235: are running CRITICAL priority jobs (dispatching from sockets, etc.).
! 236: .IP 1
! 237: is currently handling a HIGH priority job. This is actually the thread currently
! 238: providing this information via stroke.
! 239: .IP 2
! 240: are handling MEDIUM priority jobs, likely IKE_SA_INIT or CREATE_CHILD_SA
! 241: messages.
! 242: .IP 22
! 243: are handling LOW priority jobs, probably waiting for an EAP-RADIUS response
! 244: while processing IKE_AUTH messages.
! 245: .PP
! 246: The job queue load shows how many jobs are queued for each priority, ready for
! 247: execution. The single MEDIUM priority job will get executed immediately, as
! 248: we have two spare threads reserved for MEDIUM class jobs.
! 249:
! 250: .SH IKE_SA_INIT DROPPING
! 251: If a responder receives more connection requests per seconds than it can handle,
! 252: it does not make sense to accept more IKE_SA_INIT messages. And if they are
! 253: queued but can't get processed in time, an answer might be sent after the
! 254: client has already given up and restarted its connection setup. This
! 255: additionally increases the load on the responder.
! 256: .PP
! 257: To limit the responder load resulting from new connection attempts, the daemon
! 258: can drop IKE_SA_INIT messages just after reception. There are two mechanisms to
! 259: decide if this should happen, configured with the following options:
! 260: .TP
! 261: .BR charon.init_limit_half_open " [0]"
! 262: Limit based on the number of half open IKE_SAs. Half open IKE_SAs are SAs in
! 263: connecting state, but not yet established.
! 264: .TP
! 265: .BR charon.init_limit_job_load " [0]"
! 266: Limit based on the number of jobs currently queued for processing (sum over all
! 267: job priorities).
! 268: .PP
! 269: The second limit includes load from other jobs, such as rekeying. Choosing a
! 270: good value is difficult and depends on the hardware and expected load.
! 271: .PP
! 272: The first limit is simpler to calculate, but includes the load from new
! 273: connections only. If your responder is capable of negotiating 100 tunnels/s, you
! 274: might set this limit to 1000. The daemon will then drop new connection attempts
! 275: if generating a response would require more than 10 seconds. If you are
! 276: allowing for a maximum response time of more than 30 seconds, consider adjusting
! 277: the timeout for connecting IKE_SAs
! 278: .RB ( charon.half_open_timeout ).
! 279: A responder, by default, deletes an IKE_SA if the initiator does not establish
! 280: it within 30 seconds. Under high load, a higher value might be required.
! 281:
! 282: .SH LOAD TESTS
! 283: To do stability testing and performance optimizations, the IKE daemon charon
! 284: provides the \fIload-tester\fR plugin. This plugin allows one to setup thousands
! 285: of tunnels concurrently against the daemon itself or a remote host.
! 286: .PP
! 287: .B WARNING:
! 288: Never enable the load-testing plugin on productive systems. It provides
! 289: preconfigured credentials and allows an attacker to authenticate as any user.
! 290: .PP
! 291: .SS Configuration details
! 292: For public key authentication, the responder uses the
! 293: .B \(dqCN=srv, OU=load-test, O=strongSwan\(dq
! 294: identity. For the initiator, each connection attempt uses a different identity
! 295: in the form
! 296: .BR "\(dqCN=c1-r1, OU=load-test, O=strongSwan\(dq" ,
! 297: where the first number indicates the client number, the second the
! 298: authentication round (if multiple authentication rounds are used).
! 299: .PP
! 300: For PSK authentication, FQDN identities are used. The server uses
! 301: .BR srv.strongswan.org ,
! 302: the client uses an identity in the form
! 303: .BR c1-r1.strongswan.org .
! 304: .PP
! 305: For EAP authentication, the client uses a NAI in the form
! 306: .BR 100000000010001@strongswan.org .
! 307: .PP
! 308: To configure multiple authentication rounds, concatenate multiple methods using,
! 309: e.g.
! 310: .EX
! 311: initiator_auth = pubkey|psk|eap-md5|eap-aka
! 312: .EE
! 313: .PP
! 314: The responder uses a hardcoded certificate based on a 1024-bit RSA key.
! 315: This certificate additionally serves as CA certificate. A peer uses the same
! 316: private key, but generates client certificates on demand signed by the CA
! 317: certificate. Install the Responder/CA certificate on the remote host to
! 318: authenticate all clients.
! 319: .PP
! 320: To speed up testing, the load tester plugin implements a special Diffie-Hellman
! 321: implementation called \fImodpnull\fR. By setting
! 322: .EX
! 323: proposal = aes128-sha1-modpnull
! 324: .EE
! 325: this wicked fast DH implementation is used. It does not provide any security
! 326: at all, but allows one to run tests without DH calculation overhead.
! 327: .SS Examples
! 328: .PP
! 329: In the simplest case, the daemon initiates IKE_SAs against itself using the
! 330: loopback interface. This will actually establish double the number of IKE_SAs,
! 331: as the daemon is initiator and responder for each IKE_SA at the same time.
! 332: Installation of IPsec SAs would fail, as each SA gets installed twice. To
! 333: simulate the correct behavior, a fake kernel interface can be enabled which does
! 334: not install the IPsec SAs at the kernel level.
! 335: .PP
! 336: A simple loopback configuration might look like this:
! 337: .PP
! 338: .EX
! 339: charon {
! 340: # create new IKE_SAs for each CHILD_SA to simulate
! 341: # different clients
! 342: reuse_ikesa = no
! 343: # turn off denial of service protection
! 344: dos_protection = no
! 345:
! 346: plugins {
! 347: load-tester {
! 348: # enable the plugin
! 349: enable = yes
! 350: # use 4 threads to initiate connections
! 351: # simultaneously
! 352: initiators = 4
! 353: # each thread initiates 1000 connections
! 354: iterations = 1000
! 355: # delay each initiation in each thread by 20ms
! 356: delay = 20
! 357: # enable the fake kernel interface to
! 358: # avoid SA conflicts
! 359: fake_kernel = yes
! 360: }
! 361: }
! 362: }
! 363: .EE
! 364: .PP
! 365: This will initiate 4000 IKE_SAs within 20 seconds. You may increase the delay
! 366: value if your box can not handle that much load, or decrease it to put more
! 367: load on it. If the daemon starts retransmitting messages your box probably can
! 368: not handle all connection attempts.
! 369: .PP
! 370: The plugin also allows one to test against a remote host. This might help to
! 371: test against a real world configuration. A connection setup to do stress
! 372: testing of a gateway might look like this:
! 373: .PP
! 374: .EX
! 375: charon {
! 376: reuse_ikesa = no
! 377: threads = 32
! 378:
! 379: plugins {
! 380: load-tester {
! 381: enable = yes
! 382: # 10000 connections, ten in parallel
! 383: initiators = 10
! 384: iterations = 1000
! 385: # use a delay of 100ms, overall time is:
! 386: # iterations * delay = 100s
! 387: delay = 100
! 388: # address of the gateway
! 389: remote = 1.2.3.4
! 390: # IKE-proposal to use
! 391: proposal = aes128-sha1-modp1024
! 392: # use faster PSK authentication instead
! 393: # of 1024bit RSA
! 394: initiator_auth = psk
! 395: responder_auth = psk
! 396: # request a virtual IP using configuration
! 397: # payloads
! 398: request_virtual_ip = yes
! 399: # enable CHILD_SA every 60s
! 400: child_rekey = 60
! 401: }
! 402: }
! 403: }
! 404: .EE
! 405:
! 406: .SH IKEv2 RETRANSMISSION
! 407: Retransmission timeouts in the IKEv2 daemon charon can be configured globally
! 408: using the three keys listed below:
! 409: .PP
! 410: .RS
! 411: .nf
! 412: .BR charon.retransmit_base " [1.8]"
! 413: .BR charon.retransmit_timeout " [4.0]"
! 414: .BR charon.retransmit_tries " [5]"
! 415: .BR charon.retransmit_jitter " [0]"
! 416: .BR charon.retransmit_limit " [0]"
! 417: .fi
! 418: .RE
! 419: .PP
! 420: The following algorithm is used to calculate the timeout:
! 421: .PP
! 422: .EX
! 423: relative timeout = retransmit_timeout * retransmit_base ^ (n-1)
! 424: .EE
! 425: .PP
! 426: Where
! 427: .I n
! 428: is the current retransmission count. The calculated timeout can't exceed the
! 429: configured retransmit_limit (if any), which is useful if the number of retries
! 430: is high.
! 431: .PP
! 432: If a jitter in percent is configured, the timeout is modified as follows:
! 433: .PP
! 434: .EX
! 435: relative timeout -= random(0, retransmit_jitter * relative timeout)
! 436: .EE
! 437: .PP
! 438: Using the default values, packets are retransmitted in:
! 439:
! 440: .TS
! 441: l r r
! 442: ---
! 443: lB r r.
! 444: Retransmission Relative Timeout Absolute Timeout
! 445: 1 4s 4s
! 446: 2 7s 11s
! 447: 3 13s 24s
! 448: 4 23s 47s
! 449: 5 42s 89s
! 450: giving up 76s 165s
! 451: .TE
! 452: .
! 453: .SH VARIABLES
! 454: .
! 455: The variables used above are configured as follows:
! 456:
! 457: .nf
! 458: .na
! 459: ${piddir} @piddir@
! 460: ${prefix} @prefix@
! 461: ${random_device} @random_device@
! 462: ${urandom_device} @urandom_device@
! 463: .ad
! 464: .fi
! 465: .
! 466: .SH FILES
! 467: .
! 468: .nf
! 469: .na
! 470: /etc/strongswan.conf configuration file
! 471: /etc/strongswan.d/ directory containing included config snippets
! 472: /etc/strongswan.d/charon/ plugin specific config snippets
! 473: .ad
! 474: .fi
! 475: .
! 476: .SH SEE ALSO
! 477: \fBipsec.conf\fR(5), \fBipsec.secrets\fR(5), \fBipsec\fR(8), \fBcharon-cmd\fR(8)
! 478:
! 479: .SH HISTORY
! 480: Written for the
! 481: .UR http://www.strongswan.org
! 482: strongSwan project
! 483: .UE
! 484: by Tobias Brunner, Andreas Steffen and Martin Willi.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to strongswan.conf.5.tail.in CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / strongswan / conf