[svn-upgrade] new version strongswan (4.5.0)

8 files changed, 5406 insertions, 0 deletions

diff --git a/man/Makefile.am b/man/Makefile.am
new file mode 100644
index 000000000..a74a901b8
--- /dev/null
+++ b/man/Makefile.am
@@ -0,0 +1,11 @@
+dist_man_MANS = ipsec.conf.5 ipsec.secrets.5 strongswan.conf.5
+EXTRA_DIST = ipsec.conf.5.in ipsec.secrets.5.in strongswan.conf.5.in
+CLEANFILES = ipsec.conf.5 ipsec.secrets.5 strongswan.conf.5
+
+SUFFIXES = .in
+
+.in:
+	sed \
+	-e "s:@IPSEC_VERSION@:$(PACKAGE_VERSION):" \
+	$(srcdir)/$@.in > $@
+
diff --git a/man/Makefile.in b/man/Makefile.in
new file mode 100644
index 000000000..4388e318b
--- /dev/null
+++ b/man/Makefile.in
@@ -0,0 +1,507 @@
+# Makefile.in generated by automake 1.11.1 from Makefile.am.
+# @configure_input@
+
+# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+# 2003, 2004, 2005, 2006, 2007, 2008, 2009  Free Software Foundation,
+# Inc.
+# This Makefile.in is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+@SET_MAKE@
+VPATH = @srcdir@
+pkgdatadir = $(datadir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkglibexecdir = $(libexecdir)/@PACKAGE@
+am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
+install_sh_DATA = $(install_sh) -c -m 644
+install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
+INSTALL_HEADER = $(INSTALL_DATA)
+transform = $(program_transform_name)
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+build_triplet = @build@
+host_triplet = @host@
+subdir = man
+DIST_COMMON = $(dist_man_MANS) $(srcdir)/Makefile.am \
+	$(srcdir)/Makefile.in
+ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
+am__aclocal_m4_deps = $(top_srcdir)/m4/config/libtool.m4 \
+	$(top_srcdir)/m4/config/ltoptions.m4 \
+	$(top_srcdir)/m4/config/ltsugar.m4 \
+	$(top_srcdir)/m4/config/ltversion.m4 \
+	$(top_srcdir)/m4/config/lt~obsolete.m4 \
+	$(top_srcdir)/m4/macros/with.m4 \
+	$(top_srcdir)/m4/macros/enable-disable.m4 \
+	$(top_srcdir)/m4/macros/add-plugin.m4 \
+	$(top_srcdir)/configure.in
+am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
+	$(ACLOCAL_M4)
+mkinstalldirs = $(install_sh) -d
+CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_VPATH_FILES =
+SOURCES =
+DIST_SOURCES =
+am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
+am__vpath_adj = case $$p in \
+    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
+    *) f=$$p;; \
+  esac;
+am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
+am__install_max = 40
+am__nobase_strip_setup = \
+  srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
+am__nobase_strip = \
+  for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
+am__nobase_list = $(am__nobase_strip_setup); \
+  for p in $$list; do echo "$$p $$p"; done | \
+  sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
+  $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
+    if (++n[$$2] == $(am__install_max)) \
+      { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
+    END { for (dir in files) print dir, files[dir] }'
+am__base_list = \
+  sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
+  sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
+man5dir = $(mandir)/man5
+am__installdirs = "$(DESTDIR)$(man5dir)"
+NROFF = nroff
+MANS = $(dist_man_MANS)
+DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
+ACLOCAL = @ACLOCAL@
+ALLOCA = @ALLOCA@
+AMTAR = @AMTAR@
+AR = @AR@
+AUTOCONF = @AUTOCONF@
+AUTOHEADER = @AUTOHEADER@
+AUTOMAKE = @AUTOMAKE@
+AWK = @AWK@
+BTLIB = @BTLIB@
+CC = @CC@
+CCDEPMODE = @CCDEPMODE@
+CFLAGS = @CFLAGS@
+CPP = @CPP@
+CPPFLAGS = @CPPFLAGS@
+CYGPATH_W = @CYGPATH_W@
+DEFS = @DEFS@
+DEPDIR = @DEPDIR@
+DLLIB = @DLLIB@
+DSYMUTIL = @DSYMUTIL@
+DUMPBIN = @DUMPBIN@
+ECHO_C = @ECHO_C@
+ECHO_N = @ECHO_N@
+ECHO_T = @ECHO_T@
+EGREP = @EGREP@
+EXEEXT = @EXEEXT@
+FGREP = @FGREP@
+GPERF = @GPERF@
+GREP = @GREP@
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_PROGRAM = @INSTALL_PROGRAM@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
+LD = @LD@
+LDFLAGS = @LDFLAGS@
+LEX = @LEX@
+LEXLIB = @LEXLIB@
+LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
+LIBOBJS = @LIBOBJS@
+LIBS = @LIBS@
+LIBTOOL = @LIBTOOL@
+LIPO = @LIPO@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+MKDIR_P = @MKDIR_P@
+MYSQLCFLAG = @MYSQLCFLAG@
+MYSQLCONFIG = @MYSQLCONFIG@
+MYSQLLIB = @MYSQLLIB@
+NM = @NM@
+NMEDIT = @NMEDIT@
+OBJDUMP = @OBJDUMP@
+OBJEXT = @OBJEXT@
+OTOOL = @OTOOL@
+OTOOL64 = @OTOOL64@
+PACKAGE = @PACKAGE@
+PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
+PACKAGE_NAME = @PACKAGE_NAME@
+PACKAGE_STRING = @PACKAGE_STRING@
+PACKAGE_TARNAME = @PACKAGE_TARNAME@
+PACKAGE_URL = @PACKAGE_URL@
+PACKAGE_VERSION = @PACKAGE_VERSION@
+PATH_SEPARATOR = @PATH_SEPARATOR@
+PERL = @PERL@
+PKG_CONFIG = @PKG_CONFIG@
+PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
+PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
+PTHREADLIB = @PTHREADLIB@
+RANLIB = @RANLIB@
+RTLIB = @RTLIB@
+RUBY = @RUBY@
+RUBYINCLUDE = @RUBYINCLUDE@
+SED = @SED@
+SET_MAKE = @SET_MAKE@
+SHELL = @SHELL@
+SOCKLIB = @SOCKLIB@
+STRIP = @STRIP@
+VERSION = @VERSION@
+YACC = @YACC@
+YFLAGS = @YFLAGS@
+abs_builddir = @abs_builddir@
+abs_srcdir = @abs_srcdir@
+abs_top_builddir = @abs_top_builddir@
+abs_top_srcdir = @abs_top_srcdir@
+ac_ct_CC = @ac_ct_CC@
+ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
+am__include = @am__include@
+am__leading_dot = @am__leading_dot@
+am__quote = @am__quote@
+am__tar = @am__tar@
+am__untar = @am__untar@
+bindir = @bindir@
+build = @build@
+build_alias = @build_alias@
+build_cpu = @build_cpu@
+build_os = @build_os@
+build_vendor = @build_vendor@
+builddir = @builddir@
+c_plugins = @c_plugins@
+datadir = @datadir@
+datarootdir = @datarootdir@
+dbusservicedir = @dbusservicedir@
+default_pkcs11 = @default_pkcs11@
+docdir = @docdir@
+dvidir = @dvidir@
+exec_prefix = @exec_prefix@
+gtk_CFLAGS = @gtk_CFLAGS@
+gtk_LIBS = @gtk_LIBS@
+h_plugins = @h_plugins@
+host = @host@
+host_alias = @host_alias@
+host_cpu = @host_cpu@
+host_os = @host_os@
+host_vendor = @host_vendor@
+htmldir = @htmldir@
+includedir = @includedir@
+infodir = @infodir@
+install_sh = @install_sh@
+ipsecdir = @ipsecdir@
+ipsecgid = @ipsecgid@
+ipsecgroup = @ipsecgroup@
+ipsecuid = @ipsecuid@
+ipsecuser = @ipsecuser@
+libcharon_plugins = @libcharon_plugins@
+libdir = @libdir@
+libexecdir = @libexecdir@
+linux_headers = @linux_headers@
+localedir = @localedir@
+localstatedir = @localstatedir@
+lt_ECHO = @lt_ECHO@
+maemo_CFLAGS = @maemo_CFLAGS@
+maemo_LIBS = @maemo_LIBS@
+manager_plugins = @manager_plugins@
+mandir = @mandir@
+medsrv_plugins = @medsrv_plugins@
+mkdir_p = @mkdir_p@
+nm_CFLAGS = @nm_CFLAGS@
+nm_LIBS = @nm_LIBS@
+nm_ca_dir = @nm_ca_dir@
+oldincludedir = @oldincludedir@
+openac_plugins = @openac_plugins@
+p_plugins = @p_plugins@
+pdfdir = @pdfdir@
+piddir = @piddir@
+pki_plugins = @pki_plugins@
+plugindir = @plugindir@
+pluto_plugins = @pluto_plugins@
+pool_plugins = @pool_plugins@
+prefix = @prefix@
+program_transform_name = @program_transform_name@
+psdir = @psdir@
+random_device = @random_device@
+resolv_conf = @resolv_conf@
+routing_table = @routing_table@
+routing_table_prio = @routing_table_prio@
+s_plugins = @s_plugins@
+sbindir = @sbindir@
+scepclient_plugins = @scepclient_plugins@
+scripts_plugins = @scripts_plugins@
+sharedstatedir = @sharedstatedir@
+srcdir = @srcdir@
+strongswan_conf = @strongswan_conf@
+sysconfdir = @sysconfdir@
+target_alias = @target_alias@
+top_build_prefix = @top_build_prefix@
+top_builddir = @top_builddir@
+top_srcdir = @top_srcdir@
+urandom_device = @urandom_device@
+xml_CFLAGS = @xml_CFLAGS@
+xml_LIBS = @xml_LIBS@
+dist_man_MANS = ipsec.conf.5 ipsec.secrets.5 strongswan.conf.5
+EXTRA_DIST = ipsec.conf.5.in ipsec.secrets.5.in strongswan.conf.5.in
+CLEANFILES = ipsec.conf.5 ipsec.secrets.5 strongswan.conf.5
+SUFFIXES = .in
+all: all-am
+
+.SUFFIXES:
+.SUFFIXES: .in
+$(srcdir)/Makefile.in:  $(srcdir)/Makefile.am  $(am__configure_deps)
+	@for dep in $?; do \
+	  case '$(am__configure_deps)' in \
+	    *$$dep*) \
+	      ( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
+	        && { if test -f $@; then exit 0; else break; fi; }; \
+	      exit 1;; \
+	  esac; \
+	done; \
+	echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu man/Makefile'; \
+	$(am__cd) $(top_srcdir) && \
+	  $(AUTOMAKE) --gnu man/Makefile
+.PRECIOUS: Makefile
+Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
+	@case '$?' in \
+	  *config.status*) \
+	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
+	  *) \
+	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
+	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
+	esac;
+
+$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+
+$(top_srcdir)/configure:  $(am__configure_deps)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+$(ACLOCAL_M4):  $(am__aclocal_m4_deps)
+	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+$(am__aclocal_m4_deps):
+
+mostlyclean-libtool:
+	-rm -f *.lo
+
+clean-libtool:
+	-rm -rf .libs _libs
+install-man5: $(dist_man_MANS)
+	@$(NORMAL_INSTALL)
+	test -z "$(man5dir)" || $(MKDIR_P) "$(DESTDIR)$(man5dir)"
+	@list=''; test -n "$(man5dir)" || exit 0; \
+	{ for i in $$list; do echo "$$i"; done; \
+	l2='$(dist_man_MANS)'; for i in $$l2; do echo "$$i"; done | \
+	  sed -n '/\.5[a-z]*$$/p'; \
+	} | while read p; do \
+	  if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
+	  echo "$$d$$p"; echo "$$p"; \
+	done | \
+	sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
+	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \
+	sed 'N;N;s,\n, ,g' | { \
+	list=; while read file base inst; do \
+	  if test "$$base" = "$$inst"; then list="$$list $$file"; else \
+	    echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man5dir)/$$inst'"; \
+	    $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man5dir)/$$inst" || exit $$?; \
+	  fi; \
+	done; \
+	for i in $$list; do echo "$$i"; done | $(am__base_list) | \
+	while read files; do \
+	  test -z "$$files" || { \
+	    echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man5dir)'"; \
+	    $(INSTALL_DATA) $$files "$(DESTDIR)$(man5dir)" || exit $$?; }; \
+	done; }
+
+uninstall-man5:
+	@$(NORMAL_UNINSTALL)
+	@list=''; test -n "$(man5dir)" || exit 0; \
+	files=`{ for i in $$list; do echo "$$i"; done; \
+	l2='$(dist_man_MANS)'; for i in $$l2; do echo "$$i"; done | \
+	  sed -n '/\.5[a-z]*$$/p'; \
+	} | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^5][0-9a-z]*$$,5,;x' \
+	      -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \
+	test -z "$$files" || { \
+	  echo " ( cd '$(DESTDIR)$(man5dir)' && rm -f" $$files ")"; \
+	  cd "$(DESTDIR)$(man5dir)" && rm -f $$files; }
+tags: TAGS
+TAGS:
+
+ctags: CTAGS
+CTAGS:
+
+
+distdir: $(DISTFILES)
+	@list='$(MANS)'; if test -n "$$list"; then \
+	  list=`for p in $$list; do \
+	    if test -f $$p; then d=; else d="$(srcdir)/"; fi; \
+	    if test -f "$$d$$p"; then echo "$$d$$p"; else :; fi; done`; \
+	  if test -n "$$list" && \
+	    grep 'ab help2man is required to generate this page' $$list >/dev/null; then \
+	    echo "error: found man pages containing the \`missing help2man' replacement text:" >&2; \
+	    grep -l 'ab help2man is required to generate this page' $$list | sed 's/^/         /' >&2; \
+	    echo "       to fix them, install help2man, remove and regenerate the man pages;" >&2; \
+	    echo "       typically \`make maintainer-clean' will remove them" >&2; \
+	    exit 1; \
+	  else :; fi; \
+	else :; fi
+	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
+	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
+	list='$(DISTFILES)'; \
+	  dist_files=`for file in $$list; do echo $$file; done | \
+	  sed -e "s|^$$srcdirstrip/||;t" \
+	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
+	case $$dist_files in \
+	  */*) $(MKDIR_P) `echo "$$dist_files" | \
+			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
+			   sort -u` ;; \
+	esac; \
+	for file in $$dist_files; do \
+	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
+	  if test -d $$d/$$file; then \
+	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
+	    if test -d "$(distdir)/$$file"; then \
+	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
+	    fi; \
+	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
+	      cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
+	      find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
+	    fi; \
+	    cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
+	  else \
+	    test -f "$(distdir)/$$file" \
+	    || cp -p $$d/$$file "$(distdir)/$$file" \
+	    || exit 1; \
+	  fi; \
+	done
+check-am: all-am
+check: check-am
+all-am: Makefile $(MANS)
+installdirs:
+	for dir in "$(DESTDIR)$(man5dir)"; do \
+	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
+	done
+install: install-am
+install-exec: install-exec-am
+install-data: install-data-am
+uninstall: uninstall-am
+
+install-am: all-am
+	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
+
+installcheck: installcheck-am
+install-strip:
+	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
+	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
+	  `test -z '$(STRIP)' || \
+	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
+mostlyclean-generic:
+
+clean-generic:
+	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
+
+distclean-generic:
+	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
+	-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
+
+maintainer-clean-generic:
+	@echo "This command is intended for maintainers to use"
+	@echo "it deletes files that may require special tools to rebuild."
+clean: clean-am
+
+clean-am: clean-generic clean-libtool mostlyclean-am
+
+distclean: distclean-am
+	-rm -f Makefile
+distclean-am: clean-am distclean-generic
+
+dvi: dvi-am
+
+dvi-am:
+
+html: html-am
+
+html-am:
+
+info: info-am
+
+info-am:
+
+install-data-am: install-man
+
+install-dvi: install-dvi-am
+
+install-dvi-am:
+
+install-exec-am:
+
+install-html: install-html-am
+
+install-html-am:
+
+install-info: install-info-am
+
+install-info-am:
+
+install-man: install-man5
+
+install-pdf: install-pdf-am
+
+install-pdf-am:
+
+install-ps: install-ps-am
+
+install-ps-am:
+
+installcheck-am:
+
+maintainer-clean: maintainer-clean-am
+	-rm -f Makefile
+maintainer-clean-am: distclean-am maintainer-clean-generic
+
+mostlyclean: mostlyclean-am
+
+mostlyclean-am: mostlyclean-generic mostlyclean-libtool
+
+pdf: pdf-am
+
+pdf-am:
+
+ps: ps-am
+
+ps-am:
+
+uninstall-am: uninstall-man
+
+uninstall-man: uninstall-man5
+
+.MAKE: install-am install-strip
+
+.PHONY: all all-am check check-am clean clean-generic clean-libtool \
+	distclean distclean-generic distclean-libtool distdir dvi \
+	dvi-am html html-am info info-am install install-am \
+	install-data install-data-am install-dvi install-dvi-am \
+	install-exec install-exec-am install-html install-html-am \
+	install-info install-info-am install-man install-man5 \
+	install-pdf install-pdf-am install-ps install-ps-am \
+	install-strip installcheck installcheck-am installdirs \
+	maintainer-clean maintainer-clean-generic mostlyclean \
+	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
+	uninstall uninstall-am uninstall-man uninstall-man5
+
+
+.in:
+	sed \
+	-e "s:@IPSEC_VERSION@:$(PACKAGE_VERSION):" \
+	$(srcdir)/$@.in > $@
+
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/man/ipsec.conf.5 b/man/ipsec.conf.5
new file mode 100644
index 000000000..b1e60b280
--- /dev/null
+++ b/man/ipsec.conf.5
@@ -0,0 +1,1358 @@
+.TH IPSEC.CONF 5 "2010-10-19" "4.5.0rc2" "strongSwan"
+.SH NAME
+ipsec.conf \- IPsec configuration and connections
+.SH DESCRIPTION
+The optional
+.I ipsec.conf
+file
+specifies most configuration and control information for the
+strongSwan IPsec subsystem.
+The major exception is secrets for authentication;
+see
+.IR ipsec.secrets (5).
+Its contents are not security-sensitive.
+.PP
+The file is a text file, consisting of one or more
+.IR sections .
+White space followed by
+.B #
+followed by anything to the end of the line
+is a comment and is ignored,
+as are empty lines which are not within a section.
+.PP
+A line which contains
+.B include
+and a file name, separated by white space,
+is replaced by the contents of that file,
+preceded and followed by empty lines.
+If the file name is not a full pathname,
+it is considered to be relative to the directory containing the
+including file.
+Such inclusions can be nested.
+Only a single filename may be supplied, and it may not contain white space,
+but it may include shell wildcards (see
+.IR sh (1));
+for example:
+.PP
+.B include
+.B "ipsec.*.conf"
+.PP
+The intention of the include facility is mostly to permit keeping
+information on connections, or sets of connections,
+separate from the main configuration file.
+This permits such connection descriptions to be changed,
+copied to the other security gateways involved, etc.,
+without having to constantly extract them from the configuration
+file and then insert them back into it.
+Note also the
+.B also
+parameter (described below) which permits splitting a single logical
+section (e.g. a connection description) into several actual sections.
+.PP
+A section
+begins with a line of the form:
+.PP
+.I type
+.I name
+.PP
+where
+.I type
+indicates what type of section follows, and
+.I name
+is an arbitrary name which distinguishes the section from others
+of the same type.
+Names must start with a letter and may contain only
+letters, digits, periods, underscores, and hyphens.
+All subsequent non-empty lines
+which begin with white space are part of the section;
+comments within a section must begin with white space too.
+There may be only one section of a given type with a given name.
+.PP
+Lines within the section are generally of the form
+.PP
+\ \ \ \ \ \fIparameter\fB=\fIvalue\fR
+.PP
+(note the mandatory preceding white space).
+There can be white space on either side of the
+.BR = .
+Parameter names follow the same syntax as section names,
+and are specific to a section type.
+Unless otherwise explicitly specified,
+no parameter name may appear more than once in a section.
+.PP
+An empty
+.I value
+stands for the system default value (if any) of the parameter,
+i.e. it is roughly equivalent to omitting the parameter line entirely.
+A
+.I value
+may contain white space only if the entire
+.I value
+is enclosed in double quotes (\fB"\fR);
+a
+.I value
+cannot itself contain a double quote,
+nor may it be continued across more than one line.
+.PP
+Numeric values are specified to be either an ``integer''
+(a sequence of digits) or a ``decimal number''
+(sequence of digits optionally followed by `.' and another sequence of digits).
+.PP
+There is currently one parameter which is available in any type of
+section:
+.TP
+.B also
+the value is a section name;
+the parameters of that section are appended to this section,
+as if they had been written as part of it.
+The specified section must exist, must follow the current one,
+and must have the same section type.
+(Nesting is permitted,
+and there may be more than one
+.B also
+in a single section,
+although it is forbidden to append the same section more than once.)
+.PP
+A section with name
+.B %default
+specifies defaults for sections of the same type.
+For each parameter in it,
+any section of that type which does not have a parameter of the same name
+gets a copy of the one from the
+.B %default
+section.
+There may be multiple
+.B %default
+sections of a given type,
+but only one default may be supplied for any specific parameter name,
+and all
+.B %default
+sections of a given type must precede all non-\c
+.B %default
+sections of that type.
+.B %default
+sections may not contain the
+.B also
+parameter.
+.PP
+Currently there are three types of sections:
+a
+.B config
+section specifies general configuration information for IPsec, a
+.B conn
+section specifies an IPsec connection, while a
+.B ca
+section specifies special properties of a certification authority.
+.SH "CONN SECTIONS"
+A
+.B conn
+section contains a
+.IR "connection specification" ,
+defining a network connection to be made using IPsec.
+The name given is arbitrary, and is used to identify the connection.
+Here's a simple example:
+.PP
+.ne 10
+.nf
+.ft B
+.ta 1c
+conn snt
+	left=192.168.0.1
+	leftsubnet=10.1.0.0/16
+	right=192.168.0.2
+	rightsubnet=10.1.0.0/16
+	keyingtries=%forever
+	auto=add
+.ft
+.fi
+.PP
+A note on terminology: There are two kinds of communications going on:
+transmission of user IP packets, and gateway-to-gateway negotiations for
+keying, rekeying, and general control.
+The path to control the connection is called 'ISAKMP SA' in IKEv1
+and 'IKE SA' in the IKEv2 protocol. That what is being negotiated, the kernel
+level data path, is called 'IPsec SA' or 'Child SA'.
+strongSwan currently uses two separate keying daemons. \fIpluto\fP handles
+all IKEv1 connections, \fIcharon\fP is the daemon handling the IKEv2
+protocol.
+.PP
+To avoid trivial editing of the configuration file to suit it to each system
+involved in a connection,
+connection specifications are written in terms of
+.I left
+and
+.I right
+participants,
+rather than in terms of local and remote.
+Which participant is considered
+.I left
+or
+.I right
+is arbitrary;
+for every connection description an attempt is made to figure out whether
+the local endpoint should act as the
+.I left
+or
+.I right
+endpoint. This is done by matching the IP addresses defined for both endpoints
+with the IP addresses assigned to local network interfaces. If a match is found
+then the role (left or right) that matches is going to be considered local.
+If no match is found during startup,
+.I left
+is considered local.
+This permits using identical connection specifications on both ends.
+There are cases where there is no symmetry; a good convention is to
+use
+.I left
+for the local side and
+.I right
+for the remote side (the first letters are a good mnemonic).
+.PP
+Many of the parameters relate to one participant or the other;
+only the ones for
+.I left
+are listed here, but every parameter whose name begins with
+.B left
+has a
+.B right
+counterpart,
+whose description is the same but with
+.B left
+and
+.B right
+reversed.
+.PP
+Parameters are optional unless marked '(required)'.
+.SS "CONN PARAMETERS"
+Unless otherwise noted, for a connection to work,
+in general it is necessary for the two ends to agree exactly
+on the values of these parameters.
+.TP
+.BR aaa_identity " = <id>"
+defines the identity of the AAA backend used during IKEv2 EAP authentication.
+This is required if the EAP client uses a method that verifies the server
+identity (such as EAP-TLS), but it does not match the IKEv2 gateway identity.
+.TP
+.BR also " = <name>"
+includes conn section
+.BR <name> .
+.TP
+.BR auth " = " esp " | ah"
+whether authentication should be done as part of
+ESP encryption, or separately using the AH protocol;
+acceptable values are
+.B esp
+(the default) and
+.BR ah .
+.br
+The IKEv2 daemon currently supports ESP only.
+.TP
+.BR authby " = " pubkey " | rsasig | ecdsasig | psk | eap | never | xauth..."
+how the two security gateways should authenticate each other;
+acceptable values are
+.B psk
+or
+.B secret
+for pre-shared secrets,
+.B pubkey
+(the default) for public key signatures as well as the synonyms
+.B rsasig
+for RSA digital signatures and
+.B ecdsasig
+for Elliptic Curve DSA signatures.
+.B never
+can be used if negotiation is never to be attempted or accepted (useful for
+shunt-only conns).
+Digital signatures are superior in every way to shared secrets.
+IKEv1 additionally supports the values
+.B xauthpsk
+and
+.B xauthrsasig
+that will enable eXtended AUTHentication (XAUTH) in addition to IKEv1 main mode
+based on shared secrets  or digital RSA signatures, respectively.
+IKEv2 additionally supports the value
+.BR eap ,
+which indicates an initiator to request EAP authentication. The EAP method
+to use is selected by the server (see
+.BR eap ).
+This parameter is deprecated for IKEv2 connections, as two peers do not need
+to agree on an authentication method. Use the
+.B leftauth
+parameter instead to define authentication methods in IKEv2.
+.TP
+.BR auto " = " ignore " | add | route | start"
+what operation, if any, should be done automatically at IPsec startup;
+currently-accepted values are
+.BR add ,
+.BR route ,
+.B start
+and
+.B ignore
+(the default).
+.B add
+loads a connection without starting it.
+.B route
+loads a connection and installs kernel traps. If traffic is detected between
+.B leftsubnet
+and
+.B rightsubnet
+, a connection is established.
+.B start
+loads a connection and brings it up immediatly.
+.B ignore
+ignores the connection. This is equal to delete a connection from the config
+file.
+Relevant only locally, other end need not agree on it
+(but in general, for an intended-to-be-permanent connection,
+both ends should use
+.B auto=start
+to ensure that any reboot causes immediate renegotiation).
+.TP
+.BR compress " = yes | " no
+whether IPComp compression of content is proposed on the connection
+(link-level compression does not work on encrypted data,
+so to be effective, compression must be done \fIbefore\fR encryption);
+acceptable values are
+.B yes
+and
+.B no
+(the default). A value of
+.B yes
+causes IPsec to propose both compressed and uncompressed,
+and prefer compressed.
+A value of
+.B no
+prevents IPsec from proposing compression;
+a proposal to compress will still be accepted.
+.TP
+.BR dpdaction " = " none " | clear | hold | restart"
+controls the use of the Dead Peer Detection protocol (DPD, RFC 3706) where
+R_U_THERE notification messages (IKEv1) or empty INFORMATIONAL messages (IKEv2)
+are periodically sent in order to check the
+liveliness of the IPsec peer. The values
+.BR clear ,
+.BR hold ,
+and
+.B restart
+all activate DPD. If no activity is detected, all connections with a dead peer
+are stopped and unrouted
+.RB ( clear ),
+put in the hold state
+.RB ( hold )
+or restarted
+.RB ( restart ).
+For IKEv1, the default is
+.B none
+which disables the active sending of R_U_THERE notifications.
+Nevertheless pluto will always send the DPD Vendor ID during connection set up
+in order to signal the readiness to act passively as a responder if the peer
+wants to use DPD. For IKEv2,
+.B none
+does't make sense, since all messages are used to detect dead peers. If specified,
+it has the same meaning as the default
+.RB ( clear ).
+.TP
+.BR dpddelay " = " 30s " | <time>"
+defines the period time interval with which R_U_THERE messages/INFORMATIONAL
+exchanges are sent to the peer. These are only sent if no other traffic is
+received. In IKEv2, a value of 0 sends no additional INFORMATIONAL
+messages and uses only standard messages (such as those to rekey) to detect
+dead peers.
+.TP
+.BR dpdtimeout " = " 150s " | <time>"
+defines the timeout interval, after which all connections to a peer are deleted
+in case of inactivity. This only applies to IKEv1, in IKEv2 the default
+retransmission timeout applies, as every exchange is used to detect dead peers.
+See
+.IR strongswan.conf (5)
+for a description of the IKEv2 retransmission timeout.
+.TP
+.BR inactivity " = <time>"
+defines the timeout interval, after which a CHILD_SA is closed if it did
+not send or receive any traffic. Currently supported in IKEv2 connections only.
+.TP
+.BR eap " = md5 | mschapv2 | radius | ... | <type> | <type>-<vendor>
+defines the EAP type to propose as server if the client requests EAP
+authentication. Currently supported values are
+.B aka
+for EAP-AKA,
+.B gtc
+for EAP-GTC,
+.B md5
+for EAP-MD5,
+.B mschapv2
+for EAP-MS-CHAPv2,
+.B radius
+for the EAP-RADIUS proxy and
+.B sim
+for EAP-SIM. Additionally, IANA assigned EAP method numbers are accepted, or a
+definition in the form
+.B eap=type-vendor
+(e.g. eap=7-12345) can be used to specify vendor specific EAP types.
+This parameter is deprecated in the favour of
+.B leftauth.
+
+To forward EAP authentication to a RADIUS server using the EAP-RADIUS plugin,
+set
+.BR eap=radius .
+.TP
+.BR eap_identity " = <id>"
+defines the identity the client uses to reply to a EAP Identity request.
+If defined on the EAP server, the defined identity will be used as peer
+identity during EAP authentication. The special value
+.B %identity
+uses the EAP Identity method to ask the client for an EAP identity. If not
+defined, the IKEv2 identity will be used as EAP identity.
+.TP
+.BR esp " = <cipher suites>"
+comma-separated list of ESP encryption/authentication algorithms to be used
+for the connection, e.g.
+.BR aes128-sha256 .
+The notation is
+.BR encryption-integrity-[dh-group] .
+.br
+If
+.B dh-group
+is specified, CHILD_SA setup and rekeying include a separate diffe hellman
+exchange (IKEv2 only).
+.TP
+.BR forceencaps " = yes | " no
+force UDP encapsulation for ESP packets even if no NAT situation is detected.
+This may help to surmount restrictive firewalls. In order to force the peer to
+encapsulate packets, NAT detection payloads are faked (IKEv2 only).
+.TP
+.BR ike " = <cipher suites>"
+comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms
+to be used, e.g.
+.BR aes128-sha1-modp2048 .
+The notation is
+.BR encryption-integrity-dhgroup .
+In IKEv2, multiple algorithms and proposals may be included, such as
+.B aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024.
+.TP
+.BR ikelifetime " = " 3h " | <time>"
+how long the keying channel of a connection (ISAKMP or IKE SA)
+should last before being renegotiated. Also see EXPIRY/REKEY below.
+.TP
+.BR installpolicy " = " yes " | no"
+decides whether IPsec policies are installed in the kernel by the IKEv2
+charon daemon for a given connection. Allows peaceful cooperation e.g. with
+the Mobile IPv6 daemon mip6d who wants to control the kernel policies.
+Acceptable values are
+.B yes
+(the default) and
+.BR no .
+.TP
+.BR keyexchange " = " ike " | ikev1 | ikev2"
+method of key exchange;
+which protocol should be used to initialize the connection. Connections marked with
+.B ikev1
+are initiated with pluto, those marked with
+.B ikev2
+with charon. An incoming request from the remote peer is handled by the correct
+daemon, unaffected from the
+.B keyexchange
+setting. Starting with strongSwan 4.5 the default value
+.B ike
+is a synonym for
+.BR ikev2 ,
+whereas in older strongSwan releases
+.B ikev1
+was assumed.
+.TP
+.BR keyingtries " = " %forever " | <number>"
+how many attempts (a whole number or \fB%forever\fP) should be made to
+negotiate a connection, or a replacement for one, before giving up
+(default
+.BR %forever ).
+The value \fB%forever\fP
+means 'never give up'.
+Relevant only locally, other end need not agree on it.
+.TP
+.B keylife
+synonym for
+.BR lifetime .
+.TP
+.BR left " = <ip address> | <fqdn> | %defaultroute | " %any
+(required)
+the IP address of the left participant's public-network interface
+or one of several magic values.
+If it is
+.BR %defaultroute ,
+.B left
+will be filled in automatically with the local address
+of the default-route interface (as determined at IPsec startup time and
+during configuration update).
+Either
+.B left
+or
+.B right
+may be
+.BR %defaultroute ,
+but not both.
+The prefix
+.B  %
+in front of a fully-qualified domain name or an IP address will implicitly set
+.B leftallowany=yes.
+If the domain name cannot be resolved into an IP address at IPsec startup or
+update time then
+.B left=%any
+and
+.B leftallowany=no
+will be assumed.
+
+In case of an IKEv2 connection, the value
+.B %any
+for the local endpoint signifies an address to be filled in (by automatic
+keying) during negotiation. If the local peer initiates the connection setup
+the routing table will be queried to determine the correct local IP address.
+In case the local peer is responding to a connection setup then any IP address
+that is assigned to a local interface will be accepted.
+.br
+Note that specifying
+.B %any
+for the local endpoint is not supported by the IKEv1 pluto daemon.
+
+If
+.B %any
+is used for the remote endpoint it literally means any IP address.
+
+Please note that with the usage of wildcards multiple connection descriptions
+might match a given incoming connection attempt. The most specific description
+is used in that case.
+.TP
+.BR leftallowany " = yes | " no
+a modifier for
+.B left
+, making it behave as
+.B %any
+although a concrete IP address has been assigned.
+Recommended for dynamic IP addresses that can be resolved by DynDNS at IPsec
+startup or update time.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR leftauth " = <auth method>"
+Authentication method to use locally (left) or require from the remote (right)
+side.
+This parameter is supported in IKEv2 only. Acceptable values are
+.B pubkey
+for public key authentication (RSA/ECDSA),
+.B psk
+for pre-shared key authentication and
+.B eap
+to (require the) use of the Extensible Authentication Protocol. In the case
+of
+.B eap,
+an optional EAP method can be appended. Currently defined methods are
+.BR eap-aka ,
+.BR eap-gtc ,
+.BR eap-md5 ,
+.BR eap-tls ,
+.B eap-mschapv2
+and
+.BR eap-sim .
+Alternatively, IANA assigned EAP method numbers are accepted. Vendor specific
+EAP methods are defined in the form
+.B eap-type-vendor
+.RB "(e.g. " eap-7-12345 ).
+.TP
+.BR leftauth2 " = <auth method>"
+Same as
+.BR leftauth ,
+but defines an additional authentication exchange. IKEv2 supports multiple
+authentication rounds using "Multiple Authentication Exchanges" defined
+in RFC4739. This allows, for example, separated authentication
+of host and user (IKEv2 only).
+.TP
+.BR leftca " = <issuer dn> | %same"
+the distinguished name of a certificate authority which is required to
+lie in the trust path going from the left participant's certificate up
+to the root certification authority.
+.TP
+.BR leftca2 " = <issuer dn> | %same"
+Same as
+.BR leftca ,
+but for the second authentication round (IKEv2 only).
+.TP
+.BR leftcert " = <path>"
+the path to the left participant's X.509 certificate. The file can be encoded
+either in PEM or DER format. OpenPGP certificates are supported as well.
+Both absolute paths or paths relative to \fI/etc/ipsec.d/certs\fP
+are accepted. By default
+.B leftcert
+sets
+.B leftid
+to the distinguished name of the certificate's subject and
+.B leftca
+to the distinguished name of the certificate's issuer.
+The left participant's ID can be overriden by specifying a
+.B leftid
+value which must be certified by the certificate, though.
+.TP
+.BR leftcert2 " = <path>"
+Same as
+.B leftcert,
+but for the second authentication round (IKEv2 only).
+.TP
+.BR leftfirewall " = yes | " no
+whether the left participant is doing forwarding-firewalling
+(including masquerading) using iptables for traffic from \fIleftsubnet\fR,
+which should be turned off (for traffic to the other subnet)
+once the connection is established;
+acceptable values are
+.B yes
+and
+.B no
+(the default).
+May not be used in the same connection description with
+.BR leftupdown .
+Implemented as a parameter to the default \fBipsec _updown\fR script.
+See notes below.
+Relevant only locally, other end need not agree on it.
+
+If one or both security gateways are doing forwarding firewalling
+(possibly including masquerading),
+and this is specified using the firewall parameters,
+tunnels established with IPsec are exempted from it
+so that packets can flow unchanged through the tunnels.
+(This means that all subnets connected in this manner must have
+distinct, non-overlapping subnet address blocks.)
+This is done by the default \fBipsec _updown\fR script (see
+.IR pluto (8)).
+
+In situations calling for more control,
+it may be preferable for the user to supply his own
+.I updown
+script,
+which makes the appropriate adjustments for his system.
+.TP
+.BR leftgroups " = <group list>"
+a comma separated list of group names. If the
+.B leftgroups
+parameter is present then the peer must be a member of at least one
+of the groups defined by the parameter. Group membership must be certified
+by a valid attribute certificate stored in \fI/etc/ipsec.d/acerts/\fP thas has
+been issued to the peer by a trusted Authorization Authority stored in
+\fI/etc/ipsec.d/aacerts/\fP.
+.br
+Attribute certificates are not supported in IKEv2 yet.
+.TP
+.BR lefthostaccess " = yes | " no
+inserts a pair of INPUT and OUTPUT iptables rules using the default
+\fBipsec _updown\fR script, thus allowing access to the host itself
+in the case where the host's internal interface is part of the
+negotiated client subnet.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR leftid " = <id>"
+how the left participant should be identified for authentication;
+defaults to
+.BR left .
+Can be an IP address or a fully-qualified domain name preceded by
+.B @
+(which is used as a literal string and not resolved).
+.TP
+.BR leftid2 " = <id>"
+identity to use for a second authentication for the left participant
+(IKEv2 only); defaults to
+.BR leftid .
+.TP
+.BR leftikeport " = <port>"
+UDP port the left participant uses for IKE communication. Currently supported in
+IKEv2 connections only. If unspecified, port 500 is used with the port floating
+to 4500 if a NAT is detected or MOBIKE is enabled. Specifying a local IKE port
+different from the default additionally requires a socket implementation that
+listens to this port.
+.TP
+.BR leftnexthop " = %direct | %defaultroute | <ip address> | <fqdn>"
+this parameter is usually not needed any more because the NETKEY IPsec stack
+does not require explicit routing entries for the traffic to be tunneled. If
+.B leftsourceip
+is used with IKEv1 then
+.B leftnexthop
+must still be set in order for the source routes to work properly.
+.TP
+.BR leftprotoport " = <protocol>/<port>"
+restrict the traffic selector to a single protocol and/or port.
+Examples:
+.B leftprotoport=tcp/http
+or
+.B leftprotoport=6/80
+or
+.B leftprotoport=udp
+.TP
+.BR leftrsasigkey " = " %cert " | <raw rsa public key>"
+the left participant's
+public key for RSA signature authentication,
+in RFC 2537 format using
+.IR ttodata (3)
+encoding.
+The magic value
+.B %none
+means the same as not specifying a value (useful to override a default).
+The value
+.B %cert
+(the default)
+means that the key is extracted from a certificate.
+The identity used for the left participant
+must be a specific host, not
+.B %any
+or another magic value.
+.B Caution:
+if two connection descriptions
+specify different public keys for the same
+.BR leftid ,
+confusion and madness will ensue.
+.TP
+.BR leftsendcert " = never | no | " ifasked " | always | yes"
+Accepted values are
+.B never
+or
+.BR no ,
+.B always
+or
+.BR yes ,
+and
+.BR ifasked " (the default),"
+the latter meaning that the peer must send a certificate request payload in
+order to get a certificate in return.
+.TP
+.BR leftsourceip " = %config | %cfg | %modeconfig | %modecfg | <ip address>"
+The internal source IP to use in a tunnel, also known as virtual IP. If the
+value is one of the synonyms
+.BR %config ,
+.BR %cfg ,
+.BR %modeconfig ,
+or
+.BR %modecfg ,
+an address is requested from the peer. In IKEv2, a statically defined address
+is also requested, since the server may change it.
+.TP
+.BR rightsourceip " = %config | <network>/<netmask> | %poolname"
+The internal source IP to use in a tunnel for the remote peer. If the
+value is
+.B %config
+on the responder side, the initiator must propose an address which is then
+echoed back. Also supported are address pools expressed as
+\fInetwork\fB/\fInetmask\fR
+or the use of an external IP address pool using %\fIpoolname\fR,
+where \fIpoolname\fR is the name of the IP address pool used for the lookup.
+.TP
+.BR leftsubnet " = <ip subnet>"
+private subnet behind the left participant, expressed as
+\fInetwork\fB/\fInetmask\fR;
+if omitted, essentially assumed to be \fIleft\fB/32\fR,
+signifying that the left end of the connection goes to the left participant
+only. When using IKEv2, the configured subnet of the peers may differ, the
+protocol narrows it to the greatest common subnet. Further, IKEv2 supports
+multiple subnets separated by commas. IKEv1 only interprets the first subnet
+of such a definition.
+.TP
+.BR leftsubnetwithin " = <ip subnet>"
+the peer can propose any subnet or single IP address that fits within the
+range defined by
+.BR leftsubnetwithin.
+Not relevant for IKEv2, as subnets are narrowed.
+.TP
+.BR leftupdown " = <path>"
+what ``updown'' script to run to adjust routing and/or firewalling
+when the status of the connection
+changes (default
+.BR "ipsec _updown" ).
+May include positional parameters separated by white space
+(although this requires enclosing the whole string in quotes);
+including shell metacharacters is unwise.
+See
+.IR pluto (8)
+for details.
+Relevant only locally, other end need not agree on it. IKEv2 uses the updown
+script to insert firewall rules only, since routing has been implemented
+directly into charon.
+.TP
+.BR lifebytes " = <number>"
+the number of bytes transmitted over an IPsec SA before it expires (IKEv2
+only).
+.TP
+.BR lifepackets " = <number>"
+the number of packets transmitted over an IPsec SA before it expires (IKEv2
+only).
+.TP
+.BR lifetime " = " 1h " | <time>"
+how long a particular instance of a connection
+(a set of encryption/authentication keys for user packets) should last,
+from successful negotiation to expiry;
+acceptable values are an integer optionally followed by
+.BR s
+(a time in seconds)
+or a decimal number followed by
+.BR m ,
+.BR h ,
+or
+.B d
+(a time
+in minutes, hours, or days respectively)
+(default
+.BR 1h ,
+maximum
+.BR 24h ).
+Normally, the connection is renegotiated (via the keying channel)
+before it expires (see
+.BR margintime ).
+The two ends need not exactly agree on
+.BR lifetime ,
+although if they do not,
+there will be some clutter of superseded connections on the end
+which thinks the lifetime is longer. Also see EXPIRY/REKEY below.
+.TP
+.BR marginbytes " = <number>"
+how many bytes before IPsec SA expiry (see
+.BR lifebytes )
+should attempts to negotiate a replacement begin (IKEv2 only).
+.TP
+.BR marginpackets " = <number>"
+how many packets before IPsec SA expiry (see
+.BR lifepackets )
+should attempts to negotiate a replacement begin (IKEv2 only).
+.TP
+.BR margintime " = " 9m " | <time>"
+how long before connection expiry or keying-channel expiry
+should attempts to
+negotiate a replacement
+begin; acceptable values as for
+.B lifetime
+(default
+.BR 9m ).
+Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY
+below.
+.TP
+.BR mark " = <value>[/<mask>]"
+sets an XFRM mark in the inbound and outbound
+IPsec SAs and policies. If the mask is missing then a default
+mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mark_in " = <value>[/<mask>]"
+sets an XFRM mark in the inbound IPsec SA and
+policy. If the mask is missing then a default mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mark_out " = <value>[/<mask>]"
+sets an XFRM mark in the outbound IPsec SA and
+policy. If the mask is missing then a default mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mobike " = " yes " | no"
+enables the IKEv2 MOBIKE protocol defined by RFC 4555. Accepted values are
+.B yes
+(the default) and
+.BR no .
+If set to
+.BR no ,
+the IKEv2 charon daemon will not actively propose MOBIKE as initiator and
+ignore the MOBIKE_SUPPORTED notify as responder.
+.TP
+.BR modeconfig " = push | " pull
+defines which mode is used to assign a virtual IP.
+Accepted values are
+.B push
+and
+.B pull
+(the default).
+Currently relevant for IKEv1 only since IKEv2 always uses the configuration
+payload in pull mode. Cisco VPN gateways usually operate in
+.B push
+mode.
+.TP
+.BR pfs " = " yes " | no"
+whether Perfect Forward Secrecy of keys is desired on the connection's
+keying channel
+(with PFS, penetration of the key-exchange protocol
+does not compromise keys negotiated earlier);
+acceptable values are
+.B yes
+(the default)
+and
+.BR no.
+IKEv2 always uses PFS for IKE_SA rekeying whereas for CHILD_SA rekeying
+PFS is enforced by defining a Diffie-Hellman modp group in the
+.B esp
+parameter.
+.TP
+.BR pfsgroup " = <modp group>"
+defines a Diffie-Hellman group for perfect forward secrecy in IKEv1 Quick Mode
+differing from the DH group used for IKEv1 Main Mode (IKEv1 only).
+.TP
+.BR reauth " = " yes " | no"
+whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1,
+reauthentication is always done. In IKEv2, a value of
+.B no
+rekeys without uninstalling the IPsec SAs, a value of
+.B yes
+(the default) creates a new IKE_SA from scratch and tries to recreate
+all IPsec SAs.
+.TP
+.BR rekey " = " yes " | no"
+whether a connection should be renegotiated when it is about to expire;
+acceptable values are
+.B yes
+(the default)
+and
+.BR no .
+The two ends need not agree, but while a value of
+.B no
+prevents pluto/charon from requesting renegotiation,
+it does not prevent responding to renegotiation requested from the other end,
+so
+.B no
+will be largely ineffective unless both ends agree on it.
+.TP
+.BR rekeyfuzz " = " 100% " | <percentage>"
+maximum percentage by which
+.BR marginbytes ,
+.B marginpackets
+and
+.B margintime
+should be randomly increased to randomize rekeying intervals
+(important for hosts with many connections);
+acceptable values are an integer,
+which may exceed 100,
+followed by a `%'
+(defaults to
+.BR 100% ).
+The value of
+.BR marginTYPE ,
+after this random increase,
+must not exceed
+.B lifeTYPE
+(where TYPE is one of
+.IR bytes ,
+.I packets
+or
+.IR time ).
+The value
+.B 0%
+will suppress randomization.
+Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY
+below.
+.TP
+.B rekeymargin
+synonym for
+.BR margintime .
+.TP
+.BR reqid " = <number>"
+sets the reqid for a given connection to a pre-configured fixed value.
+.TP
+.BR type " = " tunnel " | transport | transport_proxy | passthrough | drop"
+the type of the connection; currently the accepted values
+are
+.B tunnel
+(the default)
+signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel;
+.BR transport ,
+signifying host-to-host transport mode;
+.BR transport_proxy ,
+signifying the special Mobile IPv6 transport proxy mode;
+.BR passthrough ,
+signifying that no IPsec processing should be done at all;
+.BR drop ,
+signifying that packets should be discarded; and
+.BR reject ,
+signifying that packets should be discarded and a diagnostic ICMP returned
+.RB ( reject
+is currently not supported by the NETKEY stack of the Linux 2.6 kernel).
+The IKEv2 daemon charon currently supports
+.BR tunnel ,
+.BR transport ,
+and
+.BR transport_proxy
+connection types, only.
+.TP
+.BR xauth " = " client " | server"
+specifies the role in the XAUTH protocol if activated by
+.B authby=xauthpsk
+or
+.B authby=xauthrsasig.
+Accepted values are
+.B server
+and
+.B client
+(the default).
+
+.SS "CONN PARAMETERS: IKEv2 MEDIATION EXTENSION"
+The following parameters are relevant to IKEv2 Mediation Extension
+operation only.
+.TP
+.BR mediation " = yes | " no
+whether this connection is a mediation connection, ie. whether this
+connection is used to mediate other connections.  Mediation connections
+create no child SA. Acceptable values are
+.B no
+(the default) and
+.BR yes .
+.TP
+.BR mediated_by " = <name>"
+the name of the connection to mediate this connection through.  If given,
+the connection will be mediated through the named mediation connection.
+The mediation connection must set
+.BR mediation=yes .
+.TP
+.BR me_peerid " = <id>"
+ID as which the peer is known to the mediation server, ie. which the other
+end of this connection uses as its
+.B leftid
+on its connection to the mediation server.  This is the ID we request the
+mediation server to mediate us with.  If
+.B me_peerid
+is not given, the
+.B rightid
+of this connection will be used as peer ID.
+
+.SH "CA SECTIONS"
+This are optional sections that can be used to assign special
+parameters to a Certification Authority (CA).
+.TP
+.BR also " = <name>"
+includes ca section
+.BR <name> .
+.TP
+.BR auto " = " ignore " | add"
+currently can have either the value
+.B ignore
+(the default) or
+.BR add .
+.TP
+.BR cacert " = <path>"
+defines a path to the CA certificate either relative to
+\fI/etc/ipsec.d/cacerts\fP or as an absolute path.
+.TP
+.BR crluri " = <uri>"
+defines a CRL distribution point (ldap, http, or file URI)
+.TP
+.B crluri1
+synonym for
+.B crluri.
+.TP
+.BR crluri2 " = <uri>"
+defines an alternative CRL distribution point (ldap, http, or file URI)
+.TP
+.BR ldaphost " = <hostname>"
+defines an ldap host. Currently used by IKEv1 only.
+.TP
+.BR ocspuri " = <uri>"
+defines an OCSP URI.
+.TP
+.B ocspuri1
+synonym for
+.B ocspuri.
+.TP
+.BR ocspuri2 " = <uri>"
+defines an alternative OCSP URI. Currently used by IKEv2 only.
+.TP
+.BR certuribase " = <uri>"
+defines the base URI for the Hash and URL feature supported by IKEv2.
+Instead of exchanging complete certificates, IKEv2 allows to send an URI
+that resolves to the DER encoded certificate. The certificate URIs are built
+by appending the SHA1 hash of the DER encoded certificates to this base URI.
+.SH "CONFIG SECTIONS"
+At present, the only
+.B config
+section known to the IPsec software is the one named
+.BR setup ,
+which contains information used when the software is being started.
+Here's an example:
+.PP
+.ne 8
+.nf
+.ft B
+.ta 1c
+config setup
+	plutodebug=all
+	crlcheckinterval=10m
+	strictcrlpolicy=yes
+.ft
+.fi
+.PP
+Parameters are optional unless marked ``(required)''.
+The currently-accepted
+.I parameter
+names in a
+.B config
+.B setup
+section affecting both daemons are:
+.TP
+.BR cachecrls " = yes | " no
+certificate revocation lists (CRLs) fetched via http or ldap will be cached in
+\fI/etc/ipsec.d/crls/\fR under a unique file name derived from the certification
+authority's public key.
+Accepted values are
+.B yes
+and
+.B no
+(the default). Only relevant for IKEv1, as CRLs are always cached in IKEv2.
+.TP
+.BR charonstart " = " yes " | no"
+whether to start the IKEv2 charon daemon or not.
+The default is
+.B yes
+if starter was compiled with IKEv2 support.
+.TP
+.BR plutostart " = " yes " | no"
+whether to start the IKEv1 pluto daemon or not.
+The default is
+.B yes
+if starter was compiled with IKEv1 support.
+.TP
+.BR strictcrlpolicy " = yes | ifuri | " no
+defines if a fresh CRL must be available in order for the peer authentication
+based on RSA signatures to succeed.
+IKEv2 additionally recognizes
+.B ifuri
+which reverts to
+.B yes
+if at least one CRL URI is defined and to
+.B no
+if no URI is known.
+.TP
+.BR uniqueids " = " yes " | no | replace | keep"
+whether a particular participant ID should be kept unique,
+with any new (automatically keyed)
+connection using an ID from a different IP address
+deemed to replace all old ones using that ID;
+acceptable values are
+.B yes
+(the default)
+and
+.BR no .
+Participant IDs normally \fIare\fR unique,
+so a new (automatically-keyed) connection using the same ID is
+almost invariably intended to replace an old one.
+The IKEv2 daemon also accepts the value
+.B replace
+wich is identical to
+.B yes
+and the value
+.B keep
+to reject new IKE_SA setups and keep the duplicate established earlier.
+.PP
+The following
+.B config section
+parameters are used by the IKEv1 Pluto daemon only:
+.TP
+.BR crlcheckinterval " = " 0s " | <time>"
+interval in seconds. CRL fetching is enabled if the value is greater than zero.
+Asynchronous, periodic checking for fresh CRLs is currently done by the
+IKEv1 Pluto daemon only.
+.TP
+.BR keep_alive " = " 20s " | <time>"
+interval in seconds between NAT keep alive packets, the default being 20 seconds.
+.TP
+.BR nat_traversal " = yes | " no
+activates NAT traversal by accepting source ISAKMP ports different from udp/500 and
+being able of floating to udp/4500 if a NAT situation is detected.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+Used by IKEv1 only, NAT traversal is always being active in IKEv2.
+.TP
+.BR nocrsend " = yes | " no
+no certificate request payloads will be sent.
+.TP
+.BR pkcs11initargs " = <args>"
+non-standard argument string for PKCS#11 C_Initialize() function;
+required by NSS softoken.
+.TP
+.BR pkcs11module " = <args>"
+defines the path to a dynamically loadable PKCS #11 library.
+.TP
+.BR pkcs11keepstate " = yes | " no
+PKCS #11 login sessions will be kept during the whole lifetime of the keying
+daemon. Useful with pin-pad smart card readers.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR pkcs11proxy " = yes | " no
+Pluto will act as a PKCS #11 proxy accessible via the whack interface.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR plutodebug " = " none " | <debug list> | all"
+how much pluto debugging output should be logged.
+An empty value,
+or the magic value
+.BR none ,
+means no debugging output (the default).
+The magic value
+.B all
+means full output.
+Otherwise only the specified types of output
+(a quoted list, names without the
+.B \-\-debug\-
+prefix,
+separated by white space) are enabled;
+for details on available debugging types, see
+.IR pluto (8).
+.TP
+.BR plutostderrlog " = <file>"
+Pluto will not use syslog, but rather log to stderr, and redirect stderr
+to <file>.
+.TP
+.BR postpluto " = <command>"
+shell command to run after starting pluto
+(e.g., to remove a decrypted copy of the
+.I ipsec.secrets
+file).
+It's run in a very simple way;
+complexities like I/O redirection are best hidden within a script.
+Any output is redirected for logging,
+so running interactive commands is difficult unless they use
+.I /dev/tty
+or equivalent for their interaction.
+Default is none.
+.TP
+.BR prepluto " = <command>"
+shell command to run before starting pluto
+(e.g., to decrypt an encrypted copy of the
+.I ipsec.secrets
+file).
+It's run in a very simple way;
+complexities like I/O redirection are best hidden within a script.
+Any output is redirected for logging,
+so running interactive commands is difficult unless they use
+.I /dev/tty
+or equivalent for their interaction.
+Default is none.
+.TP
+.BR virtual_private " = <networks>"
+defines private networks using a wildcard notation.
+.PP
+The following
+.B config section
+parameters are used by the IKEv2 charon daemon only:
+.TP
+.BR charondebug " = <debug list>"
+how much charon debugging output should be logged.
+A comma separated list containing type level/pairs may
+be specified, e.g:
+.B dmn 3, ike 1, net -1.
+Acceptable values for types are
+.B dmn, mgr, ike, chd, job, cfg, knl, net, enc, lib
+and the level is one of
+.B -1, 0, 1, 2, 3, 4
+(for silent, audit, control, controlmore, raw, private).
+For more flexibility see LOGGER CONFIGURATION in
+.IR strongswan.conf (5).
+
+.SH IKEv2 EXPIRY/REKEY
+The IKE SAs and IPsec SAs negotiated by the daemon can be configured to expire
+after a specific amount of time. For IPsec SAs this can also happen after a
+specified number of transmitted packets or transmitted bytes. The following
+settings can be used to configure this:
+.TS
+l r l r,- - - -,lB s lB s,a r a r.
+Setting	Default	Setting	Default
+IKE SA	IPsec SA
+ikelifetime	3h	lifebytes	-
+		lifepackets	-
+		lifetime	1h
+.TE
+.SS Rekeying
+IKE SAs as well as IPsec SAs can be rekeyed before they expire. This can be
+configured using the following settings:
+.TS
+l r l r,- - - -,lB s lB s,a r a r.
+Setting	Default	Setting	Default
+IKE and IPsec SA	IPsec SA
+margintime	9m	marginbytes	-
+		marginpackets	-
+.TE
+.SS Randomization
+To avoid collisions the specified margins are increased randomly before
+subtracting them from the expiration limits (see formula below). This is
+controlled by the
+.B rekeyfuzz
+setting:
+.TS
+l r,- -,lB s,a r.
+Setting	Default
+IKE and IPsec SA
+rekeyfuzz	100%
+.TE
+.PP
+Randomization can be disabled by setting
+.BR rekeyfuzz " to " 0% .
+.SS Formula
+The following formula is used to calculate the rekey time of IPsec SAs:
+.PP
+.EX
+ rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))
+.EE
+.PP
+It applies equally to IKE SAs and byte and packet limits for IPsec SAs.
+.SS Example
+Let's consider the default configuration:
+.PP
+.EX
+	lifetime = 1h
+	margintime = 9m
+	rekeyfuzz = 100%
+.EE
+.PP
+From the formula above follows that the rekey time lies between:
+.PP
+.EX
+	rekeytime_min = 1h - (9m + 9m) = 42m
+	rekeytime_max = 1h - (9m + 0m) = 51m
+.EE
+.PP
+Thus, the daemon will attempt to rekey the IPsec SA at a random time
+between 42 and 51 minutes after establishing the SA. Or, in other words,
+between 9 and 18 minutes before the SA expires.
+.SS Notes
+.IP \[bu]
+Since the rekeying of an SA needs some time, the margin values must not be
+too low.
+.IP \[bu]
+The value
+.B margin... + margin... * rekeyfuzz
+must not exceed the original limit. For example, specifying
+.B margintime = 30m
+in the default configuration is a bad idea as there is a chance that the rekey
+time equals zero and, thus, rekeying gets disabled.
+.SH FILES
+.nf
+/etc/ipsec.conf
+/etc/ipsec.d/aacerts
+/etc/ipsec.d/acerts
+/etc/ipsec.d/cacerts
+/etc/ipsec.d/certs
+/etc/ipsec.d/crls
+
+.SH SEE ALSO
+strongswan.conf(5), ipsec.secrets(5), ipsec(8), pluto(8)
+.SH HISTORY
+Originally written for the FreeS/WAN project by Henry Spencer.
+Updated and extended for the strongSwan project <http://www.strongswan.org> by
+Tobias Brunner, Andreas Steffen and Martin Willi.
+.SH BUGS
+.PP
+If conns are to be added before DNS is available, \fBleft=\fP\fIFQDN\fP
+will fail.
diff --git a/man/ipsec.conf.5.in b/man/ipsec.conf.5.in
new file mode 100644
index 000000000..187f36957
--- /dev/null
+++ b/man/ipsec.conf.5.in
@@ -0,0 +1,1358 @@
+.TH IPSEC.CONF 5 "2010-10-19" "@IPSEC_VERSION@" "strongSwan"
+.SH NAME
+ipsec.conf \- IPsec configuration and connections
+.SH DESCRIPTION
+The optional
+.I ipsec.conf
+file
+specifies most configuration and control information for the
+strongSwan IPsec subsystem.
+The major exception is secrets for authentication;
+see
+.IR ipsec.secrets (5).
+Its contents are not security-sensitive.
+.PP
+The file is a text file, consisting of one or more
+.IR sections .
+White space followed by
+.B #
+followed by anything to the end of the line
+is a comment and is ignored,
+as are empty lines which are not within a section.
+.PP
+A line which contains
+.B include
+and a file name, separated by white space,
+is replaced by the contents of that file,
+preceded and followed by empty lines.
+If the file name is not a full pathname,
+it is considered to be relative to the directory containing the
+including file.
+Such inclusions can be nested.
+Only a single filename may be supplied, and it may not contain white space,
+but it may include shell wildcards (see
+.IR sh (1));
+for example:
+.PP
+.B include
+.B "ipsec.*.conf"
+.PP
+The intention of the include facility is mostly to permit keeping
+information on connections, or sets of connections,
+separate from the main configuration file.
+This permits such connection descriptions to be changed,
+copied to the other security gateways involved, etc.,
+without having to constantly extract them from the configuration
+file and then insert them back into it.
+Note also the
+.B also
+parameter (described below) which permits splitting a single logical
+section (e.g. a connection description) into several actual sections.
+.PP
+A section
+begins with a line of the form:
+.PP
+.I type
+.I name
+.PP
+where
+.I type
+indicates what type of section follows, and
+.I name
+is an arbitrary name which distinguishes the section from others
+of the same type.
+Names must start with a letter and may contain only
+letters, digits, periods, underscores, and hyphens.
+All subsequent non-empty lines
+which begin with white space are part of the section;
+comments within a section must begin with white space too.
+There may be only one section of a given type with a given name.
+.PP
+Lines within the section are generally of the form
+.PP
+\ \ \ \ \ \fIparameter\fB=\fIvalue\fR
+.PP
+(note the mandatory preceding white space).
+There can be white space on either side of the
+.BR = .
+Parameter names follow the same syntax as section names,
+and are specific to a section type.
+Unless otherwise explicitly specified,
+no parameter name may appear more than once in a section.
+.PP
+An empty
+.I value
+stands for the system default value (if any) of the parameter,
+i.e. it is roughly equivalent to omitting the parameter line entirely.
+A
+.I value
+may contain white space only if the entire
+.I value
+is enclosed in double quotes (\fB"\fR);
+a
+.I value
+cannot itself contain a double quote,
+nor may it be continued across more than one line.
+.PP
+Numeric values are specified to be either an ``integer''
+(a sequence of digits) or a ``decimal number''
+(sequence of digits optionally followed by `.' and another sequence of digits).
+.PP
+There is currently one parameter which is available in any type of
+section:
+.TP
+.B also
+the value is a section name;
+the parameters of that section are appended to this section,
+as if they had been written as part of it.
+The specified section must exist, must follow the current one,
+and must have the same section type.
+(Nesting is permitted,
+and there may be more than one
+.B also
+in a single section,
+although it is forbidden to append the same section more than once.)
+.PP
+A section with name
+.B %default
+specifies defaults for sections of the same type.
+For each parameter in it,
+any section of that type which does not have a parameter of the same name
+gets a copy of the one from the
+.B %default
+section.
+There may be multiple
+.B %default
+sections of a given type,
+but only one default may be supplied for any specific parameter name,
+and all
+.B %default
+sections of a given type must precede all non-\c
+.B %default
+sections of that type.
+.B %default
+sections may not contain the
+.B also
+parameter.
+.PP
+Currently there are three types of sections:
+a
+.B config
+section specifies general configuration information for IPsec, a
+.B conn
+section specifies an IPsec connection, while a
+.B ca
+section specifies special properties of a certification authority.
+.SH "CONN SECTIONS"
+A
+.B conn
+section contains a
+.IR "connection specification" ,
+defining a network connection to be made using IPsec.
+The name given is arbitrary, and is used to identify the connection.
+Here's a simple example:
+.PP
+.ne 10
+.nf
+.ft B
+.ta 1c
+conn snt
+	left=192.168.0.1
+	leftsubnet=10.1.0.0/16
+	right=192.168.0.2
+	rightsubnet=10.1.0.0/16
+	keyingtries=%forever
+	auto=add
+.ft
+.fi
+.PP
+A note on terminology: There are two kinds of communications going on:
+transmission of user IP packets, and gateway-to-gateway negotiations for
+keying, rekeying, and general control.
+The path to control the connection is called 'ISAKMP SA' in IKEv1
+and 'IKE SA' in the IKEv2 protocol. That what is being negotiated, the kernel
+level data path, is called 'IPsec SA' or 'Child SA'.
+strongSwan currently uses two separate keying daemons. \fIpluto\fP handles
+all IKEv1 connections, \fIcharon\fP is the daemon handling the IKEv2
+protocol.
+.PP
+To avoid trivial editing of the configuration file to suit it to each system
+involved in a connection,
+connection specifications are written in terms of
+.I left
+and
+.I right
+participants,
+rather than in terms of local and remote.
+Which participant is considered
+.I left
+or
+.I right
+is arbitrary;
+for every connection description an attempt is made to figure out whether
+the local endpoint should act as the
+.I left
+or
+.I right
+endpoint. This is done by matching the IP addresses defined for both endpoints
+with the IP addresses assigned to local network interfaces. If a match is found
+then the role (left or right) that matches is going to be considered local.
+If no match is found during startup,
+.I left
+is considered local.
+This permits using identical connection specifications on both ends.
+There are cases where there is no symmetry; a good convention is to
+use
+.I left
+for the local side and
+.I right
+for the remote side (the first letters are a good mnemonic).
+.PP
+Many of the parameters relate to one participant or the other;
+only the ones for
+.I left
+are listed here, but every parameter whose name begins with
+.B left
+has a
+.B right
+counterpart,
+whose description is the same but with
+.B left
+and
+.B right
+reversed.
+.PP
+Parameters are optional unless marked '(required)'.
+.SS "CONN PARAMETERS"
+Unless otherwise noted, for a connection to work,
+in general it is necessary for the two ends to agree exactly
+on the values of these parameters.
+.TP
+.BR aaa_identity " = <id>"
+defines the identity of the AAA backend used during IKEv2 EAP authentication.
+This is required if the EAP client uses a method that verifies the server
+identity (such as EAP-TLS), but it does not match the IKEv2 gateway identity.
+.TP
+.BR also " = <name>"
+includes conn section
+.BR <name> .
+.TP
+.BR auth " = " esp " | ah"
+whether authentication should be done as part of
+ESP encryption, or separately using the AH protocol;
+acceptable values are
+.B esp
+(the default) and
+.BR ah .
+.br
+The IKEv2 daemon currently supports ESP only.
+.TP
+.BR authby " = " pubkey " | rsasig | ecdsasig | psk | eap | never | xauth..."
+how the two security gateways should authenticate each other;
+acceptable values are
+.B psk
+or
+.B secret
+for pre-shared secrets,
+.B pubkey
+(the default) for public key signatures as well as the synonyms
+.B rsasig
+for RSA digital signatures and
+.B ecdsasig
+for Elliptic Curve DSA signatures.
+.B never
+can be used if negotiation is never to be attempted or accepted (useful for
+shunt-only conns).
+Digital signatures are superior in every way to shared secrets.
+IKEv1 additionally supports the values
+.B xauthpsk
+and
+.B xauthrsasig
+that will enable eXtended AUTHentication (XAUTH) in addition to IKEv1 main mode
+based on shared secrets  or digital RSA signatures, respectively.
+IKEv2 additionally supports the value
+.BR eap ,
+which indicates an initiator to request EAP authentication. The EAP method
+to use is selected by the server (see
+.BR eap ).
+This parameter is deprecated for IKEv2 connections, as two peers do not need
+to agree on an authentication method. Use the
+.B leftauth
+parameter instead to define authentication methods in IKEv2.
+.TP
+.BR auto " = " ignore " | add | route | start"
+what operation, if any, should be done automatically at IPsec startup;
+currently-accepted values are
+.BR add ,
+.BR route ,
+.B start
+and
+.B ignore
+(the default).
+.B add
+loads a connection without starting it.
+.B route
+loads a connection and installs kernel traps. If traffic is detected between
+.B leftsubnet
+and
+.B rightsubnet
+, a connection is established.
+.B start
+loads a connection and brings it up immediatly.
+.B ignore
+ignores the connection. This is equal to delete a connection from the config
+file.
+Relevant only locally, other end need not agree on it
+(but in general, for an intended-to-be-permanent connection,
+both ends should use
+.B auto=start
+to ensure that any reboot causes immediate renegotiation).
+.TP
+.BR compress " = yes | " no
+whether IPComp compression of content is proposed on the connection
+(link-level compression does not work on encrypted data,
+so to be effective, compression must be done \fIbefore\fR encryption);
+acceptable values are
+.B yes
+and
+.B no
+(the default). A value of
+.B yes
+causes IPsec to propose both compressed and uncompressed,
+and prefer compressed.
+A value of
+.B no
+prevents IPsec from proposing compression;
+a proposal to compress will still be accepted.
+.TP
+.BR dpdaction " = " none " | clear | hold | restart"
+controls the use of the Dead Peer Detection protocol (DPD, RFC 3706) where
+R_U_THERE notification messages (IKEv1) or empty INFORMATIONAL messages (IKEv2)
+are periodically sent in order to check the
+liveliness of the IPsec peer. The values
+.BR clear ,
+.BR hold ,
+and
+.B restart
+all activate DPD. If no activity is detected, all connections with a dead peer
+are stopped and unrouted
+.RB ( clear ),
+put in the hold state
+.RB ( hold )
+or restarted
+.RB ( restart ).
+For IKEv1, the default is
+.B none
+which disables the active sending of R_U_THERE notifications.
+Nevertheless pluto will always send the DPD Vendor ID during connection set up
+in order to signal the readiness to act passively as a responder if the peer
+wants to use DPD. For IKEv2,
+.B none
+does't make sense, since all messages are used to detect dead peers. If specified,
+it has the same meaning as the default
+.RB ( clear ).
+.TP
+.BR dpddelay " = " 30s " | <time>"
+defines the period time interval with which R_U_THERE messages/INFORMATIONAL
+exchanges are sent to the peer. These are only sent if no other traffic is
+received. In IKEv2, a value of 0 sends no additional INFORMATIONAL
+messages and uses only standard messages (such as those to rekey) to detect
+dead peers.
+.TP
+.BR dpdtimeout " = " 150s " | <time>"
+defines the timeout interval, after which all connections to a peer are deleted
+in case of inactivity. This only applies to IKEv1, in IKEv2 the default
+retransmission timeout applies, as every exchange is used to detect dead peers.
+See
+.IR strongswan.conf (5)
+for a description of the IKEv2 retransmission timeout.
+.TP
+.BR inactivity " = <time>"
+defines the timeout interval, after which a CHILD_SA is closed if it did
+not send or receive any traffic. Currently supported in IKEv2 connections only.
+.TP
+.BR eap " = md5 | mschapv2 | radius | ... | <type> | <type>-<vendor>
+defines the EAP type to propose as server if the client requests EAP
+authentication. Currently supported values are
+.B aka
+for EAP-AKA,
+.B gtc
+for EAP-GTC,
+.B md5
+for EAP-MD5,
+.B mschapv2
+for EAP-MS-CHAPv2,
+.B radius
+for the EAP-RADIUS proxy and
+.B sim
+for EAP-SIM. Additionally, IANA assigned EAP method numbers are accepted, or a
+definition in the form
+.B eap=type-vendor
+(e.g. eap=7-12345) can be used to specify vendor specific EAP types.
+This parameter is deprecated in the favour of
+.B leftauth.
+
+To forward EAP authentication to a RADIUS server using the EAP-RADIUS plugin,
+set
+.BR eap=radius .
+.TP
+.BR eap_identity " = <id>"
+defines the identity the client uses to reply to a EAP Identity request.
+If defined on the EAP server, the defined identity will be used as peer
+identity during EAP authentication. The special value
+.B %identity
+uses the EAP Identity method to ask the client for an EAP identity. If not
+defined, the IKEv2 identity will be used as EAP identity.
+.TP
+.BR esp " = <cipher suites>"
+comma-separated list of ESP encryption/authentication algorithms to be used
+for the connection, e.g.
+.BR aes128-sha256 .
+The notation is
+.BR encryption-integrity-[dh-group] .
+.br
+If
+.B dh-group
+is specified, CHILD_SA setup and rekeying include a separate diffe hellman
+exchange (IKEv2 only).
+.TP
+.BR forceencaps " = yes | " no
+force UDP encapsulation for ESP packets even if no NAT situation is detected.
+This may help to surmount restrictive firewalls. In order to force the peer to
+encapsulate packets, NAT detection payloads are faked (IKEv2 only).
+.TP
+.BR ike " = <cipher suites>"
+comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms
+to be used, e.g.
+.BR aes128-sha1-modp2048 .
+The notation is
+.BR encryption-integrity-dhgroup .
+In IKEv2, multiple algorithms and proposals may be included, such as
+.B aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024.
+.TP
+.BR ikelifetime " = " 3h " | <time>"
+how long the keying channel of a connection (ISAKMP or IKE SA)
+should last before being renegotiated. Also see EXPIRY/REKEY below.
+.TP
+.BR installpolicy " = " yes " | no"
+decides whether IPsec policies are installed in the kernel by the IKEv2
+charon daemon for a given connection. Allows peaceful cooperation e.g. with
+the Mobile IPv6 daemon mip6d who wants to control the kernel policies.
+Acceptable values are
+.B yes
+(the default) and
+.BR no .
+.TP
+.BR keyexchange " = " ike " | ikev1 | ikev2"
+method of key exchange;
+which protocol should be used to initialize the connection. Connections marked with
+.B ikev1
+are initiated with pluto, those marked with
+.B ikev2
+with charon. An incoming request from the remote peer is handled by the correct
+daemon, unaffected from the
+.B keyexchange
+setting. Starting with strongSwan 4.5 the default value
+.B ike
+is a synonym for
+.BR ikev2 ,
+whereas in older strongSwan releases
+.B ikev1
+was assumed.
+.TP
+.BR keyingtries " = " %forever " | <number>"
+how many attempts (a whole number or \fB%forever\fP) should be made to
+negotiate a connection, or a replacement for one, before giving up
+(default
+.BR %forever ).
+The value \fB%forever\fP
+means 'never give up'.
+Relevant only locally, other end need not agree on it.
+.TP
+.B keylife
+synonym for
+.BR lifetime .
+.TP
+.BR left " = <ip address> | <fqdn> | %defaultroute | " %any
+(required)
+the IP address of the left participant's public-network interface
+or one of several magic values.
+If it is
+.BR %defaultroute ,
+.B left
+will be filled in automatically with the local address
+of the default-route interface (as determined at IPsec startup time and
+during configuration update).
+Either
+.B left
+or
+.B right
+may be
+.BR %defaultroute ,
+but not both.
+The prefix
+.B  %
+in front of a fully-qualified domain name or an IP address will implicitly set
+.B leftallowany=yes.
+If the domain name cannot be resolved into an IP address at IPsec startup or
+update time then
+.B left=%any
+and
+.B leftallowany=no
+will be assumed.
+
+In case of an IKEv2 connection, the value
+.B %any
+for the local endpoint signifies an address to be filled in (by automatic
+keying) during negotiation. If the local peer initiates the connection setup
+the routing table will be queried to determine the correct local IP address.
+In case the local peer is responding to a connection setup then any IP address
+that is assigned to a local interface will be accepted.
+.br
+Note that specifying
+.B %any
+for the local endpoint is not supported by the IKEv1 pluto daemon.
+
+If
+.B %any
+is used for the remote endpoint it literally means any IP address.
+
+Please note that with the usage of wildcards multiple connection descriptions
+might match a given incoming connection attempt. The most specific description
+is used in that case.
+.TP
+.BR leftallowany " = yes | " no
+a modifier for
+.B left
+, making it behave as
+.B %any
+although a concrete IP address has been assigned.
+Recommended for dynamic IP addresses that can be resolved by DynDNS at IPsec
+startup or update time.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR leftauth " = <auth method>"
+Authentication method to use locally (left) or require from the remote (right)
+side.
+This parameter is supported in IKEv2 only. Acceptable values are
+.B pubkey
+for public key authentication (RSA/ECDSA),
+.B psk
+for pre-shared key authentication and
+.B eap
+to (require the) use of the Extensible Authentication Protocol. In the case
+of
+.B eap,
+an optional EAP method can be appended. Currently defined methods are
+.BR eap-aka ,
+.BR eap-gtc ,
+.BR eap-md5 ,
+.BR eap-tls ,
+.B eap-mschapv2
+and
+.BR eap-sim .
+Alternatively, IANA assigned EAP method numbers are accepted. Vendor specific
+EAP methods are defined in the form
+.B eap-type-vendor
+.RB "(e.g. " eap-7-12345 ).
+.TP
+.BR leftauth2 " = <auth method>"
+Same as
+.BR leftauth ,
+but defines an additional authentication exchange. IKEv2 supports multiple
+authentication rounds using "Multiple Authentication Exchanges" defined
+in RFC4739. This allows, for example, separated authentication
+of host and user (IKEv2 only).
+.TP
+.BR leftca " = <issuer dn> | %same"
+the distinguished name of a certificate authority which is required to
+lie in the trust path going from the left participant's certificate up
+to the root certification authority.
+.TP
+.BR leftca2 " = <issuer dn> | %same"
+Same as
+.BR leftca ,
+but for the second authentication round (IKEv2 only).
+.TP
+.BR leftcert " = <path>"
+the path to the left participant's X.509 certificate. The file can be encoded
+either in PEM or DER format. OpenPGP certificates are supported as well.
+Both absolute paths or paths relative to \fI/etc/ipsec.d/certs\fP
+are accepted. By default
+.B leftcert
+sets
+.B leftid
+to the distinguished name of the certificate's subject and
+.B leftca
+to the distinguished name of the certificate's issuer.
+The left participant's ID can be overriden by specifying a
+.B leftid
+value which must be certified by the certificate, though.
+.TP
+.BR leftcert2 " = <path>"
+Same as
+.B leftcert,
+but for the second authentication round (IKEv2 only).
+.TP
+.BR leftfirewall " = yes | " no
+whether the left participant is doing forwarding-firewalling
+(including masquerading) using iptables for traffic from \fIleftsubnet\fR,
+which should be turned off (for traffic to the other subnet)
+once the connection is established;
+acceptable values are
+.B yes
+and
+.B no
+(the default).
+May not be used in the same connection description with
+.BR leftupdown .
+Implemented as a parameter to the default \fBipsec _updown\fR script.
+See notes below.
+Relevant only locally, other end need not agree on it.
+
+If one or both security gateways are doing forwarding firewalling
+(possibly including masquerading),
+and this is specified using the firewall parameters,
+tunnels established with IPsec are exempted from it
+so that packets can flow unchanged through the tunnels.
+(This means that all subnets connected in this manner must have
+distinct, non-overlapping subnet address blocks.)
+This is done by the default \fBipsec _updown\fR script (see
+.IR pluto (8)).
+
+In situations calling for more control,
+it may be preferable for the user to supply his own
+.I updown
+script,
+which makes the appropriate adjustments for his system.
+.TP
+.BR leftgroups " = <group list>"
+a comma separated list of group names. If the
+.B leftgroups
+parameter is present then the peer must be a member of at least one
+of the groups defined by the parameter. Group membership must be certified
+by a valid attribute certificate stored in \fI/etc/ipsec.d/acerts/\fP thas has
+been issued to the peer by a trusted Authorization Authority stored in
+\fI/etc/ipsec.d/aacerts/\fP.
+.br
+Attribute certificates are not supported in IKEv2 yet.
+.TP
+.BR lefthostaccess " = yes | " no
+inserts a pair of INPUT and OUTPUT iptables rules using the default
+\fBipsec _updown\fR script, thus allowing access to the host itself
+in the case where the host's internal interface is part of the
+negotiated client subnet.
+Acceptable values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR leftid " = <id>"
+how the left participant should be identified for authentication;
+defaults to
+.BR left .
+Can be an IP address or a fully-qualified domain name preceded by
+.B @
+(which is used as a literal string and not resolved).
+.TP
+.BR leftid2 " = <id>"
+identity to use for a second authentication for the left participant
+(IKEv2 only); defaults to
+.BR leftid .
+.TP
+.BR leftikeport " = <port>"
+UDP port the left participant uses for IKE communication. Currently supported in
+IKEv2 connections only. If unspecified, port 500 is used with the port floating
+to 4500 if a NAT is detected or MOBIKE is enabled. Specifying a local IKE port
+different from the default additionally requires a socket implementation that
+listens to this port.
+.TP
+.BR leftnexthop " = %direct | %defaultroute | <ip address> | <fqdn>"
+this parameter is usually not needed any more because the NETKEY IPsec stack
+does not require explicit routing entries for the traffic to be tunneled. If
+.B leftsourceip
+is used with IKEv1 then
+.B leftnexthop
+must still be set in order for the source routes to work properly.
+.TP
+.BR leftprotoport " = <protocol>/<port>"
+restrict the traffic selector to a single protocol and/or port.
+Examples:
+.B leftprotoport=tcp/http
+or
+.B leftprotoport=6/80
+or
+.B leftprotoport=udp
+.TP
+.BR leftrsasigkey " = " %cert " | <raw rsa public key>"
+the left participant's
+public key for RSA signature authentication,
+in RFC 2537 format using
+.IR ttodata (3)
+encoding.
+The magic value
+.B %none
+means the same as not specifying a value (useful to override a default).
+The value
+.B %cert
+(the default)
+means that the key is extracted from a certificate.
+The identity used for the left participant
+must be a specific host, not
+.B %any
+or another magic value.
+.B Caution:
+if two connection descriptions
+specify different public keys for the same
+.BR leftid ,
+confusion and madness will ensue.
+.TP
+.BR leftsendcert " = never | no | " ifasked " | always | yes"
+Accepted values are
+.B never
+or
+.BR no ,
+.B always
+or
+.BR yes ,
+and
+.BR ifasked " (the default),"
+the latter meaning that the peer must send a certificate request payload in
+order to get a certificate in return.
+.TP
+.BR leftsourceip " = %config | %cfg | %modeconfig | %modecfg | <ip address>"
+The internal source IP to use in a tunnel, also known as virtual IP. If the
+value is one of the synonyms
+.BR %config ,
+.BR %cfg ,
+.BR %modeconfig ,
+or
+.BR %modecfg ,
+an address is requested from the peer. In IKEv2, a statically defined address
+is also requested, since the server may change it.
+.TP
+.BR rightsourceip " = %config | <network>/<netmask> | %poolname"
+The internal source IP to use in a tunnel for the remote peer. If the
+value is
+.B %config
+on the responder side, the initiator must propose an address which is then
+echoed back. Also supported are address pools expressed as
+\fInetwork\fB/\fInetmask\fR
+or the use of an external IP address pool using %\fIpoolname\fR,
+where \fIpoolname\fR is the name of the IP address pool used for the lookup.
+.TP
+.BR leftsubnet " = <ip subnet>"
+private subnet behind the left participant, expressed as
+\fInetwork\fB/\fInetmask\fR;
+if omitted, essentially assumed to be \fIleft\fB/32\fR,
+signifying that the left end of the connection goes to the left participant
+only. When using IKEv2, the configured subnet of the peers may differ, the
+protocol narrows it to the greatest common subnet. Further, IKEv2 supports
+multiple subnets separated by commas. IKEv1 only interprets the first subnet
+of such a definition.
+.TP
+.BR leftsubnetwithin " = <ip subnet>"
+the peer can propose any subnet or single IP address that fits within the
+range defined by
+.BR leftsubnetwithin.
+Not relevant for IKEv2, as subnets are narrowed.
+.TP
+.BR leftupdown " = <path>"
+what ``updown'' script to run to adjust routing and/or firewalling
+when the status of the connection
+changes (default
+.BR "ipsec _updown" ).
+May include positional parameters separated by white space
+(although this requires enclosing the whole string in quotes);
+including shell metacharacters is unwise.
+See
+.IR pluto (8)
+for details.
+Relevant only locally, other end need not agree on it. IKEv2 uses the updown
+script to insert firewall rules only, since routing has been implemented
+directly into charon.
+.TP
+.BR lifebytes " = <number>"
+the number of bytes transmitted over an IPsec SA before it expires (IKEv2
+only).
+.TP
+.BR lifepackets " = <number>"
+the number of packets transmitted over an IPsec SA before it expires (IKEv2
+only).
+.TP
+.BR lifetime " = " 1h " | <time>"
+how long a particular instance of a connection
+(a set of encryption/authentication keys for user packets) should last,
+from successful negotiation to expiry;
+acceptable values are an integer optionally followed by
+.BR s
+(a time in seconds)
+or a decimal number followed by
+.BR m ,
+.BR h ,
+or
+.B d
+(a time
+in minutes, hours, or days respectively)
+(default
+.BR 1h ,
+maximum
+.BR 24h ).
+Normally, the connection is renegotiated (via the keying channel)
+before it expires (see
+.BR margintime ).
+The two ends need not exactly agree on
+.BR lifetime ,
+although if they do not,
+there will be some clutter of superseded connections on the end
+which thinks the lifetime is longer. Also see EXPIRY/REKEY below.
+.TP
+.BR marginbytes " = <number>"
+how many bytes before IPsec SA expiry (see
+.BR lifebytes )
+should attempts to negotiate a replacement begin (IKEv2 only).
+.TP
+.BR marginpackets " = <number>"
+how many packets before IPsec SA expiry (see
+.BR lifepackets )
+should attempts to negotiate a replacement begin (IKEv2 only).
+.TP
+.BR margintime " = " 9m " | <time>"
+how long before connection expiry or keying-channel expiry
+should attempts to
+negotiate a replacement
+begin; acceptable values as for
+.B lifetime
+(default
+.BR 9m ).
+Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY
+below.
+.TP
+.BR mark " = <value>[/<mask>]"
+sets an XFRM mark in the inbound and outbound
+IPsec SAs and policies. If the mask is missing then a default
+mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mark_in " = <value>[/<mask>]"
+sets an XFRM mark in the inbound IPsec SA and
+policy. If the mask is missing then a default mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mark_out " = <value>[/<mask>]"
+sets an XFRM mark in the outbound IPsec SA and
+policy. If the mask is missing then a default mask of
+.B 0xffffffff
+is assumed.
+.TP
+.BR mobike " = " yes " | no"
+enables the IKEv2 MOBIKE protocol defined by RFC 4555. Accepted values are
+.B yes
+(the default) and
+.BR no .
+If set to
+.BR no ,
+the IKEv2 charon daemon will not actively propose MOBIKE as initiator and
+ignore the MOBIKE_SUPPORTED notify as responder.
+.TP
+.BR modeconfig " = push | " pull
+defines which mode is used to assign a virtual IP.
+Accepted values are
+.B push
+and
+.B pull
+(the default).
+Currently relevant for IKEv1 only since IKEv2 always uses the configuration
+payload in pull mode. Cisco VPN gateways usually operate in
+.B push
+mode.
+.TP
+.BR pfs " = " yes " | no"
+whether Perfect Forward Secrecy of keys is desired on the connection's
+keying channel
+(with PFS, penetration of the key-exchange protocol
+does not compromise keys negotiated earlier);
+acceptable values are
+.B yes
+(the default)
+and
+.BR no.
+IKEv2 always uses PFS for IKE_SA rekeying whereas for CHILD_SA rekeying
+PFS is enforced by defining a Diffie-Hellman modp group in the
+.B esp
+parameter.
+.TP
+.BR pfsgroup " = <modp group>"
+defines a Diffie-Hellman group for perfect forward secrecy in IKEv1 Quick Mode
+differing from the DH group used for IKEv1 Main Mode (IKEv1 only).
+.TP
+.BR reauth " = " yes " | no"
+whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1,
+reauthentication is always done. In IKEv2, a value of
+.B no
+rekeys without uninstalling the IPsec SAs, a value of
+.B yes
+(the default) creates a new IKE_SA from scratch and tries to recreate
+all IPsec SAs.
+.TP
+.BR rekey " = " yes " | no"
+whether a connection should be renegotiated when it is about to expire;
+acceptable values are
+.B yes
+(the default)
+and
+.BR no .
+The two ends need not agree, but while a value of
+.B no
+prevents pluto/charon from requesting renegotiation,
+it does not prevent responding to renegotiation requested from the other end,
+so
+.B no
+will be largely ineffective unless both ends agree on it.
+.TP
+.BR rekeyfuzz " = " 100% " | <percentage>"
+maximum percentage by which
+.BR marginbytes ,
+.B marginpackets
+and
+.B margintime
+should be randomly increased to randomize rekeying intervals
+(important for hosts with many connections);
+acceptable values are an integer,
+which may exceed 100,
+followed by a `%'
+(defaults to
+.BR 100% ).
+The value of
+.BR marginTYPE ,
+after this random increase,
+must not exceed
+.B lifeTYPE
+(where TYPE is one of
+.IR bytes ,
+.I packets
+or
+.IR time ).
+The value
+.B 0%
+will suppress randomization.
+Relevant only locally, other end need not agree on it. Also see EXPIRY/REKEY
+below.
+.TP
+.B rekeymargin
+synonym for
+.BR margintime .
+.TP
+.BR reqid " = <number>"
+sets the reqid for a given connection to a pre-configured fixed value.
+.TP
+.BR type " = " tunnel " | transport | transport_proxy | passthrough | drop"
+the type of the connection; currently the accepted values
+are
+.B tunnel
+(the default)
+signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel;
+.BR transport ,
+signifying host-to-host transport mode;
+.BR transport_proxy ,
+signifying the special Mobile IPv6 transport proxy mode;
+.BR passthrough ,
+signifying that no IPsec processing should be done at all;
+.BR drop ,
+signifying that packets should be discarded; and
+.BR reject ,
+signifying that packets should be discarded and a diagnostic ICMP returned
+.RB ( reject
+is currently not supported by the NETKEY stack of the Linux 2.6 kernel).
+The IKEv2 daemon charon currently supports
+.BR tunnel ,
+.BR transport ,
+and
+.BR transport_proxy
+connection types, only.
+.TP
+.BR xauth " = " client " | server"
+specifies the role in the XAUTH protocol if activated by
+.B authby=xauthpsk
+or
+.B authby=xauthrsasig.
+Accepted values are
+.B server
+and
+.B client
+(the default).
+
+.SS "CONN PARAMETERS: IKEv2 MEDIATION EXTENSION"
+The following parameters are relevant to IKEv2 Mediation Extension
+operation only.
+.TP
+.BR mediation " = yes | " no
+whether this connection is a mediation connection, ie. whether this
+connection is used to mediate other connections.  Mediation connections
+create no child SA. Acceptable values are
+.B no
+(the default) and
+.BR yes .
+.TP
+.BR mediated_by " = <name>"
+the name of the connection to mediate this connection through.  If given,
+the connection will be mediated through the named mediation connection.
+The mediation connection must set
+.BR mediation=yes .
+.TP
+.BR me_peerid " = <id>"
+ID as which the peer is known to the mediation server, ie. which the other
+end of this connection uses as its
+.B leftid
+on its connection to the mediation server.  This is the ID we request the
+mediation server to mediate us with.  If
+.B me_peerid
+is not given, the
+.B rightid
+of this connection will be used as peer ID.
+
+.SH "CA SECTIONS"
+This are optional sections that can be used to assign special
+parameters to a Certification Authority (CA).
+.TP
+.BR also " = <name>"
+includes ca section
+.BR <name> .
+.TP
+.BR auto " = " ignore " | add"
+currently can have either the value
+.B ignore
+(the default) or
+.BR add .
+.TP
+.BR cacert " = <path>"
+defines a path to the CA certificate either relative to
+\fI/etc/ipsec.d/cacerts\fP or as an absolute path.
+.TP
+.BR crluri " = <uri>"
+defines a CRL distribution point (ldap, http, or file URI)
+.TP
+.B crluri1
+synonym for
+.B crluri.
+.TP
+.BR crluri2 " = <uri>"
+defines an alternative CRL distribution point (ldap, http, or file URI)
+.TP
+.BR ldaphost " = <hostname>"
+defines an ldap host. Currently used by IKEv1 only.
+.TP
+.BR ocspuri " = <uri>"
+defines an OCSP URI.
+.TP
+.B ocspuri1
+synonym for
+.B ocspuri.
+.TP
+.BR ocspuri2 " = <uri>"
+defines an alternative OCSP URI. Currently used by IKEv2 only.
+.TP
+.BR certuribase " = <uri>"
+defines the base URI for the Hash and URL feature supported by IKEv2.
+Instead of exchanging complete certificates, IKEv2 allows to send an URI
+that resolves to the DER encoded certificate. The certificate URIs are built
+by appending the SHA1 hash of the DER encoded certificates to this base URI.
+.SH "CONFIG SECTIONS"
+At present, the only
+.B config
+section known to the IPsec software is the one named
+.BR setup ,
+which contains information used when the software is being started.
+Here's an example:
+.PP
+.ne 8
+.nf
+.ft B
+.ta 1c
+config setup
+	plutodebug=all
+	crlcheckinterval=10m
+	strictcrlpolicy=yes
+.ft
+.fi
+.PP
+Parameters are optional unless marked ``(required)''.
+The currently-accepted
+.I parameter
+names in a
+.B config
+.B setup
+section affecting both daemons are:
+.TP
+.BR cachecrls " = yes | " no
+certificate revocation lists (CRLs) fetched via http or ldap will be cached in
+\fI/etc/ipsec.d/crls/\fR under a unique file name derived from the certification
+authority's public key.
+Accepted values are
+.B yes
+and
+.B no
+(the default). Only relevant for IKEv1, as CRLs are always cached in IKEv2.
+.TP
+.BR charonstart " = " yes " | no"
+whether to start the IKEv2 charon daemon or not.
+The default is
+.B yes
+if starter was compiled with IKEv2 support.
+.TP
+.BR plutostart " = " yes " | no"
+whether to start the IKEv1 pluto daemon or not.
+The default is
+.B yes
+if starter was compiled with IKEv1 support.
+.TP
+.BR strictcrlpolicy " = yes | ifuri | " no
+defines if a fresh CRL must be available in order for the peer authentication
+based on RSA signatures to succeed.
+IKEv2 additionally recognizes
+.B ifuri
+which reverts to
+.B yes
+if at least one CRL URI is defined and to
+.B no
+if no URI is known.
+.TP
+.BR uniqueids " = " yes " | no | replace | keep"
+whether a particular participant ID should be kept unique,
+with any new (automatically keyed)
+connection using an ID from a different IP address
+deemed to replace all old ones using that ID;
+acceptable values are
+.B yes
+(the default)
+and
+.BR no .
+Participant IDs normally \fIare\fR unique,
+so a new (automatically-keyed) connection using the same ID is
+almost invariably intended to replace an old one.
+The IKEv2 daemon also accepts the value
+.B replace
+wich is identical to
+.B yes
+and the value
+.B keep
+to reject new IKE_SA setups and keep the duplicate established earlier.
+.PP
+The following
+.B config section
+parameters are used by the IKEv1 Pluto daemon only:
+.TP
+.BR crlcheckinterval " = " 0s " | <time>"
+interval in seconds. CRL fetching is enabled if the value is greater than zero.
+Asynchronous, periodic checking for fresh CRLs is currently done by the
+IKEv1 Pluto daemon only.
+.TP
+.BR keep_alive " = " 20s " | <time>"
+interval in seconds between NAT keep alive packets, the default being 20 seconds.
+.TP
+.BR nat_traversal " = yes | " no
+activates NAT traversal by accepting source ISAKMP ports different from udp/500 and
+being able of floating to udp/4500 if a NAT situation is detected.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+Used by IKEv1 only, NAT traversal is always being active in IKEv2.
+.TP
+.BR nocrsend " = yes | " no
+no certificate request payloads will be sent.
+.TP
+.BR pkcs11initargs " = <args>"
+non-standard argument string for PKCS#11 C_Initialize() function;
+required by NSS softoken.
+.TP
+.BR pkcs11module " = <args>"
+defines the path to a dynamically loadable PKCS #11 library.
+.TP
+.BR pkcs11keepstate " = yes | " no
+PKCS #11 login sessions will be kept during the whole lifetime of the keying
+daemon. Useful with pin-pad smart card readers.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR pkcs11proxy " = yes | " no
+Pluto will act as a PKCS #11 proxy accessible via the whack interface.
+Accepted values are
+.B yes
+and
+.B no
+(the default).
+.TP
+.BR plutodebug " = " none " | <debug list> | all"
+how much pluto debugging output should be logged.
+An empty value,
+or the magic value
+.BR none ,
+means no debugging output (the default).
+The magic value
+.B all
+means full output.
+Otherwise only the specified types of output
+(a quoted list, names without the
+.B \-\-debug\-
+prefix,
+separated by white space) are enabled;
+for details on available debugging types, see
+.IR pluto (8).
+.TP
+.BR plutostderrlog " = <file>"
+Pluto will not use syslog, but rather log to stderr, and redirect stderr
+to <file>.
+.TP
+.BR postpluto " = <command>"
+shell command to run after starting pluto
+(e.g., to remove a decrypted copy of the
+.I ipsec.secrets
+file).
+It's run in a very simple way;
+complexities like I/O redirection are best hidden within a script.
+Any output is redirected for logging,
+so running interactive commands is difficult unless they use
+.I /dev/tty
+or equivalent for their interaction.
+Default is none.
+.TP
+.BR prepluto " = <command>"
+shell command to run before starting pluto
+(e.g., to decrypt an encrypted copy of the
+.I ipsec.secrets
+file).
+It's run in a very simple way;
+complexities like I/O redirection are best hidden within a script.
+Any output is redirected for logging,
+so running interactive commands is difficult unless they use
+.I /dev/tty
+or equivalent for their interaction.
+Default is none.
+.TP
+.BR virtual_private " = <networks>"
+defines private networks using a wildcard notation.
+.PP
+The following
+.B config section
+parameters are used by the IKEv2 charon daemon only:
+.TP
+.BR charondebug " = <debug list>"
+how much charon debugging output should be logged.
+A comma separated list containing type level/pairs may
+be specified, e.g:
+.B dmn 3, ike 1, net -1.
+Acceptable values for types are
+.B dmn, mgr, ike, chd, job, cfg, knl, net, enc, lib
+and the level is one of
+.B -1, 0, 1, 2, 3, 4
+(for silent, audit, control, controlmore, raw, private).
+For more flexibility see LOGGER CONFIGURATION in
+.IR strongswan.conf (5).
+
+.SH IKEv2 EXPIRY/REKEY
+The IKE SAs and IPsec SAs negotiated by the daemon can be configured to expire
+after a specific amount of time. For IPsec SAs this can also happen after a
+specified number of transmitted packets or transmitted bytes. The following
+settings can be used to configure this:
+.TS
+l r l r,- - - -,lB s lB s,a r a r.
+Setting	Default	Setting	Default
+IKE SA	IPsec SA
+ikelifetime	3h	lifebytes	-
+		lifepackets	-
+		lifetime	1h
+.TE
+.SS Rekeying
+IKE SAs as well as IPsec SAs can be rekeyed before they expire. This can be
+configured using the following settings:
+.TS
+l r l r,- - - -,lB s lB s,a r a r.
+Setting	Default	Setting	Default
+IKE and IPsec SA	IPsec SA
+margintime	9m	marginbytes	-
+		marginpackets	-
+.TE
+.SS Randomization
+To avoid collisions the specified margins are increased randomly before
+subtracting them from the expiration limits (see formula below). This is
+controlled by the
+.B rekeyfuzz
+setting:
+.TS
+l r,- -,lB s,a r.
+Setting	Default
+IKE and IPsec SA
+rekeyfuzz	100%
+.TE
+.PP
+Randomization can be disabled by setting
+.BR rekeyfuzz " to " 0% .
+.SS Formula
+The following formula is used to calculate the rekey time of IPsec SAs:
+.PP
+.EX
+ rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))
+.EE
+.PP
+It applies equally to IKE SAs and byte and packet limits for IPsec SAs.
+.SS Example
+Let's consider the default configuration:
+.PP
+.EX
+	lifetime = 1h
+	margintime = 9m
+	rekeyfuzz = 100%
+.EE
+.PP
+From the formula above follows that the rekey time lies between:
+.PP
+.EX
+	rekeytime_min = 1h - (9m + 9m) = 42m
+	rekeytime_max = 1h - (9m + 0m) = 51m
+.EE
+.PP
+Thus, the daemon will attempt to rekey the IPsec SA at a random time
+between 42 and 51 minutes after establishing the SA. Or, in other words,
+between 9 and 18 minutes before the SA expires.
+.SS Notes
+.IP \[bu]
+Since the rekeying of an SA needs some time, the margin values must not be
+too low.
+.IP \[bu]
+The value
+.B margin... + margin... * rekeyfuzz
+must not exceed the original limit. For example, specifying
+.B margintime = 30m
+in the default configuration is a bad idea as there is a chance that the rekey
+time equals zero and, thus, rekeying gets disabled.
+.SH FILES
+.nf
+/etc/ipsec.conf
+/etc/ipsec.d/aacerts
+/etc/ipsec.d/acerts
+/etc/ipsec.d/cacerts
+/etc/ipsec.d/certs
+/etc/ipsec.d/crls
+
+.SH SEE ALSO
+strongswan.conf(5), ipsec.secrets(5), ipsec(8), pluto(8)
+.SH HISTORY
+Originally written for the FreeS/WAN project by Henry Spencer.
+Updated and extended for the strongSwan project <http://www.strongswan.org> by
+Tobias Brunner, Andreas Steffen and Martin Willi.
+.SH BUGS
+.PP
+If conns are to be added before DNS is available, \fBleft=\fP\fIFQDN\fP
+will fail.
diff --git a/man/ipsec.secrets.5 b/man/ipsec.secrets.5
new file mode 100644
index 000000000..1e586a491
--- /dev/null
+++ b/man/ipsec.secrets.5
@@ -0,0 +1,176 @@
+.TH IPSEC.SECRETS 5 "2010-05-30" "4.5.0rc2" "strongSwan"
+.SH NAME
+ipsec.secrets \- secrets for IKE/IPsec authentication
+.SH DESCRIPTION
+The file \fIipsec.secrets\fP holds a table of secrets.
+These secrets are used by the strongSwan Internet Key Exchange (IKE) daemons
+pluto (IKEv1) and charon (IKEv2) to authenticate other hosts.
+.LP
+It is vital that these secrets be protected.  The file should be owned
+by the super-user,
+and its permissions should be set to block all access by others.
+.LP
+The file is a sequence of entries and include directives.
+Here is an example.
+.LP
+.RS
+.nf
+# /etc/ipsec.secrets - strongSwan IPsec secrets file
+192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"
+
+: RSA moonKey.pem
+
+alice@strongswan.org : EAP "x3.dEhgN"
+
+carol : XAUTH "4iChxLT3"
+
+dave  : XAUTH "ryftzG4A"
+
+# get secrets from other files
+include ipsec.*.secrets
+.fi
+.RE
+.LP
+Each entry in the file is a list of optional ID selectors, followed by a secret.
+The two parts are separated by a colon (\fB:\fP) that is surrounded
+by whitespace. If no ID selectors are specified the line must start with a
+colon.
+.LP
+A selector is an IP address, a Fully Qualified Domain Name, user@FQDN,
+\fB%any\fP or \fB%any6\fP (other kinds may come).  An IP address may be written
+in the familiar dotted quad form or as a domain name to be looked up
+when the file is loaded.
+In many cases it is a bad idea to use domain names because
+the name server may not be running or may be insecure.  To denote a
+Fully Qualified Domain Name (as opposed to an IP address denoted by
+its domain name), precede the name with an at sign (\fB@\fP).
+.LP
+Matching IDs with selectors is fairly straightforward: they have to be
+equal.  In the case of a ``Road Warrior'' connection, if an equal
+match is not found for the Peer's ID, and it is in the form of an IP
+address, a selector of \fB%any\fP will match the peer's IP address if IPV4
+and \fB%any6\fP will match a the peer's IP address if IPV6.
+Currently, the obsolete notation \fB0.0.0.0\fP may be used in place of
+\fB%any\fP.
+.LP
+In IKEv1 an additional complexity
+arises in the case of authentication by preshared secret: the
+responder will need to look up the secret before the Peer's ID payload has
+been decoded, so the ID used will be the IP address.
+.LP
+To authenticate a connection between two hosts, the entry that most
+specifically matches the host and peer IDs is used.  An entry with no
+selectors will match any host and peer.  More specifically, an entry with one
+selector will match a host and peer if the selector matches the host's ID (the
+peer isn't considered).  Still more specifically, an entry with multiple
+selectors will match a host and peer if the host ID and peer ID each match one
+of the selectors.  If the key is for an asymmetric authentication technique
+(i.e. a public key system such as RSA), an entry with multiple selectors will
+match a host and peer even if only the host ID matches a selector (it is
+presumed that the selectors are all identities of the host).
+It is acceptable for two entries to be the best match as
+long as they agree about the secret or private key.
+.LP
+Authentication by preshared secret requires that both systems find the
+identical secret (the secret is not actually transmitted by the IKE
+protocol).  If both the host and peer appear in the selector list, the
+same entry will be suitable for both systems so verbatim copying
+between systems can be used.  This naturally extends to larger groups
+sharing the same secret.  Thus multiple-selector entries are best for PSK
+authentication.
+.LP
+Authentication by public key systems such as RSA requires that each host
+have its own private key.  A host could reasonably use a different private keys
+for different interfaces and for different peers.  But it would not
+be normal to share entries between systems.  Thus thus no-selector and
+one-selector forms of entry often make sense for public key authentication.
+.LP
+The key part of an entry must start with a token indicating the kind of
+key.  The following types of secrets are currently supported:
+.TP
+.B PSK
+defines a pre-shared key
+.TP
+.B RSA
+defines an RSA private key
+.TP
+.B ECDSA
+defines an ECDSA private key
+.TP
+.B EAP
+defines EAP credentials
+.TP
+.B XAUTH
+defines XAUTH credentials
+.TP
+.B PIN
+defines a smartcard PIN
+.LP
+Details on each type of secret are given below.
+.LP
+Whitespace at the end of a line is ignored. At the start of a line or
+after whitespace, \fB#\fP and the following text up to the end of the
+line is treated as a comment.
+.LP
+An include directive causes the contents of the named file to be processed
+before continuing with the current file.  The filename is subject to
+``globbing'' as in \fIsh\fP(1), so every file with a matching name
+is processed.  Includes may be nested to a modest
+depth (10, currently).  If the filename doesn't start with a \fB/\fP, the
+directory containing the current file is prepended to the name.  The
+include directive is a line that starts with the word \fBinclude\fP,
+followed by whitespace, followed by the filename (which must not contain
+whitespace).
+.SS TYPES OF SECRETS
+.TP
+.B [ <selectors> ] : PSK <secret>
+A preshared secret is most conveniently represented as a sequence of
+characters, delimited by double-quote characters (\fB"\fP).
+The sequence cannot contain a newline or double-quote.
+Strictly speaking, the secret is actually the sequence
+of bytes that is used in the file to represent the sequence of
+characters (excluding the delimiters).
+.TP
+.B [ <selectors> ] : RSA <private key file> [ <passphrase> | %prompt ]
+.TQ
+.B [ <selectors> ] : ECDSA <private key file> [ <passphrase> | %prompt ]
+For the private key file both absolute paths or paths relative to
+\fI/etc/ipsec.d/private\fP are accepted. If the private key file is
+encrypted, the \fIpassphrase\fP must be defined. Instead of a passphrase
+.B %prompt
+can be used which then causes the daemons to ask the user for the password
+whenever it is required to decrypt the key.
+.TP
+.B <user id> : EAP <secret>
+As with \fBPSK\fP secrets the \fIsecret\fP is a sequence of characters,
+delimited by double-quote characters (\fB"\fP).
+.br
+\fBEAP\fP secrets are IKEv2 only.
+.TP
+.B [ <servername> ] <username> : XAUTH <password>
+\fBXAUTH\fP secrets are IKEv1 only.
+.TP
+.B : PIN <smartcard selector> <pin code> | %prompt
+IKEv1 uses the format
+.B "%smartcard[<slot nr>[:<key id>]]"
+to specify the smartcard selector (e.g. %smartcard1:50).
+The IKEv2 daemon supports multiple modules with the format
+.B "%smartcard[<slot nr>[@<module>]]:<keyid>"
+, but always requires a keyid to uniquely select the correct key. Instead of
+specifying the pin code statically,
+.B %prompt
+can be specified, which causes the daemons to ask the user for the pin code.
+.LP
+
+.SH FILES
+/etc/ipsec.secrets
+.SH SEE ALSO
+ipsec.conf(5), strongswan.conf(5), ipsec(8)
+.br
+.SH HISTORY
+Originally written for the FreeS/WAN project by D. Hugh Redelmeier.
+Updated and extended for the strongSwan project <http://www.strongswan.org> by
+Tobias Brunner and Andreas Steffen.
+.SH BUGS
+If an ID is \fB0.0.0.0\fP, it will match \fB%any\fP;
+if it is \fB0::0\fP, it will match \fB%any6\fP.
diff --git a/man/ipsec.secrets.5.in b/man/ipsec.secrets.5.in
new file mode 100644
index 000000000..875b8e219
--- /dev/null
+++ b/man/ipsec.secrets.5.in
@@ -0,0 +1,176 @@
+.TH IPSEC.SECRETS 5 "2010-05-30" "@IPSEC_VERSION@" "strongSwan"
+.SH NAME
+ipsec.secrets \- secrets for IKE/IPsec authentication
+.SH DESCRIPTION
+The file \fIipsec.secrets\fP holds a table of secrets.
+These secrets are used by the strongSwan Internet Key Exchange (IKE) daemons
+pluto (IKEv1) and charon (IKEv2) to authenticate other hosts.
+.LP
+It is vital that these secrets be protected.  The file should be owned
+by the super-user,
+and its permissions should be set to block all access by others.
+.LP
+The file is a sequence of entries and include directives.
+Here is an example.
+.LP
+.RS
+.nf
+# /etc/ipsec.secrets - strongSwan IPsec secrets file
+192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"
+
+: RSA moonKey.pem
+
+alice@strongswan.org : EAP "x3.dEhgN"
+
+carol : XAUTH "4iChxLT3"
+
+dave  : XAUTH "ryftzG4A"
+
+# get secrets from other files
+include ipsec.*.secrets
+.fi
+.RE
+.LP
+Each entry in the file is a list of optional ID selectors, followed by a secret.
+The two parts are separated by a colon (\fB:\fP) that is surrounded
+by whitespace. If no ID selectors are specified the line must start with a
+colon.
+.LP
+A selector is an IP address, a Fully Qualified Domain Name, user@FQDN,
+\fB%any\fP or \fB%any6\fP (other kinds may come).  An IP address may be written
+in the familiar dotted quad form or as a domain name to be looked up
+when the file is loaded.
+In many cases it is a bad idea to use domain names because
+the name server may not be running or may be insecure.  To denote a
+Fully Qualified Domain Name (as opposed to an IP address denoted by
+its domain name), precede the name with an at sign (\fB@\fP).
+.LP
+Matching IDs with selectors is fairly straightforward: they have to be
+equal.  In the case of a ``Road Warrior'' connection, if an equal
+match is not found for the Peer's ID, and it is in the form of an IP
+address, a selector of \fB%any\fP will match the peer's IP address if IPV4
+and \fB%any6\fP will match a the peer's IP address if IPV6.
+Currently, the obsolete notation \fB0.0.0.0\fP may be used in place of
+\fB%any\fP.
+.LP
+In IKEv1 an additional complexity
+arises in the case of authentication by preshared secret: the
+responder will need to look up the secret before the Peer's ID payload has
+been decoded, so the ID used will be the IP address.
+.LP
+To authenticate a connection between two hosts, the entry that most
+specifically matches the host and peer IDs is used.  An entry with no
+selectors will match any host and peer.  More specifically, an entry with one
+selector will match a host and peer if the selector matches the host's ID (the
+peer isn't considered).  Still more specifically, an entry with multiple
+selectors will match a host and peer if the host ID and peer ID each match one
+of the selectors.  If the key is for an asymmetric authentication technique
+(i.e. a public key system such as RSA), an entry with multiple selectors will
+match a host and peer even if only the host ID matches a selector (it is
+presumed that the selectors are all identities of the host).
+It is acceptable for two entries to be the best match as
+long as they agree about the secret or private key.
+.LP
+Authentication by preshared secret requires that both systems find the
+identical secret (the secret is not actually transmitted by the IKE
+protocol).  If both the host and peer appear in the selector list, the
+same entry will be suitable for both systems so verbatim copying
+between systems can be used.  This naturally extends to larger groups
+sharing the same secret.  Thus multiple-selector entries are best for PSK
+authentication.
+.LP
+Authentication by public key systems such as RSA requires that each host
+have its own private key.  A host could reasonably use a different private keys
+for different interfaces and for different peers.  But it would not
+be normal to share entries between systems.  Thus thus no-selector and
+one-selector forms of entry often make sense for public key authentication.
+.LP
+The key part of an entry must start with a token indicating the kind of
+key.  The following types of secrets are currently supported:
+.TP
+.B PSK
+defines a pre-shared key
+.TP
+.B RSA
+defines an RSA private key
+.TP
+.B ECDSA
+defines an ECDSA private key
+.TP
+.B EAP
+defines EAP credentials
+.TP
+.B XAUTH
+defines XAUTH credentials
+.TP
+.B PIN
+defines a smartcard PIN
+.LP
+Details on each type of secret are given below.
+.LP
+Whitespace at the end of a line is ignored. At the start of a line or
+after whitespace, \fB#\fP and the following text up to the end of the
+line is treated as a comment.
+.LP
+An include directive causes the contents of the named file to be processed
+before continuing with the current file.  The filename is subject to
+``globbing'' as in \fIsh\fP(1), so every file with a matching name
+is processed.  Includes may be nested to a modest
+depth (10, currently).  If the filename doesn't start with a \fB/\fP, the
+directory containing the current file is prepended to the name.  The
+include directive is a line that starts with the word \fBinclude\fP,
+followed by whitespace, followed by the filename (which must not contain
+whitespace).
+.SS TYPES OF SECRETS
+.TP
+.B [ <selectors> ] : PSK <secret>
+A preshared secret is most conveniently represented as a sequence of
+characters, delimited by double-quote characters (\fB"\fP).
+The sequence cannot contain a newline or double-quote.
+Strictly speaking, the secret is actually the sequence
+of bytes that is used in the file to represent the sequence of
+characters (excluding the delimiters).
+.TP
+.B [ <selectors> ] : RSA <private key file> [ <passphrase> | %prompt ]
+.TQ
+.B [ <selectors> ] : ECDSA <private key file> [ <passphrase> | %prompt ]
+For the private key file both absolute paths or paths relative to
+\fI/etc/ipsec.d/private\fP are accepted. If the private key file is
+encrypted, the \fIpassphrase\fP must be defined. Instead of a passphrase
+.B %prompt
+can be used which then causes the daemons to ask the user for the password
+whenever it is required to decrypt the key.
+.TP
+.B <user id> : EAP <secret>
+As with \fBPSK\fP secrets the \fIsecret\fP is a sequence of characters,
+delimited by double-quote characters (\fB"\fP).
+.br
+\fBEAP\fP secrets are IKEv2 only.
+.TP
+.B [ <servername> ] <username> : XAUTH <password>
+\fBXAUTH\fP secrets are IKEv1 only.
+.TP
+.B : PIN <smartcard selector> <pin code> | %prompt
+IKEv1 uses the format
+.B "%smartcard[<slot nr>[:<key id>]]"
+to specify the smartcard selector (e.g. %smartcard1:50).
+The IKEv2 daemon supports multiple modules with the format
+.B "%smartcard[<slot nr>[@<module>]]:<keyid>"
+, but always requires a keyid to uniquely select the correct key. Instead of
+specifying the pin code statically,
+.B %prompt
+can be specified, which causes the daemons to ask the user for the pin code.
+.LP
+
+.SH FILES
+/etc/ipsec.secrets
+.SH SEE ALSO
+ipsec.conf(5), strongswan.conf(5), ipsec(8)
+.br
+.SH HISTORY
+Originally written for the FreeS/WAN project by D. Hugh Redelmeier.
+Updated and extended for the strongSwan project <http://www.strongswan.org> by
+Tobias Brunner and Andreas Steffen.
+.SH BUGS
+If an ID is \fB0.0.0.0\fP, it will match \fB%any\fP;
+if it is \fB0::0\fP, it will match \fB%any6\fP.
diff --git a/man/strongswan.conf.5 b/man/strongswan.conf.5
new file mode 100644
index 000000000..2a8703503
--- /dev/null
+++ b/man/strongswan.conf.5
@@ -0,0 +1,910 @@
+.TH STRONGSWAN.CONF 5 "2010-09-09" "4.5.0rc2" "strongSwan"
+.SH NAME
+strongswan.conf \- strongSwan configuration file
+.SH DESCRIPTION
+While the
+.IR 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
+.I 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
+.IR strongswan.conf (5)
+was introduced which meets these requirements.
+
+.SH SYNTAX
+The format of the strongswan.conf file consists of hierarchical
+.B sections
+and a list of
+.B 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:
+.PP
+.EX
+	settings := (section|keyvalue)*
+	section  := name { settings }
+	keyvalue := key = value\\n
+.EE
+.PP
+Values must be terminated by a newline.
+.PP
+Comments are possible using the \fB#\fP-character, but be careful: The parser
+implementation is currently limited and does not like brackets in comments.
+.PP
+Section names and keys may contain any printable character except:
+.PP
+.EX
+	. { } # \\n \\t space
+.EE
+.PP
+An example file in this format might look like this:
+.PP
+.EX
+	a = b
+	section-one {
+		somevalue = asdf
+		subsection {
+			othervalue = xxx
+		}
+		# yei, a comment
+		yetanother = zz
+	}
+	section-two {
+		x = 12
+	}
+.EE
+.PP
+Indentation is optional, you may use tabs or spaces.
+
+.SH READING VALUES
+Values are accessed using a dot-separated section list and a key.
+With reference to the example above, accessing
+.B section-one.subsection.othervalue
+will return
+.BR xxx .
+
+.SH DEFINED KEYS
+The following keys are currently defined (using dot notation). The default
+value (if any) is listed in brackets after the key.
+
+.SS charon section
+.TP
+.BR charon.block_threshold " [5]"
+Maximum number of half-open IKE_SAs for a single peer IP
+.TP
+.BR charon.close_ike_on_child_failure " [no]"
+Close the IKE_SA if setup of the CHILD_SA along with IKE_AUTH failed
+.TP
+.BR charon.cookie_threshold " [10]"
+Number of half-open IKE_SAs that activate the cookie mechanism
+.TP
+.BR charon.dns1
+.TQ
+.BR charon.dns2
+DNS servers assigned to peer via configuration payload (CP)
+.TP
+.BR charon.dos_protection " [yes]"
+Enable Denial of Service protection using cookies and aggressiveness checks
+.TP
+.BR charon.filelog
+Section to define file loggers, see LOGGER CONFIGURATION
+.TP
+.BR charon.flush_auth_cfg " [no]"
+
+.TP
+.BR charon.hash_and_url " [no]"
+Enable hash and URL support
+.TP
+.BR charon.ignore_routing_tables
+A list of routing tables to be excluded from route lookup
+.TP
+.BR charon.ikesa_table_segments " [1]"
+Number of exclusively locked segments in the hash table
+.TP
+.BR charon.ikesa_table_size " [1]"
+Size of the IKE_SA hash table
+.TP
+.BR charon.inactivity_close_ike " [no]"
+Whether to close IKE_SA if the only CHILD_SA closed due to inactivity
+.TP
+.BR charon.install_routes " [yes]"
+Install routes into a separate routing table for established IPsec tunnels
+.TP
+.BR charon.install_virtual_ip " [yes]"
+Install virtual IP addresses
+.TP
+.BR charon.keep_alive " [20s]"
+NAT keep alive interval
+.TP
+.BR charon.load
+Plugins to load in the IKEv2 daemon charon
+.TP
+.BR charon.max_packet " [10000]"
+Maximum packet size accepted by charon
+.TP
+.BR charon.multiple_authentication " [yes]"
+Enable multiple authentication exchanges (RFC 4739)
+.TP
+.BR charon.nbns1
+.TQ
+.BR charon.nbns2
+WINS servers assigned to peer via configuration payload (CP)
+.TP
+.BR charon.process_route " [yes]"
+Process RTM_NEWROUTE and RTM_DELROUTE events
+.TP
+.BR charon.receive_delay " [0]"
+Delay for receiving packets, to simulate larger RTT
+.TP
+.BR charon.receive_delay_response " [yes]"
+Delay response messages
+.TP
+.BR charon.receive_delay_request " [yes]"
+Delay request messages
+.TP
+.BR charon.receive_delay_type " [0]"
+Specific IKEv2 message type to delay, 0 for any
+.TP
+.BR charon.retransmit_base " [1.8]"
+Base to use for calculating exponential back off, see IKEv2 RETRANSMISSION
+.TP
+.BR charon.retransmit_timeout " [4.0]
+Timeout in seconds before sending first retransmit
+.TP
+.BR charon.retransmit_tries " [5]"
+Number of times to retransmit a packet before giving up
+.TP
+.BR charon.reuse_ikesa " [yes]
+Initiate CHILD_SA within existing IKE_SAs
+.TP
+.BR charon.routing_table
+Numerical routing table to install routes to
+.TP
+.BR charon.routing_table_prio
+Priority of the routing table
+.TP
+.BR charon.send_delay " [0]"
+Delay for sending packets, to simulate larger RTT
+.TP
+.BR charon.send_delay_response " [yes]"
+Delay response messages
+.TP
+.BR charon.send_delay_request " [yes]"
+Delay request messages
+.TP
+.BR charon.send_delay_type " [0]"
+Specific IKEv2 message type to delay, 0 for any
+.TP
+.BR charon.send_vendor_id " [no]
+Send strongSwan vendor ID payload
+.TP
+.BR charon.syslog
+Section to define syslog loggers, see LOGGER CONFIGURATION
+.TP
+.BR charon.threads " [16]"
+Number of worker threads in charon
+.SS charon.plugins subsection
+.TP
+.BR charon.plugins.android.loglevel " [1]"
+Loglevel for logging to Android specific logger
+.TP
+.BR charon.plugins.attr
+Section to specify arbitrary attributes that are assigned to a peer via
+configuration payload (CP)
+.TP
+.BR charon.plugins.dhcp.identity_lease " [no]"
+Derive user-defined MAC address from hash of IKEv2 identity
+.TP
+.BR charon.plugins.dhcp.server " [255.255.255.255]"
+DHCP server unicast or broadcast IP address
+.TP
+.BR charon.plugins.eap-aka.request_identity " [yes]"
+
+.TP
+.BR charon.plugins.eap-aka-3ggp2.seq_check
+
+.TP
+.BR charon.plugins.eap-gtc.pam_service " [login]"
+PAM service to be used for authentication
+.TP
+.BR charon.plugins.eap-radius.class_group " [no]"
+Use the
+.I class
+attribute sent in the RADIUS-Accept message as group membership information that
+is compared to the groups specified in the
+.B rightgroups
+option in
+.B ipsec.conf (5).
+.TP
+.BR charon.plugins.eap-radius.eap_start " [no]"
+Send EAP-Start instead of EAP-Identity to start RADIUS conversation
+.TP
+.BR charon.plugins.eap-radius.filter_id " [no]"
+If the RADIUS
+.I tunnel_type
+attribute with value
+.B ESP
+is received, use the
+.I filter_id 
+attribute sent in the RADIUS-Accept message as group membership information that
+is compared to the groups specified in the
+.B rightgroups
+option in
+.B ipsec.conf (5).
+.TP
+.BR charon.plugins.eap-radius.id_prefix
+Prefix to EAP-Identity, some AAA servers use a IMSI prefix to select the
+EAP method
+.TP
+.BR charon.plugins.eap-radius.nas_identifier " [strongSwan]"
+NAS-Identifier to include in RADIUS messages
+.TP
+.BR charon.plugins.eap-radius.port " [1812]"
+Port of RADIUS server (authentication)
+.TP
+.BR charon.plugins.eap-radius.secret
+Shared secret between RADIUS and NAS
+.TP
+.BR charon.plugins.eap-radius.server
+IP/Hostname of RADIUS server
+.TP
+.BR charon.plugins.eap-radius.servers
+Section to specify multiple RADIUS servers. The
+.BR nas_identifier ,
+.BR secret ,
+.B sockets
+and
+.B port
+options can be specified for each server. A server's IP/Hostname can be
+configured using the
+.B address
+option. For each RADIUS server a priority can be specified using the
+.BR preference " [0]"
+option.
+.TP
+.BR charon.plugins.eap-radius.sockets " [1]"
+Number of sockets (ports) to use, increase for high load
+.TP
+.BR charon.plugins.eap-sim.request_identity " [yes]"
+
+.TP
+.BR charon.plugins.eap-simaka-sql.database
+
+.TP
+.BR charon.plugins.eap-simaka-sql.remove_used
+
+.TP
+.BR charon.plugins.eap-tls.fragment_size " [1024]"
+Maximum size of an EAP-TLS packet
+.TP
+.BR charon.plugins.eap-tls.max_message_count " [32]"
+Maximum number of processed EAP-TLS packets
+.TP
+.BR charon.plugins.eap-tnc.fragment_size " [50000]"
+Maximum size of an EAP-TNC packet
+.TP
+.BR charon.plugins.eap-tnc.max_message_count " [10]"
+Maximum number of processed EAP-TNC packets
+.TP
+.BR charon.plugins.eap-ttls.fragment_size " [1024]"
+Maximum size of an EAP-TTLS packet
+.TP
+.BR charon.plugins.eap-ttls.max_message_count " [32]"
+Maximum number of processed EAP-TTLS packets
+.TP
+.BR charon.plugins.eap-ttls.phase2_method " [md5]"
+Phase2 EAP client authentication method
+.TP
+.BR charon.plugins.eap-ttls.phase2_piggyback " [no]"
+Phase2 EAP Identity request piggybacked by server onto TLS Finished message
+.TP
+.BR charon.plugins.eap-ttls.phase2_tnc " [no]"
+Start phase2 EAP TNC protocol after successful client authentication
+.TP
+.BR charon.plugins.eap-ttls.request_peer_auth " [no]"
+Request peer authentication based on a client certificate
+.TP
+.BR charon.plugins.ha.fifo_interface " [yes]"
+
+.TP
+.BR charon.plugins.ha.heartbeat_delay " [1000]"
+
+.TP
+.BR charon.plugins.ha.heartbeat_timeout " [2100]"
+
+.TP
+.BR charon.plugins.ha.local
+
+.TP
+.BR charon.plugins.ha.monitor " [yes]"
+
+.TP
+.BR charon.plugins.ha.pools
+
+.TP
+.BR charon.plugins.ha.remote
+ 
+.TP
+.BR charon.plugins.ha.resync " [yes]"
+
+.TP
+.BR charon.plugins.ha.secret
+
+.TP
+.BR charon.plugins.ha.segment_count " [1]"
+
+.TP
+.BR charon.plugins.led.activity_led
+
+.TP
+.BR charon.plugins.led.blink_time " [50]"
+
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_count " [4]"
+Number of ipsecN devices
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_mtu " [0]"
+Set MTU of ipsecN device
+.TP
+.BR charon.plugins.load-tester
+Section to configure the load-tester plugin, see LOAD TESTS
+.TP
+.BR charon.plugins.resolve.file " [/etc/resolv.conf]"
+File where to add DNS server entries
+.TP
+.BR charon.plugins.sql.database
+Database URI for charons SQL plugin
+.TP
+.BR charon.plugins.sql.loglevel " [-1]"
+Loglevel for logging to SQL database
+.TP
+.BR charon.plugins.tnc-imc.preferred_language " [en]"
+Preferred language for TNC recommendations
+.TP
+.BR charon.plugins.tnc-imc.tnc_config " [/etc/tnc_config]"
+TNC IMC configuration directory
+.TP
+.BR charon.plugins.tnc-imv.tnc_config " [/etc/tnc_config]"
+TNC IMV configuration directory
+.SS libstrongswan section
+.TP
+.BR libstrongswan.crypto_test.bench " [no]"
+
+.TP
+.BR libstrongswan.crypto_test.bench_size " [1024]"
+
+.TP
+.BR libstrongswan.crypto_test.bench_time " [50]"
+
+.TP
+.BR libstrongswan.crypto_test.on_add " [no]"
+Test crypto algorithms during registration
+.TP
+.BR libstrongswan.crypto_test.on_create " [no]"
+Test crypto algorithms on each crypto primitive instantiation
+.TP
+.BR libstrongswan.crypto_test.required " [no]"
+Strictly require at least one test vector to enable an algorithm
+.TP
+.BR libstrongswan.crypto_test.rng_true " [no]"
+Whether to test RNG with TRUE quality; requires a lot of entropy
+.TP
+.BR libstrongswan.dh_exponent_ansi_x9_42 " [yes]"
+Use ANSI X9.42 DH exponent size or optimum size matched to cryptographical
+strength
+.TP
+.BR libstrongswan.ecp_x_coordinate_only " [yes]"
+Compliance with the errata for RFC 4753
+.TP
+.BR libstrongswan.integrity_test " [no]"
+Check daemon, libstrongswan and plugin integrity at startup
+.TP
+.BR libstrongswan.leak_detective.detailed " [yes]"
+Includes source file names and line numbers in leak detective output
+.SS libstrongswan.plugins subsection
+.TP
+.BR libstrongswan.plugins.attr-sql.database
+Database URI for attr-sql plugin used by charon and pluto
+.TP
+.BR libstrongswan.plugins.attr-sql.lease_history " [yes]"
+Enable logging of SQL IP pool leases
+.TP
+.BR libstrongswan.plugins.gcrypt.quick_random " [no]"
+Use faster random numbers in gcrypt; for testing only, produces weak keys!
+.TP
+.BR libstrongswan.plugins.openssl.engine_id " [pkcs11]"
+ENGINE ID to use in the OpenSSL plugin
+.TP
+.BR libstrongswan.plugins.pkcs11.modules
+
+.TP
+.BR libstrongswan.plugins.pkcs11.use_hasher " [no]"
+
+.TP
+.BR libstrongswan.plugins.x509.enforce_critical " [no]"
+Discard certificates with unsupported or unknown critical extensions
+.SS libtls section
+.TP
+.BR libtls.cipher
+List of TLS encryption ciphers
+.TP
+.BR libtls.key_exchange
+List of TLS key exchange methods
+.TP
+.BR libtls.mac
+List of TLS MAC algorithms
+.TP
+.BR libtls.suites
+List of TLS cipher suites
+.SS manager section
+.TP
+.BR manager.database
+Credential database URI for manager
+.TP
+.BR manager.debug " [no]"
+Enable debugging in manager
+.TP
+.BR manager.load
+Plugins to load in manager
+.TP
+.BR manager.socket
+FastCGI socket of manager, to run it statically
+.TP
+.BR manager.threads " [10]"
+Threads to use for request handling
+.TP
+.BR manager.timeout " [15m]"
+Session timeout for manager
+.SS mediation client section
+.TP
+.BR medcli.database
+Mediation client database URI
+.TP
+.BR medcli.dpd " [5m]"
+DPD timeout to use in mediation client plugin
+.TP
+.BR medcli.rekey " [20m]"
+Rekeying time on mediation connections in mediation client plugin
+.SS mediation server section
+.TP
+.BR medsrv.database
+Mediation server database URI
+.TP
+.BR medsrv.debug " [no]"
+Debugging in mediation server web application
+.TP
+.BR medsrv.dpd " [5m]"
+DPD timeout to use in mediation server plugin
+.TP
+.BR medsrv.load
+Plugins to load in mediation server plugin
+.TP
+.BR medsrv.password_length " [6]"
+Minimum password length required for mediation server user accounts
+.TP
+.BR medsrv.rekey " [20m]"
+Rekeying time on mediation connections in mediation server plugin
+.TP
+.BR medsrv.socket
+Run Mediation server web application statically on socket
+.TP
+.BR medsrv.threads " [5]"
+Number of thread for mediation service web application
+.TP
+.BR medsrv.timeout " [15m]"
+Session timeout for mediation service
+.SS openac section
+.TP
+.BR openac.load
+Plugins to load in ipsec openac tool
+.SS pki section
+.TP
+.BR pki.load
+Plugins to load in ipsec pki tool
+.SS pluto section
+.TP
+.BR pluto.dns1
+.TQ
+.BR pluto.dns2
+DNS servers assigned to peer via Mode Config
+.TP
+.BR pluto.load
+Plugins to load in IKEv1 pluto daemon
+.TP
+.BR pluto.nbns1
+.TQ
+.BR pluto.nbns2
+WINS servers assigned to peer via Mode Config
+.TP
+.BR pluto.threads " [4]"
+Number of worker threads in pluto
+.SS pluto.plugins section
+.TP
+.BR pluto.plugins.attr
+Section to specify arbitrary attributes that are assigned to a peer via
+Mode Config
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_count " [4]"
+Number of ipsecN devices
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_mtu " [0]"
+Set MTU of ipsecN device
+.SS pool section
+.TP
+.BR pool.load
+Plugins to load in ipsec pool tool
+.SS scepclient section
+.TP
+.BR scepclient.load
+Plugins to load in ipsec scepclient tool
+.SS starter section
+.TP
+.BR starter.load_warning " [yes]"
+Disable charon/pluto plugin load option warning
+
+.SH LOGGER CONFIGURATION
+The options described below provide a much more flexible way to configure
+loggers for the IKEv2 daemon charon than using the
+.B charondebug
+option in
+.BR ipsec.conf (5).
+.PP
+.B Please note
+that if any loggers are specified in strongswan.conf,
+.B charondebug
+does not have any effect.
+.PP
+There are currently two types of loggers defined:
+.TP
+.B File loggers
+Log directly to a file and are defined by specifying the full path to the
+file as subsection in the
+.B charon.filelog
+section. To log to the console the two special filenames
+.BR stdout " and " stderr
+can be used.
+.TP
+.B 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
+.B charon.syslog
+section. The following facilities are currently supported:
+.BR daemon " and " auth .
+.PP
+Multiple loggers can be defined for each type with different log verbosity for
+the different subsystems of the daemon.
+.SS Options
+.TP
+.BR charon.filelog.<filename>.default " [1]"
+.TQ
+.BR charon.syslog.<facility>.default
+Specifies the default loglevel to be used for subsystems for which no specific
+loglevel is defined.
+.TP
+.BR charon.filelog.<filename>.<subsystem> " [<default>]"
+.TQ
+.BR charon.syslog.<facility>.<subsystem>
+Specifies the loglevel for the given subsystem.
+.TP
+.BR charon.filelog.<filename>.append " [yes]"
+If this option is enabled log entries are appended to the existing file.
+.TP
+.BR charon.filelog.<filename>.flush_line " [no]"
+Enabling this option disables block buffering and enables line buffering.
+.TP
+.BR charon.filelog.<filename>.ike_name " [no]"
+.TQ
+.BR charon.syslog.<facility>.ike_name
+Prefix each log entry with the connection name and a unique numerical
+identifier for each IKE_SA.
+.TP
+.BR charon.filelog.<filename>.time_format
+Prefix each log entry with a timestamp. The option accepts a format string as
+passed to
+.BR strftime (3).
+
+.SS Subsystems
+.TP
+.B dmn
+Main daemon setup/cleanup/signal handling
+.TP
+.B mgr
+IKE_SA manager, handling synchronization for IKE_SA access
+.TP
+.B ike
+IKE_SA
+.TP
+.B chd
+CHILD_SA
+.TP
+.B job
+Jobs queueing/processing and thread pool management
+.TP
+.B cfg
+Configuration management and plugins
+.TP
+.B knl
+IPsec/Networking kernel interface
+.TP
+.B net
+IKE network communication
+.TP
+.B enc
+Packet encoding/decoding encryption/decryption operations
+.TP
+.B tls
+libtls library messages
+.TP
+.B lib
+libstrongwan library messages
+.SS Loglevels
+.TP
+.B -1
+Absolutely silent
+.TP
+.B 0
+Very basic auditing logs, (e.g. SA up/SA down)
+.TP
+.B 1
+Generic control flow with errors, a good default to see whats going on
+.TP
+.B 2
+More detailed debugging control flow
+.TP
+.B 3
+Including RAW data dumps in Hex
+.TP
+.B 4
+Also include sensitive material in dumps, e.g. keys
+.SS Example
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+
+.SH 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.
+.PP
+.B WARNING:
+Never enable the load-testing plugin on productive systems. It provides
+preconfigured credentials and allows an attacker to authenticate as any user.
+.SS Options
+.TP
+.BR charon.plugins.load-tester.child_rekey " [600]"
+Seconds to start CHILD_SA rekeying after setup
+.TP
+.BR charon.plugins.load-tester.delay " [0]"
+Delay between initiatons for each thread
+.TP
+.BR charon.plugins.load-tester.delete_after_established " [no]"
+Delete an IKE_SA as soon as it has been established
+.TP
+.BR charon.plugins.load-tester.dynamic_port " [0]"
+Base port to be used for requests (each client uses a different port)
+.TP
+.BR charon.plugins.load-tester.enable " [no]"
+Enable the load testing plugin
+.TP
+.BR charon.plugins.load-tester.fake_kernel " [no]"
+Fake the kernel interface to allow load-testing against self
+.TP
+.BR charon.plugins.load-tester.ike_rekey " [0]"
+Seconds to start IKE_SA rekeying after setup
+.TP
+.BR charon.plugins.load-tester.initiators " [0]"
+Number of concurrent initiator threads to use in load test
+.TP
+.BR charon.plugins.load-tester.initiator_auth " [pubkey]"
+Authentication method(s) the intiator uses
+.TP
+.BR charon.plugins.load-tester.iterations " [1]"
+Number of IKE_SAs to initate by each initiator in load test
+.TP
+.BR charon.plugins.load-tester.pool
+Provide INTERNAL_IPV4_ADDRs from a named pool
+.TP
+.BR charon.plugins.load-tester.proposal " [aes128-sha1-modp768]"
+IKE proposal to use in load test
+.TP
+.BR charon.plugins.load-tester.remote " [127.0.0.1]"
+Address to initiation connections to
+.TP
+.BR charon.plugins.load-tester.responder_auth " [pubkey]"
+Authentication method(s) the responder uses
+.TP
+.BR charon.plugins.load-tester.request_virtual_ip " [no]"
+Request an INTERNAL_IPV4_ADDR from the server
+.TP
+.BR charon.plugins.load-tester.shutdown_when_complete " [no]"
+Shutdown the daemon after all IKE_SAs have been established
+.SS Configuration details
+For public key authentication, the responder uses the
+.B \(dqCN=srv, OU=load-test, O=strongSwan\(dq
+identity. For the initiator, each connection attempt uses a different identity
+in the form
+.BR "\(dqCN=c1-r1, OU=load-test, O=strongSwan\(dq" ,
+where the first number inidicates the client number, the second the
+authentication round (if multiple authentication is used).
+.PP
+For PSK authentication, FQDN identities are used. The server uses
+.BR srv.strongswan.org ,
+the client uses an identity in the form
+.BR c1-r1.strongswan.org .
+.PP
+For EAP authentication, the client uses a NAI in the form
+.BR 100000000010001@strongswan.org .
+.PP
+To configure multiple authentication, concatenate multiple methods using, e.g.
+.EX
+	initiator_auth = pubkey|psk|eap-md5|eap-aka
+.EE
+.PP
+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.
+.PP
+To speed up testing, the load tester plugin implements a special Diffie-Hellman
+implementation called modpnull. By setting
+.EX
+	proposal = aes128-sha1-modpnull
+.EE
+this wicked fast DH implementation is used. It does not provide any security
+at all, but allows to run tests without DH calculation overhead.
+.SS Examples
+.PP
+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.
+.PP
+A simple loopback configuration might look like this:
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+.PP
+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.
+.PP
+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:
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+
+.SH IKEv2 RETRANSMISSION
+Retransmission timeouts in the IKEv2 daemon charon can be configured globally
+using the three keys listed below:
+.PP
+.RS
+.nf
+.BR charon.retransmit_base " [1.8]"
+.BR charon.retransmit_timeout " [4.0]"
+.BR charon.retransmit_tries " [5]"
+.fi
+.RE
+.PP
+The following algorithm is used to calculate the timeout:
+.PP
+.EX
+	relative timeout = retransmit_timeout * retransmit_base ^ (n-1)
+.EE
+.PP
+Where
+.I n
+is the current retransmission count.
+.PP
+Using the default values, packets are retransmitted in:
+
+.TS
+l r r
+---
+lB r r.
+Retransmission	Relative Timeout	Absolute Timeout
+1	4s	4s
+2	7s	11s
+3	13s	24s
+4	23s	47s
+5	42s	89s
+giving up	76s	165s
+.TE
+
+.SH FILES
+/etc/strongswan.conf
+
+.SH SEE ALSO
+ipsec.conf(5), ipsec.secrets(5), ipsec(8)
+.SH HISTORY
+Written for the
+.UR http://www.strongswan.org
+strongSwan project
+.UE
+by Tobias Brunner, Andreas Steffen and Martin Willi.
diff --git a/man/strongswan.conf.5.in b/man/strongswan.conf.5.in
new file mode 100644
index 000000000..77db9a3c0
--- /dev/null
+++ b/man/strongswan.conf.5.in
@@ -0,0 +1,910 @@
+.TH STRONGSWAN.CONF 5 "2010-09-09" "@IPSEC_VERSION@" "strongSwan"
+.SH NAME
+strongswan.conf \- strongSwan configuration file
+.SH DESCRIPTION
+While the
+.IR 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
+.I 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
+.IR strongswan.conf (5)
+was introduced which meets these requirements.
+
+.SH SYNTAX
+The format of the strongswan.conf file consists of hierarchical
+.B sections
+and a list of
+.B 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:
+.PP
+.EX
+	settings := (section|keyvalue)*
+	section  := name { settings }
+	keyvalue := key = value\\n
+.EE
+.PP
+Values must be terminated by a newline.
+.PP
+Comments are possible using the \fB#\fP-character, but be careful: The parser
+implementation is currently limited and does not like brackets in comments.
+.PP
+Section names and keys may contain any printable character except:
+.PP
+.EX
+	. { } # \\n \\t space
+.EE
+.PP
+An example file in this format might look like this:
+.PP
+.EX
+	a = b
+	section-one {
+		somevalue = asdf
+		subsection {
+			othervalue = xxx
+		}
+		# yei, a comment
+		yetanother = zz
+	}
+	section-two {
+		x = 12
+	}
+.EE
+.PP
+Indentation is optional, you may use tabs or spaces.
+
+.SH READING VALUES
+Values are accessed using a dot-separated section list and a key.
+With reference to the example above, accessing
+.B section-one.subsection.othervalue
+will return
+.BR xxx .
+
+.SH DEFINED KEYS
+The following keys are currently defined (using dot notation). The default
+value (if any) is listed in brackets after the key.
+
+.SS charon section
+.TP
+.BR charon.block_threshold " [5]"
+Maximum number of half-open IKE_SAs for a single peer IP
+.TP
+.BR charon.close_ike_on_child_failure " [no]"
+Close the IKE_SA if setup of the CHILD_SA along with IKE_AUTH failed
+.TP
+.BR charon.cookie_threshold " [10]"
+Number of half-open IKE_SAs that activate the cookie mechanism
+.TP
+.BR charon.dns1
+.TQ
+.BR charon.dns2
+DNS servers assigned to peer via configuration payload (CP)
+.TP
+.BR charon.dos_protection " [yes]"
+Enable Denial of Service protection using cookies and aggressiveness checks
+.TP
+.BR charon.filelog
+Section to define file loggers, see LOGGER CONFIGURATION
+.TP
+.BR charon.flush_auth_cfg " [no]"
+
+.TP
+.BR charon.hash_and_url " [no]"
+Enable hash and URL support
+.TP
+.BR charon.ignore_routing_tables
+A list of routing tables to be excluded from route lookup
+.TP
+.BR charon.ikesa_table_segments " [1]"
+Number of exclusively locked segments in the hash table
+.TP
+.BR charon.ikesa_table_size " [1]"
+Size of the IKE_SA hash table
+.TP
+.BR charon.inactivity_close_ike " [no]"
+Whether to close IKE_SA if the only CHILD_SA closed due to inactivity
+.TP
+.BR charon.install_routes " [yes]"
+Install routes into a separate routing table for established IPsec tunnels
+.TP
+.BR charon.install_virtual_ip " [yes]"
+Install virtual IP addresses
+.TP
+.BR charon.keep_alive " [20s]"
+NAT keep alive interval
+.TP
+.BR charon.load
+Plugins to load in the IKEv2 daemon charon
+.TP
+.BR charon.max_packet " [10000]"
+Maximum packet size accepted by charon
+.TP
+.BR charon.multiple_authentication " [yes]"
+Enable multiple authentication exchanges (RFC 4739)
+.TP
+.BR charon.nbns1
+.TQ
+.BR charon.nbns2
+WINS servers assigned to peer via configuration payload (CP)
+.TP
+.BR charon.process_route " [yes]"
+Process RTM_NEWROUTE and RTM_DELROUTE events
+.TP
+.BR charon.receive_delay " [0]"
+Delay for receiving packets, to simulate larger RTT
+.TP
+.BR charon.receive_delay_response " [yes]"
+Delay response messages
+.TP
+.BR charon.receive_delay_request " [yes]"
+Delay request messages
+.TP
+.BR charon.receive_delay_type " [0]"
+Specific IKEv2 message type to delay, 0 for any
+.TP
+.BR charon.retransmit_base " [1.8]"
+Base to use for calculating exponential back off, see IKEv2 RETRANSMISSION
+.TP
+.BR charon.retransmit_timeout " [4.0]
+Timeout in seconds before sending first retransmit
+.TP
+.BR charon.retransmit_tries " [5]"
+Number of times to retransmit a packet before giving up
+.TP
+.BR charon.reuse_ikesa " [yes]
+Initiate CHILD_SA within existing IKE_SAs
+.TP
+.BR charon.routing_table
+Numerical routing table to install routes to
+.TP
+.BR charon.routing_table_prio
+Priority of the routing table
+.TP
+.BR charon.send_delay " [0]"
+Delay for sending packets, to simulate larger RTT
+.TP
+.BR charon.send_delay_response " [yes]"
+Delay response messages
+.TP
+.BR charon.send_delay_request " [yes]"
+Delay request messages
+.TP
+.BR charon.send_delay_type " [0]"
+Specific IKEv2 message type to delay, 0 for any
+.TP
+.BR charon.send_vendor_id " [no]
+Send strongSwan vendor ID payload
+.TP
+.BR charon.syslog
+Section to define syslog loggers, see LOGGER CONFIGURATION
+.TP
+.BR charon.threads " [16]"
+Number of worker threads in charon
+.SS charon.plugins subsection
+.TP
+.BR charon.plugins.android.loglevel " [1]"
+Loglevel for logging to Android specific logger
+.TP
+.BR charon.plugins.attr
+Section to specify arbitrary attributes that are assigned to a peer via
+configuration payload (CP)
+.TP
+.BR charon.plugins.dhcp.identity_lease " [no]"
+Derive user-defined MAC address from hash of IKEv2 identity
+.TP
+.BR charon.plugins.dhcp.server " [255.255.255.255]"
+DHCP server unicast or broadcast IP address
+.TP
+.BR charon.plugins.eap-aka.request_identity " [yes]"
+
+.TP
+.BR charon.plugins.eap-aka-3ggp2.seq_check
+
+.TP
+.BR charon.plugins.eap-gtc.pam_service " [login]"
+PAM service to be used for authentication
+.TP
+.BR charon.plugins.eap-radius.class_group " [no]"
+Use the
+.I class
+attribute sent in the RADIUS-Accept message as group membership information that
+is compared to the groups specified in the
+.B rightgroups
+option in
+.B ipsec.conf (5).
+.TP
+.BR charon.plugins.eap-radius.eap_start " [no]"
+Send EAP-Start instead of EAP-Identity to start RADIUS conversation
+.TP
+.BR charon.plugins.eap-radius.filter_id " [no]"
+If the RADIUS
+.I tunnel_type
+attribute with value
+.B ESP
+is received, use the
+.I filter_id 
+attribute sent in the RADIUS-Accept message as group membership information that
+is compared to the groups specified in the
+.B rightgroups
+option in
+.B ipsec.conf (5).
+.TP
+.BR charon.plugins.eap-radius.id_prefix
+Prefix to EAP-Identity, some AAA servers use a IMSI prefix to select the
+EAP method
+.TP
+.BR charon.plugins.eap-radius.nas_identifier " [strongSwan]"
+NAS-Identifier to include in RADIUS messages
+.TP
+.BR charon.plugins.eap-radius.port " [1812]"
+Port of RADIUS server (authentication)
+.TP
+.BR charon.plugins.eap-radius.secret
+Shared secret between RADIUS and NAS
+.TP
+.BR charon.plugins.eap-radius.server
+IP/Hostname of RADIUS server
+.TP
+.BR charon.plugins.eap-radius.servers
+Section to specify multiple RADIUS servers. The
+.BR nas_identifier ,
+.BR secret ,
+.B sockets
+and
+.B port
+options can be specified for each server. A server's IP/Hostname can be
+configured using the
+.B address
+option. For each RADIUS server a priority can be specified using the
+.BR preference " [0]"
+option.
+.TP
+.BR charon.plugins.eap-radius.sockets " [1]"
+Number of sockets (ports) to use, increase for high load
+.TP
+.BR charon.plugins.eap-sim.request_identity " [yes]"
+
+.TP
+.BR charon.plugins.eap-simaka-sql.database
+
+.TP
+.BR charon.plugins.eap-simaka-sql.remove_used
+
+.TP
+.BR charon.plugins.eap-tls.fragment_size " [1024]"
+Maximum size of an EAP-TLS packet
+.TP
+.BR charon.plugins.eap-tls.max_message_count " [32]"
+Maximum number of processed EAP-TLS packets
+.TP
+.BR charon.plugins.eap-tnc.fragment_size " [50000]"
+Maximum size of an EAP-TNC packet
+.TP
+.BR charon.plugins.eap-tnc.max_message_count " [10]"
+Maximum number of processed EAP-TNC packets
+.TP
+.BR charon.plugins.eap-ttls.fragment_size " [1024]"
+Maximum size of an EAP-TTLS packet
+.TP
+.BR charon.plugins.eap-ttls.max_message_count " [32]"
+Maximum number of processed EAP-TTLS packets
+.TP
+.BR charon.plugins.eap-ttls.phase2_method " [md5]"
+Phase2 EAP client authentication method
+.TP
+.BR charon.plugins.eap-ttls.phase2_piggyback " [no]"
+Phase2 EAP Identity request piggybacked by server onto TLS Finished message
+.TP
+.BR charon.plugins.eap-ttls.phase2_tnc " [no]"
+Start phase2 EAP TNC protocol after successful client authentication
+.TP
+.BR charon.plugins.eap-ttls.request_peer_auth " [no]"
+Request peer authentication based on a client certificate
+.TP
+.BR charon.plugins.ha.fifo_interface " [yes]"
+
+.TP
+.BR charon.plugins.ha.heartbeat_delay " [1000]"
+
+.TP
+.BR charon.plugins.ha.heartbeat_timeout " [2100]"
+
+.TP
+.BR charon.plugins.ha.local
+
+.TP
+.BR charon.plugins.ha.monitor " [yes]"
+
+.TP
+.BR charon.plugins.ha.pools
+
+.TP
+.BR charon.plugins.ha.remote
+ 
+.TP
+.BR charon.plugins.ha.resync " [yes]"
+
+.TP
+.BR charon.plugins.ha.secret
+
+.TP
+.BR charon.plugins.ha.segment_count " [1]"
+
+.TP
+.BR charon.plugins.led.activity_led
+
+.TP
+.BR charon.plugins.led.blink_time " [50]"
+
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_count " [4]"
+Number of ipsecN devices
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_mtu " [0]"
+Set MTU of ipsecN device
+.TP
+.BR charon.plugins.load-tester
+Section to configure the load-tester plugin, see LOAD TESTS
+.TP
+.BR charon.plugins.resolve.file " [/etc/resolv.conf]"
+File where to add DNS server entries
+.TP
+.BR charon.plugins.sql.database
+Database URI for charons SQL plugin
+.TP
+.BR charon.plugins.sql.loglevel " [-1]"
+Loglevel for logging to SQL database
+.TP
+.BR charon.plugins.tnc-imc.preferred_language " [en]"
+Preferred language for TNC recommendations
+.TP
+.BR charon.plugins.tnc-imc.tnc_config " [/etc/tnc_config]"
+TNC IMC configuration directory
+.TP
+.BR charon.plugins.tnc-imv.tnc_config " [/etc/tnc_config]"
+TNC IMV configuration directory
+.SS libstrongswan section
+.TP
+.BR libstrongswan.crypto_test.bench " [no]"
+
+.TP
+.BR libstrongswan.crypto_test.bench_size " [1024]"
+
+.TP
+.BR libstrongswan.crypto_test.bench_time " [50]"
+
+.TP
+.BR libstrongswan.crypto_test.on_add " [no]"
+Test crypto algorithms during registration
+.TP
+.BR libstrongswan.crypto_test.on_create " [no]"
+Test crypto algorithms on each crypto primitive instantiation
+.TP
+.BR libstrongswan.crypto_test.required " [no]"
+Strictly require at least one test vector to enable an algorithm
+.TP
+.BR libstrongswan.crypto_test.rng_true " [no]"
+Whether to test RNG with TRUE quality; requires a lot of entropy
+.TP
+.BR libstrongswan.dh_exponent_ansi_x9_42 " [yes]"
+Use ANSI X9.42 DH exponent size or optimum size matched to cryptographical
+strength
+.TP
+.BR libstrongswan.ecp_x_coordinate_only " [yes]"
+Compliance with the errata for RFC 4753
+.TP
+.BR libstrongswan.integrity_test " [no]"
+Check daemon, libstrongswan and plugin integrity at startup
+.TP
+.BR libstrongswan.leak_detective.detailed " [yes]"
+Includes source file names and line numbers in leak detective output
+.SS libstrongswan.plugins subsection
+.TP
+.BR libstrongswan.plugins.attr-sql.database
+Database URI for attr-sql plugin used by charon and pluto
+.TP
+.BR libstrongswan.plugins.attr-sql.lease_history " [yes]"
+Enable logging of SQL IP pool leases
+.TP
+.BR libstrongswan.plugins.gcrypt.quick_random " [no]"
+Use faster random numbers in gcrypt; for testing only, produces weak keys!
+.TP
+.BR libstrongswan.plugins.openssl.engine_id " [pkcs11]"
+ENGINE ID to use in the OpenSSL plugin
+.TP
+.BR libstrongswan.plugins.pkcs11.modules
+
+.TP
+.BR libstrongswan.plugins.pkcs11.use_hasher " [no]"
+
+.TP
+.BR libstrongswan.plugins.x509.enforce_critical " [no]"
+Discard certificates with unsupported or unknown critical extensions
+.SS libtls section
+.TP
+.BR libtls.cipher
+List of TLS encryption ciphers
+.TP
+.BR libtls.key_exchange
+List of TLS key exchange methods
+.TP
+.BR libtls.mac
+List of TLS MAC algorithms
+.TP
+.BR libtls.suites
+List of TLS cipher suites
+.SS manager section
+.TP
+.BR manager.database
+Credential database URI for manager
+.TP
+.BR manager.debug " [no]"
+Enable debugging in manager
+.TP
+.BR manager.load
+Plugins to load in manager
+.TP
+.BR manager.socket
+FastCGI socket of manager, to run it statically
+.TP
+.BR manager.threads " [10]"
+Threads to use for request handling
+.TP
+.BR manager.timeout " [15m]"
+Session timeout for manager
+.SS mediation client section
+.TP
+.BR medcli.database
+Mediation client database URI
+.TP
+.BR medcli.dpd " [5m]"
+DPD timeout to use in mediation client plugin
+.TP
+.BR medcli.rekey " [20m]"
+Rekeying time on mediation connections in mediation client plugin
+.SS mediation server section
+.TP
+.BR medsrv.database
+Mediation server database URI
+.TP
+.BR medsrv.debug " [no]"
+Debugging in mediation server web application
+.TP
+.BR medsrv.dpd " [5m]"
+DPD timeout to use in mediation server plugin
+.TP
+.BR medsrv.load
+Plugins to load in mediation server plugin
+.TP
+.BR medsrv.password_length " [6]"
+Minimum password length required for mediation server user accounts
+.TP
+.BR medsrv.rekey " [20m]"
+Rekeying time on mediation connections in mediation server plugin
+.TP
+.BR medsrv.socket
+Run Mediation server web application statically on socket
+.TP
+.BR medsrv.threads " [5]"
+Number of thread for mediation service web application
+.TP
+.BR medsrv.timeout " [15m]"
+Session timeout for mediation service
+.SS openac section
+.TP
+.BR openac.load
+Plugins to load in ipsec openac tool
+.SS pki section
+.TP
+.BR pki.load
+Plugins to load in ipsec pki tool
+.SS pluto section
+.TP
+.BR pluto.dns1
+.TQ
+.BR pluto.dns2
+DNS servers assigned to peer via Mode Config
+.TP
+.BR pluto.load
+Plugins to load in IKEv1 pluto daemon
+.TP
+.BR pluto.nbns1
+.TQ
+.BR pluto.nbns2
+WINS servers assigned to peer via Mode Config
+.TP
+.BR pluto.threads " [4]"
+Number of worker threads in pluto
+.SS pluto.plugins section
+.TP
+.BR pluto.plugins.attr
+Section to specify arbitrary attributes that are assigned to a peer via
+Mode Config
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_count " [4]"
+Number of ipsecN devices
+.TP
+.BR charon.plugins.kernel-klips.ipsec_dev_mtu " [0]"
+Set MTU of ipsecN device
+.SS pool section
+.TP
+.BR pool.load
+Plugins to load in ipsec pool tool
+.SS scepclient section
+.TP
+.BR scepclient.load
+Plugins to load in ipsec scepclient tool
+.SS starter section
+.TP
+.BR starter.load_warning " [yes]"
+Disable charon/pluto plugin load option warning
+
+.SH LOGGER CONFIGURATION
+The options described below provide a much more flexible way to configure
+loggers for the IKEv2 daemon charon than using the
+.B charondebug
+option in
+.BR ipsec.conf (5).
+.PP
+.B Please note
+that if any loggers are specified in strongswan.conf,
+.B charondebug
+does not have any effect.
+.PP
+There are currently two types of loggers defined:
+.TP
+.B File loggers
+Log directly to a file and are defined by specifying the full path to the
+file as subsection in the
+.B charon.filelog
+section. To log to the console the two special filenames
+.BR stdout " and " stderr
+can be used.
+.TP
+.B 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
+.B charon.syslog
+section. The following facilities are currently supported:
+.BR daemon " and " auth .
+.PP
+Multiple loggers can be defined for each type with different log verbosity for
+the different subsystems of the daemon.
+.SS Options
+.TP
+.BR charon.filelog.<filename>.default " [1]"
+.TQ
+.BR charon.syslog.<facility>.default
+Specifies the default loglevel to be used for subsystems for which no specific
+loglevel is defined.
+.TP
+.BR charon.filelog.<filename>.<subsystem> " [<default>]"
+.TQ
+.BR charon.syslog.<facility>.<subsystem>
+Specifies the loglevel for the given subsystem.
+.TP
+.BR charon.filelog.<filename>.append " [yes]"
+If this option is enabled log entries are appended to the existing file.
+.TP
+.BR charon.filelog.<filename>.flush_line " [no]"
+Enabling this option disables block buffering and enables line buffering.
+.TP
+.BR charon.filelog.<filename>.ike_name " [no]"
+.TQ
+.BR charon.syslog.<facility>.ike_name
+Prefix each log entry with the connection name and a unique numerical
+identifier for each IKE_SA.
+.TP
+.BR charon.filelog.<filename>.time_format
+Prefix each log entry with a timestamp. The option accepts a format string as
+passed to
+.BR strftime (3).
+
+.SS Subsystems
+.TP
+.B dmn
+Main daemon setup/cleanup/signal handling
+.TP
+.B mgr
+IKE_SA manager, handling synchronization for IKE_SA access
+.TP
+.B ike
+IKE_SA
+.TP
+.B chd
+CHILD_SA
+.TP
+.B job
+Jobs queueing/processing and thread pool management
+.TP
+.B cfg
+Configuration management and plugins
+.TP
+.B knl
+IPsec/Networking kernel interface
+.TP
+.B net
+IKE network communication
+.TP
+.B enc
+Packet encoding/decoding encryption/decryption operations
+.TP
+.B tls
+libtls library messages
+.TP
+.B lib
+libstrongwan library messages
+.SS Loglevels
+.TP
+.B -1
+Absolutely silent
+.TP
+.B 0
+Very basic auditing logs, (e.g. SA up/SA down)
+.TP
+.B 1
+Generic control flow with errors, a good default to see whats going on
+.TP
+.B 2
+More detailed debugging control flow
+.TP
+.B 3
+Including RAW data dumps in Hex
+.TP
+.B 4
+Also include sensitive material in dumps, e.g. keys
+.SS Example
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+
+.SH 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.
+.PP
+.B WARNING:
+Never enable the load-testing plugin on productive systems. It provides
+preconfigured credentials and allows an attacker to authenticate as any user.
+.SS Options
+.TP
+.BR charon.plugins.load-tester.child_rekey " [600]"
+Seconds to start CHILD_SA rekeying after setup
+.TP
+.BR charon.plugins.load-tester.delay " [0]"
+Delay between initiatons for each thread
+.TP
+.BR charon.plugins.load-tester.delete_after_established " [no]"
+Delete an IKE_SA as soon as it has been established
+.TP
+.BR charon.plugins.load-tester.dynamic_port " [0]"
+Base port to be used for requests (each client uses a different port)
+.TP
+.BR charon.plugins.load-tester.enable " [no]"
+Enable the load testing plugin
+.TP
+.BR charon.plugins.load-tester.fake_kernel " [no]"
+Fake the kernel interface to allow load-testing against self
+.TP
+.BR charon.plugins.load-tester.ike_rekey " [0]"
+Seconds to start IKE_SA rekeying after setup
+.TP
+.BR charon.plugins.load-tester.initiators " [0]"
+Number of concurrent initiator threads to use in load test
+.TP
+.BR charon.plugins.load-tester.initiator_auth " [pubkey]"
+Authentication method(s) the intiator uses
+.TP
+.BR charon.plugins.load-tester.iterations " [1]"
+Number of IKE_SAs to initate by each initiator in load test
+.TP
+.BR charon.plugins.load-tester.pool
+Provide INTERNAL_IPV4_ADDRs from a named pool
+.TP
+.BR charon.plugins.load-tester.proposal " [aes128-sha1-modp768]"
+IKE proposal to use in load test
+.TP
+.BR charon.plugins.load-tester.remote " [127.0.0.1]"
+Address to initiation connections to
+.TP
+.BR charon.plugins.load-tester.responder_auth " [pubkey]"
+Authentication method(s) the responder uses
+.TP
+.BR charon.plugins.load-tester.request_virtual_ip " [no]"
+Request an INTERNAL_IPV4_ADDR from the server
+.TP
+.BR charon.plugins.load-tester.shutdown_when_complete " [no]"
+Shutdown the daemon after all IKE_SAs have been established
+.SS Configuration details
+For public key authentication, the responder uses the
+.B \(dqCN=srv, OU=load-test, O=strongSwan\(dq
+identity. For the initiator, each connection attempt uses a different identity
+in the form
+.BR "\(dqCN=c1-r1, OU=load-test, O=strongSwan\(dq" ,
+where the first number inidicates the client number, the second the
+authentication round (if multiple authentication is used).
+.PP
+For PSK authentication, FQDN identities are used. The server uses
+.BR srv.strongswan.org ,
+the client uses an identity in the form
+.BR c1-r1.strongswan.org .
+.PP
+For EAP authentication, the client uses a NAI in the form
+.BR 100000000010001@strongswan.org .
+.PP
+To configure multiple authentication, concatenate multiple methods using, e.g.
+.EX
+	initiator_auth = pubkey|psk|eap-md5|eap-aka
+.EE
+.PP
+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.
+.PP
+To speed up testing, the load tester plugin implements a special Diffie-Hellman
+implementation called modpnull. By setting
+.EX
+	proposal = aes128-sha1-modpnull
+.EE
+this wicked fast DH implementation is used. It does not provide any security
+at all, but allows to run tests without DH calculation overhead.
+.SS Examples
+.PP
+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.
+.PP
+A simple loopback configuration might look like this:
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+.PP
+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.
+.PP
+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:
+.PP
+.EX
+	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
+			}
+		}
+	}
+.EE
+
+.SH IKEv2 RETRANSMISSION
+Retransmission timeouts in the IKEv2 daemon charon can be configured globally
+using the three keys listed below:
+.PP
+.RS
+.nf
+.BR charon.retransmit_base " [1.8]"
+.BR charon.retransmit_timeout " [4.0]"
+.BR charon.retransmit_tries " [5]"
+.fi
+.RE
+.PP
+The following algorithm is used to calculate the timeout:
+.PP
+.EX
+	relative timeout = retransmit_timeout * retransmit_base ^ (n-1)
+.EE
+.PP
+Where
+.I n
+is the current retransmission count.
+.PP
+Using the default values, packets are retransmitted in:
+
+.TS
+l r r
+---
+lB r r.
+Retransmission	Relative Timeout	Absolute Timeout
+1	4s	4s
+2	7s	11s
+3	13s	24s
+4	23s	47s
+5	42s	89s
+giving up	76s	165s
+.TE
+
+.SH FILES
+/etc/strongswan.conf
+
+.SH SEE ALSO
+ipsec.conf(5), ipsec.secrets(5), ipsec(8)
+.SH HISTORY
+Written for the
+.UR http://www.strongswan.org
+strongSwan project
+.UE
+by Tobias Brunner, Andreas Steffen and Martin Willi.