strongswan.conf.5.head.in 5.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191
  1. .TH STRONGSWAN.CONF 5 "" "@PACKAGE_VERSION@" "strongSwan"
  2. .SH NAME
  3. strongswan.conf \- strongSwan configuration file
  4. .SH DESCRIPTION
  5. While the
  6. .IR ipsec.conf (5)
  7. configuration file is well suited to define IPsec related configuration
  8. parameters, it is not useful for other strongSwan applications to read options
  9. from this file.
  10. The file is hard to parse and only
  11. .I ipsec starter
  12. is capable of doing so. As the number of components of the strongSwan project
  13. is continually growing, a more flexible configuration file was needed, one that
  14. is easy to extend and can be used by all components. With strongSwan 4.2.1
  15. .IR strongswan.conf (5)
  16. was introduced which meets these requirements.
  17. .SH SYNTAX
  18. The format of the strongswan.conf file consists of hierarchical
  19. .B sections
  20. and a list of
  21. .B key/value pairs
  22. in each section. Each section has a name, followed by C-Style curly brackets
  23. defining the section body. Each section body contains a set of subsections
  24. and key/value pairs:
  25. .PP
  26. .EX
  27. settings := (section|keyvalue)*
  28. section := name { settings }
  29. keyvalue := key = value\\n
  30. .EE
  31. .PP
  32. Values must be terminated by a newline.
  33. .PP
  34. Comments are possible using the \fB#\fP-character.
  35. .PP
  36. Section names and keys may contain any printable character except:
  37. .PP
  38. .EX
  39. . , : { } = " # \\n \\t space
  40. .EE
  41. .PP
  42. An example file in this format might look like this:
  43. .PP
  44. .EX
  45. a = b
  46. section-one {
  47. somevalue = asdf
  48. subsection {
  49. othervalue = xxx
  50. }
  51. # yei, a comment
  52. yetanother = zz
  53. }
  54. section-two {
  55. x = 12
  56. }
  57. .EE
  58. .PP
  59. Indentation is optional, you may use tabs or spaces.
  60. .SH REFERENCING OTHER SECTIONS
  61. It is possible to inherit settings and sections from another section. This
  62. feature is mainly useful in swanctl.conf (which uses the same file format).
  63. The syntax is as follows:
  64. .PP
  65. .EX
  66. section := name : references { settings }
  67. references := absname[, absname]*
  68. absname := name[.name]*
  69. .EE
  70. .PP
  71. All key/value pairs and all subsections of the referenced sections will be
  72. inherited by the section that references them via their absolute name. Values
  73. may be overridden in the section or any of its sub-sections (use an empty
  74. assignment to clear a value so its default value, if any, will apply). It is
  75. currently not possible to limit the inclusion level or clear/remove inherited
  76. sub-sections.
  77. If the order is important (e.g. for auth rounds in a connection, if \fIround\fR
  78. is not used), it should be noted that inherited settings/sections will follow
  79. those defined in the current section (if multiple sections are referenced, their
  80. settings are enumerated left to right).
  81. References are evaluated dynamically at runtime, so referring to sections later
  82. in the config file or included via other files is no problem.
  83. Here is an example of how this might look like:
  84. .PP
  85. .EX
  86. conn-defaults {
  87. # default settings for all conns (e.g. a cert, or IP pools)
  88. }
  89. eap-defaults {
  90. # defaults if eap is used (e.g. a remote auth round)
  91. }
  92. child-defaults {
  93. # defaults for child configs (e.g. traffic selectors)
  94. }
  95. connections {
  96. conn-a : conn-defaults, eap-defaults {
  97. # set/override stuff specific to this connection
  98. children {
  99. child-a : child-defaults {
  100. # set/override stuff specific to this child
  101. }
  102. }
  103. }
  104. conn-b : conn-defaults {
  105. # set/override stuff specific to this connection
  106. children {
  107. child-b : child-defaults {
  108. # set/override stuff specific to this child
  109. }
  110. }
  111. }
  112. conn-c : connections.conn-a {
  113. # everything is inherited, including everything conn-a
  114. # already inherits from the sections it and its
  115. # sub-section reference
  116. }
  117. }
  118. .EE
  119. .PP
  120. .SH INCLUDING FILES
  121. Using the
  122. .B include
  123. statement it is possible to include other files into strongswan.conf, e.g.
  124. .PP
  125. .EX
  126. include /some/path/*.conf
  127. .EE
  128. .PP
  129. If the file name is not an absolute path, it is considered to be relative
  130. to the directory of the file containing the include statement. The file name
  131. may include shell wildcards (see
  132. .IR sh (1)).
  133. Also, such inclusions can be nested.
  134. .PP
  135. Sections loaded from included files
  136. .I extend
  137. previously loaded sections; already existing values are
  138. .IR replaced .
  139. It is important to note that settings are added relative to the section the
  140. include statement is in.
  141. .PP
  142. As an example, the following three files result in the same final
  143. config as the one given above:
  144. .PP
  145. .EX
  146. a = b
  147. section-one {
  148. somevalue = before include
  149. include include.conf
  150. }
  151. include other.conf
  152. include.conf:
  153. # settings loaded from this file are added to section-one
  154. # the following replaces the previous value
  155. somevalue = asdf
  156. subsection {
  157. othervalue = yyy
  158. }
  159. yetanother = zz
  160. other.conf:
  161. # this extends section-one and subsection
  162. section-one {
  163. subsection {
  164. # this replaces the previous value
  165. othervalue = xxx
  166. }
  167. }
  168. section-two {
  169. x = 12
  170. }
  171. .EE
  172. .SH READING VALUES
  173. Values are accessed using a dot-separated section list and a key.
  174. With reference to the example above, accessing
  175. .B section-one.subsection.othervalue
  176. will return
  177. .BR xxx .
  178. .SH DEFINED KEYS
  179. The following keys are currently defined (using dot notation). The default
  180. value (if any) is listed in brackets after the key.