- introduced autotools
authorMartin Willi <martin@strongswan.org>
Tue, 16 May 2006 14:24:03 +0000 (14:24 -0000)
committerMartin Willi <martin@strongswan.org>
Tue, 16 May 2006 14:24:03 +0000 (14:24 -0000)
  - first working version
  - make dist should work
  - things to do:
    - UML testing!
    - more cleanups

141 files changed:
AUTHORS [new file with mode: 0644]
CHANGES [deleted file]
ChangeLog [new file with mode: 0644]
LICENSE
Makefile [deleted file]
Makefile.am [new file with mode: 0644]
Makefile.inc [deleted file]
Makefile.ver [deleted file]
NEWS [new file with mode: 0644]
README [new file with mode: 0644]
README.pluto [deleted file]
configure.in [new file with mode: 0644]
src/Makefile [deleted file]
src/Makefile.am [new file with mode: 0644]
src/Makefile.program [deleted file]
src/_copyright/Makefile [deleted file]
src/_copyright/Makefile.am [new file with mode: 0644]
src/_updown/Makefile [deleted file]
src/_updown/Makefile.am [new file with mode: 0644]
src/_updown/_updown [new file with mode: 0755]
src/_updown/_updown.in [deleted file]
src/_updown_espmark/Makefile [deleted file]
src/_updown_espmark/Makefile.am [new file with mode: 0644]
src/_updown_espmark/_updown_espmark [new file with mode: 0644]
src/_updown_espmark/_updown_espmark.in [deleted file]
src/charon/Architecture.txt [deleted file]
src/charon/Known-bugs.txt [deleted file]
src/charon/Makefile [deleted file]
src/charon/Makefile.am [new file with mode: 0644]
src/charon/Makefile.charon [deleted file]
src/charon/Todo-list.txt [deleted file]
src/charon/config/Makefile.config [deleted file]
src/charon/config/connections/Makefile.connections [deleted file]
src/charon/config/credentials/Makefile.credentials [deleted file]
src/charon/config/policies/Makefile.policies [deleted file]
src/charon/daemon.h
src/charon/doc/Architecture.txt [new file with mode: 0644]
src/charon/doc/Known-bugs.txt [new file with mode: 0644]
src/charon/doc/Todo-list.txt [new file with mode: 0644]
src/charon/encoding/Makefile.encoding [deleted file]
src/charon/encoding/payloads/Makefile.payloads [deleted file]
src/charon/network/Makefile.network [deleted file]
src/charon/queues/Makefile.queues [deleted file]
src/charon/queues/jobs/Makefile.jobs [deleted file]
src/charon/sa/Makefile.sa [deleted file]
src/charon/sa/states/Makefile.states [deleted file]
src/charon/testing/Makefile.testcases [deleted file]
src/charon/threads/Makefile.threads [deleted file]
src/ipsec/Makefile [deleted file]
src/ipsec/Makefile.am [new file with mode: 0644]
src/ipsec/ipsec.8
src/ipsec/ipsec.in
src/libcrypto/Makefile.am
src/libcrypto/libaes/Makefile.am [deleted file]
src/libcrypto/libblowfish/Makefile.am [deleted file]
src/libcrypto/libdes/Makefile [deleted file]
src/libcrypto/libdes/Makefile.am [deleted file]
src/libcrypto/libserpent/Makefile.am [deleted file]
src/libcrypto/libsha2/Makefile.am [deleted file]
src/libcrypto/libtwofish/Makefile.am [deleted file]
src/libcrypto/oldlibdes/.cvsignore [deleted file]
src/libfreeswan/Makefile [deleted file]
src/libfreeswan/Makefile.am [new file with mode: 0644]
src/libfreeswan/Makefile.objs [deleted file]
src/libfreeswan/freeswan.h
src/libfreeswan/pfkey.h [new file with mode: 0644]
src/libfreeswan/pfkey_v2_build.c
src/libfreeswan/pfkey_v2_parse.c
src/libfreeswan/pfkeyv2.h [new file with mode: 0644]
src/libfreeswan/version.c [new file with mode: 0644]
src/libfreeswan/version.in.c [deleted file]
src/libstrongswan/Makefile.am [new file with mode: 0644]
src/openac/Makefile [deleted file]
src/openac/Makefile.am [new file with mode: 0644]
src/openac/loglite.c
src/openac/openac.c
src/pluto/Makefile [deleted file]
src/pluto/Makefile.am [new file with mode: 0644]
src/pluto/alg/Config.ike_alg
src/pluto/alg/Makefile [deleted file]
src/pluto/alg/Makefile.ike_alg_aes [deleted file]
src/pluto/alg/Makefile.ike_alg_blowfish [deleted file]
src/pluto/alg/Makefile.ike_alg_serpent [deleted file]
src/pluto/alg/Makefile.ike_alg_sha2 [deleted file]
src/pluto/alg/Makefile.ike_alg_twofish [deleted file]
src/pluto/alg/ike_alginit.c [new file with mode: 0644]
src/pluto/alg_info.c
src/pluto/ca.c
src/pluto/certs.c
src/pluto/certs.h
src/pluto/connections.c
src/pluto/constants.c
src/pluto/constants.h
src/pluto/crl.c
src/pluto/crypto.c
src/pluto/dnskey.c
src/pluto/foodgroups.c
src/pluto/id.c
src/pluto/ike_alg.c
src/pluto/ipsec_doi.c
src/pluto/kernel.c
src/pluto/kernel_alg.c
src/pluto/keys.c
src/pluto/keys.h
src/pluto/log.h
src/pluto/nat_traversal.c
src/pluto/ocsp.c
src/pluto/pem.c
src/pluto/pgp.c
src/pluto/pkcs7.c
src/pluto/rcv_info.c [deleted file]
src/pluto/rcv_info.h [deleted file]
src/pluto/server.c
src/pluto/smartcard.c
src/pluto/spdb.c
src/pluto/x509.c
src/scepclient/Makefile [deleted file]
src/scepclient/Makefile.am [new file with mode: 0644]
src/starter/Makefile [deleted file]
src/starter/Makefile.am [new file with mode: 0644]
src/starter/confread.h
src/starter/files.h
src/starter/interfaces.c
src/starter/lex.yy.c
src/starter/parser.l
src/starter/parser.output [deleted file]
src/starter/parser.tab.c [deleted file]
src/starter/parser.tab.h [deleted file]
src/starter/parser.y
src/starter/starter.c
src/starter/starterstroke.c
src/starter/starterwhack.c
src/starter/y.output [new file with mode: 0644]
src/starter/y.tab.c [new file with mode: 0644]
src/starter/y.tab.h [new file with mode: 0644]
src/stroke/Makefile.am [new file with mode: 0644]
src/stroke/stroke.c
src/whack/Makefile.am [new file with mode: 0644]
src/whack/whack.c
src/whack/whack.h
utils/manlink [deleted file]

diff --git a/AUTHORS b/AUTHORS
new file mode 100644 (file)
index 0000000..e69de29
diff --git a/CHANGES b/CHANGES
deleted file mode 100644 (file)
index 00aa018..0000000
--- a/CHANGES
+++ /dev/null
@@ -1,706 +0,0 @@
-strongswan-4.0.0
-----------------
-
-- initial support of the IKEv2 protocol. Connections in
-  ipsec.conf designated by keyexchange=ikev2 are negotiated 
-  by the new IKEv2 charon keying daemon whereas those marked
-  by keyexchange=ikev1 or the default keyexchange=ike are
-  handled thy the IKEv1 pluto keying daemon. Currently only
-  a limited subset of functions are available with IKEv2
-  (Default AES encryption, authentication based on locally
-  imported X.509 certificates, unencrypted private RSA keys
-  in PKCS#1 file format, limited functionality of the ipsec
-  status command).
-
-
-strongswan-2.7.0
-----------------
-
-- the dynamic iptables rules from the _updown_x509 template
-  for KLIPS and the _updown_policy template for NETKEY have
-  been merged into the default _updown script. The existing
-  left|rightfirewall keyword causes the automatic insertion
-  and deletion of ACCEPT rules for tunneled traffic upon
-  the successful setup and teardown of an IPsec SA, respectively.
-  left|rightfirwall can be used with KLIPS under any Linux 2.4
-  kernel or with NETKEY under a Linux kernel version >= 2.6.16
-  in conjuction with iptables >= 1.3.5. For NETKEY under a Linux
-  kernel version < 2.6.16 which does not support IPsec policy
-  matching yet, please continue to use a copy of the _updown_espmark
-  template loaded via the left|rightupdown keyword.
-
-- a new left|righthostaccess keyword has been introduced which
-  can be used in conjunction with left|rightfirewall and the
-  default _updown script. By default leftfirewall=yes inserts
-  a bi-directional iptables FORWARD rule for a local client network
-  with a netmask different from 255.255.255.255 (single host).
-  This does not allow to access the VPN gateway host via its
-  internal network interface which is part of the client subnet
-  because an iptables INPUT and OUTPUT rule would be required.
-  lefthostaccess=yes will cause this additional ACCEPT rules to
-  be inserted. 
-
-- mixed PSK|RSA roadwarriors are now supported. The ISAKMP proposal
-  payload is preparsed in order to find out whether the roadwarrior
-  requests PSK or RSA so that a matching connection candidate can
-  be found.
-
-
-strongswan-2.6.4
-----------------
-
-- the new _updown_policy template allows ipsec policy based
-  iptables firewall rules. Required are iptables version
-  >= 1.3.5 and linux kernel >= 2.6.16. This script obsoletes
-  the _updown_espmark template, so that no INPUT mangle rules 
-  are required any more.
-
-- added support of DPD restart mode
-
-- ipsec starter now allows the use of wildcards in include
-  statements as e.g. in "include /etc/my_ipsec/*.conf".
-  Patch courtesy of Matthias Haas.
-
-- the Netscape OID 'employeeNumber' is now recognized and can be
-  used as a Relative Distinguished Name in certificates.
-
-
-strongswan-2.6.3
-----------------
-
-- /etc/init.d/ipsec or /etc/rc.d/ipsec is now a copy of the ipsec 
-  command and not of ipsec setup any more.
-
-- ipsec starter now supports AH authentication in conjunction with
-  ESP encryption. AH authentication is configured in ipsec.conf
-  via the auth=ah parameter.
-  
-- The command ipsec scencrypt|scdecrypt <args> is now an alias for
-  ipsec whack --scencrypt|scdecrypt <args>.
-
-- get_sa_info() now determines for the native netkey IPsec stack
-  the exact time of the last use of an active eroute. This information
-  is used by the Dead Peer Detection algorithm and is also displayed by
-  the ipsec status command.
-  
-
-strongswan-2.6.2
-----------------
-
-- running under the native Linux 2.6 IPsec stack, the function
-  get_sa_info() is called by ipsec auto --status to display the current
-  number of transmitted bytes per IPsec SA.
-
-- get_sa_info() is also used  by the Dead Peer Detection process to detect
-  recent ESP activity. If ESP traffic was received from the peer within
-  the last dpd_delay interval then no R_Y_THERE notification must be sent.
-
-- strongSwan now supports the Relative Distinguished Name "unstructuredName"
-  in ID_DER_ASN1_DN identities. The following notations are possible:
-
-    rightid="unstructuredName=John Doe"
-    rightid="UN=John Doe"
-
-- fixed a long-standing bug which caused PSK-based roadwarrior connections
-  to segfault in the function id.c:same_id() called by keys.c:get_secret()
-  if an FQDN, USER_FQDN, or Key ID was defined, as in the following example.
-
-  conn rw
-       right=%any
-       rightid=@foo.bar
-       authby=secret
-
-- the ipsec command now supports most ipsec auto commands (e.g. ipsec listall).
-
-- ipsec starter didn't set host_addr and client.addr ports in whack msg.
-
-- in order to guarantee backwards-compatibility with the script-based
-  auto function (e.g. auto --replace), the ipsec starter scripts stores
-  the defaultroute information in the temporary file /var/run/ipsec.info.
-
-- The compile-time option USE_XAUTH_VID enables the sending of the XAUTH
-  Vendor ID which is expected by Cisco PIX 7 boxes that act as IKE Mode Config
-  servers.
-
-- the ipsec starter now also recognizes the parameters authby=never and
-  type=passthrough|pass|drop|reject.
-
-
-strongswan-2.6.1
-----------------
-
-- ipsec starter now supports the also parameter which allows
-  a modular structure of the connection definitions. Thus
-  "ipsec start" is now ready to replace "ipsec setup".
-
-
-strongswan-2.6.0
-----------------
-
-- Mathieu Lafon's popular ipsec starter tool has been added to the
-  strongSwan distribution. Many thanks go to Stephan Scholz from astaro
-  for his integration work. ipsec starter is a C program which is going
-  to replace the various shell and awk starter scripts (setup, _plutoload,
-  _plutostart, _realsetup, _startklips, _confread, and auto). Since
-  ipsec.conf is now parsed only once, the starting of multiple tunnels is
-  accelerated tremedously.
-
-- Added support of %defaultroute to the ipsec starter. If the IP address
-  changes, a HUP signal to the ipsec starter will automatically 
-  reload pluto's connections.
-
-- moved most compile time configurations from pluto/Makefile to
-  Makefile.inc by defining the options USE_LIBCURL, USE_LDAP,
-  USE_SMARTCARD, and USE_NAT_TRAVERSAL_TRANSPORT_MODE.
-
-- removed the ipsec verify and ipsec newhostkey commands
-
-- fixed some 64-bit issues in formatted print statements
-
-- The scepclient functionality implementing the Simple Certificate
-  Enrollment Protocol (SCEP) is nearly complete but hasn't been
-  documented yet.
-
-
-strongswan-2.5.7
-----------------
-
-- CA certicates are now automatically loaded from a smartcard
-  or USB crypto token and appear in the ipsec auto --listcacerts
-  listing.
-
-
-strongswan-2.5.6
-----------------
-
-- when using "ipsec whack --scencrypt <data>" with  a PKCS#11
-  library that does not support the C_Encrypt() Cryptoki
-  function (e.g. OpenSC), the RSA encryption is done in
-  software using the public key fetched from the smartcard.
-
-- The scepclient function now allows to define the 
-  validity of a self-signed certificate using the --days,
-  --startdate, and --enddate options. The default validity
-  has been changed from one year to five years.
-
-
-strongswan-2.5.5
-----------------
-
-- the config setup parameter pkcs11proxy=yes opens pluto's PKCS#11
-  interface to other applications for RSA encryption and decryption
-  via the whack interface. Notation:
-
-  ipsec whack --scencrypt <data>
-             [--inbase  16|hex|64|base64|256|text|ascii]
-             [--outbase 16|hex|64|base64|256|text|ascii]
-             [--keyid <keyid>]
-
-  ipsec whack --scdecrypt <data>
-             [--inbase  16|hex|64|base64|256|text|ascii]
-             [--outbase 16|hex|64|base64|256|text|ascii]
-             [--keyid <keyid>]
-
-  The default setting for inbase and outbase is hex. 
-
-  The new proxy interface can be used for securing symmetric
-  encryption keys required by the cryptoloop or dm-crypt
-  disk encryption schemes, especially in the case when
-  pkcs11keepstate=yes causes pluto to lock the pkcs11 slot
-  permanently.
-
-- if the file /etc/ipsec.secrets is lacking during the startup of
-  pluto then the root-readable file /etc/ipsec.d/private/myKey.der
-  containing a 2048 bit RSA private key and a matching self-signed
-  certificate stored in the file /etc/ipsec.d/certs/selfCert.der
-  is automatically generated by calling the function
-
-  ipsec scepclient --out pkcs1 --out cert-self
-
-  scepclient was written by Jan Hutter and Martin Willi, students
-  at the University of Applied Sciences in Rapperswil, Switzerland.
-
-
-strongswan-2.5.4
-----------------
-
-- the current extension of the PKCS#7 framework introduced
-  a parsing error in PKCS#7 wrapped X.509 certificates that are
-  e.g. transmitted by Windows XP when multi-level CAs are used.
-  the parsing syntax has been fixed.
-
-- added a patch by Gerald Richter which tolerates multiple occurrences
-  of the ipsec0 interface when using KLIPS.
-
-
-strongswan-2.5.3
-----------------
-
-- with gawk-3.1.4 the word "default2 has become a protected
-  keyword for use in switch statements and cannot be used any
-  more in the strongSwan scripts. This problem has been
-  solved by renaming "default" to "defaults" and "setdefault"
-  in the scripts _confread and auto, respectively.
-
-- introduced the parameter leftsendcert with the values
-
-  always|yes (the default, always send a cert)
-  ifasked    (send the cert only upon a cert request)
-  never|no   (never send a cert, used for raw RSA keys and
-              self-signed certs) 
-
-- fixed the initialization of the ESP key length to a default of
-  128 bits in the case that the peer does not send a key length
-   attribute for AES encryption.
-
-- applied Herbert Xu's uniqueIDs patch
-
-- applied Herbert Xu's CLOEXEC patches
-
-
-strongswan-2.5.2
-----------------
-
-- CRLs can now be cached also in the case when the issuer's
-  certificate does not contain a subjectKeyIdentifier field.
-  In that case the subjectKeyIdentifier is computed by pluto as the
-  160 bit SHA-1 hash of the issuer's public key in compliance
-  with section 4.2.1.2 of RFC 3280.
-
-- Fixed a bug introduced by strongswan-2.5.1 which eliminated
-  not only multiple Quick Modes of a given connection but also
-  multiple connections between two security gateways.
-
-
-strongswan-2.5.1
-----------------
-
-- Under the native IPsec of the Linux 2.6 kernel, a %trap eroute
-  installed either by setting auto=route in ipsec.conf or by
-  a connection put into hold, generates an XFRM_AQUIRE event
-  for each packet that wants to use the not-yet exisiting
-  tunnel. Up to now each XFRM_AQUIRE event led to an entry in
-  the Quick Mode queue, causing multiple IPsec SA to be
-  established in rapid succession. Starting with strongswan-2.5.1
-  only a single IPsec SA is established per host-pair connection.
-
-- Right after loading the PKCS#11 module, all smartcard slots are
-  searched for certificates. The result can be viewed using
-  the command
-
-    ipsec auto --listcards
-
-  The certificate objects found in the slots are numbered
-  starting with #1, #2, etc. This position number can be used to address
-  certificates (leftcert=%smartcard) and keys (: PIN %smartcard)
-  in ipsec.conf and ipsec.secrets, respectively:
-
-    %smartcard      (selects object #1)
-    %smartcard#1    (selects object #1)
-    %smartcard#3    (selects object #3)
-
-  As an alternative the existing retrieval scheme can be used:
-
-    %smartcard:45   (selects object with id=45)
-    %smartcard0     (selects first object in slot 0)
-    %smartcard4:45  (selects object in slot 4 with id=45)
-
-- Depending on the settings of CKA_SIGN and CKA_DECRYPT
-  private key flags either C_Sign() or C_Decrypt() is used
-  to generate a signature.
-
-- The output buffer length parameter siglen in C_Sign()
-  is now initialized to the actual size of the output
-  buffer prior to the function call. This fixes the
-  CKR_BUFFER_TOO_SMALL error that could occur when using
-  the OpenSC PKCS#11 module.
-
-- Changed the initialization of the PKCS#11 CK_MECHANISM in
-  C_SignInit() to mech  = { CKM_RSA_PKCS, NULL_PTR, 0 }.
-
-- Refactored the RSA public/private key code and transferred it
-  from keys.c to the new pkcs1.c file as a preparatory step
-  towards the release of the SCEP client.
-
-
-strongswan-2.5.0
-----------------
-
-- The loading of a PKCS#11 smartcard library module during
-  runtime does not require OpenSC library functions any more
-  because the corresponding code has been integrated into
-  smartcard.c. Also the RSAREF pkcs11 header files have been
-  included in a newly created pluto/rsaref directory so that
-  no external include path has to be defined any longer.
-
-- A long-awaited feature has been implemented at last:
-  The local caching of CRLs fetched via HTTP or LDAP, activated
-  by the parameter cachecrls=yes in the config setup section
-  of ipsec.conf. The dynamically fetched CRLs are stored under
-  a unique file name containing the issuer's subjectKeyID
-  in /etc/ipsec.d/crls.
-  
-- Applied a one-line patch courtesy of Michael Richardson
-  from the Openswan project which fixes the kernel-oops
-  in KLIPS when an snmp daemon is running on the same box.
-
-
-strongswan-2.4.4
-----------------
-
-- Eliminated null length CRL distribution point strings.
-
-- Fixed a trust path evaluation bug introduced with 2.4.3
-
-
-strongswan-2.4.3
-----------------
-
-- Improved the joint OCSP / CRL revocation policy.
-  OCSP responses have precedence over CRL entries.
-
-- Introduced support of CRLv2 reason codes.
-
-- Fixed a bug with key-pad equipped readers which caused
-  pluto to prompt for the pin via the console when the first
-  occasion to enter the pin via the key-pad was missed.
-
-- When pluto is built with LDAP_V3 enabled, the library
-  liblber required by newer versions of openldap is now
-  included.
-
-
-strongswan-2.4.2
-----------------
-
-- Added the _updown_espmark template which requires all
-  incoming ESP traffic to be marked with a default mark
-  value of 50.
-  
-- Introduced the pkcs11keepstate parameter in the config setup
-  section of ipsec.conf. With pkcs11keepstate=yes the PKCS#11
-  session and login states are kept as long as possible during 
-  the lifetime of pluto. This means that a PIN entry via a key
-  pad has to be done only once.
-
-- Introduced the pkcs11module parameter in the config setup
-  section of ipsec.conf which specifies the PKCS#11 module
-  to be used with smart cards. Example:
-  
-    pkcs11module=/usr/lib/pkcs11/opensc-pkcs11.lo
-  
-- Added support of smartcard readers equipped with a PIN pad.
-
-- Added patch by Jay Pfeifer which detects when netkey
-  modules have been statically built into the Linux 2.6 kernel.
-
-- Added two patches by Herbert Xu. The first uses ip xfrm
-  instead of setkey to flush the IPsec policy database. The
-  second sets the optional flag in inbound IPComp SAs only.
-    
-- Applied Ulrich Weber's patch which fixes an interoperability
-  problem between native IPsec and KLIPS systems caused by
-  setting the replay window to 32 instead of 0 for ipcomp.
-
-
-strongswan-2.4.1
-----------------
-
-- Fixed a bug which caused an unwanted Mode Config request
-  to be initiated in the case where "right" was used to denote
-  the local side in ipsec.conf and "left" the remote side,
-  contrary to the recommendation that "right" be remote and
-  "left" be"local".
-
-
-strongswan-2.4.0a
------------------
-
-- updated Vendor ID to strongSwan-2.4.0
-
-- updated copyright statement to include David Buechi and
-  Michael Meier
-  
-  
-strongswan-2.4.0
-----------------
-
-- strongSwan now communicates with attached smartcards and
-  USB crypto tokens via the standardized PKCS #11 interface.
-  By default the OpenSC library from www.opensc.org is used
-  but any other PKCS#11 library could be dynamically linked.
-  strongSwan's PKCS#11 API was implemented by David Buechi
-  and Michael Meier, both graduates of the Zurich University
-  of Applied Sciences in Winterthur, Switzerland.
-
-- When a %trap eroute is triggered by an outgoing IP packet
-  then the native IPsec stack of the Linux 2.6 kernel [often/
-  always?] returns an XFRM_ACQUIRE message with an undefined
-  protocol family field and the connection setup fails.
-  As a workaround IPv4 (AF_INET) is now assumed.
-  
-- the results of the UML test scenarios are now enhanced 
-  with block diagrams of the virtual network topology used
-  in a particular test. 
-
-
-strongswan-2.3.2
-----------------
-
-- fixed IV used to decrypt informational messages.
-  This bug was introduced with Mode Config functionality.
-- fixed NCP Vendor ID.
-
-- undid one of Ulrich Weber's maximum udp size patches
-  because it caused a segmentation fault with NAT-ed
-  Delete SA messages.
-  
-- added UML scenarios wildcards and attr-cert which
-  demonstrate the implementation of IPsec policies based
-  on wildcard parameters contained in Distinguished Names and
-  on X.509 attribute certificates, respectively.
-
-
-strongswan-2.3.1
-----------------
-
-- Added basic Mode Config functionality
-
-- Added Mathieu Lafon's patch which upgrades the status of
-  the NAT-Traversal implementation to RFC 3947.
-- The _startklips script now also loads the xfrm4_tunnel
-  module.
-  
-- Added Ulrich Weber's netlink replay window size and
-  maximum udp size patches.
-
-- UML testing now uses the Linux 2.6.10 UML kernel by default.
-   
-
-strongswan-2.3.0
-----------------
-
-- Eric Marchionni and Patrik Rayo, both recent graduates from
-  the Zuercher Hochschule Winterthur in Switzerland, created a
-  User-Mode-Linux test setup for strongSwan. For more details
-  please read the INSTALL and README documents in the testing
-  subdirectory.
-
-- Full support of group attributes based on X.509 attribute
-  certificates. Attribute certificates can be generated 
-  using the openac facility. For more details see
-   
-  man ipsec_openac.
-  The group attributes can be used in connection definitions
-  in order to give IPsec access to specific user groups.
-  This is done with the new parameter left|rightgroups as in
-  
-  rightgroups="Research, Sales"
-
-  giving access to users possessing the group attributes
-  Research or Sales, only.
-
-- In Quick Mode clients with subnet mask /32 are now
-  coded as IP_V4_ADDRESS or IP_V6_ADDRESS. This should 
-  fix rekeying problems with the SafeNet/SoftRemote and NCP
-  Secure Entry Clients.
-
-- Changed the defaults of the ikelifetime and keylife parameters
-  to 3h and 1h, respectively. The maximum allowable values are
-  now both set to 24 h.
-
-- Suppressed notification wars between two IPsec peers that
-  could e.g. be triggered by incorrect ISAKMP encryption.
-
-- Public RSA keys can now have identical IDs if either the
-  issuing CA or the serial number is different. The serial
-  number of a certificate is now shown by the command
-  
-  ipsec auto --listpubkeys
-
-
-strongswan-2.2.2
-----------------
-
-- Added Tuomo Soini's sourceip feature which allows a strongSwan
-  roadwarrior to use a fixed Virtual IP (see README section 2.6)
-  and reduces the well-known four tunnel case on VPN gateways to
-  a single tunnel definition (see README section 2.4).
-
-- Fixed a bug occuring with NAT-Traversal enabled when the responder
-  suddenly turns initiator and the initiator cannot find a matching
-  connection because of the floated IKE port 4500.
-  
-- Removed misleading ipsec verify command from barf.
-
-- Running under the native IP stack, ipsec --version now shows
-  the Linux kernel version (courtesy to the Openswan project).
-
-
-strongswan-2.2.1
-----------------
-
-- Introduced the ipsec auto --listalgs monitoring command which lists
-  all currently registered IKE and ESP algorithms.
-
-- Fixed a bug in the ESP algorithm selection occuring when the strict flag
-  is set and the first proposed transform does not match.
-  
-- Fixed another deadlock in the use of the lock_certs_and_keys() mutex,
-  occuring when a smartcard is present.
-
-- Prevented that a superseded Phase1 state can trigger a DPD_TIMEOUT event.
-  
-- Fixed the printing of the notification names (null)
-
-- Applied another of Herbert Xu's Netlink patches.
-
-
-strongswan-2.2.0
-----------------
-
-- Support of Dead Peer Detection. The connection parameter
-
-    dpdaction=clear|hold
-     
-  activates DPD for the given connection.
-
-- The default Opportunistic Encryption (OE) policy groups are not
-  automatically included anymore. Those wishing to activate OE can include
-  the policy group with the following statement in ipsec.conf:
-  
-    include /etc/ipsec.d/examples/oe.conf
-  
-  The default for [right|left]rsasigkey is now set to %cert.
-
-- strongSwan now has a Vendor ID of its own which can be activated
-  using the compile option VENDORID
-
-- Applied Herbert Xu's patch which sets the compression algorithm correctly.
-
-- Applied Herbert Xu's patch fixing an ESPINUDP problem
-
-- Applied Herbert Xu's patch setting source/destination port numbers.
-
-- Reapplied one of Herbert Xu's NAT-Traversal patches which got
-  lost during the migration from SuperFreeS/WAN.
-  
-- Fixed a deadlock in the use of the lock_certs_and_keys() mutex.
-
-- Fixed the unsharing of alg parameters when instantiating group
-  connection.
-  
-
-strongswan-2.1.5
-----------------
-
-- Thomas Walpuski made me aware of a potential DoS attack via
-  a PKCS#7-wrapped certificate bundle which could overwrite valid CA
-  certificates in Pluto's authority certificate store. This vulnerability
-  was fixed by establishing trust in CA candidate certificates up to a
-  trusted root CA prior to insertion into Pluto's chained list.
-
-- replaced the --assign option by the -v option in the auto awk script
-  in order to make it run with mawk under debian/woody.
-
-
-strongswan-2.1.4
-----------------
-
-- Split of the status information between ipsec auto  --status (concise)
-  and ipsec auto --statusall (verbose). Both commands can be used with
-  an optional connection selector:
-
-    ipsec auto --status[all] <connection_name>
-
-- Added the description of X.509 related features to the ipsec_auto(8)
-  man page.
-
-- Hardened the ASN.1 parser in debug mode, especially the printing
-  of malformed distinguished names.
-
-- The size of an RSA public key received in a certificate is now restricted to
-
-    512 bits <= modulus length <= 8192 bits.
-
-- Fixed the debug mode enumeration.
-
-
-strongswan-2.1.3
-----------------
-
-- Fixed another PKCS#7 vulnerability which could lead to an
-  endless loop while following the X.509 trust chain.
-  
-
-strongswan-2.1.2
-----------------
-
-- Fixed the PKCS#7 vulnerability discovered by Thomas Walpuski
-  that accepted end certificates having identical issuer and subject
-  distinguished names in a multi-tier X.509 trust chain.
-  
-
-strongswan-2.1.1
-----------------
-
-- Removed all remaining references to ipsec_netlink.h in KLIPS.
-
-
-strongswan-2.1.0
-----------------
-
-- The new "ca" section allows to define the following parameters:
-
-  ca kool
-     cacert=koolCA.pem                   # cacert of kool CA
-     ocspuri=http://ocsp.kool.net:8001   # ocsp server
-     ldapserver=ldap.kool.net            # default ldap server
-     crluri=http://www.kool.net/kool.crl # crl distribution point
-     crluri2="ldap:///O=Kool, C= .."     # crl distribution point #2
-     auto=add                            # add, ignore
-     
-  The ca definitions can be monitored via the command
-  
-     ipsec auto --listcainfos
-
-- Fixed cosmetic corruption of /proc filesystem by integrating
-  D. Hugh Redelmeier's freeswan-2.06 kernel fixes.
-
-
-strongswan-2.0.2
-----------------
-
-- Added support for the 818043 NAT-Traversal update of Microsoft's
-  Windows 2000/XP IPsec client which sends an ID_FQDN during Quick Mode.
-  
-- A symbolic link to libcrypto is now added in the kernel sources 
-  during kernel compilation
-  
-- Fixed a couple of 64 bit issues (mostly casts to int).
-  Thanks to Ken Bantoft who checked my sources on a 64 bit platform.
-
-- Replaced s[n]printf() statements in the kernel by ipsec_snprintf().
-  Credits go to D. Hugh Redelmeier, Michael Richardson, and Sam Sgro
-  of the FreeS/WAN team who solved this problem with the 2.4.25 kernel.
-
-
-strongswan-2.0.1
-----------------
-
-- an empty ASN.1 SEQUENCE OF or SET OF object (e.g. a subjectAltName
-  certificate extension which contains no generalName item)  can cause
-  a pluto crash. This bug has been fixed. Additionally the ASN.1 parser has
-  been hardened to make it more robust against malformed ASN.1 objects.
-
-- applied Herbert Xu's NAT-T patches which fixes NAT-T under the native
-  Linux 2.6 IPsec stack.
-  
-  
-strongswan-2.0.0
-----------------
-
-- based on freeswan-2.04, x509-1.5.3, nat-0.6c, alg-0.8.1rc12
diff --git a/ChangeLog b/ChangeLog
new file mode 100644 (file)
index 0000000..e69de29
diff --git a/LICENSE b/LICENSE
index 1dc0f01..0b84bc0 100644 (file)
--- a/LICENSE
+++ b/LICENSE
@@ -5,22 +5,22 @@ see the file COPYING.
 See the file CREDITS for details on origins of more of the code. 
 
 The DES library is under a BSD style license, see
-       linux/crypto/ciphers/des/COPYRIGHT.
+       src/libcrypto/libdes/COPYRIGHT.
 Note that this software has a advertising clause in it. 
 
 The MD2 implementation is from RSA Data Security Inc., so this package must
 include the following phrase: "RSA Data Security, Inc. MD2 Message Digest
-Algorithm"  It is not under the GPL; see details in programs/pluto/md2.c.
+Algorithm"  It is not under the GPL; see details in src/pluto/md2.c.
 
 The MD5 implementation is from RSA Data Security Inc., so this package must
 include the following phrase: "derived from the RSA Data Security, Inc.
 MD5 Message-Digest Algorithm".  It is not under the GPL; see details in
-linux/net/ipsec/ipsec_md5c.c. 
+src/libfreeswan/ipsec_md5c.c. 
 
 The PKCS#11 header files in programs/pluto/rsaref/ are from RSA Security Inc.,
 so they must include the following phrase: "RSA Security Inc. PKCS#11
 Cryptographic Token Interface (Cryptoki)". The headers are not under the GPL;
-see details in programs/pluto/rsaref/pkcs11.h.
+see details in src/pluto/rsaref/pkcs11.h.
 
 The linux/net/ipsec/radij.c code is derived from BSD 4.4lite code
 from sys/net/radix.c. 
diff --git a/Makefile b/Makefile
deleted file mode 100644 (file)
index 2dc9275..0000000
--- a/Makefile
+++ /dev/null
@@ -1,42 +0,0 @@
-# FreeS/WAN master makefile
-# Copyright (C) 1998-2002  Henry Spencer.
-# 
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2 of the License, or (at your
-# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# RCSID $Id: Makefile,v 1.4 2004/11/14 21:50:59 as Exp $
-
-
-FREESWANSRCDIR=$(shell pwd)
-export FREESWANSRCDIR
-
-include Makefile.inc
-
-# directories visited by all recursion
-SUBDIRS=lib src linux
-
-# declaration for make's benefit
-.PHONY:        programs install clean distclean \
-       uninstall install_file_list
-
-# programs
-
-all:   programs
-
-programs install install_file_list clean::
-       @for d in $(SUBDIRS) ; \
-       do \
-               (cd $$d && $(MAKE) FREESWANSRCDIR=.. $@ ) || exit 1; \
-       done; \
-
-# uninstall, as much as possible
-uninstall:
-       $(MAKE) --no-print-directory install_file_list | egrep -v '(/ipsec.conf$$|/ipsec.d/)' | xargs rm -f
-
diff --git a/Makefile.am b/Makefile.am
new file mode 100644 (file)
index 0000000..af437a6
--- /dev/null
@@ -0,0 +1 @@
+SUBDIRS = src
diff --git a/Makefile.inc b/Makefile.inc
deleted file mode 100644 (file)
index d4d38f0..0000000
+++ /dev/null
@@ -1,235 +0,0 @@
-# FreeS/WAN pathnames and other master configuration
-# Copyright (C) 2001, 2002  Henry Spencer.
-# 
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2 of the License, or (at your
-# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# RCSID $Id: Makefile.inc,v 1.12 2006/01/25 17:23:15 as Exp $
-
-
-# Variables in this file with names starting with INC_ are not for use
-# by Makefiles which include it; they are subject to change without warning.
-#
-# "Final" and "finally" refer to where the files will end up on the
-# running IPsec system, as opposed to where they get installed by our
-# Makefiles.  (The two are different for cross-compiles and the like,
-# where our Makefiles are not the end of the installation process.)
-# Paths with FINAL in their names are the only ones that the installed
-# software itself depends on.  (Very few things should know about the
-# FINAL paths; think twice and consult Henry before making something new
-# depend on them.)  All other paths are install targets.
-# See also DESTDIR, below.
-
-
-### boilerplate, do not change
-SHELL=/bin/sh
-
-### paths within the source tree
-
-KLIPSINC=${FREESWANSRCDIR}/linux/include
-KLIPSSRC=${FREESWANSRCDIR}/linux/net/ipsec
-
-LIBFREESWANDIR=${FREESWANSRCDIR}/linux/lib/libfreeswan
-FREESWANLIB=${FREESWANSRCDIR}/lib/libfreeswan/libfreeswan.a
-
-LWRESDIR=${FREESWANSRCDIR}/lib/liblwres
-LWRESLIB=${LWRESDIR}/liblwres.a
-
-LIBDESSRCDIR=${FREESWANSRCDIR}/linux/crypto/ciphers/des
-LIBDESLITE=${FREESWANSRCDIR}/lib/libdes/libdes.a
-
-LIBPOLICYDIR=${FREESWANSRCDIR}/linux/lib/libipsecpolicy
-POLICYLIB=${FREESWANSRCDIR}/lib/libipsecpolicy/libipsecpolicy.a
-
-.PHONY:        programs checkprograms clean
-
-### install pathnames
-
-# DESTDIR can be used to supply a prefix to all install targets.
-# (Note that "final" pathnames, signifying where files will eventually
-# reside rather than where install puts them, are exempt from this.)
-# The prefixing is done in this file, so as to have central control over
-# it; DESTDIR itself should never appear in any other Makefile.
-DESTDIR?=
-
-# "local" part of tree, used in building other pathnames
-INC_USRLOCAL=/usr/local
-
-# PUBDIR is where the "ipsec" command goes; beware, many things define PATH
-# settings which are assumed to include it (or at least, to include *some*
-# copy of the "ipsec" command).
-PUBDIR=$(DESTDIR)$(INC_USRLOCAL)/sbin
-
-# BINDIR is where sub-commands get put, FINALBINDIR is where the "ipsec"
-# command will look for them when it is run. Also called LIBEXECDIR.
-FINALLIBEXECDIR=$(INC_USRLOCAL)/libexec/ipsec
-LIBEXECDIR=$(DESTDIR)$(FINALBINDIR)
-
-FINALBINDIR=${FINALLIBEXECDIR}
-BINDIR=${LIBEXECDIR}
-
-
-# SBINDIR is where the user interface command goes.
-FINALSBINDIR=$(INC_USRLOCAL)/sbin
-SBINDIR=$(DESTDIR)$(FINALSBINDIR)
-
-# libdir is where utility files go
-FINALLIBDIR=$(INC_USRLOCAL)/lib/ipsec
-LIBDIR=$(DESTDIR)$(FINALLIBDIR)
-
-# sharedlibdir is where shared libraries go
-SHAREDLIBDIR=$(DESTDIR)$(INC_USRLOCAL)/lib
-
-# where the appropriate manpage tree is located
-# location within INC_USRLOCAL
-INC_MANDIR=man
-# the full pathname
-MANTREE=$(DESTDIR)$(INC_USRLOCAL)/$(INC_MANDIR)
-# all relevant subdirectories of MANTREE
-MANPLACES=man3 man5 man8
-
-# where configuration files go
-FINALCONFFILE?=/etc/ipsec.conf
-CONFFILE=$(DESTDIR)$(FINALCONFFILE)
-
-FINALCONFDIR?=/etc
-CONFDIR=$(DESTDIR)$(FINALCONFDIR)
-
-FINALCONFDDIR?=${FINALCONFDIR}/ipsec.d
-CONFDDIR=$(DESTDIR)$(FINALCONFDDIR)
-
-# sample configuration files go into
-INC_DOCDIR?=share/doc
-FINALEXAMPLECONFDIR=${INC_USRLOCAL}/${INC_DOCDIR}/strongswan
-EXAMPLECONFDIR=${DESTDIR}${FINALEXAMPLECONFDIR}
-
-FINALDOCDIR?=${INC_USRLOCAL}/${INC_DOCDIR}/strongswan
-DOCDIR=${DESTDIR}${FINALDOCDIR}
-
-# where per-conn pluto logs go
-VARDIR?=/var
-LOGDIR?=${VARDIR}/log
-FINALLOGDIR?=${DESTDIR}${LOGDIR}
-
-
-# An attempt is made to automatically figure out where boot/shutdown scripts 
-# will finally go:  the first directory in INC_RCDIRS which exists gets them.
-# If none of those exists (or INC_RCDIRS is empty), INC_RCDEFAULT gets them.
-# With a non-null DESTDIR, INC_RCDEFAULT will be used unless one of the
-# INC_RCDIRS directories has been pre-created under DESTDIR.
-INC_RCDIRS=/etc/rc.d/init.d /etc/rc.d /etc/init.d /sbin/init.d
-INC_RCDEFAULT=/etc/rc.d/init.d
-
-# RCDIR is where boot/shutdown scripts go; FINALRCDIR is where they think
-# will finally be (so utils/Makefile can create a symlink in BINDIR to the
-# place where the boot/shutdown script will finally be, rather than the
-# place where it is installed).
-FINALRCDIR=$(shell for d in $(INC_RCDIRS) ; \
-               do if test -d $(DESTDIR)/$$d ; \
-               then echo $$d ; exit 0 ; \
-               fi ; done ; echo $(INC_RCDEFAULT) )
-RCDIR=$(DESTDIR)$(FINALRCDIR)
-
-
-
-### misc installation stuff
-
-# what program to use when installing things
-INSTALL=install
-
-# flags to the install program, for programs, manpages, and config files
-# -b has install make backups (n.b., unlinks original), --suffix controls
-# how backup names are composed.
-# Note that the install procedures will never overwrite an existing config
-# file, which is why -b is not specified for them.
-INSTBINFLAGS=-b --suffix=.old
-INSTMANFLAGS=
-INSTCONFFLAGS=
-
-
-### misc configuration, included here in hopes that other files will not
-### have to be changed for common customizations.
-
-# extra compile flags, for userland and kernel stuff, e.g. -g for debug info
-# (caution, this stuff is still being sorted out, will change in future)
-USERCOMPILE?=-g -O3
-
-# FreeSWAN 3.x will require bind9. 
-USE_LWRES?=false
-
-# whether or not to use iproute2 based commands.
-#
-USE_IPROUTE2?=true
-
-# what kind of firewalling to use:
-#  2.0         - ipfwadm
-#  2.2  - ipchains
-#  2.4  - iptables
-IPSEC_FIREWALLTYPE=iptables
-
-# whether or not to include ipsec policy code into pluto.
-# false for now, since it is still experimental.
-USE_IPSECPOLICY?=false
-
-# include support for KEY RR 
-# this will become false in late 2003.
-USE_KEYRR?=true
-
-# include support for KERNEL 2.5/2.6 IPsec in pluto
-USE_KERNEL26?=true
-
-# whether or not pluto sends its strongSwan Vendor ID
-USE_VENDORID?=true
-
-# whether or not pluto sends an XAUTH VID (Cisco Mode Config Interoperability)
-USE_XAUTH_VID?=false
-
-# whether to support NAT Traversal (aka NAT-T)
-USE_NAT_TRAVERSAL?=true
-
-# whether to support NAT-T in transport mode (needed for Win2K NAT-T Interop)
-USE_NAT_TRAVERSAL_TRANSPORT_MODE?=false
-
-# include libcurl support (currently used for fetching CRLs, OCSP and SCEP)
-USE_LIBCURL?=false
-
-# include LDAP support (currently used for fetching CRLs)
-USE_LDAP?=false
-
-# uncomment this line if using the LDAPv3 protocol
-LDAP_VERSION=3
-# uncomment this line if using the LDAPv2 protocol
-#LDAP_VERSION=2
-
-# include PKCS11-based smartcard support
-USE_SMARTCARD?=false
-
-# Default PKCS11 library
-# Uncomment this line if using OpenSC <= 0.9.6
-#PKCS11_DEFAULT_LIB=\"/usr/lib/pkcs11/opensc-pkcs11.so\"
-# Uncomment this line if using OpenSC >= 0.10.0
-PKCS11_DEFAULT_LIB=\"/usr/lib/opensc-pkcs11.so\"
-# Uncomment and complete this line if using another default library
-#PKCS11_DEFAULT_LIB=\"/usr/lib/...\"
-
-# Enable the leak detective to find memory leaks
-USE_LEAK_DETECTIVE?=false
-
-# export everything so that scripts can use them.
-export LIBFREESWANDIR FREESWANSRCDIR FREESWANLIB
-
--include ${FREESWANSRCDIR}/Makefile.ver
-
-# for emacs
-#
-# Local Variables: ;;;
-# mode: makefile ;;;
-# End Variables: ;;;
-#
diff --git a/Makefile.ver b/Makefile.ver
deleted file mode 100644 (file)
index 48f2cac..0000000
+++ /dev/null
@@ -1 +0,0 @@
-IPSECVERSION=4.0.0
diff --git a/NEWS b/NEWS
new file mode 100644 (file)
index 0000000..8595682
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,712 @@
+
+- new build environment featuring autotools. Features such
+  as HTTP, LDAP and smartcard support may be enabled using
+  the ./configure script. Changing install directories 
+  is possible, too. See ./configure --help for more details.
+
+strongswan-4.0.0
+----------------
+
+- initial support of the IKEv2 protocol. Connections in
+  ipsec.conf designated by keyexchange=ikev2 are negotiated 
+  by the new IKEv2 charon keying daemon whereas those marked
+  by keyexchange=ikev1 or the default keyexchange=ike are
+  handled thy the IKEv1 pluto keying daemon. Currently only
+  a limited subset of functions are available with IKEv2
+  (Default AES encryption, authentication based on locally
+  imported X.509 certificates, unencrypted private RSA keys
+  in PKCS#1 file format, limited functionality of the ipsec
+  status command).
+
+
+strongswan-2.7.0
+----------------
+
+- the dynamic iptables rules from the _updown_x509 template
+  for KLIPS and the _updown_policy template for NETKEY have
+  been merged into the default _updown script. The existing
+  left|rightfirewall keyword causes the automatic insertion
+  and deletion of ACCEPT rules for tunneled traffic upon
+  the successful setup and teardown of an IPsec SA, respectively.
+  left|rightfirwall can be used with KLIPS under any Linux 2.4
+  kernel or with NETKEY under a Linux kernel version >= 2.6.16
+  in conjuction with iptables >= 1.3.5. For NETKEY under a Linux
+  kernel version < 2.6.16 which does not support IPsec policy
+  matching yet, please continue to use a copy of the _updown_espmark
+  template loaded via the left|rightupdown keyword.
+
+- a new left|righthostaccess keyword has been introduced which
+  can be used in conjunction with left|rightfirewall and the
+  default _updown script. By default leftfirewall=yes inserts
+  a bi-directional iptables FORWARD rule for a local client network
+  with a netmask different from 255.255.255.255 (single host).
+  This does not allow to access the VPN gateway host via its
+  internal network interface which is part of the client subnet
+  because an iptables INPUT and OUTPUT rule would be required.
+  lefthostaccess=yes will cause this additional ACCEPT rules to
+  be inserted. 
+
+- mixed PSK|RSA roadwarriors are now supported. The ISAKMP proposal
+  payload is preparsed in order to find out whether the roadwarrior
+  requests PSK or RSA so that a matching connection candidate can
+  be found.
+
+
+strongswan-2.6.4
+----------------
+
+- the new _updown_policy template allows ipsec policy based
+  iptables firewall rules. Required are iptables version
+  >= 1.3.5 and linux kernel >= 2.6.16. This script obsoletes
+  the _updown_espmark template, so that no INPUT mangle rules 
+  are required any more.
+
+- added support of DPD restart mode
+
+- ipsec starter now allows the use of wildcards in include
+  statements as e.g. in "include /etc/my_ipsec/*.conf".
+  Patch courtesy of Matthias Haas.
+
+- the Netscape OID 'employeeNumber' is now recognized and can be
+  used as a Relative Distinguished Name in certificates.
+
+
+strongswan-2.6.3
+----------------
+
+- /etc/init.d/ipsec or /etc/rc.d/ipsec is now a copy of the ipsec 
+  command and not of ipsec setup any more.
+
+- ipsec starter now supports AH authentication in conjunction with
+  ESP encryption. AH authentication is configured in ipsec.conf
+  via the auth=ah parameter.
+  
+- The command ipsec scencrypt|scdecrypt <args> is now an alias for
+  ipsec whack --scencrypt|scdecrypt <args>.
+
+- get_sa_info() now determines for the native netkey IPsec stack
+  the exact time of the last use of an active eroute. This information
+  is used by the Dead Peer Detection algorithm and is also displayed by
+  the ipsec status command.
+  
+
+strongswan-2.6.2
+----------------
+
+- running under the native Linux 2.6 IPsec stack, the function
+  get_sa_info() is called by ipsec auto --status to display the current
+  number of transmitted bytes per IPsec SA.
+
+- get_sa_info() is also used  by the Dead Peer Detection process to detect
+  recent ESP activity. If ESP traffic was received from the peer within
+  the last dpd_delay interval then no R_Y_THERE notification must be sent.
+
+- strongSwan now supports the Relative Distinguished Name "unstructuredName"
+  in ID_DER_ASN1_DN identities. The following notations are possible:
+
+    rightid="unstructuredName=John Doe"
+    rightid="UN=John Doe"
+
+- fixed a long-standing bug which caused PSK-based roadwarrior connections
+  to segfault in the function id.c:same_id() called by keys.c:get_secret()
+  if an FQDN, USER_FQDN, or Key ID was defined, as in the following example.
+
+  conn rw
+       right=%any
+       rightid=@foo.bar
+       authby=secret
+
+- the ipsec command now supports most ipsec auto commands (e.g. ipsec listall).
+
+- ipsec starter didn't set host_addr and client.addr ports in whack msg.
+
+- in order to guarantee backwards-compatibility with the script-based
+  auto function (e.g. auto --replace), the ipsec starter scripts stores
+  the defaultroute information in the temporary file /var/run/ipsec.info.
+
+- The compile-time option USE_XAUTH_VID enables the sending of the XAUTH
+  Vendor ID which is expected by Cisco PIX 7 boxes that act as IKE Mode Config
+  servers.
+
+- the ipsec starter now also recognizes the parameters authby=never and
+  type=passthrough|pass|drop|reject.
+
+
+strongswan-2.6.1
+----------------
+
+- ipsec starter now supports the also parameter which allows
+  a modular structure of the connection definitions. Thus
+  "ipsec start" is now ready to replace "ipsec setup".
+
+
+strongswan-2.6.0
+----------------
+
+- Mathieu Lafon's popular ipsec starter tool has been added to the
+  strongSwan distribution. Many thanks go to Stephan Scholz from astaro
+  for his integration work. ipsec starter is a C program which is going
+  to replace the various shell and awk starter scripts (setup, _plutoload,
+  _plutostart, _realsetup, _startklips, _confread, and auto). Since
+  ipsec.conf is now parsed only once, the starting of multiple tunnels is
+  accelerated tremedously.
+
+- Added support of %defaultroute to the ipsec starter. If the IP address
+  changes, a HUP signal to the ipsec starter will automatically 
+  reload pluto's connections.
+
+- moved most compile time configurations from pluto/Makefile to
+  Makefile.inc by defining the options USE_LIBCURL, USE_LDAP,
+  USE_SMARTCARD, and USE_NAT_TRAVERSAL_TRANSPORT_MODE.
+
+- removed the ipsec verify and ipsec newhostkey commands
+
+- fixed some 64-bit issues in formatted print statements
+
+- The scepclient functionality implementing the Simple Certificate
+  Enrollment Protocol (SCEP) is nearly complete but hasn't been
+  documented yet.
+
+
+strongswan-2.5.7
+----------------
+
+- CA certicates are now automatically loaded from a smartcard
+  or USB crypto token and appear in the ipsec auto --listcacerts
+  listing.
+
+
+strongswan-2.5.6
+----------------
+
+- when using "ipsec whack --scencrypt <data>" with  a PKCS#11
+  library that does not support the C_Encrypt() Cryptoki
+  function (e.g. OpenSC), the RSA encryption is done in
+  software using the public key fetched from the smartcard.
+
+- The scepclient function now allows to define the 
+  validity of a self-signed certificate using the --days,
+  --startdate, and --enddate options. The default validity
+  has been changed from one year to five years.
+
+
+strongswan-2.5.5
+----------------
+
+- the config setup parameter pkcs11proxy=yes opens pluto's PKCS#11
+  interface to other applications for RSA encryption and decryption
+  via the whack interface. Notation:
+
+  ipsec whack --scencrypt <data>
+             [--inbase  16|hex|64|base64|256|text|ascii]
+             [--outbase 16|hex|64|base64|256|text|ascii]
+             [--keyid <keyid>]
+
+  ipsec whack --scdecrypt <data>
+             [--inbase  16|hex|64|base64|256|text|ascii]
+             [--outbase 16|hex|64|base64|256|text|ascii]
+             [--keyid <keyid>]
+
+  The default setting for inbase and outbase is hex. 
+
+  The new proxy interface can be used for securing symmetric
+  encryption keys required by the cryptoloop or dm-crypt
+  disk encryption schemes, especially in the case when
+  pkcs11keepstate=yes causes pluto to lock the pkcs11 slot
+  permanently.
+
+- if the file /etc/ipsec.secrets is lacking during the startup of
+  pluto then the root-readable file /etc/ipsec.d/private/myKey.der
+  containing a 2048 bit RSA private key and a matching self-signed
+  certificate stored in the file /etc/ipsec.d/certs/selfCert.der
+  is automatically generated by calling the function
+
+  ipsec scepclient --out pkcs1 --out cert-self
+
+  scepclient was written by Jan Hutter and Martin Willi, students
+  at the University of Applied Sciences in Rapperswil, Switzerland.
+
+
+strongswan-2.5.4
+----------------
+
+- the current extension of the PKCS#7 framework introduced
+  a parsing error in PKCS#7 wrapped X.509 certificates that are
+  e.g. transmitted by Windows XP when multi-level CAs are used.
+  the parsing syntax has been fixed.
+
+- added a patch by Gerald Richter which tolerates multiple occurrences
+  of the ipsec0 interface when using KLIPS.
+
+
+strongswan-2.5.3
+----------------
+
+- with gawk-3.1.4 the word "default2 has become a protected
+  keyword for use in switch statements and cannot be used any
+  more in the strongSwan scripts. This problem has been
+  solved by renaming "default" to "defaults" and "setdefault"
+  in the scripts _confread and auto, respectively.
+
+- introduced the parameter leftsendcert with the values
+
+  always|yes (the default, always send a cert)
+  ifasked    (send the cert only upon a cert request)
+  never|no   (never send a cert, used for raw RSA keys and
+              self-signed certs) 
+
+- fixed the initialization of the ESP key length to a default of
+  128 bits in the case that the peer does not send a key length
+   attribute for AES encryption.
+
+- applied Herbert Xu's uniqueIDs patch
+
+- applied Herbert Xu's CLOEXEC patches
+
+
+strongswan-2.5.2
+----------------
+
+- CRLs can now be cached also in the case when the issuer's
+  certificate does not contain a subjectKeyIdentifier field.
+  In that case the subjectKeyIdentifier is computed by pluto as the
+  160 bit SHA-1 hash of the issuer's public key in compliance
+  with section 4.2.1.2 of RFC 3280.
+
+- Fixed a bug introduced by strongswan-2.5.1 which eliminated
+  not only multiple Quick Modes of a given connection but also
+  multiple connections between two security gateways.
+
+
+strongswan-2.5.1
+----------------
+
+- Under the native IPsec of the Linux 2.6 kernel, a %trap eroute
+  installed either by setting auto=route in ipsec.conf or by
+  a connection put into hold, generates an XFRM_AQUIRE event
+  for each packet that wants to use the not-yet exisiting
+  tunnel. Up to now each XFRM_AQUIRE event led to an entry in
+  the Quick Mode queue, causing multiple IPsec SA to be
+  established in rapid succession. Starting with strongswan-2.5.1
+  only a single IPsec SA is established per host-pair connection.
+
+- Right after loading the PKCS#11 module, all smartcard slots are
+  searched for certificates. The result can be viewed using
+  the command
+
+    ipsec auto --listcards
+
+  The certificate objects found in the slots are numbered
+  starting with #1, #2, etc. This position number can be used to address
+  certificates (leftcert=%smartcard) and keys (: PIN %smartcard)
+  in ipsec.conf and ipsec.secrets, respectively:
+
+    %smartcard      (selects object #1)
+    %smartcard#1    (selects object #1)
+    %smartcard#3    (selects object #3)
+
+  As an alternative the existing retrieval scheme can be used:
+
+    %smartcard:45   (selects object with id=45)
+    %smartcard0     (selects first object in slot 0)
+    %smartcard4:45  (selects object in slot 4 with id=45)
+
+- Depending on the settings of CKA_SIGN and CKA_DECRYPT
+  private key flags either C_Sign() or C_Decrypt() is used
+  to generate a signature.
+
+- The output buffer length parameter siglen in C_Sign()
+  is now initialized to the actual size of the output
+  buffer prior to the function call. This fixes the
+  CKR_BUFFER_TOO_SMALL error that could occur when using
+  the OpenSC PKCS#11 module.
+
+- Changed the initialization of the PKCS#11 CK_MECHANISM in
+  C_SignInit() to mech  = { CKM_RSA_PKCS, NULL_PTR, 0 }.
+
+- Refactored the RSA public/private key code and transferred it
+  from keys.c to the new pkcs1.c file as a preparatory step
+  towards the release of the SCEP client.
+
+
+strongswan-2.5.0
+----------------
+
+- The loading of a PKCS#11 smartcard library module during
+  runtime does not require OpenSC library functions any more
+  because the corresponding code has been integrated into
+  smartcard.c. Also the RSAREF pkcs11 header files have been
+  included in a newly created pluto/rsaref directory so that
+  no external include path has to be defined any longer.
+
+- A long-awaited feature has been implemented at last:
+  The local caching of CRLs fetched via HTTP or LDAP, activated
+  by the parameter cachecrls=yes in the config setup section
+  of ipsec.conf. The dynamically fetched CRLs are stored under
+  a unique file name containing the issuer's subjectKeyID
+  in /etc/ipsec.d/crls.
+  
+- Applied a one-line patch courtesy of Michael Richardson
+  from the Openswan project which fixes the kernel-oops
+  in KLIPS when an snmp daemon is running on the same box.
+
+
+strongswan-2.4.4
+----------------
+
+- Eliminated null length CRL distribution point strings.
+
+- Fixed a trust path evaluation bug introduced with 2.4.3
+
+
+strongswan-2.4.3
+----------------
+
+- Improved the joint OCSP / CRL revocation policy.
+  OCSP responses have precedence over CRL entries.
+
+- Introduced support of CRLv2 reason codes.
+
+- Fixed a bug with key-pad equipped readers which caused
+  pluto to prompt for the pin via the console when the first
+  occasion to enter the pin via the key-pad was missed.
+
+- When pluto is built with LDAP_V3 enabled, the library
+  liblber required by newer versions of openldap is now
+  included.
+
+
+strongswan-2.4.2
+----------------
+
+- Added the _updown_espmark template which requires all
+  incoming ESP traffic to be marked with a default mark
+  value of 50.
+  
+- Introduced the pkcs11keepstate parameter in the config setup
+  section of ipsec.conf. With pkcs11keepstate=yes the PKCS#11
+  session and login states are kept as long as possible during 
+  the lifetime of pluto. This means that a PIN entry via a key
+  pad has to be done only once.
+
+- Introduced the pkcs11module parameter in the config setup
+  section of ipsec.conf which specifies the PKCS#11 module
+  to be used with smart cards. Example:
+  
+    pkcs11module=/usr/lib/pkcs11/opensc-pkcs11.lo
+  
+- Added support of smartcard readers equipped with a PIN pad.
+
+- Added patch by Jay Pfeifer which detects when netkey
+  modules have been statically built into the Linux 2.6 kernel.
+
+- Added two patches by Herbert Xu. The first uses ip xfrm
+  instead of setkey to flush the IPsec policy database. The
+  second sets the optional flag in inbound IPComp SAs only.
+    
+- Applied Ulrich Weber's patch which fixes an interoperability
+  problem between native IPsec and KLIPS systems caused by
+  setting the replay window to 32 instead of 0 for ipcomp.
+
+
+strongswan-2.4.1
+----------------
+
+- Fixed a bug which caused an unwanted Mode Config request
+  to be initiated in the case where "right" was used to denote
+  the local side in ipsec.conf and "left" the remote side,
+  contrary to the recommendation that "right" be remote and
+  "left" be"local".
+
+
+strongswan-2.4.0a
+-----------------
+
+- updated Vendor ID to strongSwan-2.4.0
+
+- updated copyright statement to include David Buechi and
+  Michael Meier
+  
+  
+strongswan-2.4.0
+----------------
+
+- strongSwan now communicates with attached smartcards and
+  USB crypto tokens via the standardized PKCS #11 interface.
+  By default the OpenSC library from www.opensc.org is used
+  but any other PKCS#11 library could be dynamically linked.
+  strongSwan's PKCS#11 API was implemented by David Buechi
+  and Michael Meier, both graduates of the Zurich University
+  of Applied Sciences in Winterthur, Switzerland.
+
+- When a %trap eroute is triggered by an outgoing IP packet
+  then the native IPsec stack of the Linux 2.6 kernel [often/
+  always?] returns an XFRM_ACQUIRE message with an undefined
+  protocol family field and the connection setup fails.
+  As a workaround IPv4 (AF_INET) is now assumed.
+  
+- the results of the UML test scenarios are now enhanced 
+  with block diagrams of the virtual network topology used
+  in a particular test. 
+
+
+strongswan-2.3.2
+----------------
+
+- fixed IV used to decrypt informational messages.
+  This bug was introduced with Mode Config functionality.
+- fixed NCP Vendor ID.
+
+- undid one of Ulrich Weber's maximum udp size patches
+  because it caused a segmentation fault with NAT-ed
+  Delete SA messages.
+  
+- added UML scenarios wildcards and attr-cert which
+  demonstrate the implementation of IPsec policies based
+  on wildcard parameters contained in Distinguished Names and
+  on X.509 attribute certificates, respectively.
+
+
+strongswan-2.3.1
+----------------
+
+- Added basic Mode Config functionality
+
+- Added Mathieu Lafon's patch which upgrades the status of
+  the NAT-Traversal implementation to RFC 3947.
+- The _startklips script now also loads the xfrm4_tunnel
+  module.
+  
+- Added Ulrich Weber's netlink replay window size and
+  maximum udp size patches.
+
+- UML testing now uses the Linux 2.6.10 UML kernel by default.
+   
+
+strongswan-2.3.0
+----------------
+
+- Eric Marchionni and Patrik Rayo, both recent graduates from
+  the Zuercher Hochschule Winterthur in Switzerland, created a
+  User-Mode-Linux test setup for strongSwan. For more details
+  please read the INSTALL and README documents in the testing
+  subdirectory.
+
+- Full support of group attributes based on X.509 attribute
+  certificates. Attribute certificates can be generated 
+  using the openac facility. For more details see
+   
+  man ipsec_openac.
+  The group attributes can be used in connection definitions
+  in order to give IPsec access to specific user groups.
+  This is done with the new parameter left|rightgroups as in
+  
+  rightgroups="Research, Sales"
+
+  giving access to users possessing the group attributes
+  Research or Sales, only.
+
+- In Quick Mode clients with subnet mask /32 are now
+  coded as IP_V4_ADDRESS or IP_V6_ADDRESS. This should 
+  fix rekeying problems with the SafeNet/SoftRemote and NCP
+  Secure Entry Clients.
+
+- Changed the defaults of the ikelifetime and keylife parameters
+  to 3h and 1h, respectively. The maximum allowable values are
+  now both set to 24 h.
+
+- Suppressed notification wars between two IPsec peers that
+  could e.g. be triggered by incorrect ISAKMP encryption.
+
+- Public RSA keys can now have identical IDs if either the
+  issuing CA or the serial number is different. The serial
+  number of a certificate is now shown by the command
+  
+  ipsec auto --listpubkeys
+
+
+strongswan-2.2.2
+----------------
+
+- Added Tuomo Soini's sourceip feature which allows a strongSwan
+  roadwarrior to use a fixed Virtual IP (see README section 2.6)
+  and reduces the well-known four tunnel case on VPN gateways to
+  a single tunnel definition (see README section 2.4).
+
+- Fixed a bug occuring with NAT-Traversal enabled when the responder
+  suddenly turns initiator and the initiator cannot find a matching
+  connection because of the floated IKE port 4500.
+  
+- Removed misleading ipsec verify command from barf.
+
+- Running under the native IP stack, ipsec --version now shows
+  the Linux kernel version (courtesy to the Openswan project).
+
+
+strongswan-2.2.1
+----------------
+
+- Introduced the ipsec auto --listalgs monitoring command which lists
+  all currently registered IKE and ESP algorithms.
+
+- Fixed a bug in the ESP algorithm selection occuring when the strict flag
+  is set and the first proposed transform does not match.
+  
+- Fixed another deadlock in the use of the lock_certs_and_keys() mutex,
+  occuring when a smartcard is present.
+
+- Prevented that a superseded Phase1 state can trigger a DPD_TIMEOUT event.
+  
+- Fixed the printing of the notification names (null)
+
+- Applied another of Herbert Xu's Netlink patches.
+
+
+strongswan-2.2.0
+----------------
+
+- Support of Dead Peer Detection. The connection parameter
+
+    dpdaction=clear|hold
+     
+  activates DPD for the given connection.
+
+- The default Opportunistic Encryption (OE) policy groups are not
+  automatically included anymore. Those wishing to activate OE can include
+  the policy group with the following statement in ipsec.conf:
+  
+    include /etc/ipsec.d/examples/oe.conf
+  
+  The default for [right|left]rsasigkey is now set to %cert.
+
+- strongSwan now has a Vendor ID of its own which can be activated
+  using the compile option VENDORID
+
+- Applied Herbert Xu's patch which sets the compression algorithm correctly.
+
+- Applied Herbert Xu's patch fixing an ESPINUDP problem
+
+- Applied Herbert Xu's patch setting source/destination port numbers.
+
+- Reapplied one of Herbert Xu's NAT-Traversal patches which got
+  lost during the migration from SuperFreeS/WAN.
+  
+- Fixed a deadlock in the use of the lock_certs_and_keys() mutex.
+
+- Fixed the unsharing of alg parameters when instantiating group
+  connection.
+  
+
+strongswan-2.1.5
+----------------
+
+- Thomas Walpuski made me aware of a potential DoS attack via
+  a PKCS#7-wrapped certificate bundle which could overwrite valid CA
+  certificates in Pluto's authority certificate store. This vulnerability
+  was fixed by establishing trust in CA candidate certificates up to a
+  trusted root CA prior to insertion into Pluto's chained list.
+
+- replaced the --assign option by the -v option in the auto awk script
+  in order to make it run with mawk under debian/woody.
+
+
+strongswan-2.1.4
+----------------
+
+- Split of the status information between ipsec auto  --status (concise)
+  and ipsec auto --statusall (verbose). Both commands can be used with
+  an optional connection selector:
+
+    ipsec auto --status[all] <connection_name>
+
+- Added the description of X.509 related features to the ipsec_auto(8)
+  man page.
+
+- Hardened the ASN.1 parser in debug mode, especially the printing
+  of malformed distinguished names.
+
+- The size of an RSA public key received in a certificate is now restricted to
+
+    512 bits <= modulus length <= 8192 bits.
+
+- Fixed the debug mode enumeration.
+
+
+strongswan-2.1.3
+----------------
+
+- Fixed another PKCS#7 vulnerability which could lead to an
+  endless loop while following the X.509 trust chain.
+  
+
+strongswan-2.1.2
+----------------
+
+- Fixed the PKCS#7 vulnerability discovered by Thomas Walpuski
+  that accepted end certificates having identical issuer and subject
+  distinguished names in a multi-tier X.509 trust chain.
+  
+
+strongswan-2.1.1
+----------------
+
+- Removed all remaining references to ipsec_netlink.h in KLIPS.
+
+
+strongswan-2.1.0
+----------------
+
+- The new "ca" section allows to define the following parameters:
+
+  ca kool
+     cacert=koolCA.pem                   # cacert of kool CA
+     ocspuri=http://ocsp.kool.net:8001   # ocsp server
+     ldapserver=ldap.kool.net            # default ldap server
+     crluri=http://www.kool.net/kool.crl # crl distribution point
+     crluri2="ldap:///O=Kool, C= .."     # crl distribution point #2
+     auto=add                            # add, ignore
+     
+  The ca definitions can be monitored via the command
+  
+     ipsec auto --listcainfos
+
+- Fixed cosmetic corruption of /proc filesystem by integrating
+  D. Hugh Redelmeier's freeswan-2.06 kernel fixes.
+
+
+strongswan-2.0.2
+----------------
+
+- Added support for the 818043 NAT-Traversal update of Microsoft's
+  Windows 2000/XP IPsec client which sends an ID_FQDN during Quick Mode.
+  
+- A symbolic link to libcrypto is now added in the kernel sources 
+  during kernel compilation
+  
+- Fixed a couple of 64 bit issues (mostly casts to int).
+  Thanks to Ken Bantoft who checked my sources on a 64 bit platform.
+
+- Replaced s[n]printf() statements in the kernel by ipsec_snprintf().
+  Credits go to D. Hugh Redelmeier, Michael Richardson, and Sam Sgro
+  of the FreeS/WAN team who solved this problem with the 2.4.25 kernel.
+
+
+strongswan-2.0.1
+----------------
+
+- an empty ASN.1 SEQUENCE OF or SET OF object (e.g. a subjectAltName
+  certificate extension which contains no generalName item)  can cause
+  a pluto crash. This bug has been fixed. Additionally the ASN.1 parser has
+  been hardened to make it more robust against malformed ASN.1 objects.
+
+- applied Herbert Xu's NAT-T patches which fixes NAT-T under the native
+  Linux 2.6 IPsec stack.
+  
+  
+strongswan-2.0.0
+----------------
+
+- based on freeswan-2.04, x509-1.5.3, nat-0.6c, alg-0.8.1rc12
diff --git a/README b/README
new file mode 100644 (file)
index 0000000..e9ebfee
--- /dev/null
+++ b/README
@@ -0,0 +1,3091 @@
+                 ----------------------------
+                  strongSwan - Configuration
+                 ----------------------------
+
+
+Contents
+--------
+
+   1. Overview
+   2. Quickstart
+       2.1 Site-to-Site case
+       2.2 Host-to-Host case
+       2.3 Four Tunnel case
+       2.4 Four Tunnel case the elegant way with source routing
+       2.5 Roadwarrior case
+       2.6 Roadwarrior case with virtual IP
+   3. Generating X.509 certificates and CRLs with OpenSSL
+       3.1 Generating a CA certificate
+       3.2 Generating a host or user certificate
+       3.3 Generating a CRL
+       3.4 Revoking a certificate
+   4. Configuring the connections - ipsec.conf
+       4.1 Configuring my side
+       4.2 Multiple certificates
+       4.3 Configuring the peer side using CA certificates
+       4.4 Handling Virtual IPs and wildcard subnets
+       4.5 Protocol and port selectors
+       4.6 IPsec policies based on wildcards
+       4.7 IPsec policies based on CA certificates
+       4.8 Sending certificate requests
+       4.9 IPsec policies based on group attributes
+   5. Configuring certificates and CRLs
+       5.1 Installing CA certificates
+       5.2 Installing optional Certificate Revocation Lists (CRLs)
+       5.3 Dynamic update of certificates and CRLs
+       5.4 Local caching of CRLs
+       5.5 Online Certificate Status Protocol (OCSP)
+       5.6 CRL policy
+       5.7 Configuring the peer side using locally stored certificates
+   6. Configuring the private keys - ipsec.secrets
+       6.1 Loading private key files in PKCS#1 format
+       6.2 Entering passphrases interactively
+       6.3 Multiple private keys
+   7. Configuring CA properties - ipsec.conf
+   8. Smartcard support
+       8.1 Configuring a smartcard-based connection
+       8.2 Entering the PIN code
+       8.3 PIN-pad equipped smartcard readers
+       8.4 Configuring a smartcard using pkcs15-init
+        8.5 PKCS#1 proxy functions
+   9. Configuring the clients
+       9.1 strongSwan
+       9.2 PGPnet
+       9.3 Safenet/Soft-Remote
+       9.4 SSH Sentinel
+       9.5 Windows 2000/XP
+  10. Monitoring functions
+  11. Firewall support functions
+       11.1 Environment variables in the updown script
+       11.2 Automatic insertion and deletion of iptables firewall rules  (NEW)
+       11.3 Sample Linux 2.6 _updown_espmark script for iptables < 1.3.5
+  12. Authentication with raw RSA public keys
+  13. Authentication with OpenPGP certificates
+       13.1 OpenPGP certificates
+       13.2 OpenPGP private keys
+       13.3 Monitoring functions
+       13.4 Suppression of certificate request messages
+  14. Additional features
+       14.1 Authentication and encryption algorithms
+       14.2 NAT traversal
+       14.3 Dead peer detection
+       14.4 IKE Mode Config
+  15. Copyright statement and acknowledgements
+
+
+1. Overview
+   --------
+
+strongSwan is an OpenSource IPsec solution for the Linux operating system
+and currently supports the following features:
+
+  * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels.
+
+  * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption.
+
+  * Authentication based on X.509 certificates or preshared secrets.
+
+  * IPsec policies based on wildcards or intermediate CAs.
+
+  * Powerful and flexible IPsec policies based on group attributes.
+
+  * Retrieval of Certificate Revocation Lists (CRLs) via HTTP or LDAP.
+
+  * Local caching of fetched CRLs
+
+  * Full support of the Online Certificate Status Protocol (OCSP, RFC 2560).
+
+  * CA management functions including OCSP and CRL URIs and default LDAP server.
+
+  * Optional storage of RSA private keys on smartcards or USB crypto tokens
+
+  * Standardized PKCS#11 interface with optional proxy functions serving 
+    external applications (disc encryption, etc.).
+  * NAT-Traversal (RFC 3947)
+
+  * Support of Virtual IPs via static configuratin and IKE Mode Config
+
+  * Support of Delete SA and informational Notification messages.
+
+  * Dead Peer Detection (DPD, RFC 3706)
+
+Compatibility has successfully been tested with peers running the following
+IPsec clients:
+
+  FreeS/WAN, Openswan, SafeNet/SoftRemote, NCP Secure Entry Client,
+  SonicWALL Global VPN Client, The GreenBow, Microsoft Windows 2000/XP, etc.
+
+Furthermore, interoperability with the following VPN gateways
+has been demonstrated during the IPsec 2001 Conference in Paris:
+
+  Cisco IOS Routers, Cisco PIX firewall, Cisco VPN3000,
+  Nortel Contivity VPN Switch, NetScreen (FreeS/WAN as responder only),
+  OpenBSD with isakmpd, Netasq, Netcelo, and 6WIND.
+
+Potentially any IPsec implementation with X.509 certificate support can
+be made to cooperate with strongSwan. The latest addition has been the successful
+interoperability with the Check Point VPN-1 NG gateway.
+
+
+2. Quickstart
+   ----------
+   
+In the following examples we assume for reasons of clarity that left designates
+the local host and that right is the remote host. Certificates for users, hosts
+and gateways are issued by a ficticious strongSwan CA. How to generate private keys
+and certificates using OpenSSL will be explained in section 3. The CA certificate
+"strongswanCert.pem" must be present on all VPN end points in order to be able to
+authenticate the peers.
+
+
+2.1 Site-to-site case
+    -----------------
+
+In this scenario two security gateways moon and sun will connect the
+two subnets moon-net and sun-net with each other through a VPN tunnel
+set up between the two gateways:
+
+    10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
+      moon-net          moon                 sun           sun-net
+
+Configuration on gateway moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         left=%defaultroute
+         leftsubnet=10.1.0.0/16
+         leftcert=moonCert.pem
+         right=192.168.0.2
+         rightsubnet=10.2.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
+         auto=start
+
+Configuration on gateway sun:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/sunCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA sunKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         left=%defaultroute
+         leftsubnet=10.2.0.0/16
+         leftcert=sunCert.pem
+         right=192.168.0.1
+         rightsubnet=10.1.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+2.2 Host-to-host case
+    -----------------
+
+This is a setup between two single hosts which don't have a subnet behind
+them. Although IPsec transport mode would be sufficient for host-to-host
+connections we will use the default IPsec tunnel mode.
+
+    | 192.168.0.1 | === | 192.168.0.2 |
+         moon                sun
+
+Configuration on host moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn host-host
+         left=%defaultroute
+         leftcert=moonCert.pem
+         right=192.168.0.2
+         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
+         auto=start
+
+Configuration on host sun:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/sunCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA sunKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn host-host
+         left=%defaultroute
+         leftcert=sunCert.pem
+         right=192.168.0.1
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+2.3 Four Tunnel case
+    ----------------
+
+In a site-to-site setup a system administrator logged into the local gateway
+often would like to access the peer gateway or a server in the subnet behind
+the peer gateway over a secure IPsec tunnel.Since IP packets leaving a gateway
+via the outer network interface carry the IP address of this NIC, four IPsec
+Security Associations (SAs) must be set up to achieve full connectivity. The
+example below shows how this can be done without much additional typing work ,
+using the "also" macro which includes connection definitions defined farther
+down in the ipsec.conf file.
+
+   10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
+    moon-net           moon                 sun           sun-net
+
+Configuration on gateway moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         leftsubnet=10.1.0.0/16
+         rightsubnet=10.2.0.0/16
+         also host-host
+
+     conn net-host
+         leftsubnet=10.1.0.0/16
+         also host-host
+
+     conn host-net
+         rightsubnet=10.2.0.0/16
+         also host-host
+
+     conn host-host
+         left=%defaultroute
+         leftcert=moonCert.pem
+         right=192.168.0.2
+         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
+         auto=start
+
+Configuration on gateway sun:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/sunCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA sunKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         leftsubnet=10.2.0.0/16
+         rightsubnet=10.1.0.0/16
+         also=host-host
+
+     conn net-host
+         leftsubnet=10.2.0.0/16
+         also=host-host
+
+     conn host-net
+         rightsubnet=10.1.0.0/16
+         also=host-host
+
+     conn host-host
+         left=%defaultroute
+         leftcert=sunCert.pem
+         right=192.168.0.1
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+2.4 The four tunnel case the elegant way with source routing
+    --------------------------------------------------------
+
+As you certainly agree, the full four tunnel case described in the previous
+section becomes quite complex. If we could force the source address of the
+IP packets leaving the gateway through the outer interface to take on the
+IP address of the inner interface then we could use the single subnet-to-subnet
+tunnel from section 2.1. Such a setup becomes possible if we use the
+source routing capabilites of the ip route command that is already used
+by strongSwan's updown scripts.
+
+    10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
+      moon-net          moon                sun            sun-net
+
+If we assume that the inner IP address of gateway moon is 10.1.0.1
+and the inner IP address of gateway sun is 10.2.0.1 then the
+insertion of the parameter
+
+    leftsourceip=10.1.0.1
+   
+in the connection definition of moon and
+
+      leftsourceip=10.2.0.1
+  
+on sun, respectively, will install source routing on both gateways.
+As a result the command
+
+      ping 10.2.0.1
+  
+executed on moon will leave the gateway with a source address of
+10.1.0.1 and will therefore take the net-net IPsec tunnel.
+
+Configuration on gateway moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         left=%defaultroute
+         leftsourceip=10.1.0.1
+         leftsubnet=10.1.0.0/16
+         leftcert=moonCert.pem
+         right=192.168.0.2
+         rightsubnet=10.2.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
+         auto=start
+
+Configuration on gateway sun:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/sunCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA sunKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn net-net
+         left=%defaultroute
+         leftsubnet=10.2.0.0/16
+         leftsourceip=10.2.0.1
+         leftcert=sunCert.pem
+         right=192.168.0.1
+         rightsubnet=10.1.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+2.5 Roadwarrior case
+    ----------------
+
+This is a very common case where a strongSwan gateway serves an arbitrary number
+of remote VPN clients usually having dynamic IP addresses.
+
+    10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
+      moon-net          moon              carol
+
+Configuration on gateway moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn rw
+         left=%defaultroute
+         leftsubnet=10.1.0.0/16
+         leftcert=moonCert.pem
+          right=%any
+         auto=add
+
+Configuration on roadwarrior carol:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/carolCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA carolKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn home
+         left=%defaultroute
+         leftcert=carolCert.pem
+         right=192.168.0.1
+         rightsubnet=10.1.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+2.6 Roadwarrior case with virtual IP
+    --------------------------------
+
+Roadwarriors usually have dynamic IP addresses assigned by the ISP they are
+currently attached to. In order to simplify the routing from moon-net back
+to the remote access client carol it would be desirable if the roadwarrior had
+an inner IP address chosen from a pre-assigned pool.
+    10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
+      moon-net          moon              carol       virtual IP
+
+This virtual IP address can be assigned to a strongSwan roadwarrior by adding 
+the parameter
+
+    leftsourceip=10.3.0.1
+    
+to the roadwarrior's ipsec.conf. Of course the virtual IP of each roadwarrior
+must be distinct. In our example it is chosen from the address pool
+
+    rightsubnetwithin=10.3.0.0/16
+    
+which can be added to the gateway's ipsec.conf so that a single connection
+definition can handle multiple roadwarriors.
+
+Configuration on gateway moon:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/moonCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA moonKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn rw
+         left=%defaultroute
+         leftsubnet=10.1.0.0/16
+         leftcert=moonCert.pem
+         right=%any
+         rightsubnetwithin=10.3.0.0/16
+         auto=add
+
+Configuration on roadwarrior carol:
+
+   /etc/ipsec.d/cacerts/strongswanCert.pem
+
+   /etc/ipsec.d/certs/carolCert.pem
+
+   /etc/ipsec.secrets:
+
+     : RSA carolKey.pem "<optional passphrase>"
+
+   /etc/ipsec.conf:
+
+     conn home
+         left=%defaultroute
+         leftsourceip=10.3.0.1
+         leftcert=carolCert.pem
+         right=192.168.0.1
+         rightsubnet=10.1.0.0/16
+         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+         auto=start
+
+
+3. Generating certificates and CRLs with OpenSSL
+   ---------------------------------------------
+
+This section is not a full-blown tutorial on how to use OpenSSL. It just lists
+a few points that are relevant if you want to generate your own certificates
+and CRLs for use with strongSwan.
+
+
+3.1 Generating a CA certificate
+    ---------------------------
+
+The OpenSSL statement
+
+     openssl req -x509 -days 1460 -newkey rsa:2048 \
+                 -keyout strongswanKey.pem -out strongswanCert.pem
+
+creates a 2048 bit RSA private key strongswanKey.pem and a self-signed CA
+certificate strongswanCert.pem with a validity of 4 years (1460 days).
+
+     openssl x509 -in cert.pem -noout -text
+
+lists the properties of  a X.509 certificate cert.pem. It allows you to verify
+whether the configuration defaults in openssl.cnf have been inserted correctly.
+
+If you prefer the CA certificate to be in binary DER format then the following
+command achieves this transformation:
+
+     openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der
+
+The directory /etc/ipsec.d/cacerts contains all required CA certificates either
+in binary DER or in base64 PEM format. Irrespective of the file suffix, Pluto
+"automagically" determines the correct format.
+
+
+3.2 Generating a host or user certificate
+    -------------------------------------
+
+The OpenSSL statement
+
+     openssl req -newkey rsa:1024 -keyout hostKey.pem \
+                 -out hostReq.pem
+
+generates a 1024 bit RSA private key hostKey.pem and a certificate request
+hostReq.pem which has to be signed by the CA.
+
+If you want to add a subjectAltName field to the host certificate you must edit
+the OpenSSL configuration file openssl.cnf and add the following line in the
+[ usr_cert ] section:
+
+     subjectAltName=DNS:moon.strongswan.org
+
+if you want to identify the host by its Fully Qualified Domain Name (FQDN ), or
+
+     subjectAltName=IP:192.168.0.1
+
+if you want the ID to be of type IPV4_ADDR. Of course you could include both
+ID types with
+
+     subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1
+
+but the use of an IP address for the identification of a host should be
+discouraged anyway.
+
+For user certificates the appropriate ID type is USER_FQDN which can be
+specified as
+
+     subjectAltName=email:carol@strongswan.org
+
+or if the user's e-mail address is part of the subject's distinguished name
+
+     subjectAltName=email:copy
+
+Now the certificate request can be signed by the CA with the command
+
+     openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext
+
+If you omit the -days option then the default_days value (365 days) specified
+in openssl.cnf is used. The -notext option avoids that a human readable
+listing of the certificate is prepended to the base64 encoded certificate
+body.
+
+If you want to use the dynamic CRL fetching feature described in section 4.7
+then you may include one or several crlDistributionPoints in your end
+certificates. This can be done in the [ usr_cert ] section of the openssl.cnf
+configuration file:
+
+    crlDistributionPoints= @crl_dp
+
+    [ crl_dp ]
+
+    URI.1="http://crl.strongswan.org/strongswan.crl"
+    URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=Linux strongSwan
+      , c=CH?certificateRevocationList"
+
+If you have only a single http distribution point then the short form
+
+    crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl"
+
+also works. Due to a known bug in OpenSSL this notation fails with ldap URIs.
+
+Usually a Windows-based VPN client needs its private key, its host or
+user certificate, and the CA certificate. The most convenient way to load
+this information is to put everything into a  PKCS#12 file:
+
+     openssl pkcs12 -export -inkey carolKey.pem \
+                    -in carolCert.pem -name "carol" \
+                    -certfile strongswanCert.pem -caname "strongSwan Root CA" \
+                    -out carolCert.p12
+
+
+3.3 Generating a CRL
+    ----------------
+
+An empty CRL that is signed by the CA can be generated with the command
+
+     openssl ca -gencrl -crldays 15 -out crl.pem
+
+If you omit the -crldays option then the default_crl_days value (30 days)
+specified in openssl.cnf is used.
+
+If you prefer the CRL to be in binary DER format then this conversion
+can be achieved with
+
+     openssl crl -in crl.pem -outform DER -out cert.crl
+
+The directory /etc/ipsec.d/crls contains all CRLs either in binary DER
+or in base64 PEM format. Irrespective of the file suffix, Pluto
+"automagically" determines the correct format.
+
+
+3.4 Revoking a certificate
+    ----------------------
+
+A specific host certificate stored in the file host.pem is revoked with the
+command
+
+     openssl ca -revoke host.pem
+
+Next the CRL file must be updated
+
+     openssl ca -gencrl -crldays 60 -out crl.pem
+
+The content of the CRL file can be listed with the command
+
+     openssl crl -in crl.pem -noout -text
+
+in the case of a base64 CRL, or alternatively for a CRL in DER format
+
+     openssl crl -inform DER -in cert.crl -noout -text
+
+
+
+4. Configuring the connections - ipsec.conf
+   ----------------------------------------
+
+4.1 Configuring my side
+    -------------------
+
+Usually the local side is the same for all connections. Therefore it makes
+sense to put the definitions characterizing the strongSwan security gateway into
+the conn %default section of the configuration file /etc/ipsec.conf. If we
+assume throughout this document that the strongSwan security gateway is left and
+the peer is right then we can write
+
+conn %default
+     # my side is left - the freeswan security gateway
+     left=%defaultroute
+     leftcert=moonCert.pem
+     # load connection definitions automatically
+     auto=add
+
+The X.509 certificate by which the strongSwan security gateway will authenticate
+itself by sending it in binary form to its peers as part of the Internet Key
+Exchange (IKE) is specified in the line
+
+     leftcert=moonCert.pem
+
+The certificate can either be stored in base64 PEM-format or in the binary
+DER-format. Irrespective of the file suffix, Pluto "automagically" determines
+the correct format. Therefore
+
+     leftcert=moonCert.der
+
+or
+
+     leftcert=moonCert.cer
+
+would also be valid alternatives.
+
+When using relative pathnames as in the examples above, the certificate files
+must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish
+strongSwan's own certificates from locally stored trusted peer certificates
+(see section 5.5 for details), they could also be stored in a subdirectory
+below /etc/ipsec.d/certs as e.g. in
+
+    leftcert=mycerts/moonCert.pem
+
+Absolute pathnames are also possible as in
+
+    leftcert=/usr/ssl/certs/moonCert.pem
+
+As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain
+Name (FQDN) of the form
+
+conn rw
+     right=%any
+     leftid=@moon.strongswan.org
+
+Important: When an FQDN identifier is used it must be explicitly included as a
+so called subjectAltName of type dnsName (DNS:) in the certificate indicated
+by leftcert. For details on how to generate certificates with subjectAltNames,
+please refer to section 7.2.
+
+If you don't want to mess with subjectAltNames, you can use the certificate's
+Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN
+and which can be written e.g. in the LDAP-type format
+
+conn rw
+     right=%any
+     leftid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
+
+Since the subject's DN is part of the certificate, the leftid does not have to
+be declared explicitly. Thus the entry
+
+conn rw
+     right=%any
+
+automatically assumes the subject DN of leftcert to be the host ID.
+
+
+4.2 Multiple certificates
+    ---------------------
+
+strongSwan supports multiple local host certificates and corresponding
+RSA private keys:
+
+conn rw1
+     right=%any
+     rightid=@peer1.domain1
+     leftcert=myCert1.pem
+     # leftid is DN of myCert1
+
+conn rw2
+     right=%any
+     rightid=@peer2.domain2
+     leftcert=myCert2.pem
+     # leftid is DN of myCert2
+
+When peer1 initiates a connection then strongSwan will send myCert1 and will
+sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas
+myCert2 and myKey2 will be used in a connection setup started from peer2.
+
+
+4.3 Configuring the peer side using CA certificates
+    -----------------------------------------------
+
+Now we can proceed to define our connections. In many applications we might
+have dozens of mostly Windows-based road warriors connecting to a central
+strongSwan security gateway. The following most simple statement:
+
+conn rw
+     right=%any
+
+defines the general roadwarrior case. The line right=%any literally means that
+any IPSec peer is accepted, regardless of its current IP source address and its
+ID, as long as the peer presents a valid X.509 certificate signed by a CA the
+strongSwan security gateway puts explicit trust in. Additionally the signature
+during IKE main mode gives proof that the peer is in possession of the private
+RSA key matching the public key contained in the transmitted certificate.
+
+The ID by which a peer is identifying itself during IKE main mode can by any of
+the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first
+three ID types is used, then the accompanying X.509 certificate of the peer
+must contain a matching subjectAltName field of the type ipAddress (IP:),
+dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type
+DER_ASN1_DN the identifier must completely match the subject field of the
+peer's certificate. One of the two possible representations of a
+Distinguished Name (DN) is the LDAP-type format
+
+     rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
+
+Additional whitespace can be added everywhere as desired since it will be
+automatically eliminated by the X.509 parser. An exception is the single
+whitespace between individual words , like e.g. in Linux strongSwan, which is
+preserved by the parser.
+
+The Relative Distinguished Names (RDNs) can alternatively be separated by a
+slash '/' instead of a comma ','
+
+     rightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org"
+
+This is the representation extracted from the certificate by the OpenSSL
+command line option
+
+     openssl x509 -in sunCert.pem -noout -subject
+
+The following RDNs are supported by strongSwan
+
++---------------------------------------------------+
+| DC               Domain Component                 |
+|---------------------------------------------------|
+| C                Country                          |
+|---------------------------------------------------|
+| ST               State or province                |
+|---------------------------------------------------|
+| L                Locality or town                 |
+|---------------------------------------------------|
+| O                Organisation                     |
+|---------------------------------------------------|
+| OU               Organisational Unit              |
+|---------------------------------------------------|
+| CN               Common Name                      |
+|---------------------------------------------------|
+| ND               NameDistinguisher, used with CN  |
+|---------------------------------------------------|
+| N                Name                             |
+|---------------------------------------------------|
+| G                Given name                       |
+|---------------------------------------------------|
+| S                Surname                          |
+|---------------------------------------------------|
+| I                Initials                         |
+|---------------------------------------------------|
+| T                Personal title                   |
+|---------------------------------------------------|
+| E                E-mail                           |
+|---------------------------------------------------|
+| Email            E-mail                           |
+|---------------------------------------------------|
+| emailAddress     E-mail                           |
+|---------------------------------------------------|
+| SN               Serial number                    |
+|---------------------------------------------------|
+| serialNumber     Serial number                    |
+|---------------------------------------------------|
+| D                Description                      |
+|---------------------------------------------------|
+| ID               X.500 Unique Identifier          |
+|---------------------------------------------------|
+| UID              User ID                          |
+|---------------------------------------------------|
+| TCGID            [Siemens] Trust Center Global ID |
+|---------------------------------------------------|
+| unstructuredName Unstructured Name                |
+|---------------------------------------------------|
+| UN               Unstructured Name                |
+|---------------------------------------------------|
+| employeeNumber   Employee Number                  |
+|---------------------------------------------------|
+| EN               Employee Number                  |
++---------------------------------------------------+
+
+With the roadwarrior connection definition listed above, an IPsec SA for
+the strongSwan security gateway moon.strongswan.org itself can be established.
+If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24
+and 10.1.3.0/24 behind the security gateway then the following connection
+definitions will make this possible
+
+conn rw1
+     right=%any
+     leftsubnet=10.1.0.0/24
+
+conn rw3
+     right=%any
+     leftsubnet=10.1.3.0/24
+
+If not all peers in possession of a X.509 certificate signed by a specific
+certificate authority shall be given access to the Linux security gateway,
+then either a subset of them can be barred by listing the serial numbers of
+their certificates in a certificate revocation list (CRL) as specified in
+section 5.2 or as an alternative, access can be controlled by explicitly
+putting a roadwarrior entry for each eligible peer into ipsec.conf:
+
+conn sun
+     right=%any
+     rightid=@sun.strongswan.org
+
+conn carol
+     right=%any
+     rightid=carol@strongswan.org
+
+conn dave
+     right=%any
+     rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org"
+
+When the IP address of a peer is known to be stable, it can be specified as
+well. This entry is mandatory when the strongSwan host wants to act as the
+initiator of an IPSec connection.
+
+conn sun
+     right=192.168.0.2
+     rightid=@sun.strongswan.org
+
+conn carol
+     right=192.168.0.100
+     rightid=carol@strongswan.org
+
+conn dave
+     right=192.168.0.200
+     rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org"
+
+conn venus
+     right=192.168.0.50
+
+In the last example the ID types FQDN, USER_FQDN, DER_ASN1_DN and IPV4_ADDR,
+respectively, were used. Of course all connection definitions presented so far
+have included the lines in the conn %defaults section, comprising among other
+a left and leftcert entry.
+
+
+4.4 Handling Virtual IPs and wildcard subnets
+    -----------------------------------------
+
+Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes
+the inner IP source address of an IPsec tunnel to be different from the
+outer IP source address usually assigned dynamically by the ISP.
+Whereas the varying outer IP address can be handled by the right=%any
+construct, the inner IP address or subnet must always be declared in a
+connection definition. Therefore for the three roadwarriors rw1 to rw3
+connecting to a strongSwan security gateway the following entries are
+required in /etc/ipsec.conf:
+
+conn rw1
+     right=%any
+     righsubnet=10.4.0.5/32
+
+conn rw2
+     right=%any
+     rightsubnet=10.4.0.47/32
+
+conn rw3
+     right=%any
+     rightsubnet=10.4.0.128/28
+
+With the wildcard parameter rightsubnetwithin these three entries can be
+reduced to the single connection definition
+
+conn rw
+     right=%any
+     rightsubnetwithin=10.4.0.0/24
+
+Any host will be accepted (of course after successful authentication based on
+the peer's X.509 certificate only) if it declares a client subnet lying totally
+within the brackets defined by the wildcard subnet definition (in our example
+10.4.0.0/24). For each roadwarrior a connection instance tailored to the
+subnet of the particular client will be created,based on the generic
+rightsubnetwithin template.
+
+This strongSwan feature can also be helpful with VPN clients getting a
+dynamically assigned inner IP from a DHCP server located on the NAT router box.
+
+
+4.5 Protocol and Port Selectors
+    ---------------------------
+
+strongSwan offer the possibility to restrict the protocol and optionally the
+ports in an IPsec SA using the rightprotoport and leftprotoport parameters.
+
+Some examples:
+
+conn icmp
+     right=%any
+     rightprotoport=icmp
+     left=%defaultroute
+     leftid=@moon.strongswan.org
+     leftprotoport=icmp
+
+conn http
+     right=%any
+     rightprotoport=6
+     left=%defaultroute
+     leftid=@moon.strongswan.org
+     leftprotoport=6/80
+
+conn l2tp       # with port wildcard for Mac OS X Panther interoperability
+     right=%any
+     rightprotoport=17/%any
+     left=%defaultroute
+     leftid=@moon.strongswan.org
+     leftprotoport=17/1701
+
+conn dhcp
+     right=%any
+     rightprotoport=udp/bootpc
+     left=%defaultroute
+     leftid=@moon.strongswan.org
+     leftsubnet=0.0.0.0/0  #allows DHCP discovery broadcast
+     leftprotoport=udp/bootps
+     rekey=no
+     keylife=20s
+     rekeymargin=10s
+     auto=add
+
+Protocols and ports can be designated either by their numerical values
+or by their acronyms defined in /etc/services.
+
+    ipsec status
+
+shows the following connection definitions:
+
+"icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0
+"http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0
+"l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any
+"dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]:17/67...%any:17/68
+
+Based on the protocol and port selectors appropriate eroutes will be set
+up, so that only the specified payload types will pass through the IPsec
+tunnel.
+
+
+4.6 IPsec policies based on wildcards
+    ---------------------------------
+
+In large VPN-based remote access networks there is often a requirement that
+access to the various parts of an internal network must be granted selectively,
+e.g. depending on the group membership of the remote access user. strongSwan
+makes this possible by applying wildcard filtering on the VPN user's 
+distinguished name (ID_DER_ASN1_DN).
+
+Let's make a practical example:
+An organization has a sales department (OU=Sales) and a research group
+(OU=Research). In the company intranet there are separate subnets for Sales
+(10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web
+server (10.0.2.100). The VPN clients use Virtual IP addresses that are either
+assigned statically or via DHCP-over-IPsec. The sales and research departments
+use IP addresses from separate DHCP address pools (10.1.0.0/24) and (10.1.1.0/24),
+respectively. An X.509 certificate is issued to each employee, containing in its
+subject distinguished name the country (C=CH), the company (O=ACME),
+the group membership(OU=Sales or OU=Research) and the common name (e.g.
+CN=Bart Simpson).
+
+The IPsec policy defined above can now be enforced with the following three
+IPsec security associations:
+
+conn sales
+     right=%any
+     rightid="C=CH, O=ACME, OU=Sales, CN=*"
+     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
+     leftsubnet=10.0.0.0/24         # Sales subnet
+
+conn research
+     right=%any
+     rightid="C=CH, O=ACME, OU=Research, CN=*"
+     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
+     leftsubnet=10.0.1.0/24          # Research subnet
+
+conn web
+     right=%any
+     rightid="C=CH, O=ACME, OU=*, CN=*"
+     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
+     leftsubnet=10.0.2.100/32        # Web server
+     rightprotoport=tcp              # TCP protocol only
+     leftprotoport=tcp/http          # TCP port 80 only
+
+Of course group specific tunneling could be implemented on the
+basis of the Virtual IP range specified by the rightsubnetwithin
+parameter alone, but the wildcard matching mechanism guarantees that
+only authorized user can access the corresponding subnets.
+
+The '*' character is used as a wildcard in relative distinguished names (RDNs).
+In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain
+the same number of RDNs (selected from the list in section 4.3) appearing in the
+exact order defined by the template.
+
+    "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson"
+
+matches the templates
+
+    "C=CH, O=ACME, OU=Research, OU=*, CN=*"
+
+    "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*"
+
+    "C=CH, O=ACME, OU=*, OU=*, CN=*"
+
+but not the template
+
+    "C=CH, O=ACME, OU=*, CN=*"
+
+which doesn't have the same number of RDNs.
+
+
+4.7 IPsec policies based on CA certificates
+    ---------------------------------------
+
+As an alternative to the wildcard based IPsec policies described in section 4.6,
+access to specific client host and subnets can abe controlled on the basis of
+the CA that issued the peer certificate
+
+
+conn sales
+     right=%any
+     rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA"
+     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
+     leftsubnet=10.0.0.0/24         # Sales subnet
+
+conn research
+     right=%any
+     rightca="C=CH, O=ACME, OU=Research, CN=Research CA"
+     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
+     leftsubnet=10.0.1.0/24          # Research subnet
+
+conn web
+     right=%any
+     rightca="C=CH, O=ACME, CN=ACME Root CA"
+     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
+     leftsubnet=10.0.2.100/32        # Web server
+     rightprotoport=tcp              # TCP protocol only
+     leftprotoport=tcp/http          # TCP port 80 only
+
+In the example above, the connection "sales" can be used by peers
+presenting certificates issued by the Sales CA, only. In the same way,
+the use of the connection "research" is restricted to owners of certificates
+issued by the Research CA. The connection "web" is open to both "Sales" and
+"Research" peers because the required "ACME Root CA" is the issuer of the
+Research and Sales intermediate CAs. If no rightca parameter is present
+then any valid certificate issued by one of the trusted CAs in
+/etc/ipsec.d/cacerts can be used by the peer.
+
+The leftca parameter usually doesn't have to be set explicitly because
+by default it is set to the issuer field of the certificate loaded via
+leftcert. The statement
+
+     rightca=%same
+
+sets the CA requested from the peer to the CA used by the left side itself
+as e.g. in
+
+conn sales
+     right=%any
+     rightca=%same
+     leftcert=mySalesCert.pem
+
+
+4.8 Sending certificate requests
+    ----------------------------
+
+The presence of a rightca parameter also causes the CA to be sent as
+part of the certificate request message when strongSwan is the initiator.
+A special case occurs when strongSwan responds to a roadwarrior. If several
+roadwarrior connections based on different CAs are defined then all eligible
+CAs will be listed in Pluto\92s certificate request message.
+
+
+4.9 IPsec policies based on group attributes
+    ----------------------------------------
+
+X.509 attribute certificates are the most powerful mechanism for implementing
+IPsec security policies. The rightgroups parameter in a connection definition
+restricts the access to members of the listed groups only. An IPsec peer must
+have a valid attribute certificate issued by a trusted Authorization Authority
+and listing one of the requirede group attributes in order to get admitted.
+
+conn sales
+     right=%any
+     rightgroups="Sales"
+     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
+     leftsubnet=10.0.0.0/24         # Sales subnet
+
+conn research
+     right=%any
+     rightgroups="Research"
+     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
+     leftsubnet=10.0.1.0/24          # Research subnet
+
+conn web
+     right=%any
+     rightgroups="Sales, Research"
+     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
+     leftsubnet=10.0.2.100/32        # Web server
+     rightprotoport=tcp              # TCP protocol only
+     leftprotoport=tcp/http          # TCP port 80 only
+
+In the examples above membership of the group "Sales" is required for
+connection sales and membership of "Research" for connection research
+whereas connection web is accessible for both groups.
+
+Currently the attribute certificates of the peers must be loaded statically
+via the /etc/ipsec.d/acerts/ directory. In future releases of strongSwan it
+will be possible to fetch them from an LDAP directory server.
+
+
+5. Configuring certificates and CRLs
+   ---------------------------------
+
+
+5.1 Installing the CA certificates
+    ------------------------------
+
+X.509 certificates received by strongSwan during the IKE protocol are
+automatically authenticated by going up the trust chain until a self-signed
+root CA certificate is reached. Usually host certificates are directly signed
+by a root CA, but strongSwan also supports multi-level hierarchies with
+intermediate CAs in between. All CA certificates belonging to a trust chain
+must be copied in either binary DER or base64 PEM format into the directory
+
+     /etc/ipsec.d/cacerts/
+
+
+5.2 Installing optional certificate revocation lists (CRLs)
+    -------------------------------------------------------
+
+By copying a CA certificate into /etc/ipsec.d/cacerts/, automatically all user
+or host certificates issued by this CA are declared valid. Unfortunately
+private keys might get compromised inadvertently or intentionally, personal
+certificates of users leaving a company have to be blocked immediately, etc.
+To this purpose certificate revocation lists (CRLs) have been created. CRLs
+contain the serial numbers of all user or host certificates that have been
+revoked due to various reasons.
+
+After successful verification of the X.509 trust chain, Pluto searches its
+list of CRLs either obtained by loading them from the /etc/ipsec.d/crls/
+directory or fetching them dynamically from a HTTP or LDAP server for the
+presence of a CRL issued by the CA that has signed the certificate.
+
+If the serial number of the certificate is found in the CRL then the public key
+contained in the certificate is declared invalid and the IPSec SA will not be
+established. If no CRL is found or if the deadline defined in the nextUpdate
+field of the CRL has been reached, a warning is issued but the public key will
+nevertheless be accepted. CRLs must be stored either in binary DER or base64 PEM
+format in the crls directory. Section 7.3 will explain in detail how CRLs can
+be created using OpenSSL.
+
+
+5.3 Dynamic update of certificates and CRLs
+    ---------------------------------------
+
+Pluto reads certificates and CRLs from their respective files during system
+startup and keeps them in memory in the form of chained lists. X.509
+certificates have a finite life span defined by their validity field. Therefore
+it must be possible to replace CA or OCSP certificates kept in system memory
+without disturbing established ISAKMP SAs. Certificate revocation lists should
+also be updated in the regular intervals indicated by the nextUpdate field in
+the CRL body. The following interactive commands allow the manual replacement
+of the various files:
+
++---------------------------------------------------------------------------+
+| ipsec rereadsecrets       reload file /etc/ipsec.secrets                  |
+|---------------------------------------------------------------------------|
+| ipsec rereadcacerts       reload all files in /etc/ipsec.d/cacerts/       |
+|---------------------------------------------------------------------------|
+| ipsec rereadaacerts       reload all files in /etc/ipsec.d/aacerts/       |
+|---------------------------------------------------------------------------|
+| ipsec rereadocspcerts     reload all files in /etc/ipsec.d/ocspcerts/     |
+|---------------------------------------------------------------------------|
+| ipsec rereadacerts        reload all files in /etc/ipsec.d/acerts/        |
+|---------------------------------------------------------------------------|
+| ipsec rereadcrls          reload all files in /etc/ipsec.d/crls/          |
+|---------------------------------------------------------------------------|
+| ipsec rereadall           ipsec rereadsecrets                             |
+|                                 rereadcacerts                             |
+|                                 rereadaacerts                             |
+|                                 rereadocspcerts                           |
+|                                 rereadacerts                              |
+|                                 rereadcrls                                |
+|---------------------------------------------------------------------------|
+| ipsec purgeocsp           purge the OCSP cache and fetching requests      |
++---------------------------------------------------------------------------+
+
+CRLs can also be automatically fetched from an HTTP or LDAP server by using
+the CRL distribution points contained in X.509 certificates. The command
+
+    ipsec listcrls
+    
+shows any pending fetch requests:
+
+  Oct 31 00:29:53 2002, trials: 2
+         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         distPts: 'http://crl.strongswan.org/strongswan.crl'
+                 'ldap://ldap.strongswan.org/o=Linux strongSwan, c=CH
+                    ?certificateRevocationList?base
+                    ?(objectClass=certificationAuthority)'
+
+In the example above, an http and an ldap URL were extracted from a received
+end certificate. An independent thread then tries to fetch a CRL from the
+designated distribution points. The same thread also periodically checks
+if any loaded CRLs are about to expire. The check interval can be defined in
+the "config setup" section of the ipsec.conf file:
+
+   config setup
+       crlcheckinterval=600
+
+In our example the thread wakes up every 600 seconds or 10 minutes in order
+to check the validity of the CRLs or to retry any pending fetch requests:
+
+  List of X.509 CRLs:
+  
+  Dec 19 09:35:31 2002, revoked certs: 40
+         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         distPts: 'http://crl.strongswan.org/strongswan.crl'
+         updates:  this Dec 19 09:35:00 2002
+                   next Dec 19 10:35:00 2002 warning (expires in 19 minutes)
+
+  List of fetch requests:
+
+  Dec 19 10:15:31 2002, trials: 1
+        issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+        distPts: 'http://crl.strongwan.org/strongswan.crl'
+
+The first trial to update a CRL is started 2*crlcheckinterval before the
+nextUpdate time, i.e. when less than 20 minutes are left in our practical
+example. When crlcheckinterval is set to 0 (this is also the default value
+when the parameter is not set in ipsec.conf) then the CRL checking and updating 
+thread is not started and dynamic CRL fetching is disabled.
+
+
+5.4 Local caching of CRLs
+    ---------------------
+
+The the ipsec.conf option
+
+   config setup
+        cachecrls=yes
+
+activates the local caching of CRLs that were dynamically fetched from an
+HTTP or LDAP server. Cached copies are stored in /etc/ipsec.d/crls under a
+unique filename formed from the issuer's SubjectKeyIdentifier and the suffix .crl.
+
+With the cached copy the CRL is immediately available after pluto's startup.
+When the local copy is about to expire it is automatically replaced with an
+updated CRL fetched from one of the defined CRL distribution points.
+
+
+5.5 Online Certificate Status Protocol (OCSP)
+    -----------------------------------------
+
+The Online Certificate Status Protocol is defined by RFC 2560. It can be
+used to query an OCSP server about the current status of an X.509 certificate
+and is often used as a more dynamic alternative to a static Certificate
+Revocation List (CRL). Both the OCSP request sent by the client and the OCSP
+response messages returned by the server are transported via a standard
+TCP/HTTP connection. Therefore cURL support must be enabled in pluto/Makefile:
+
+  # Uncomment this line to enable OCSP fetching using HTTP
+  LIBCURL=1
+
+In the simplest OCSP setup, a default URI under which the OCSP server for a
+given CA can be accessed is defined in ipsec.conf:
+
+   config setup
+        crlcheckinterval=600
+       
+   ca strongswan
+        cacert=strongswanCert.pem
+        ocspuri=http://ocsp.strongswan.org:8880
+        auto=add
+
+The HTTP port can be freely chosen. In our example we have assumed TCP port 8880.
+The crlcheckinterval must be set to a value different from zero. Otherwise the
+OCSP fetching thread will not be started.
+
+The well-known openssl-0.9.7 package from http://www.openssl.org implements
+an OCSP server that can be used in conjunction with an openssl-based Public
+Key Infrastructure. The OCSP client integrated into Pluto does not contain
+any OpenSSL code though, but is based on the existing ASN.1 functionality of
+strongSwan.
+
+The OpenSSL-based OCSP server is started with the following command:
+
+    openssl ocsp -index index.txt -CA strongswanCert.pem -port 8880 \
+                 -rkey ocspKey.pem -rsigner ocspCert.pem \
+                 -resp_no_certs -nmin 60 -text
+
+The command consists of the parameters
+
+ -index  index.txt is a copy of the OpenSSL index file containing the list of
+         all issued certificates. The certificate status in indext.txt
+         is designated either by V for valid or R for revoked. If
+         a new certificate is added or if a certificate is revoked
+         using the openssl ca command, the OCSP server must be restarted
+         in order for the changes in index.txt to take effect.
+
+ -CA     the CA certificate
+
+ -port   the HTTP port the OCSP server is listening on.
+-rkey    the private key used to sign the OCSP response. The use of the
+         sensitive CA private key is not recommended since this could
+         jeopardize the security of your production PKI if the OCSP
+         server is hacked. It is much better to generate a special
+         RSA private key just for OCSP signing use instead.
+
+-rsigner the certificate of the OCSP server containing a public key which
+         matches the private key defined by -rkey and which can be used by
+         the client to check the trustworthiness of the signed OCSP response.
+
+-resp_no_certs  With this option the OCSP signer certificate defined by
+                -rsigner is not included in the OCSP response.
+
+-nmin    the validity interval of an OCSP response given in minutes.
+         2*crlcheckinterval before the expiration of the OCSP responses,
+         a new query will by pro-actively started by the Pluto fetching thread.
+
+         If nmin is missing or set to zero then the default validity interval
+         compiled into Pluto will be 2 minutes, leading to a quasi one-time
+         use of the OCSP status response which will not be periodically 
+         refreshed by the fetching thread. In conjunction with the parameter
+        setting "strictcrlpolicy=yes" a real-time certificate status query
+        can be implemented in this way.
+
+-text   This option activates a verbose logging output, showing the contents
+        of both the received OCSP request and sent OCSP response.
+
+How does Pluto get hold of the OCSP signer certificate? There are two
+possibilities:
+Either you put the OCSP certificate into the default directory
+
+    /etc/ipsec.d/ocspcerts
+    
+or alternatively Pluto can receive it as part of the OCSP response from the
+remote OCSP server. In the latter case, how can Pluto make sure that
+the server has indeed been authorized by the CA to deal out certificate status
+information? In order to ascertain the OCSP signer capability, an extended
+key usage attribute can be included in the OCSP server certificate. Just
+insert the parameter
+
+    extendedKeyUsage=OCSPSigner
+
+in the [ usr_cert ] section of your openssl.cnf configuration file before
+the CA signs the OCSP server certificate.
+
+For a given CA the corresponding ca section in ipsec.conf (see section 7) allows
+to define the URI of a single OCSP server. As an alternative an OCSP URI can be
+embedded into each host and user certificate by putting the line
+
+    authorityInfoAccess = OCSP;URI:http://ocsp.strongswan.org:8880
+
+into the [ usr_cert ] section of your openssl.cnf configuration file.
+If an OCSP authorityInfoAccess extension is present in a certificate then this
+record overrides the default URI defined by the ca section.
+
+
+5.6 CRL Policy
+    ----------
+
+By default Pluto is quite tolerant concerning the handling of CRLs. It is not
+mandatory for a CRL to be present in /etc/ipsec.d/crls and if the expiration
+date defined by the nextUpdate field of a CRL has been reached just a warning
+is issued but a peer certificate will always be accepted if it has not been
+revoked.
+
+If you want to enforce a stricter CRL policy then you can do this by setting
+the "strictcrlpolicy" option. This is done in the "config setup" section
+of the ipsec.conf file:
+
+    config setup
+         strictcrlpolicy=yes
+          ...
+
+A certificate received from a peer will not be accepted if no corresponding
+CRL or OCSP response is available. And if an ISAKMP SA re-negotiation takes
+place after the nextUpdate deadline has been reached, the peer certificate
+will be declared invalid and the cached RSA public key will be deleted, causing
+the connection in question to fail. Therefore if you are going to use the
+"strictcrlpolicy=yes" option, make sure that the CRLs will always be updated
+in time. Otherwise a total standstill would ensue.
+
+As mentioned earlier the default setting is "strictcrlpolicy=no"
+
+
+5.7 Configuring the peer side using locally stored certificates
+    -----------------------------------------------------------
+
+If you don't want to use trust chains based on CA certificates as proposed in
+section 4.3 you can alternatively import trusted peer certificates directly
+into Pluto. Thus you do not have to rely on the certificate to be transmitted
+by the peer as part of the IKE protocol.
+
+With the conn %default section defined in section 4.1 and the use of the
+rightcert keyword for the peer side, the connection definitions in section 4.3
+can alternatively be written as
+
+    conn sun
+          right=%any
+          rightid=@sun.strongswan.org
+          rightcert=sunCert.cer
+
+     conn carol
+          right=192.168.0.100
+          rightcert=carolCert.der
+
+If the peer certificates are loaded locally then there is no sense in sending
+any certificates to the other end via the IKE Main Mode protocol. Especially
+if self-signed certificates are used which wouldn't be accepted any way by
+the other side. In these cases it is recommended to add
+
+          leftsendcert=never
+
+to the connection definition[s] in order to avoid the sending of the host's
+own certificate. The default value is
+
+    leftsendcert=always.
+
+If a peer certificate contains a subjectAltName extension, then an alternative
+rightid type can be used, as the example "conn sun" shows. If no rightid
+entry is present then the subject distinguished name contained in the
+certificate is taken as the ID.
+
+Using the same rules concerning pathnames that apply to strongSwan's own
+certificates, the following two definitions are also valid for trusted peer
+certificates:
+
+    rightcert=peercerts/carolCert.der
+
+or
+
+    rightcert=/usr/ssl/certs/carolCert.der
+
+
+6. Installing the private key - ipsec.secrets
+   ------------------------------------------
+
+6.1 Loading private key files in PKCS#1 format
+    ------------------------------------------
+
+Besides strongSwan's raw private key format strongSwan has been enabled to
+load RSA private keys in the PKCS#1 file format. The key files can be
+optionally secured with a passphrase.
+
+RSA private key files are declared in /etc/ipsec.secrets using the syntax
+
+    : RSA <my keyfile> "<optional passphrase>"
+
+The key file can be either in base64 PEM-format or binary DER-format. The
+actual coding is detected "automagically" by Pluto. The example
+
+    : RSA moonKey.pem
+
+uses a relative pathname. In this case Pluto will look for the key file
+in the directory
+
+    /etc/ipsec.d/private
+
+As an alternative an absolute pathname can be given as in
+
+    : RSA /usr/ssl/private/moonKey.pem
+
+In both cases make sure that the key files are root readable only.
+
+Often a private key must be transported from the Certification Authority
+where it was generated to the target security gateway where it is going
+to be used. In order to protect the key it can be encrypted with 3DES
+using a symmetric transport key derived from a cryptographically strong
+passphrase.
+
+    openssl genrsa -des3 -out moonKey.pem 1024
+
+Because of the weak security, key files protected by single DES will not
+be accepted by Pluto!!!
+
+Once on the security gateway the private key can either be permanently
+unlocked so that it can be used by Pluto without having to know a
+passphrase
+
+    openssl rsa -in moonKey.pem -out moonKey.pem
+
+or as an option the key file can remain secured. In this case the passphrase
+unlocking the private key must be added after the pathname in
+/etc/ipsec.secrets
+
+    : RSA moonKey.pem "This is my passphrase"
+
+Some CAs distribute private keys embedded in a PKCS#12 file. Since Pluto
+is not able yet to read this format directly, the private key part must
+first be extracted using the command
+
+     openssl pkcs12 -nocerts -in moonCert.p12 -out moonKey.pem
+
+if the key file moonKey.pem is to be secured again by a passphrase, or
+
+     openssl pkcs12 -nocerts  -nodes -in moonCert.p12 -out moonKey.pem
+
+if the private key is to be stored unlocked.
+
+
+6.2 Entering passphrases interactively
+    ----------------------------------
+    
+On a VPN gateway you would want to put the passphrase protecting the private
+key file right into /etc/ipsec.secrets as described in the previous paragraph,
+so that the gateway can be booted in unattended mode. The risk of keeping
+unencrypted secrets on a server can be minimized by putting the box into a
+locked room. As long as no one can get root access on the machine the private
+keys are safe.
+    
+On a mobile laptop computer the situation is quite different. The computer can
+be stolen or the user is leaving it unattended so that unauthorized persons
+can get access to it. In theses cases it would be preferable not to keep any
+passphrases openly in /etc/ipsec.secrets but to prompt for them interactively
+instead. This is easily done by defining
+
+    : RSA moonKey.pem %prompt
+    
+Since strongSwan is usually started during the boot process, usually no
+interactive console windows is available which can be used by Pluto to
+prompt for the passphrase. This must be initiated by the user by typing
+
+    ipsec secrets
+    
+which actually is an alias for the existing command
+
+    ipsec rereadsecrets
+
+and which causes the prompt
+
+    need passphrase for '/etc/ipsec.d/private/moonKey.pem'
+    Enter:
+
+to appear. If the passphrase was correct and the private key file could be
+successfully decrypted then
+
+    valid passphrase
+    
+results. Otherwise the prompt
+
+   invalid passphrase, please try again
+   Enter:
+
+will give you another try. Entering a carriage return will abort the
+the passphrase prompting.
+
+
+6.3 Multiple private keys
+    ---------------------
+
+strongSwan supports multiple private keys. Since the connections defined
+in ipsec.conf can find the correct private key based on the public key
+contained in the certificate assigned by leftcert, default private key
+definitions without specific IDs can be used
+
+    : RSA myKey1.pem "<optional passphrase1>"
+
+    : RSA myKey2.pem "<optional passphrase2>"
+
+
+7. Configuring CA properties - ipsec.conf
+   --------------------------------------
+
+Besides the definition of IPsec connections the ipsec.conf file can also
+be used to configure a few properties of the certification authorities
+needed to establish the X.509 trust chains. The following example shows
+the parameters that are currently available:
+
+    ca strongswan
+       cacert=strongswanCert.pem
+       ocspuri=http://ocsp.strongswan.org:8880
+       crluri=http://crl.strongswan.org/strongswan.crl'
+       crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList"
+       ldaphost=ldap.strongswan.org
+       auto=add
+
+In a similar way as conn sections are used for connection definitions, an
+arbitrary number of optional ca sections define the basic properties of CAs.
+
+Each ca section is named with a unique label
+       ca strongswan
+
+The only mandatory parameter is
+
+       cacert=strongswanCert.pem
+
+which points to the CA certificate which usually resides in the default
+directory /etc/ipsec.d/cacerts/ but could also be retrieved via an absolute
+path name. If the CA certificate is stored on a smartcard then the
+notation
+
+       cacert=%smartcard#<n>
+
+or alternatively
+
+       cacert=%smartcard<optional slot nr>:<key id>
+
+can be used. The selection of smartcard slots is described in more detail
+in section 8.1.
+
+From the certificate the CA's distinguished name and the serial number
+is extracted. If an optional subjectKeyAuthentifier is present then it can
+be used to uniquely identify consecutive generations of CA certificates
+carrying the same distinguished name.
+
+The OCSP URI
+
+       ocspuri=http://ocsp.strongswan.org:8880
+
+allows to define an individual OCSP server per CA. Also up to two additional
+CRL distribution points (CDPs) can be defined
+
+       crluri=http://crl.strongswan.org/strongswan.crl'
+       crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList"
+
+which are added to any CDPs already present in the received certificates
+themselves. The last parameter
+
+       ldaphost=ldap.strongswan.org
+
+can be used to fill in the actual server name in LDAP CDPs where the host is missing
+as e.g. in the crluri2 above. In future releases this ldaphost parameter might be used
+to retrieve user, host and attribute certificates.
+
+
+With the auto=add statement the ca definition is automatically loaded into Pluto during
+system startup. Setting auto=ignore will ignore the ca section. Additional ca definitions
+can be loaded from ipsec.conf during runtime with the command
+
+      ipsec auto --type ca --add strongswan-sales
+
+and
+
+      ipsec auto --type ca --delete strongswan-sales
+
+deletes the labeled ca entry. And finally the command
+
+    ipsec auto --type ca --replace strongswan
+
+first deletes the old definition in Pluto's memory and then loads the updated version
+from ipsec.conf. Any parameters which appear in several ca definitions can be put in
+a common ca %default section
+
+    ca %default
+       ldaphost=ldap.strongswan.org
+
+
+8. Smartcard support
+   -----------------
+
+8.1 Configuring a smartcard-based connection
+    ----------------------------------------
+
+Defining a smartcard-based connection in ipsec.conf is easy:
+
+    conn sun
+         right=192.168.0.2
+        rightid=@sun.strongswan.org
+        left=%defaultroute
+        leftcert=%smartcard
+        auto=add
+
+In most cases there is a single smartcard reader or cryptotoken and only one
+RSA private key safely stored on the crypto device. Thus usually the entry
+
+    leftcert=%smartcard
+
+which stands for the full notation
+
+    leftcert=%smartcard#1
+
+is sufficient where the first certificate/private key object enumerated by
+the PKCS#11 module is used. If several certificate/private key objects are
+present then the nth object can be selected using
+
+    leftcert=%smartcard#<n>
+
+The command
+
+    ipsec listcards
+
+gives an overview over all certificate objects made available by the PKCS#11
+module.CA certificates are automatically available as trust anchors.
+
+As an alternative the certificate ID and/or the slot number defined by
+the PKCS#11 standard can be specified using the notation
+
+   leftcert=%smartcard<optional slot nr>:<key id in hex format>
+
+Thus
+
+    leftcert=%smartcard:50
+
+will look in all available slots for ID 0x50 starting with the first slot
+(usually slot 0) whereas
+
+    leftcert=%smartcard4:50
+
+will directly check slot 4 (which is usually the first slot on the second
+reader/token when using the OpenSC library) for a key with ID 0x50.
+
+
+8.2 Entering the PIN code
+    ---------------------
+
+Since the smartcard signing operation needed to sign the hash with the
+RSA private key during IKE Main Mode is protected by a PIN code,
+the secret PIN must be made available to Pluto.
+
+For gateways that must be able to start IPsec tunnels automatically in
+unattended mode after a reboot, the secret PIN  can be stored statically
+in ipsec.secrets
+
+   : PIN %smartcard "12345678"
+  
+or with the general notation
+
+   : PIN %smartcard#<n> "<PIN code>"
+
+or alternatively
+
+   : PIN %smartcard<optional slot nr>:<key id> "<PIN code>"
+  
+On personal notebooks that could get stolen, you wouldn't want to store
+your PIN in ipsec.secrets. Thus the alternative form
+
+   : PIN %smartcard %prompt
+  
+will prompt you for the PIN when you start up the first IPsec connection
+using the command
+
+   ipsec up sun
+  
+The auto command calls the whack function which in turn communicates with
+Pluto over a socket. Since the whack function call is executed from a command
+window, Pluto can prompt you for the PIN over this socket connection.
+Unfortunately roadwarrior connections which just wait passively for peers
+cannot be initiated via the command window:
+
+   conn rw
+         right=%any
+        left=%defaultroute
+        leftcert=%smartcard4:50
+        auto=add
+
+But if there is a corresponding entry
+
+   : PIN %smartcard4:50 %prompt
+  
+in ipsec.secrets, then the standard command
+
+   ipsec rereadsecrets
+  
+or the alias
+
+   ipsec secrets
+   
+can be used to enter the PIN code for this connection interactively.
+
+The command
+
+   ipsec listcards
+
+can be executed at any time to check the current status of the PIN code[s].
+
+
+8.3 PIN-pad equipped smartcard readers
+    ----------------------------------
+
+Smartcard readers with an integrated PIN-pad offer an increased security
+level because the PIN entry cannot be sniffed on the host computer e.g.
+by a surrepticiously installed key logger. In order to tell pluto not to
+prompt for the PIN on the host itself, the entry
+
+   : PIN %smartcard:50 %pinpad
+
+can be used in ipsec.secrets. Because the key pad does not cache the PIN in
+the smartcard reader, it must be entered for every PKCS #11 session login.
+By default pluto does a session logout after every RSA signature. In order
+to avoid the repeated entry of the PIN code during the periodic IKE main
+mode rekeyings, the following parameter can be set in the config setup
+section of ipsec.conf:
+
+   config setup
+        pkcs11keepstate=yes
+
+The default setting is pkcs11keepstate=no. 
+
+
+8.4 Configuring a smartcard with pkcsc15-init
+    -----------------------------------------
+
+strongSwan's smartcard solution is based on the PKCS#15 "Cryptographic Token
+Information Format Standard" fully supported by OpenSC library functions.
+Using the command
+
+    pkcs15-init --erase-card --create-pkcs15
+
+a fresh PKCS#15 file structure is created on a smartcard or cryptotoken.
+With the next command
+
+    pkcs15-init --auth-id 1 --store-pin --pin "12345678" --puk "87654321"
+                --label "my PIN"
+
+a secret PIN code with auth-id 1 is stored in an unretrievable location on
+the smart card. The PIN will protect the RSA signing operation. If the PIN
+is entered incorrectly more than three times the smartcard will be locked
+and the PUK code can be used to unlock the card again.
+
+Next the RSA private key is transferred to the smartcard
+
+    pkcs15-init --auth-id 1 --store-private-key myKey.pem [--id 45]
+
+By default the PKCS#15 smartcard record will be assigned the id 45.
+Using the --id option multiple key records can be stored on a smartcard.
+
+At last we load the matching X.509 certificate onto the smartcard
+
+    pkcs15-init --auth-id 1 --store-certificate myCert.pem [--id 45]
+
+The pkcs15-tool can now be used to verify the contents of the smartcard.
+
+   pkcs15-tool --list-pins --list-keys --list-certificates
+
+If everything is ok then you are ready to use the generated PKCS#15
+structure with strongSwan.
+
+8.5 PKCS#11 proxy functions
+    -----------------------
+
+   With the setting pkcs11keepstate=yes some PKCS#11 implementations
+   (e.g. OpenSC) will lock the access to the smartcard as soon as pluto has
+   opened a session and will thus prevent other application from sharing the
+   smartcard resource. In order to solve this locking problem, strongSwan
+   offers a PKCS#11 proxy service making use of the whack socket communication
+   channel. The setting
+
+   config setup
+      pkcs11proxy=yes
+
+will enable the proxy mode that is disabled by default. 
+
+Currently two smartcard operations are supported: RSA encryption and
+RSA decryption. The notation is as follows:
+
+   ipsec scdecrypt <encrypted data>
+                   [--inbase  16|hex|64|base64|256|text|ascii]
+                   [--outbase 16|hex|64|base64|256|text|ascii]
+                   [--keyid <id>]
+
+The default settings for inbase and outbase is hexadecimal.
+Thus the simplest call has the form
+
+   ipsec scdecrypt bb952b71920094ce0696ef9b8b26...12e6
+
+and the returned result might be a decrypted 128 bit AES key
+
+   000 8836362e030e6707c32ffaa0bdad5540
+
+The leading three characters represent the return code of the whack channel
+with 000 signifying that no error has occured. Here is another example showing
+the use of the inbase and outbase attributes
+
+   ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text
+
+where the result has the form
+
+   000 This is a secret
+
+By default the first RSA private key found by the PKCS#11 enumeration is
+used. If a different key should be selected then the notation introduced
+in sections 8.1 and 8.2 can be used:
+
+  --keyid %smartcard:50
+  --keyid %smartcard4:50
+  --keyid %smartcard#3
+
+with --keyid %smartcard#1 being the default. If supported by the smartcard
+and PKCS#11 library RSA encryption can be used with the notation
+
+   ipsec scencrypt <plaintext data>
+                   [--inbase  16|hex|64|base64|256|text|ascii]
+                   [--outbase 16|hex|64|base64|256|text|ascii]
+                   [--keyid <id>]
+
+with the example
+
+   ipsec scencrypt "This is a secret" --inbase ascii --outbase 64
+
+returning the expected output
+
+   000 m/ewDnTs0k...woE=
+
+
+9. Configuring the clients
+   -----------------------
+
+9.1 strongSwan
+    ----------
+
+A strongSwan to strongSwan connection is symmetrical. Any of the four defined
+ID types can be used, even different types on either end of the connection,
+although this wouldn't make much sense.
+
++--------------------------------------------------------------+
+| Connection Definition        ID type          subjectAltName |
+|--------------------------------------------------------------|
+| rightid  (strongSwan)        DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
+|--------------------------------------------------------------|
+| leftid   (strongSwan)        DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
++--------------------------------------------------------------+
+
+
+9.2 PGPnet
+    ------
+
+Use the file peerCert.p12 to import PGPnet's X.509 certificate, the CA
+certificate, plus the encrypted private key in binary PKCS#12 format into the
+PGPkey tool. You will be prompted for the passphrase securing the private key.
+
+Use the file myCert.pem to import the X.509 certificate of the strongSwan
+security gateway into the PGPkey tool. The PGPkeyTool does not accept X.509
+certificates in binary DER format, so it must be imported in base64 format:
+
+     -----BEGIN CERTIFICATE-----
+     M...
+
+     ...
+     -----END CERTIFICATE-----
+
+Make sure that there is no human-readable listing of the X.509 certificate in
+front of the line
+
+     -----BEGIN CERTIFICATE-----
+
+otherwise PGPnet will refuse to load the *.PEM file. Any surplus lines can
+either be deleted by loading the certificate into a text editor or you can
+apply the command
+
+     openssl x509 -in myCert.pem -out myCert.pem
+
+to achieve the same effect.
+
+With authentication based on X.509 certificates, PGPnet always sends the ID
+type DER_ASN1_DN, therefore rightid in the connection definition of the
+strongSwan security gateway must be an ASN.1 distinguished name.
+
+In the receiving direction PGPnet accepts all four ID types from strongSwan.
+
++--------------------------------------------------------------+
+| Connection Definition        ID type          subjectAltName |
+|--------------------------------------------------------------|
+| rightid  (PGPnet)            DER_ASN1_DN      -              |
+|--------------------------------------------------------------|
+| leftid   (strongSwan)        DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
++--------------------------------------------------------------+
+
+
+9.3 SafeNet/Soft-PK/Soft-Remote
+    ---------------------------
+
+SafeNet/Soft-PK and SafeNet/Soft-Remote can be configured to send their
+identity either as DER_ASN1_DN, IPV4_ADDR, FQDN, or USER_FQDN.
+In the receiving direction SafeNet/Soft-PK and SafeNet/Soft-Remote
+accept all four ID types coming from strongSwan.
+
++--------------------------------------------------------------+
+| Connection Definition        ID type          subjectAltName |
+|--------------------------------------------------------------|
+| rightid  (SafeNet/Soft-PK)   DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
+|--------------------------------------------------------------|
+| leftid  (strongSwan)         DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
++--------------------------------------------------------------+
+
+
+9.4 SSH Sentinel
+    ------------
+
+SSH Sentinel sends its identity as DER_ASN1_DN if the subjectAltName field of
+its certificate is empty. If a subjectAltName field is present, then the
+corresponding type IPV4_ADDR, FQDN, or USER_FQDN is automatically chosen.
+With several subjectAltName entries, the precedence of the different ID types
+is not quite clear. In the receiving direction SSH Sentinel accepts all four
+ID types from strongSwan.
+
++--------------------------------------------------------------+
+| Connection Definition        ID type          subjectAltName |
+|--------------------------------------------------------------|
+| rightid  (SSH Sentinel)      DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
+|--------------------------------------------------------------|
+| leftid  (strongSwan)         DER_ASN1_DN      -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
++--------------------------------------------------------------+
+
+
+9.5 Windows 2000/XP
+    ---------------
+
+Windows 2000 and Windows XP always send the ID type DER_ASN1_DN,
+therefore rightid in the connection definition of the strongSwan
+security gateway must be an ASN.1 distinguished name.In the
+receiving direction Windows 2000/XP accepts all four ID types
+from strongSwan.
+
++--------------------------------------------------------------+
+| Connection Definition        ID type          subjectAltName |
+|--------------------------------------------------------------|
+| rightid  (Windows 2000/XP)   DER_ASN1_DN      -              |
+|--------------------------------------------------------------|
+| leftid   (strongSwan)        DER_ASN1_D       -              |
+|                              FQDN             DNS:           |
+|                              USER_FQDN        email:         |
+|                              IPV4_ADDR        IP:            |
++--------------------------------------------------------------+
+
+
+10. Monitoring functions
+    --------------------
+
+strongSwan offers the following monitoring functions:
+
+
+    ipsec listalgs
+
+lists all IKE and ESP cryptographic algorithms that are currently
+registered with strongSwan.
+
+The a listing has the following form:
+
+  List of registered IKE Encryption Algorithms:
+
+  #3     OAKLEY_BLOWFISH_CBC, blocksize: 64, keylen: 128-128-256
+  #5     OAKLEY_3DES_CBC, blocksize: 64, keylen: 192-192-192
+  #7     OAKLEY_AES_CBC, blocksize: 128, keylen: 128-128-256
+  #65004 OAKLEY_SERPENT_CBC, blocksize: 128, keylen: 128-128-256
+  #65005 OAKLEY_TWOFISH_CBC, blocksize: 128, keylen: 128-128-256
+  #65289 OAKLEY_TWOFISH_CBC_SSH, blocksize: 128, keylen: 128-128-256
+
+  List of registered IKE Hash Algorithms:
+
+  #1     OAKLEY_MD5, hashsize: 128
+  #2     OAKLEY_SHA, hashsize: 160
+  #4     OAKLEY_SHA2_256, hashsize: 256
+  #6     OAKLEY_SHA2_512, hashsize: 512
+
+  List of registered IKE DH Groups:
+
+  #2     OAKLEY_GROUP_MODP1024, groupsize: 1024
+  #5     OAKLEY_GROUP_MODP1536, groupsize: 1536
+  #14    OAKLEY_GROUP_MODP2048, groupsize: 2048
+  #15    OAKLEY_GROUP_MODP3072, groupsize: 3072
+  #16    OAKLEY_GROUP_MODP4096, groupsize: 4096
+  #17    OAKLEY_GROUP_MODP6144, groupsize: 6144
+  #18    OAKLEY_GROUP_MODP8192, groupsize: 8192
+
+  List of registered ESP Encryption Algorithms:
+
+  #3     ESP_3DES, blocksize: 64, keylen: 168-168
+  #7     ESP_BLOWFISH, blocksize: 64, keylen: 96-128
+  #12    ESP_AES, blocksize: 128, keylen: 128-256
+  #252   ESP_SERPENT, blocksize: 128, keylen: 128-256
+  #253   ESP_TWOFISH, blocksize: 128, keylen: 128-256
+
+  List of registered ESP Authentication Algorithms:
+
+  #1     AUTH_ALGORITHM_HMAC_MD5, keylen: 128-128
+  #2     AUTH_ALGORITHM_HMAC_SHA1, keylen: 160-160
+  #5     AUTH_ALGORITHM_HMAC_SHA2_256, keylen: 256-256
+  #7     AUTH_ALGORITHM_HMAC_SHA2_512, keylen: 512-512
+
+
+The command
+
+    ipsec listpubkeys [--utc]
+
+lists all public keys currently installed in the chained list of public
+keys. These keys were statically loaded from ipsec.conf or aquired either
+from received certificates or retrieved from secure DNS servers using
+opportunistic mode.
+
+The public key listing has the following form:
+
+  Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL,
+         until Sep 09 13:17:25 2009 ok
+         ID_FQDN '@moon.strongswan.org'
+         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial: '03'
+  Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL,
+         until Sep 09 13:17:25 2009 ok
+         ID_DER_ASN1_DN 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org'
+         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial: '03'
+  Feb 11 13:36:53 2005, 2048 RSA Key AwEAAbgbh,
+         until Dec 31 22:43:18 2009 ok
+         ID_USER_FQDN 'carol@strongswan.org'
+         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial: '0a'
+
+It consists of
+
+ - the date the public key was installed either in local time or UTC (--utc)
+ - the modulus size of the RSA key in bits
+ - a keyID consisting of 9 base64 symbols representing the public exponent
+   and the most significant bits of the modulus
+ - the expiration date of the public key (extracted from the certificate)
+ - the type and value of the ID associated with the public key.
+ - the issuer of the certificate the public key was extracted from.
+ - the serial number of the certificate the public key was extracted from.
+
+A public key can be associated with several IDs, e.g. using subjectAltNames
+in certificates and an ID can possess several public keys, e.g. retrieved
+from a secure DNS server.
+
+
+The command
+
+    ipsec listcerts [--utc]
+
+lists all local certificates, both strongSwan's own and those of
+trusted peer loaded via leftcert and rightcert, respectively.
+
+The output has the form
+
+  Feb 11 13:36:47 2005, count: 4
+         subject:  'C=CH, O=Linux strongSwan, CN=moon.strongswan.org'
+         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial:    03
+         pubkey:    2048 RSA Key AwEAAa+uL, has private key
+         validity:  not before Sep 10 13:17:25 2004 ok
+                    not after  Sep 09 13:17:25 2009 ok
+         subjkey:   e5:e4:10:87:6c:2a:c4:be:ad:85:49:42:a6:de:76:58:30:3a:9f:c1
+         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         aserial:   00
+
+and shows
+
+ - the date the certificate was installed either in local time or UTC (--utc)
+ - the count shows how many connections refer to this certificate
+ - the subject of the certificate
+ - the issuer of the certificate
+ - the serial number of the certificate
+ - the size and keyid of the RSA public key contained in the certificate.
+   the label "has private key" indicates that a matching RSA private key
+   has been found, defined or loaded in ipsec.secrets.
+ - the label "on smartcard" indicates that the certificate was loaded from
+   a smartcard or cryptotoken and that most probably a matching RSA private
+   key also resides on-card.
+ - the validity of the CA certificate expressed either in local time or
+   UTC (--utc). The validity is checked automatically resulting either
+   in an "ok" message or a "fatal" error message.
+ - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the certificate's public key.
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the issuer who signed the certificate.
+ - the serial number of the issuer's certificate.
+
+
+The command
+
+    ipsec listcacerts [--utc]
+
+lists all CA certificates that have been either been loaded from the directory
+/etc/ipsec.d/cacerts/ or received via the IKE protocol. The output has the form
+
+  Feb 11 13:36:52 2005, count: 1
+         subject:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial:    00
+         pubkey:    2048 RSA Key AwEAAb/yX
+         validity:  not before Sep 10 13:01:45 2004 ok
+                    not after  Sep 08 13:01:45 2014 ok
+         subjkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         aserial:   00
+
+and shows
+
+ - the date the CA certificate was installed either in local time or UTC (--utc)
+ - the count is always set to 1
+ - the subject of the CA certificate
+ - the issuer of the CA certificate
+ - the serial number of the CA certificate
+ - the size and keyid of the RSA public key contained in the certificate.
+ - the validity of the CA certificate expressed either in local time or
+   UTC (--utc). The validity is checked automatically resulting either
+   in an "ok" message or a "fatal" error message.
+ - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the CA certificate's public key.
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash 
+   over the public key of the issuer who signed the CA certificate.
+   For Root CA certificates the authorityKeyIdentifier and subjectKeyIdentifier
+   fields must be equal.
+ - the serial number of the issuer's certificate.
+
+
+The command
+
+    ipsec listaacerts [--utc]
+
+lists all Authorization Authority certificates that have been loaded from
+the directory /etc/ipsec.d/aacerts/.
+The output has the form
+
+  Dec 20 13:29:55 2004, count: 1
+         subject:  'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority'
+         issuer:   'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
+         serial:    0f
+         pubkey:    2048 RSA Key AwEAAfazH
+         validity:  not before Aug 24 13:41:56 2003 ok
+                    not after  Aug 23 13:41:56 2005 ok
+         subjkey:   56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90
+         authkey:   af:80:d5:c6:02:1c:96:78:b3:85:a5:65:a2:23:fd:ad:cf:e2:55:b2
+         aserial:   00
+
+and shows
+
+ - the date the AA certificate was installed either in local time or UTC (--utc)
+ - the count is always set to 1
+ - the subject of the AA certificate
+ - the issuer of the AA certificate
+ - the serial number of the AA certificate
+ - the size and keyid of the RSA public key contained in the certificate.
+ - the validity of the AA certificate expressed either in local time or
+   UTC (--utc). The validity is checked automatically resulting either
+   in an "ok" message or a "fatal" error message.
+ - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the AA certificate's public key.
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the issuer who signed the AA certificate.
+ - the serial number of the issuer's certificate.
+
+
+The command
+
+    ipsec listocspcerts [--utc]
+
+lists all OCSO signer certificates that have been either loaded from
+/etc/ipsec.d/ocspcerts/ or have been received included in the OCSP server
+response. The output has the form
+
+  Feb 09 22:56:17 2005, count: 1
+         subject:  'C=CH, O=Linux strongSwan, OU=OCSP, CN=ocsp.strongswan.org'
+         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         serial:    09
+         pubkey:    2048 RSA Key AwEAAaonT
+         validity:  not before Nov 19 17:29:28 2004 ok
+                    not after  Nov 18 17:29:28 2009 ok
+         subjkey:   88:07:0a:b8:ae:c7:c1:07:5c:be:68:6a:c4:a5:7f:81:1f:37:b5:56
+         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         aserial:   00
+
+and shows
+
+ - the date the OCSP signer certificate was installed either in local time
+   or UTC (--utc)
+ - the count is always set to 1
+ - the subject of the OCSP signer certificate
+ - the issuer of the OCSP signer certificate
+ - the serial number of the OCSP signer certificate
+ - the size and keyid of the RSA public key contained in the certificate.
+ - the validity of the OCSP signer certificate expressed either in local time
+   or UTC (--utc). The validity is checked automatically resulting either
+   in an "ok" message or a "fatal" error message.
+ - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the OCSP signer certificate's public key.
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the issuer who signed the OCSP certificate.
+ - the serial number of the issuer's certificate.
+
+
+The command
+
+    ipsec listacerts [--utc]
+
+lists all X.509 attribute certificates that have been loaded from the directory
+/etc/ipsec.d/acerts/.
+The output has the form
+
+  Dec 20 13:29:56 2004
+         holder:   'C=CH, O=strongSec GmbH, CN=Andreas Steffen'
+         hissuer:  'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
+         hserial:   1e
+         groups:    Research, Sales
+         issuer:   'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority'
+         serial:    2c
+         validity:  not before Dec 19 14:51:38 2004 ok
+                    not after  Dec 20 14:51:38 2004 fatal (expired)
+         authkey:   56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90
+         aserial:   0f
+
+and shows
+
+ - the date the attribute certificate was installed either in local time
+   or UTC (--utc)
+ - the holder of the attribute certificate
+ - the issuer of holder's certificate
+ - the serial number of the holder's certificate
+ - the group attributes
+ - the issuing Authorization Authority of the attribute certificate
+ - the serial number of the attribute certificate
+ - the validity of the attribute certificate expressed either in local time or
+   UTC (--utc). The validity is checked automatically resulting either
+   in an "ok" message or a "fatal" error message.
+ - an authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the issuing Authorization Authority
+ - the serial number of the AA certificate.
+
+
+The command
+
+    ipsec listgroups [--utc]
+
+lists all group attributes either defined in right|leftgroups statements
+in ipsec.conf or contained in loaded X.509 attribute certificates.
+The output has the form
+
+  Dec 20 13:29:55 2004, count: 4
+         Research
+  Dec 20 13:30:04 2004, count: 1
+         Research New York
+  Dec 20 13:29:55 2004, count: 3
+         Sales
+
+and shows
+
+ - the date the group attribute was first installed either in local time
+   or UTC (--utc)
+ - the count shows how many times the attribute is used
+ - the group name
+
+
+The command
+
+    ipsec listcainfos [--utc]
+
+lists the properties defined by the ca definition sections in ipsec.conf.
+The output has the form
+
+  Jun 08 22:31:37 2004, "strongswan"
+         authname: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         ldaphost: 'ldap.strongswan.org'
+         ocspuri:  'http://ocsp.strongswan.org:8880'
+         distPts:  'http://crl.strongswan.org/strongswan.crl'
+                   'ldap:///O=Linux strongSwan, C=CH?certificateRevocationList'
+         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         aserial:   00
+
+and shows
+
+ - the date the CA definition was loaded either in local time or UTC (--utc)
+ - the name of the ca section
+ - the distinguished name of the CA
+ - an optional default ldap host for the CA
+ - an optional OCSP URI
+ - a maximum of two optional CRL distribution points
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the CA.
+ - the serial number of the CA.
+
+
+The command
+
+    ipsec listcrls [--utc]
+
+lists all CRLs that have been loaded from /etc/ipsec.d/crls/.
+The output has the form
+
+  Feb 11 13:37:00 2005, revoked certs: 1
+         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         distPts:  'http://crl.strongswan.org/strongswan.crl'
+         updates:   this Feb 08 07:46:29 2005
+                    next Mar 10 07:46:29 2005 ok
+         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef 
+         aserial:   00
+
+and shows
+
+ - the date the CRL was installed either in local time or UTC (--utc)
+ - the number revoked certificates
+ - the issuer of the CRL
+ - the URLs of the distribution points where the CRL can be fetched from.
+ - the dates when the CRL was issued and when the next update
+   is expected, respectively, expressed either in local time or
+   UTC (--utc). It is automatically checked if the next update
+   deadline has passed, resulting either in an "ok" message, a
+   a "warning" message when strictcrlpolicy=no or a "fatal" message when
+   strictcrlpolicy=yes.
+ - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
+   over the public key of the issuer who signed the CRL. This extension is 
+   present in version 2 CRLs, only.
+ - the serial number of the issuer's certificate.
+
+
+The command
+
+
+    ipsec listocsp [--utc]
+
+lists the contents of the OCSP response cache. The output has the form
+
+         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
+         uri:     'http://ocsp.strongswan.org:8880'
+         authname: 13:9d:a0:9e:f4:32:ab:8f:e2:89:56:67:fa:d0:d4:e3:35:86:71:b9
+         authkey:  5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
+         aserial:  00
+  Feb 09 22:56:17 2005, until Feb 09 23:01:17 2005 warning (expires in 4 minutes)
+         serial:   0a, good
+
+and shows
+
+ - the distinguished name of the CA handled by the OCSP server
+ - the http URI of the OCSP server.
+ - the 20 byte SHA-1 hash of the CA's distinguished name
+ - the 20 byte SHA-1 hash of the CA's public key
+ - the serial number of the CA's certificate
+ - a certificate status list showing
+    - the time the OCSP status was received
+    - an optional nextUpdate deadline (if missing the OCSP status will be
+      onetime with a lifetime of 2 minutes only).
+    - the serial number of the certificate
+    - the status of the certificate (good, revoked, unknown)
+
+
+The command
+
+    ipsec listcards [--utc]
+
+lists all smartcard records that are currently in use by Pluto.
+The output has the form
+
+  Aug 17 16:47:59 2005, #1, count: 6
+         slot:     0, session closed, logged out, has valid pin
+         id:       45
+         label:   'strongSwan'
+         subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org'
+
+with pkcs11keepstate=no and
+
+  Aug 17 16:47:59 2005, #1, count: 6
+         slot:     0, session opened, logged in, has pin pad
+         id:       45
+         label:   'strongSwan'
+         subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org'
+
+with pkcs11keepstate=yes and shows
+
+- the date the certificate was read from the smartcard record
+- the certificate objects are numbered starting from #1
+- the count shows how many connections and secret pin entries point
+  to the smartcard record
+- the PKCS #11 slot number
+- the PKCS #11 session state: closed | opened
+- the PKCS #11 session login state: logged out | logged in
+- the status of the PIN: no pin | valid pin | invalid pin | pin pad
+- the ID of the certificate object
+- the label of the certificate object
+- the subject distinguished name of the certificate
+
+
+The command
+
+    ipsec auto --listall [--utc]
+
+is equivalent to
+
+    ipsec listalgs
+    ipsec listpubkeys [--utc]
+    ipsec listcerts [--utc]
+    ipsec listcacerts [--utc]
+    ipsec listaacerts [--utc]
+    ipsec listocspcerts [--utc]
+    ipsec listacerts [--utc]
+    ipsec listgroups [--utc]
+    ipsec listcainfos [--utc]
+    ipsec listcrls [--utc]
+    ipsec listocsp [--utc]
+    ipsec listcards [--utc]
+
+
+11. Firewall support functions
+    --------------------------
+
+
+11.1 Environment variables in the updown script
+     ------------------------------------------
+
+strongSwan makes the following environment variables available
+in the updown script indicated by the leftupdown option:
+
++------------------------------------------------------------------+
+| Variable               Example                    Comment        |
+|------------------------------------------------------------------|
+| $PLUTO_PEER_ID         carol@strongswan.org       USER_FQDN  (1) |
+|------------------------------------------------------------------|
+| $PLUTO_PEER_PROTOCOL   17                         udp        (2) |
+|------------------------------------------------------------------|
+| $PLUTO_PEER_PORT       68                         bootpc     (3) |
+|------------------------------------------------------------------|
+| $PLUTO_PEER_CA         C=CH, O=ACME, CN=Sales CA             (4) |
+|------------------------------------------------------------------|
+| $PLUTO_MY_ID           @moon.strongswan.org       FQDN       (1) |
+|------------------------------------------------------------------|
+| $PLUTO_MY_PROTOCOL     17                         udp        (2) |
+|------------------------------------------------------------------|
+| $PLUTO_MY_PORT         67                         bootps     (3) |
++------------------------------------------------------------------+
+
+(1) $PLUTO_PEER_ID/$PLUTO_MY_ID contain the IDs of the two ends
+    of an established connection. In our examples these
+    correspond to the strings defined by rightid and leftid,
+    respectively.
+
+(2) $PLUTO_PEER_PROTOCOL/$PLUTO_MY_PROTOCOL contain the protocol
+    defined by the rightprotoport and leftprotoport options,
+    respectively. Both variables contain the same protocol value.
+    The variables take on the value '0' if no protocol has been defined.
+
+(3) $PLUTO_PEER_PORT/$PLUTO_MY_PORT contain the ports defined by
+    the rightprotoport and leftprotoport options, respectively.
+    The variables take on the value '0' if no port has been defined.
+
+(4) $PLUTO_PEER_CA contains the distinguished name of the CA that
+    issued the peer's certificate.
+
+
+11.2 Automatic insertion and deletion of iptables firewall rules
+     -----------------------------------------------------------
+
+Starting with strongswan-2.7.0, the default _updown script automatically inserts
+and deletes dynamic iptables firewall rules upon the establishment or teardown,
+respectively, of an IPsec security association. This new feature is activated
+with the line
+
+   leftfirewall=yes
+
+and can be used when the following prerequisites are fulfilled:
+
+  - Linux 2.4.x kernel, KLIPS IPsec stack, and arbitrary iptables version.
+    Filtering of tunneled traffic is based on ipsecN interfaces.
+
+  - Linux 2.6.16 kernel or newer, native NETKEY IPsec stack, and
+    iptables-1.3.5 or newer. Filtering of tunneled traffic is based on
+    IPsec policy matching rules.
+
+If you define a local client subnet with a netmask larger than /32 behind
+the gateway then the automatically inserted FORWARD iptables rules will
+not allow to access the internal IP address of the host although it is
+part of the client subnet definition. If you want additional INPUT and
+OUTPUT iptables rules to be inserted, so that the host itself can be accessed
+then add the following line:
+
+   lefthostaccess=yes
+
+The _updown script also features a logging facility which will register the
+creation (+) and the expiration (-) of each successfully established VPN
+connection in a special syslog file in the following concise and easily
+readable format:
+
+Jul 19 18:58:38 moon vpn:
+    + @carol.strongswan.org  192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16
+Jul 19 22:15:17 moon vpn:
+    - @carol.strongswan.org  192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16
+
+
+11.3 Sample Linux 2.6 updown script for iptables < 1.3.5
+     ---------------------------------------------------
+
+If you are using a Linux 2.6 kernel older than 2.6.16 or an iptables version
+older than 1.3.5 then the IPsec policy matching rules will not be available.
+In order to make sure that only tunneled packets are accepted, a mark can be
+set on incoming ESP packets. This "ESP" mark will be retained on the
+decapsulated packet so that iptables rules inserted by the updown script can
+check on the presence of this mark. For this purpose the template located in
+
+   programs/_updown_espmark
+
+can be used. Store a copy of _updown_espmark e.g. in /etc/ipsec.updown and load
+the script with the line
+
+  leftupdown=/etc/updown.ipsec.
+
+In addition for the dynamic updown script to work the following static iptables rules
+must be applied:
+
+   iptables -t mangle -A INPUT -p 50 -j MARK --set-mark 50
+
+
+12. Authentication with raw RSA public keys
+    ---------------------------------------
+
+FreeS/WAN, as it is available from www.freeswan.org does public key 
+authentication with raw RSA public keys that are directly defined in
+/etc/ipsec.conf
+
+    rightrsasigkey=0sAq4c....
+
+When version 1.x of standard FreeS/WAN receives a certificate request (CR),
+it immediately drops the negotiation because it does not know how to answer
+the request. As a workaround strongSwan does not send a CR if the RSA
+key has been statically loaded using [right/left]rsasigkey. A problem
+remains with roadwarriors initiating a connection. Since strongSwan
+does not know the identity of the initiating peer in advance, it will always
+send a CR, causing the rupture of the IKE negotiation if the peer is a
+version 1.x  FreeS/WAN host. To circumvent this problem the configuration
+parameter 'nocrsend' can be set in the config setup section of /etc/ipsec.conf:
+
+    config setup:
+        nocrsend=yes
+
+With this entry no certificate request is sent in any connection.
+The default setting is nocrsend=no.
+
+
+13. Authentication with OpenPGP certificates
+    ----------------------------------------
+
+strongSwan also supports RSA based authentication using OpenPGP
+certificates and OpenPGP V3 fingerprints used as an KEY_ID identifier.
+
+
+13.1 OpenPGP certificates
+     --------------------
+     
+OpenPGP certificates containing RSA public keys can now directly be loaded
+in ASCII armored PGP format using the leftcert and rightcert parameters
+in /etc/ipsec.conf:
+
+  conn pgp
+       right=%any
+       righcert=peerCert.asc
+       left=%defaultroute
+       leftcert=gatewayCert.asc
+
+The peer certificate must be stored locally (the default directory is
+/etc/ipsec.d/certs) since currently no trust can be established for
+PGP certificates received from a peer via the IKE protocol.
+
+
+13.2 OpenPGP private keys
+     --------------------
+     
+PGP private keys in unencrypted form can now directly be loaded in ASCII
+armored PGP format via an entry in /etc/ipsec.secrets:
+
+  : RSA gatewayKey.asc
+
+Existing IDEA-encrypted RSA private keys can be unlocked with GnuPG and
+the IDEA extension (see http://www.gnupg.org/gph/en/pgp2x.html) using
+the commands
+
+  gpg --import gatewayCert.asc
+
+  gpg --allow-secret-key-import --import gatewayKey.asc
+
+  gpg --edit-key <gateway ID>
+  > passwd                    #change to empty password
+  > save
+
+  gpg -a --export-secret-key <gateway ID> gatewayKey.asc
+
+
+13.3 Monitoring functions
+     --------------------
+
+The command ipsec listcerts shows all loaded PGP certificates
+in the following format:
+
+  Aug 28 09:51:55 2002, count: 1
+         fingerprint:  0x1ccfca12d93467ffa9d5093d87a465dc
+         pubkey:   1024 RSA Key ARHso6uKQ
+         created:  Aug 27 08:51:39 2002
+         until:    --- -- --:--:-- ---- ok (expires never)
+
+The entries are
+
+ - the date the certificate was loaded either in local time or UTC (--utc)
+ - the V3 fingerprint consisting of the 16 byte MD5 hash of the public key
+   which is used as an ID of type KEY_ID
+ - the modulus size of the RSA key in bits
+ - a keyID consisting of 9 base64 symbols representing the public exponent
+   and the most significant bits of the modulus
+ - the creation date of the public key (extracted from the certificate)
+ - the optional expiration date of the public key (extracted from the
+   certificate)
+
+
+13.4 Suppression of certificate request messages
+     -------------------------------------------
+
+PGPnet configured to work with OpenPGP certificates aborts the IKE
+negotiation when it receives a X.509 certificate. Therefore it is recommended
+(mandatory for roadwarrior connections) to set
+
+    config setup:
+        nocrsend=yes
+
+in /etc/ipsec.conf.
+
+
+14. Additional Features
+    -------------------
+
+
+14.1 Authentication and encryption algorithms
+     ----------------------------------------
+
+strongSwan supports the following suite of encryption and authentication
+algorithms for both IKE and ESP payloads.
+
++------------------------------------------------------------------+
+| IKE algorithms (negotiated in Phase 1 Main Mode)                 |
++------------------------------------------------------------------+
+| Encryption algorithms:  3des, aes, serpent, twofish, blowfish    |
+|------------------------------------------------------------------|
+| Hash algorithms:        md5, sha, sha2                           |
+|------------------------------------------------------------------|
+| DH groups:              1024, 1536, 2048, 3072, 4096, 6144, 8192 |
++------------------------------------------------------------------+
+
+NOTE: For IKE the SHA-1 algorithm is denoted by "sha"
+
+The cryptographic IKE algorithms listed above are a fixed part of the
+strongSwan distribution. Particular algorithms can be added or removed
+in the "programs/pluto/alg" directory.
+  
++------------------------------------------------------------------+
+| ESP algorithms (negotiated in Phase 2 Quick Mode)                |
++------------------------------------------------------------------+
+| Encryption algorithms:  3des, aes, serpent, twofish, blowfish    |
+|------------------------------------------------------------------|
+| Hash algorithms:        md5, sha1, sha2                          |
+|------------------------------------------------------------------|
+| PFS groups:             1024, 1536, 2048, 3072, 4096, 6144, 8192 |
++------------------------------------------------------------------+
+
+The cryptographic ESP algorithms listed above are a fixed part of the
+strongSwan distribution. If your Linux 2.4 or 2.6 kernel includes the
+CryptoAPI then additional ESP algorithms can be added or deleted as
+kernel modules.
+
+The IKE and ESP cryptographic algorithms to be proposed to the peer
+as an initiator can be specified on a per connection basis in the form
+
+conn normal
+     ...
+     ike=aes128-sha-modp1536,3des-sha-modp1536
+     esp=aes128-sha1,3des-sha1
+     ...
+
+or if you are more paranoid
+
+conn paranoid
+     ...
+     ike=aes256-sha2_512-modp2048
+     esp=aes256-sha2_512
+     ...
+
+If the the "ike" and "esp" configuration parameters are missing in
+ipsec.conf, then the default settings
+   
+    ike=3des-md5-modp1536,3des-sha-modp1536,\
+        3des-md5-modp1024,3des-sha-modp1024
+    esp=3des-md5,3des-sha1
+
+arre implicitly assumed. The 3DES encryption algorithm and the MD5 and
+SHA-1 hash algorithms are hardcoded into strongSwan and cannot be removed.
+
+If Perfect Forward Secrecy (PFS is desired), then a PFS group can be
+optionally specified:
+
+conn make_sure
+     ...
+     pfs=yes
+     pfsgroup=modp2048,modp1536
+     ...
+
+If the "pfs" parameter is missing then "pfs=yes" is assumed by default.
+This means that PFS must be disabled explicitly by setting "pfs=no".
+
+If the "pfsgroup" parameter is missing then the default is
+
+    pfsgroup=<Phase1 DH group>
+    
+The "ike" and "esp" parameters are used to formulate one or several
+transform proposals to the peer if the strongSwan VPN host is the initiator.
+Attention! As a responder the first proposal from the peer is accepted that
+is supported the by one of the registered algorithms listed by the command
+
+    ipsec listalgs
+    
+If the responder wants to restrict the allowed cipher suites the '!' flag
+can be used to do so. The configuration
+
+conn normal_but_strict
+     ...
+     ike=aes128-sha-modp1536,3des-sha-modp1536!
+     esp=aes128-sha1,3des-sha1!
+     ...
+
+will only permit the listed algorithms defined above but no other methods
+even if they might be supported by the responder.
+
+
+14.2 NAT traversal
+     -------------
+
+Currently please refer to README.NAT-Traversal document in the strongSwan
+distribution.
+     
+     
+14.3 Dead peer detection
+    --------------------
+
+strongSwan implements the RFC 3706 Dead Peer Detection (DPD) keep-alive
+scheme. If an established IPsec SA has been idle (i.e. without any traffic)
+for N seconds (dpddelay=N) then strongSwan side sends a "hello" message
+(R_U_THERE) and the peer replies with an acknowledge message (R_U_THERE_ACK).
+If no response is received, the R_U_THERE messages are repeated until a DPD
+timeout of M seconds (dpdtimeout=M) has elapsed. If still no traffic or 
+R_U_THERE_ACK packets were received, the peer is declared to be dead and all
+SAs belonging to a common Phase 1 SA are deleted.
+
+DPD support is tuneable on a per connection basis by using the dpdaction,
+dpddelay and dpdtimeout directives:
+
+   conn roadwarrior
+       right=%any
+       left=%defaultroute
+       leftsubnet=10.1.0.0/16
+       dpdaction=clear
+
+   conn net-to-net
+       right=192.168.0.2
+       rightsubnet=10.2.0.0/16
+       left=%defaultroute
+       leftsubnet=10.1.0.0/16
+       dpdaction=hold
+       dpddelay=60
+       dpdtimeout=500
+
+In the first example dpdaction=clear activates the DPD mechanism under the
+condition that the peer supports RFC 3706. The values dpddelay=30s and
+dpdtimeout=120s are assumed by default in the absence of these parameters, so
+that during idle periods an R_U_THERE packet is sent every 30 seconds. If no
+traffic or a no R_U_THERE_ACK packet is received from the peer within a
+120 second time span, the peer will be declared dead and all SAs and associated
+eroutes will be cleared.
+
+In the second example R_U_THERE packets are sent every 60 seconds and the
+parameter setting dpdaction=hold will put the eroute of the ruptured connection
+into a %trap state, so that when new outgoing traffic will occur, the
+correspondig connection will be automatically renegotiated as soon as the
+peer is up again.
+
+It is recommended to use dpdaction=hold for statically defined connections and
+dpdaction=clear for dynamic roadwarrior connections. The default value is
+dpdaction=none, which disables DPD.
+
+
+14.4 IKE Mode Config
+     ---------------
+     
+The IKE Mode Config protocol <draft-ietf-ipsec-isakmp-mode-cfg-04.txt> allows
+the dynamic assignment of virtual IP addresses and optional DNS and WINS server
+information to IPsec clients. Currently only "Mode Config Pull Mode" is
+implemented where the client actively sends a Mode Config request to the server
+in order to obtain a virtual IP.
+
+Client side configuration (carol):
+
+  conn home
+       right=192.168.0.1
+       rightsubnet=10.1.0.0/16
+       rightid=@moon.strongswan.org
+       left=%defaultroute
+       leftsourceip=%modeconfig
+       leftcert=carolCert.pem
+       leftid=carol@strongswan.org
+       auto=start
+
+Server side configuration (moon):
+
+  conn roadwarrior
+       right=%any
+       rightid=carol@strongswan.org
+       rightsourceip=10.3.0.1
+       left=%defaultroute
+       leftsubnet=10.1.0.0/16
+       leftcert=moonCert.pem
+       leftid=@moon.strongswan.org
+       auto=add
+
+The wildcard %modeconfig or %modecfg used in the leftsourceip parameter of the
+client will trigger a Mode Config request. Currently the server will return
+the virtual IP address defined by the rightsourceip parameter. In the future
+an LDAP-based lookup mechanism will be supported.
+
+
+15. Copyright statement and acknowledgements
+    ----------------------------------------
+
+
+                    FreeS/WAN version base system:
+
+                       Copyright (c) 1999-2004
+                    Henry Spencer, Richard Guy Briggs,
+           D. Hugh Redelmeier, Sandy Harris, Claudia Schmeing,
+        Michael Richardson, Angelos D. Keromytis, John Ioannidis,
+
+     NAT-Traversal, ipsec starter, Delete SA and Notification messages:
+
+                Copyright (c) 2002-2003, Mathieu Lafon
+
+                Additional cryptoalgorithms (AES, etc):
+
+               Copyright (c) 2002-2003, JuanJo Ciarlante
+               
+                        Dead Peer Detection:
+
+                        Copyright (c) 2002-2004
+               Ken Bantoft, JuanJo Ciarlante, Philip Craig,
+                 Pawel Krawczyk, Srinvasan Venkataraman
+
+                     Porting to Linux 2.6 kernel:
+
+                    Copyright (c) 2003, Herbert Xu
+
+                         Dynamic CRL fetching:
+
+                  Copyright (c) 2002, Stephane Laroche
+
+                       IKE Mode Config protocol:
+
+                  Copyright (c) 2001-2002, Colubris Networks
+
+                       Virtual IP and source routing: 
+
+                    Copyright (c) 2003, Tuomo Soini
+
+             Port and protocol selectors for outbound traffic:
+
+                  Copyright (c) 2002, Stephen J. Bevan
+
+                         PGPnet-RSA parts of patch:
+
+                      Copyright (c) 2000, Kai Martius
+
+                  X.509, OCSP and smartcard functionality:
+
+  Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann
+  Copyright (c) 2001, Marco Bertossa, Andreas Schleiss
+  Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser
+  Copyright (c) 2002, Martin Berner, Lukas Suter
+  Copyright (c) 2003, Christoph Gysin, Simon Zwahlen
+  Copyright (c) 2004, David Buechi, Michael Meier
+  Copyright (c) 2000-2005, Andreas Steffen
+
+      Zurich University of Applied Sciences in Winterthur, Switzerland
+
+                               scepclient:
+
+               Copyright (c) 2005, Jan Hutter, Martin Willi
+               Copyright (c) 2005-2006, Andreas Steffen
+
+        University of Applied Sciences in Rapperswil, Switzerland
+
+  This program is free software; you can redistribute it and/or modify
+  it under the terms of the GNU General Public License as published by
+  the Free Software Foundation; either version 2 of the License, or
+  (at your option) any later version. See http://www.fsf.org/copyleft/gpl.txt.
+
+  This program is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+  or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+  for more details.
+-----------------------------------------------------------------------------
+
+This file is RCSID $Id: README,v 1.33 2006/04/24 21:27:49 as Exp $
+
diff --git a/README.pluto b/README.pluto
deleted file mode 100644 (file)
index e9ebfee..0000000
+++ /dev/null
@@ -1,3091 +0,0 @@
-                 ----------------------------
-                  strongSwan - Configuration
-                 ----------------------------
-
-
-Contents
---------
-
-   1. Overview
-   2. Quickstart
-       2.1 Site-to-Site case
-       2.2 Host-to-Host case
-       2.3 Four Tunnel case
-       2.4 Four Tunnel case the elegant way with source routing
-       2.5 Roadwarrior case
-       2.6 Roadwarrior case with virtual IP
-   3. Generating X.509 certificates and CRLs with OpenSSL
-       3.1 Generating a CA certificate
-       3.2 Generating a host or user certificate
-       3.3 Generating a CRL
-       3.4 Revoking a certificate
-   4. Configuring the connections - ipsec.conf
-       4.1 Configuring my side
-       4.2 Multiple certificates
-       4.3 Configuring the peer side using CA certificates
-       4.4 Handling Virtual IPs and wildcard subnets
-       4.5 Protocol and port selectors
-       4.6 IPsec policies based on wildcards
-       4.7 IPsec policies based on CA certificates
-       4.8 Sending certificate requests
-       4.9 IPsec policies based on group attributes
-   5. Configuring certificates and CRLs
-       5.1 Installing CA certificates
-       5.2 Installing optional Certificate Revocation Lists (CRLs)
-       5.3 Dynamic update of certificates and CRLs
-       5.4 Local caching of CRLs
-       5.5 Online Certificate Status Protocol (OCSP)
-       5.6 CRL policy
-       5.7 Configuring the peer side using locally stored certificates
-   6. Configuring the private keys - ipsec.secrets
-       6.1 Loading private key files in PKCS#1 format
-       6.2 Entering passphrases interactively
-       6.3 Multiple private keys
-   7. Configuring CA properties - ipsec.conf
-   8. Smartcard support
-       8.1 Configuring a smartcard-based connection
-       8.2 Entering the PIN code
-       8.3 PIN-pad equipped smartcard readers
-       8.4 Configuring a smartcard using pkcs15-init
-        8.5 PKCS#1 proxy functions
-   9. Configuring the clients
-       9.1 strongSwan
-       9.2 PGPnet
-       9.3 Safenet/Soft-Remote
-       9.4 SSH Sentinel
-       9.5 Windows 2000/XP
-  10. Monitoring functions
-  11. Firewall support functions
-       11.1 Environment variables in the updown script
-       11.2 Automatic insertion and deletion of iptables firewall rules  (NEW)
-       11.3 Sample Linux 2.6 _updown_espmark script for iptables < 1.3.5
-  12. Authentication with raw RSA public keys
-  13. Authentication with OpenPGP certificates
-       13.1 OpenPGP certificates
-       13.2 OpenPGP private keys
-       13.3 Monitoring functions
-       13.4 Suppression of certificate request messages
-  14. Additional features
-       14.1 Authentication and encryption algorithms
-       14.2 NAT traversal
-       14.3 Dead peer detection
-       14.4 IKE Mode Config
-  15. Copyright statement and acknowledgements
-
-
-1. Overview
-   --------
-
-strongSwan is an OpenSource IPsec solution for the Linux operating system
-and currently supports the following features:
-
-  * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels.
-
-  * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption.
-
-  * Authentication based on X.509 certificates or preshared secrets.
-
-  * IPsec policies based on wildcards or intermediate CAs.
-
-  * Powerful and flexible IPsec policies based on group attributes.
-
-  * Retrieval of Certificate Revocation Lists (CRLs) via HTTP or LDAP.
-
-  * Local caching of fetched CRLs
-
-  * Full support of the Online Certificate Status Protocol (OCSP, RFC 2560).
-
-  * CA management functions including OCSP and CRL URIs and default LDAP server.
-
-  * Optional storage of RSA private keys on smartcards or USB crypto tokens
-
-  * Standardized PKCS#11 interface with optional proxy functions serving 
-    external applications (disc encryption, etc.).
-  * NAT-Traversal (RFC 3947)
-
-  * Support of Virtual IPs via static configuratin and IKE Mode Config
-
-  * Support of Delete SA and informational Notification messages.
-
-  * Dead Peer Detection (DPD, RFC 3706)
-
-Compatibility has successfully been tested with peers running the following
-IPsec clients:
-
-  FreeS/WAN, Openswan, SafeNet/SoftRemote, NCP Secure Entry Client,
-  SonicWALL Global VPN Client, The GreenBow, Microsoft Windows 2000/XP, etc.
-
-Furthermore, interoperability with the following VPN gateways
-has been demonstrated during the IPsec 2001 Conference in Paris:
-
-  Cisco IOS Routers, Cisco PIX firewall, Cisco VPN3000,
-  Nortel Contivity VPN Switch, NetScreen (FreeS/WAN as responder only),
-  OpenBSD with isakmpd, Netasq, Netcelo, and 6WIND.
-
-Potentially any IPsec implementation with X.509 certificate support can
-be made to cooperate with strongSwan. The latest addition has been the successful
-interoperability with the Check Point VPN-1 NG gateway.
-
-
-2. Quickstart
-   ----------
-   
-In the following examples we assume for reasons of clarity that left designates
-the local host and that right is the remote host. Certificates for users, hosts
-and gateways are issued by a ficticious strongSwan CA. How to generate private keys
-and certificates using OpenSSL will be explained in section 3. The CA certificate
-"strongswanCert.pem" must be present on all VPN end points in order to be able to
-authenticate the peers.
-
-
-2.1 Site-to-site case
-    -----------------
-
-In this scenario two security gateways moon and sun will connect the
-two subnets moon-net and sun-net with each other through a VPN tunnel
-set up between the two gateways:
-
-    10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
-      moon-net          moon                 sun           sun-net
-
-Configuration on gateway moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         left=%defaultroute
-         leftsubnet=10.1.0.0/16
-         leftcert=moonCert.pem
-         right=192.168.0.2
-         rightsubnet=10.2.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
-         auto=start
-
-Configuration on gateway sun:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/sunCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA sunKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         left=%defaultroute
-         leftsubnet=10.2.0.0/16
-         leftcert=sunCert.pem
-         right=192.168.0.1
-         rightsubnet=10.1.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-2.2 Host-to-host case
-    -----------------
-
-This is a setup between two single hosts which don't have a subnet behind
-them. Although IPsec transport mode would be sufficient for host-to-host
-connections we will use the default IPsec tunnel mode.
-
-    | 192.168.0.1 | === | 192.168.0.2 |
-         moon                sun
-
-Configuration on host moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn host-host
-         left=%defaultroute
-         leftcert=moonCert.pem
-         right=192.168.0.2
-         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
-         auto=start
-
-Configuration on host sun:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/sunCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA sunKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn host-host
-         left=%defaultroute
-         leftcert=sunCert.pem
-         right=192.168.0.1
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-2.3 Four Tunnel case
-    ----------------
-
-In a site-to-site setup a system administrator logged into the local gateway
-often would like to access the peer gateway or a server in the subnet behind
-the peer gateway over a secure IPsec tunnel.Since IP packets leaving a gateway
-via the outer network interface carry the IP address of this NIC, four IPsec
-Security Associations (SAs) must be set up to achieve full connectivity. The
-example below shows how this can be done without much additional typing work ,
-using the "also" macro which includes connection definitions defined farther
-down in the ipsec.conf file.
-
-   10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
-    moon-net           moon                 sun           sun-net
-
-Configuration on gateway moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         leftsubnet=10.1.0.0/16
-         rightsubnet=10.2.0.0/16
-         also host-host
-
-     conn net-host
-         leftsubnet=10.1.0.0/16
-         also host-host
-
-     conn host-net
-         rightsubnet=10.2.0.0/16
-         also host-host
-
-     conn host-host
-         left=%defaultroute
-         leftcert=moonCert.pem
-         right=192.168.0.2
-         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
-         auto=start
-
-Configuration on gateway sun:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/sunCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA sunKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         leftsubnet=10.2.0.0/16
-         rightsubnet=10.1.0.0/16
-         also=host-host
-
-     conn net-host
-         leftsubnet=10.2.0.0/16
-         also=host-host
-
-     conn host-net
-         rightsubnet=10.1.0.0/16
-         also=host-host
-
-     conn host-host
-         left=%defaultroute
-         leftcert=sunCert.pem
-         right=192.168.0.1
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-2.4 The four tunnel case the elegant way with source routing
-    --------------------------------------------------------
-
-As you certainly agree, the full four tunnel case described in the previous
-section becomes quite complex. If we could force the source address of the
-IP packets leaving the gateway through the outer interface to take on the
-IP address of the inner interface then we could use the single subnet-to-subnet
-tunnel from section 2.1. Such a setup becomes possible if we use the
-source routing capabilites of the ip route command that is already used
-by strongSwan's updown scripts.
-
-    10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
-      moon-net          moon                sun            sun-net
-
-If we assume that the inner IP address of gateway moon is 10.1.0.1
-and the inner IP address of gateway sun is 10.2.0.1 then the
-insertion of the parameter
-
-    leftsourceip=10.1.0.1
-   
-in the connection definition of moon and
-
-      leftsourceip=10.2.0.1
-  
-on sun, respectively, will install source routing on both gateways.
-As a result the command
-
-      ping 10.2.0.1
-  
-executed on moon will leave the gateway with a source address of
-10.1.0.1 and will therefore take the net-net IPsec tunnel.
-
-Configuration on gateway moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         left=%defaultroute
-         leftsourceip=10.1.0.1
-         leftsubnet=10.1.0.0/16
-         leftcert=moonCert.pem
-         right=192.168.0.2
-         rightsubnet=10.2.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
-         auto=start
-
-Configuration on gateway sun:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/sunCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA sunKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn net-net
-         left=%defaultroute
-         leftsubnet=10.2.0.0/16
-         leftsourceip=10.2.0.1
-         leftcert=sunCert.pem
-         right=192.168.0.1
-         rightsubnet=10.1.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-2.5 Roadwarrior case
-    ----------------
-
-This is a very common case where a strongSwan gateway serves an arbitrary number
-of remote VPN clients usually having dynamic IP addresses.
-
-    10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
-      moon-net          moon              carol
-
-Configuration on gateway moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn rw
-         left=%defaultroute
-         leftsubnet=10.1.0.0/16
-         leftcert=moonCert.pem
-          right=%any
-         auto=add
-
-Configuration on roadwarrior carol:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/carolCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA carolKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn home
-         left=%defaultroute
-         leftcert=carolCert.pem
-         right=192.168.0.1
-         rightsubnet=10.1.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-2.6 Roadwarrior case with virtual IP
-    --------------------------------
-
-Roadwarriors usually have dynamic IP addresses assigned by the ISP they are
-currently attached to. In order to simplify the routing from moon-net back
-to the remote access client carol it would be desirable if the roadwarrior had
-an inner IP address chosen from a pre-assigned pool.
-    10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
-      moon-net          moon              carol       virtual IP
-
-This virtual IP address can be assigned to a strongSwan roadwarrior by adding 
-the parameter
-
-    leftsourceip=10.3.0.1
-    
-to the roadwarrior's ipsec.conf. Of course the virtual IP of each roadwarrior
-must be distinct. In our example it is chosen from the address pool
-
-    rightsubnetwithin=10.3.0.0/16
-    
-which can be added to the gateway's ipsec.conf so that a single connection
-definition can handle multiple roadwarriors.
-
-Configuration on gateway moon:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/moonCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA moonKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn rw
-         left=%defaultroute
-         leftsubnet=10.1.0.0/16
-         leftcert=moonCert.pem
-         right=%any
-         rightsubnetwithin=10.3.0.0/16
-         auto=add
-
-Configuration on roadwarrior carol:
-
-   /etc/ipsec.d/cacerts/strongswanCert.pem
-
-   /etc/ipsec.d/certs/carolCert.pem
-
-   /etc/ipsec.secrets:
-
-     : RSA carolKey.pem "<optional passphrase>"
-
-   /etc/ipsec.conf:
-
-     conn home
-         left=%defaultroute
-         leftsourceip=10.3.0.1
-         leftcert=carolCert.pem
-         right=192.168.0.1
-         rightsubnet=10.1.0.0/16
-         rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-         auto=start
-
-
-3. Generating certificates and CRLs with OpenSSL
-   ---------------------------------------------
-
-This section is not a full-blown tutorial on how to use OpenSSL. It just lists
-a few points that are relevant if you want to generate your own certificates
-and CRLs for use with strongSwan.
-
-
-3.1 Generating a CA certificate
-    ---------------------------
-
-The OpenSSL statement
-
-     openssl req -x509 -days 1460 -newkey rsa:2048 \
-                 -keyout strongswanKey.pem -out strongswanCert.pem
-
-creates a 2048 bit RSA private key strongswanKey.pem and a self-signed CA
-certificate strongswanCert.pem with a validity of 4 years (1460 days).
-
-     openssl x509 -in cert.pem -noout -text
-
-lists the properties of  a X.509 certificate cert.pem. It allows you to verify
-whether the configuration defaults in openssl.cnf have been inserted correctly.
-
-If you prefer the CA certificate to be in binary DER format then the following
-command achieves this transformation:
-
-     openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der
-
-The directory /etc/ipsec.d/cacerts contains all required CA certificates either
-in binary DER or in base64 PEM format. Irrespective of the file suffix, Pluto
-"automagically" determines the correct format.
-
-
-3.2 Generating a host or user certificate
-    -------------------------------------
-
-The OpenSSL statement
-
-     openssl req -newkey rsa:1024 -keyout hostKey.pem \
-                 -out hostReq.pem
-
-generates a 1024 bit RSA private key hostKey.pem and a certificate request
-hostReq.pem which has to be signed by the CA.
-
-If you want to add a subjectAltName field to the host certificate you must edit
-the OpenSSL configuration file openssl.cnf and add the following line in the
-[ usr_cert ] section:
-
-     subjectAltName=DNS:moon.strongswan.org
-
-if you want to identify the host by its Fully Qualified Domain Name (FQDN ), or
-
-     subjectAltName=IP:192.168.0.1
-
-if you want the ID to be of type IPV4_ADDR. Of course you could include both
-ID types with
-
-     subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1
-
-but the use of an IP address for the identification of a host should be
-discouraged anyway.
-
-For user certificates the appropriate ID type is USER_FQDN which can be
-specified as
-
-     subjectAltName=email:carol@strongswan.org
-
-or if the user's e-mail address is part of the subject's distinguished name
-
-     subjectAltName=email:copy
-
-Now the certificate request can be signed by the CA with the command
-
-     openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext
-
-If you omit the -days option then the default_days value (365 days) specified
-in openssl.cnf is used. The -notext option avoids that a human readable
-listing of the certificate is prepended to the base64 encoded certificate
-body.
-
-If you want to use the dynamic CRL fetching feature described in section 4.7
-then you may include one or several crlDistributionPoints in your end
-certificates. This can be done in the [ usr_cert ] section of the openssl.cnf
-configuration file:
-
-    crlDistributionPoints= @crl_dp
-
-    [ crl_dp ]
-
-    URI.1="http://crl.strongswan.org/strongswan.crl"
-    URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=Linux strongSwan
-      , c=CH?certificateRevocationList"
-
-If you have only a single http distribution point then the short form
-
-    crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl"
-
-also works. Due to a known bug in OpenSSL this notation fails with ldap URIs.
-
-Usually a Windows-based VPN client needs its private key, its host or
-user certificate, and the CA certificate. The most convenient way to load
-this information is to put everything into a  PKCS#12 file:
-
-     openssl pkcs12 -export -inkey carolKey.pem \
-                    -in carolCert.pem -name "carol" \
-                    -certfile strongswanCert.pem -caname "strongSwan Root CA" \
-                    -out carolCert.p12
-
-
-3.3 Generating a CRL
-    ----------------
-
-An empty CRL that is signed by the CA can be generated with the command
-
-     openssl ca -gencrl -crldays 15 -out crl.pem
-
-If you omit the -crldays option then the default_crl_days value (30 days)
-specified in openssl.cnf is used.
-
-If you prefer the CRL to be in binary DER format then this conversion
-can be achieved with
-
-     openssl crl -in crl.pem -outform DER -out cert.crl
-
-The directory /etc/ipsec.d/crls contains all CRLs either in binary DER
-or in base64 PEM format. Irrespective of the file suffix, Pluto
-"automagically" determines the correct format.
-
-
-3.4 Revoking a certificate
-    ----------------------
-
-A specific host certificate stored in the file host.pem is revoked with the
-command
-
-     openssl ca -revoke host.pem
-
-Next the CRL file must be updated
-
-     openssl ca -gencrl -crldays 60 -out crl.pem
-
-The content of the CRL file can be listed with the command
-
-     openssl crl -in crl.pem -noout -text
-
-in the case of a base64 CRL, or alternatively for a CRL in DER format
-
-     openssl crl -inform DER -in cert.crl -noout -text
-
-
-
-4. Configuring the connections - ipsec.conf
-   ----------------------------------------
-
-4.1 Configuring my side
-    -------------------
-
-Usually the local side is the same for all connections. Therefore it makes
-sense to put the definitions characterizing the strongSwan security gateway into
-the conn %default section of the configuration file /etc/ipsec.conf. If we
-assume throughout this document that the strongSwan security gateway is left and
-the peer is right then we can write
-
-conn %default
-     # my side is left - the freeswan security gateway
-     left=%defaultroute
-     leftcert=moonCert.pem
-     # load connection definitions automatically
-     auto=add
-
-The X.509 certificate by which the strongSwan security gateway will authenticate
-itself by sending it in binary form to its peers as part of the Internet Key
-Exchange (IKE) is specified in the line
-
-     leftcert=moonCert.pem
-
-The certificate can either be stored in base64 PEM-format or in the binary
-DER-format. Irrespective of the file suffix, Pluto "automagically" determines
-the correct format. Therefore
-
-     leftcert=moonCert.der
-
-or
-
-     leftcert=moonCert.cer
-
-would also be valid alternatives.
-
-When using relative pathnames as in the examples above, the certificate files
-must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish
-strongSwan's own certificates from locally stored trusted peer certificates
-(see section 5.5 for details), they could also be stored in a subdirectory
-below /etc/ipsec.d/certs as e.g. in
-
-    leftcert=mycerts/moonCert.pem
-
-Absolute pathnames are also possible as in
-
-    leftcert=/usr/ssl/certs/moonCert.pem
-
-As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain
-Name (FQDN) of the form
-
-conn rw
-     right=%any
-     leftid=@moon.strongswan.org
-
-Important: When an FQDN identifier is used it must be explicitly included as a
-so called subjectAltName of type dnsName (DNS:) in the certificate indicated
-by leftcert. For details on how to generate certificates with subjectAltNames,
-please refer to section 7.2.
-
-If you don't want to mess with subjectAltNames, you can use the certificate's
-Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN
-and which can be written e.g. in the LDAP-type format
-
-conn rw
-     right=%any
-     leftid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org"
-
-Since the subject's DN is part of the certificate, the leftid does not have to
-be declared explicitly. Thus the entry
-
-conn rw
-     right=%any
-
-automatically assumes the subject DN of leftcert to be the host ID.
-
-
-4.2 Multiple certificates
-    ---------------------
-
-strongSwan supports multiple local host certificates and corresponding
-RSA private keys:
-
-conn rw1
-     right=%any
-     rightid=@peer1.domain1
-     leftcert=myCert1.pem
-     # leftid is DN of myCert1
-
-conn rw2
-     right=%any
-     rightid=@peer2.domain2
-     leftcert=myCert2.pem
-     # leftid is DN of myCert2
-
-When peer1 initiates a connection then strongSwan will send myCert1 and will
-sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas
-myCert2 and myKey2 will be used in a connection setup started from peer2.
-
-
-4.3 Configuring the peer side using CA certificates
-    -----------------------------------------------
-
-Now we can proceed to define our connections. In many applications we might
-have dozens of mostly Windows-based road warriors connecting to a central
-strongSwan security gateway. The following most simple statement:
-
-conn rw
-     right=%any
-
-defines the general roadwarrior case. The line right=%any literally means that
-any IPSec peer is accepted, regardless of its current IP source address and its
-ID, as long as the peer presents a valid X.509 certificate signed by a CA the
-strongSwan security gateway puts explicit trust in. Additionally the signature
-during IKE main mode gives proof that the peer is in possession of the private
-RSA key matching the public key contained in the transmitted certificate.
-
-The ID by which a peer is identifying itself during IKE main mode can by any of
-the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first
-three ID types is used, then the accompanying X.509 certificate of the peer
-must contain a matching subjectAltName field of the type ipAddress (IP:),
-dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type
-DER_ASN1_DN the identifier must completely match the subject field of the
-peer's certificate. One of the two possible representations of a
-Distinguished Name (DN) is the LDAP-type format
-
-     rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org"
-
-Additional whitespace can be added everywhere as desired since it will be
-automatically eliminated by the X.509 parser. An exception is the single
-whitespace between individual words , like e.g. in Linux strongSwan, which is
-preserved by the parser.
-
-The Relative Distinguished Names (RDNs) can alternatively be separated by a
-slash '/' instead of a comma ','
-
-     rightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org"
-
-This is the representation extracted from the certificate by the OpenSSL
-command line option
-
-     openssl x509 -in sunCert.pem -noout -subject
-
-The following RDNs are supported by strongSwan
-
-+---------------------------------------------------+
-| DC               Domain Component                 |
-|---------------------------------------------------|
-| C                Country                          |
-|---------------------------------------------------|
-| ST               State or province                |
-|---------------------------------------------------|
-| L                Locality or town                 |
-|---------------------------------------------------|
-| O                Organisation                     |
-|---------------------------------------------------|
-| OU               Organisational Unit              |
-|---------------------------------------------------|
-| CN               Common Name                      |
-|---------------------------------------------------|
-| ND               NameDistinguisher, used with CN  |
-|---------------------------------------------------|
-| N                Name                             |
-|---------------------------------------------------|
-| G                Given name                       |
-|---------------------------------------------------|
-| S                Surname                          |
-|---------------------------------------------------|
-| I                Initials                         |
-|---------------------------------------------------|
-| T                Personal title                   |
-|---------------------------------------------------|
-| E                E-mail                           |
-|---------------------------------------------------|
-| Email            E-mail                           |
-|---------------------------------------------------|
-| emailAddress     E-mail                           |
-|---------------------------------------------------|
-| SN               Serial number                    |
-|---------------------------------------------------|
-| serialNumber     Serial number                    |
-|---------------------------------------------------|
-| D                Description                      |
-|---------------------------------------------------|
-| ID               X.500 Unique Identifier          |
-|---------------------------------------------------|
-| UID              User ID                          |
-|---------------------------------------------------|
-| TCGID            [Siemens] Trust Center Global ID |
-|---------------------------------------------------|
-| unstructuredName Unstructured Name                |
-|---------------------------------------------------|
-| UN               Unstructured Name                |
-|---------------------------------------------------|
-| employeeNumber   Employee Number                  |
-|---------------------------------------------------|
-| EN               Employee Number                  |
-+---------------------------------------------------+
-
-With the roadwarrior connection definition listed above, an IPsec SA for
-the strongSwan security gateway moon.strongswan.org itself can be established.
-If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24
-and 10.1.3.0/24 behind the security gateway then the following connection
-definitions will make this possible
-
-conn rw1
-     right=%any
-     leftsubnet=10.1.0.0/24
-
-conn rw3
-     right=%any
-     leftsubnet=10.1.3.0/24
-
-If not all peers in possession of a X.509 certificate signed by a specific
-certificate authority shall be given access to the Linux security gateway,
-then either a subset of them can be barred by listing the serial numbers of
-their certificates in a certificate revocation list (CRL) as specified in
-section 5.2 or as an alternative, access can be controlled by explicitly
-putting a roadwarrior entry for each eligible peer into ipsec.conf:
-
-conn sun
-     right=%any
-     rightid=@sun.strongswan.org
-
-conn carol
-     right=%any
-     rightid=carol@strongswan.org
-
-conn dave
-     right=%any
-     rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org"
-
-When the IP address of a peer is known to be stable, it can be specified as
-well. This entry is mandatory when the strongSwan host wants to act as the
-initiator of an IPSec connection.
-
-conn sun
-     right=192.168.0.2
-     rightid=@sun.strongswan.org
-
-conn carol
-     right=192.168.0.100
-     rightid=carol@strongswan.org
-
-conn dave
-     right=192.168.0.200
-     rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org"
-
-conn venus
-     right=192.168.0.50
-
-In the last example the ID types FQDN, USER_FQDN, DER_ASN1_DN and IPV4_ADDR,
-respectively, were used. Of course all connection definitions presented so far
-have included the lines in the conn %defaults section, comprising among other
-a left and leftcert entry.
-
-
-4.4 Handling Virtual IPs and wildcard subnets
-    -----------------------------------------
-
-Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes
-the inner IP source address of an IPsec tunnel to be different from the
-outer IP source address usually assigned dynamically by the ISP.
-Whereas the varying outer IP address can be handled by the right=%any
-construct, the inner IP address or subnet must always be declared in a
-connection definition. Therefore for the three roadwarriors rw1 to rw3
-connecting to a strongSwan security gateway the following entries are
-required in /etc/ipsec.conf:
-
-conn rw1
-     right=%any
-     righsubnet=10.4.0.5/32
-
-conn rw2
-     right=%any
-     rightsubnet=10.4.0.47/32
-
-conn rw3
-     right=%any
-     rightsubnet=10.4.0.128/28
-
-With the wildcard parameter rightsubnetwithin these three entries can be
-reduced to the single connection definition
-
-conn rw
-     right=%any
-     rightsubnetwithin=10.4.0.0/24
-
-Any host will be accepted (of course after successful authentication based on
-the peer's X.509 certificate only) if it declares a client subnet lying totally
-within the brackets defined by the wildcard subnet definition (in our example
-10.4.0.0/24). For each roadwarrior a connection instance tailored to the
-subnet of the particular client will be created,based on the generic
-rightsubnetwithin template.
-
-This strongSwan feature can also be helpful with VPN clients getting a
-dynamically assigned inner IP from a DHCP server located on the NAT router box.
-
-
-4.5 Protocol and Port Selectors
-    ---------------------------
-
-strongSwan offer the possibility to restrict the protocol and optionally the
-ports in an IPsec SA using the rightprotoport and leftprotoport parameters.
-
-Some examples:
-
-conn icmp
-     right=%any
-     rightprotoport=icmp
-     left=%defaultroute
-     leftid=@moon.strongswan.org
-     leftprotoport=icmp
-
-conn http
-     right=%any
-     rightprotoport=6
-     left=%defaultroute
-     leftid=@moon.strongswan.org
-     leftprotoport=6/80
-
-conn l2tp       # with port wildcard for Mac OS X Panther interoperability
-     right=%any
-     rightprotoport=17/%any
-     left=%defaultroute
-     leftid=@moon.strongswan.org
-     leftprotoport=17/1701
-
-conn dhcp
-     right=%any
-     rightprotoport=udp/bootpc
-     left=%defaultroute
-     leftid=@moon.strongswan.org
-     leftsubnet=0.0.0.0/0  #allows DHCP discovery broadcast
-     leftprotoport=udp/bootps
-     rekey=no
-     keylife=20s
-     rekeymargin=10s
-     auto=add
-
-Protocols and ports can be designated either by their numerical values
-or by their acronyms defined in /etc/services.
-
-    ipsec status
-
-shows the following connection definitions:
-
-"icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0
-"http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0
-"l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any
-"dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]:17/67...%any:17/68
-
-Based on the protocol and port selectors appropriate eroutes will be set
-up, so that only the specified payload types will pass through the IPsec
-tunnel.
-
-
-4.6 IPsec policies based on wildcards
-    ---------------------------------
-
-In large VPN-based remote access networks there is often a requirement that
-access to the various parts of an internal network must be granted selectively,
-e.g. depending on the group membership of the remote access user. strongSwan
-makes this possible by applying wildcard filtering on the VPN user's 
-distinguished name (ID_DER_ASN1_DN).
-
-Let's make a practical example:
-An organization has a sales department (OU=Sales) and a research group
-(OU=Research). In the company intranet there are separate subnets for Sales
-(10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web
-server (10.0.2.100). The VPN clients use Virtual IP addresses that are either
-assigned statically or via DHCP-over-IPsec. The sales and research departments
-use IP addresses from separate DHCP address pools (10.1.0.0/24) and (10.1.1.0/24),
-respectively. An X.509 certificate is issued to each employee, containing in its
-subject distinguished name the country (C=CH), the company (O=ACME),
-the group membership(OU=Sales or OU=Research) and the common name (e.g.
-CN=Bart Simpson).
-
-The IPsec policy defined above can now be enforced with the following three
-IPsec security associations:
-
-conn sales
-     right=%any
-     rightid="C=CH, O=ACME, OU=Sales, CN=*"
-     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
-     leftsubnet=10.0.0.0/24         # Sales subnet
-
-conn research
-     right=%any
-     rightid="C=CH, O=ACME, OU=Research, CN=*"
-     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
-     leftsubnet=10.0.1.0/24          # Research subnet
-
-conn web
-     right=%any
-     rightid="C=CH, O=ACME, OU=*, CN=*"
-     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
-     leftsubnet=10.0.2.100/32        # Web server
-     rightprotoport=tcp              # TCP protocol only
-     leftprotoport=tcp/http          # TCP port 80 only
-
-Of course group specific tunneling could be implemented on the
-basis of the Virtual IP range specified by the rightsubnetwithin
-parameter alone, but the wildcard matching mechanism guarantees that
-only authorized user can access the corresponding subnets.
-
-The '*' character is used as a wildcard in relative distinguished names (RDNs).
-In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain
-the same number of RDNs (selected from the list in section 4.3) appearing in the
-exact order defined by the template.
-
-    "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson"
-
-matches the templates
-
-    "C=CH, O=ACME, OU=Research, OU=*, CN=*"
-
-    "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*"
-
-    "C=CH, O=ACME, OU=*, OU=*, CN=*"
-
-but not the template
-
-    "C=CH, O=ACME, OU=*, CN=*"
-
-which doesn't have the same number of RDNs.
-
-
-4.7 IPsec policies based on CA certificates
-    ---------------------------------------
-
-As an alternative to the wildcard based IPsec policies described in section 4.6,
-access to specific client host and subnets can abe controlled on the basis of
-the CA that issued the peer certificate
-
-
-conn sales
-     right=%any
-     rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA"
-     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
-     leftsubnet=10.0.0.0/24         # Sales subnet
-
-conn research
-     right=%any
-     rightca="C=CH, O=ACME, OU=Research, CN=Research CA"
-     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
-     leftsubnet=10.0.1.0/24          # Research subnet
-
-conn web
-     right=%any
-     rightca="C=CH, O=ACME, CN=ACME Root CA"
-     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
-     leftsubnet=10.0.2.100/32        # Web server
-     rightprotoport=tcp              # TCP protocol only
-     leftprotoport=tcp/http          # TCP port 80 only
-
-In the example above, the connection "sales" can be used by peers
-presenting certificates issued by the Sales CA, only. In the same way,
-the use of the connection "research" is restricted to owners of certificates
-issued by the Research CA. The connection "web" is open to both "Sales" and
-"Research" peers because the required "ACME Root CA" is the issuer of the
-Research and Sales intermediate CAs. If no rightca parameter is present
-then any valid certificate issued by one of the trusted CAs in
-/etc/ipsec.d/cacerts can be used by the peer.
-
-The leftca parameter usually doesn't have to be set explicitly because
-by default it is set to the issuer field of the certificate loaded via
-leftcert. The statement
-
-     rightca=%same
-
-sets the CA requested from the peer to the CA used by the left side itself
-as e.g. in
-
-conn sales
-     right=%any
-     rightca=%same
-     leftcert=mySalesCert.pem
-
-
-4.8 Sending certificate requests
-    ----------------------------
-
-The presence of a rightca parameter also causes the CA to be sent as
-part of the certificate request message when strongSwan is the initiator.
-A special case occurs when strongSwan responds to a roadwarrior. If several
-roadwarrior connections based on different CAs are defined then all eligible
-CAs will be listed in Pluto\92s certificate request message.
-
-
-4.9 IPsec policies based on group attributes
-    ----------------------------------------
-
-X.509 attribute certificates are the most powerful mechanism for implementing
-IPsec security policies. The rightgroups parameter in a connection definition
-restricts the access to members of the listed groups only. An IPsec peer must
-have a valid attribute certificate issued by a trusted Authorization Authority
-and listing one of the requirede group attributes in order to get admitted.
-
-conn sales
-     right=%any
-     rightgroups="Sales"
-     rightsubnetwithin=10.1.0.0/24  # Sales DHCP range
-     leftsubnet=10.0.0.0/24         # Sales subnet
-
-conn research
-     right=%any
-     rightgroups="Research"
-     rightsubnetwithin=10.1.1.0/24   # Research DHCP range
-     leftsubnet=10.0.1.0/24          # Research subnet
-
-conn web
-     right=%any
-     rightgroups="Sales, Research"
-     rightsubnetwithin=10.1.0.0/23   # Remote access DHCP range
-     leftsubnet=10.0.2.100/32        # Web server
-     rightprotoport=tcp              # TCP protocol only
-     leftprotoport=tcp/http          # TCP port 80 only
-
-In the examples above membership of the group "Sales" is required for
-connection sales and membership of "Research" for connection research
-whereas connection web is accessible for both groups.
-
-Currently the attribute certificates of the peers must be loaded statically
-via the /etc/ipsec.d/acerts/ directory. In future releases of strongSwan it
-will be possible to fetch them from an LDAP directory server.
-
-
-5. Configuring certificates and CRLs
-   ---------------------------------
-
-
-5.1 Installing the CA certificates
-    ------------------------------
-
-X.509 certificates received by strongSwan during the IKE protocol are
-automatically authenticated by going up the trust chain until a self-signed
-root CA certificate is reached. Usually host certificates are directly signed
-by a root CA, but strongSwan also supports multi-level hierarchies with
-intermediate CAs in between. All CA certificates belonging to a trust chain
-must be copied in either binary DER or base64 PEM format into the directory
-
-     /etc/ipsec.d/cacerts/
-
-
-5.2 Installing optional certificate revocation lists (CRLs)
-    -------------------------------------------------------
-
-By copying a CA certificate into /etc/ipsec.d/cacerts/, automatically all user
-or host certificates issued by this CA are declared valid. Unfortunately
-private keys might get compromised inadvertently or intentionally, personal
-certificates of users leaving a company have to be blocked immediately, etc.
-To this purpose certificate revocation lists (CRLs) have been created. CRLs
-contain the serial numbers of all user or host certificates that have been
-revoked due to various reasons.
-
-After successful verification of the X.509 trust chain, Pluto searches its
-list of CRLs either obtained by loading them from the /etc/ipsec.d/crls/
-directory or fetching them dynamically from a HTTP or LDAP server for the
-presence of a CRL issued by the CA that has signed the certificate.
-
-If the serial number of the certificate is found in the CRL then the public key
-contained in the certificate is declared invalid and the IPSec SA will not be
-established. If no CRL is found or if the deadline defined in the nextUpdate
-field of the CRL has been reached, a warning is issued but the public key will
-nevertheless be accepted. CRLs must be stored either in binary DER or base64 PEM
-format in the crls directory. Section 7.3 will explain in detail how CRLs can
-be created using OpenSSL.
-
-
-5.3 Dynamic update of certificates and CRLs
-    ---------------------------------------
-
-Pluto reads certificates and CRLs from their respective files during system
-startup and keeps them in memory in the form of chained lists. X.509
-certificates have a finite life span defined by their validity field. Therefore
-it must be possible to replace CA or OCSP certificates kept in system memory
-without disturbing established ISAKMP SAs. Certificate revocation lists should
-also be updated in the regular intervals indicated by the nextUpdate field in
-the CRL body. The following interactive commands allow the manual replacement
-of the various files:
-
-+---------------------------------------------------------------------------+
-| ipsec rereadsecrets       reload file /etc/ipsec.secrets                  |
-|---------------------------------------------------------------------------|
-| ipsec rereadcacerts       reload all files in /etc/ipsec.d/cacerts/       |
-|---------------------------------------------------------------------------|
-| ipsec rereadaacerts       reload all files in /etc/ipsec.d/aacerts/       |
-|---------------------------------------------------------------------------|
-| ipsec rereadocspcerts     reload all files in /etc/ipsec.d/ocspcerts/     |
-|---------------------------------------------------------------------------|
-| ipsec rereadacerts        reload all files in /etc/ipsec.d/acerts/        |
-|---------------------------------------------------------------------------|
-| ipsec rereadcrls          reload all files in /etc/ipsec.d/crls/          |
-|---------------------------------------------------------------------------|
-| ipsec rereadall           ipsec rereadsecrets                             |
-|                                 rereadcacerts                             |
-|                                 rereadaacerts                             |
-|                                 rereadocspcerts                           |
-|                                 rereadacerts                              |
-|                                 rereadcrls                                |
-|---------------------------------------------------------------------------|
-| ipsec purgeocsp           purge the OCSP cache and fetching requests      |
-+---------------------------------------------------------------------------+
-
-CRLs can also be automatically fetched from an HTTP or LDAP server by using
-the CRL distribution points contained in X.509 certificates. The command
-
-    ipsec listcrls
-    
-shows any pending fetch requests:
-
-  Oct 31 00:29:53 2002, trials: 2
-         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         distPts: 'http://crl.strongswan.org/strongswan.crl'
-                 'ldap://ldap.strongswan.org/o=Linux strongSwan, c=CH
-                    ?certificateRevocationList?base
-                    ?(objectClass=certificationAuthority)'
-
-In the example above, an http and an ldap URL were extracted from a received
-end certificate. An independent thread then tries to fetch a CRL from the
-designated distribution points. The same thread also periodically checks
-if any loaded CRLs are about to expire. The check interval can be defined in
-the "config setup" section of the ipsec.conf file:
-
-   config setup
-       crlcheckinterval=600
-
-In our example the thread wakes up every 600 seconds or 10 minutes in order
-to check the validity of the CRLs or to retry any pending fetch requests:
-
-  List of X.509 CRLs:
-  
-  Dec 19 09:35:31 2002, revoked certs: 40
-         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         distPts: 'http://crl.strongswan.org/strongswan.crl'
-         updates:  this Dec 19 09:35:00 2002
-                   next Dec 19 10:35:00 2002 warning (expires in 19 minutes)
-
-  List of fetch requests:
-
-  Dec 19 10:15:31 2002, trials: 1
-        issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-        distPts: 'http://crl.strongwan.org/strongswan.crl'
-
-The first trial to update a CRL is started 2*crlcheckinterval before the
-nextUpdate time, i.e. when less than 20 minutes are left in our practical
-example. When crlcheckinterval is set to 0 (this is also the default value
-when the parameter is not set in ipsec.conf) then the CRL checking and updating 
-thread is not started and dynamic CRL fetching is disabled.
-
-
-5.4 Local caching of CRLs
-    ---------------------
-
-The the ipsec.conf option
-
-   config setup
-        cachecrls=yes
-
-activates the local caching of CRLs that were dynamically fetched from an
-HTTP or LDAP server. Cached copies are stored in /etc/ipsec.d/crls under a
-unique filename formed from the issuer's SubjectKeyIdentifier and the suffix .crl.
-
-With the cached copy the CRL is immediately available after pluto's startup.
-When the local copy is about to expire it is automatically replaced with an
-updated CRL fetched from one of the defined CRL distribution points.
-
-
-5.5 Online Certificate Status Protocol (OCSP)
-    -----------------------------------------
-
-The Online Certificate Status Protocol is defined by RFC 2560. It can be
-used to query an OCSP server about the current status of an X.509 certificate
-and is often used as a more dynamic alternative to a static Certificate
-Revocation List (CRL). Both the OCSP request sent by the client and the OCSP
-response messages returned by the server are transported via a standard
-TCP/HTTP connection. Therefore cURL support must be enabled in pluto/Makefile:
-
-  # Uncomment this line to enable OCSP fetching using HTTP
-  LIBCURL=1
-
-In the simplest OCSP setup, a default URI under which the OCSP server for a
-given CA can be accessed is defined in ipsec.conf:
-
-   config setup
-        crlcheckinterval=600
-       
-   ca strongswan
-        cacert=strongswanCert.pem
-        ocspuri=http://ocsp.strongswan.org:8880
-        auto=add
-
-The HTTP port can be freely chosen. In our example we have assumed TCP port 8880.
-The crlcheckinterval must be set to a value different from zero. Otherwise the
-OCSP fetching thread will not be started.
-
-The well-known openssl-0.9.7 package from http://www.openssl.org implements
-an OCSP server that can be used in conjunction with an openssl-based Public
-Key Infrastructure. The OCSP client integrated into Pluto does not contain
-any OpenSSL code though, but is based on the existing ASN.1 functionality of
-strongSwan.
-
-The OpenSSL-based OCSP server is started with the following command:
-
-    openssl ocsp -index index.txt -CA strongswanCert.pem -port 8880 \
-                 -rkey ocspKey.pem -rsigner ocspCert.pem \
-                 -resp_no_certs -nmin 60 -text
-
-The command consists of the parameters
-
- -index  index.txt is a copy of the OpenSSL index file containing the list of
-         all issued certificates. The certificate status in indext.txt
-         is designated either by V for valid or R for revoked. If
-         a new certificate is added or if a certificate is revoked
-         using the openssl ca command, the OCSP server must be restarted
-         in order for the changes in index.txt to take effect.
-
- -CA     the CA certificate
-
- -port   the HTTP port the OCSP server is listening on.
--rkey    the private key used to sign the OCSP response. The use of the
-         sensitive CA private key is not recommended since this could
-         jeopardize the security of your production PKI if the OCSP
-         server is hacked. It is much better to generate a special
-         RSA private key just for OCSP signing use instead.
-
--rsigner the certificate of the OCSP server containing a public key which
-         matches the private key defined by -rkey and which can be used by
-         the client to check the trustworthiness of the signed OCSP response.
-
--resp_no_certs  With this option the OCSP signer certificate defined by
-                -rsigner is not included in the OCSP response.
-
--nmin    the validity interval of an OCSP response given in minutes.
-         2*crlcheckinterval before the expiration of the OCSP responses,
-         a new query will by pro-actively started by the Pluto fetching thread.
-
-         If nmin is missing or set to zero then the default validity interval
-         compiled into Pluto will be 2 minutes, leading to a quasi one-time
-         use of the OCSP status response which will not be periodically 
-         refreshed by the fetching thread. In conjunction with the parameter
-        setting "strictcrlpolicy=yes" a real-time certificate status query
-        can be implemented in this way.
-
--text   This option activates a verbose logging output, showing the contents
-        of both the received OCSP request and sent OCSP response.
-
-How does Pluto get hold of the OCSP signer certificate? There are two
-possibilities:
-Either you put the OCSP certificate into the default directory
-
-    /etc/ipsec.d/ocspcerts
-    
-or alternatively Pluto can receive it as part of the OCSP response from the
-remote OCSP server. In the latter case, how can Pluto make sure that
-the server has indeed been authorized by the CA to deal out certificate status
-information? In order to ascertain the OCSP signer capability, an extended
-key usage attribute can be included in the OCSP server certificate. Just
-insert the parameter
-
-    extendedKeyUsage=OCSPSigner
-
-in the [ usr_cert ] section of your openssl.cnf configuration file before
-the CA signs the OCSP server certificate.
-
-For a given CA the corresponding ca section in ipsec.conf (see section 7) allows
-to define the URI of a single OCSP server. As an alternative an OCSP URI can be
-embedded into each host and user certificate by putting the line
-
-    authorityInfoAccess = OCSP;URI:http://ocsp.strongswan.org:8880
-
-into the [ usr_cert ] section of your openssl.cnf configuration file.
-If an OCSP authorityInfoAccess extension is present in a certificate then this
-record overrides the default URI defined by the ca section.
-
-
-5.6 CRL Policy
-    ----------
-
-By default Pluto is quite tolerant concerning the handling of CRLs. It is not
-mandatory for a CRL to be present in /etc/ipsec.d/crls and if the expiration
-date defined by the nextUpdate field of a CRL has been reached just a warning
-is issued but a peer certificate will always be accepted if it has not been
-revoked.
-
-If you want to enforce a stricter CRL policy then you can do this by setting
-the "strictcrlpolicy" option. This is done in the "config setup" section
-of the ipsec.conf file:
-
-    config setup
-         strictcrlpolicy=yes
-          ...
-
-A certificate received from a peer will not be accepted if no corresponding
-CRL or OCSP response is available. And if an ISAKMP SA re-negotiation takes
-place after the nextUpdate deadline has been reached, the peer certificate
-will be declared invalid and the cached RSA public key will be deleted, causing
-the connection in question to fail. Therefore if you are going to use the
-"strictcrlpolicy=yes" option, make sure that the CRLs will always be updated
-in time. Otherwise a total standstill would ensue.
-
-As mentioned earlier the default setting is "strictcrlpolicy=no"
-
-
-5.7 Configuring the peer side using locally stored certificates
-    -----------------------------------------------------------
-
-If you don't want to use trust chains based on CA certificates as proposed in
-section 4.3 you can alternatively import trusted peer certificates directly
-into Pluto. Thus you do not have to rely on the certificate to be transmitted
-by the peer as part of the IKE protocol.
-
-With the conn %default section defined in section 4.1 and the use of the
-rightcert keyword for the peer side, the connection definitions in section 4.3
-can alternatively be written as
-
-    conn sun
-          right=%any
-          rightid=@sun.strongswan.org
-          rightcert=sunCert.cer
-
-     conn carol
-          right=192.168.0.100
-          rightcert=carolCert.der
-
-If the peer certificates are loaded locally then there is no sense in sending
-any certificates to the other end via the IKE Main Mode protocol. Especially
-if self-signed certificates are used which wouldn't be accepted any way by
-the other side. In these cases it is recommended to add
-
-          leftsendcert=never
-
-to the connection definition[s] in order to avoid the sending of the host's
-own certificate. The default value is
-
-    leftsendcert=always.
-
-If a peer certificate contains a subjectAltName extension, then an alternative
-rightid type can be used, as the example "conn sun" shows. If no rightid
-entry is present then the subject distinguished name contained in the
-certificate is taken as the ID.
-
-Using the same rules concerning pathnames that apply to strongSwan's own
-certificates, the following two definitions are also valid for trusted peer
-certificates:
-
-    rightcert=peercerts/carolCert.der
-
-or
-
-    rightcert=/usr/ssl/certs/carolCert.der
-
-
-6. Installing the private key - ipsec.secrets
-   ------------------------------------------
-
-6.1 Loading private key files in PKCS#1 format
-    ------------------------------------------
-
-Besides strongSwan's raw private key format strongSwan has been enabled to
-load RSA private keys in the PKCS#1 file format. The key files can be
-optionally secured with a passphrase.
-
-RSA private key files are declared in /etc/ipsec.secrets using the syntax
-
-    : RSA <my keyfile> "<optional passphrase>"
-
-The key file can be either in base64 PEM-format or binary DER-format. The
-actual coding is detected "automagically" by Pluto. The example
-
-    : RSA moonKey.pem
-
-uses a relative pathname. In this case Pluto will look for the key file
-in the directory
-
-    /etc/ipsec.d/private
-
-As an alternative an absolute pathname can be given as in
-
-    : RSA /usr/ssl/private/moonKey.pem
-
-In both cases make sure that the key files are root readable only.
-
-Often a private key must be transported from the Certification Authority
-where it was generated to the target security gateway where it is going
-to be used. In order to protect the key it can be encrypted with 3DES
-using a symmetric transport key derived from a cryptographically strong
-passphrase.
-
-    openssl genrsa -des3 -out moonKey.pem 1024
-
-Because of the weak security, key files protected by single DES will not
-be accepted by Pluto!!!
-
-Once on the security gateway the private key can either be permanently
-unlocked so that it can be used by Pluto without having to know a
-passphrase
-
-    openssl rsa -in moonKey.pem -out moonKey.pem
-
-or as an option the key file can remain secured. In this case the passphrase
-unlocking the private key must be added after the pathname in
-/etc/ipsec.secrets
-
-    : RSA moonKey.pem "This is my passphrase"
-
-Some CAs distribute private keys embedded in a PKCS#12 file. Since Pluto
-is not able yet to read this format directly, the private key part must
-first be extracted using the command
-
-     openssl pkcs12 -nocerts -in moonCert.p12 -out moonKey.pem
-
-if the key file moonKey.pem is to be secured again by a passphrase, or
-
-     openssl pkcs12 -nocerts  -nodes -in moonCert.p12 -out moonKey.pem
-
-if the private key is to be stored unlocked.
-
-
-6.2 Entering passphrases interactively
-    ----------------------------------
-    
-On a VPN gateway you would want to put the passphrase protecting the private
-key file right into /etc/ipsec.secrets as described in the previous paragraph,
-so that the gateway can be booted in unattended mode. The risk of keeping
-unencrypted secrets on a server can be minimized by putting the box into a
-locked room. As long as no one can get root access on the machine the private
-keys are safe.
-    
-On a mobile laptop computer the situation is quite different. The computer can
-be stolen or the user is leaving it unattended so that unauthorized persons
-can get access to it. In theses cases it would be preferable not to keep any
-passphrases openly in /etc/ipsec.secrets but to prompt for them interactively
-instead. This is easily done by defining
-
-    : RSA moonKey.pem %prompt
-    
-Since strongSwan is usually started during the boot process, usually no
-interactive console windows is available which can be used by Pluto to
-prompt for the passphrase. This must be initiated by the user by typing
-
-    ipsec secrets
-    
-which actually is an alias for the existing command
-
-    ipsec rereadsecrets
-
-and which causes the prompt
-
-    need passphrase for '/etc/ipsec.d/private/moonKey.pem'
-    Enter:
-
-to appear. If the passphrase was correct and the private key file could be
-successfully decrypted then
-
-    valid passphrase
-    
-results. Otherwise the prompt
-
-   invalid passphrase, please try again
-   Enter:
-
-will give you another try. Entering a carriage return will abort the
-the passphrase prompting.
-
-
-6.3 Multiple private keys
-    ---------------------
-
-strongSwan supports multiple private keys. Since the connections defined
-in ipsec.conf can find the correct private key based on the public key
-contained in the certificate assigned by leftcert, default private key
-definitions without specific IDs can be used
-
-    : RSA myKey1.pem "<optional passphrase1>"
-
-    : RSA myKey2.pem "<optional passphrase2>"
-
-
-7. Configuring CA properties - ipsec.conf
-   --------------------------------------
-
-Besides the definition of IPsec connections the ipsec.conf file can also
-be used to configure a few properties of the certification authorities
-needed to establish the X.509 trust chains. The following example shows
-the parameters that are currently available:
-
-    ca strongswan
-       cacert=strongswanCert.pem
-       ocspuri=http://ocsp.strongswan.org:8880
-       crluri=http://crl.strongswan.org/strongswan.crl'
-       crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList"
-       ldaphost=ldap.strongswan.org
-       auto=add
-
-In a similar way as conn sections are used for connection definitions, an
-arbitrary number of optional ca sections define the basic properties of CAs.
-
-Each ca section is named with a unique label
-       ca strongswan
-
-The only mandatory parameter is
-
-       cacert=strongswanCert.pem
-
-which points to the CA certificate which usually resides in the default
-directory /etc/ipsec.d/cacerts/ but could also be retrieved via an absolute
-path name. If the CA certificate is stored on a smartcard then the
-notation
-
-       cacert=%smartcard#<n>
-
-or alternatively
-
-       cacert=%smartcard<optional slot nr>:<key id>
-
-can be used. The selection of smartcard slots is described in more detail
-in section 8.1.
-
-From the certificate the CA's distinguished name and the serial number
-is extracted. If an optional subjectKeyAuthentifier is present then it can
-be used to uniquely identify consecutive generations of CA certificates
-carrying the same distinguished name.
-
-The OCSP URI
-
-       ocspuri=http://ocsp.strongswan.org:8880
-
-allows to define an individual OCSP server per CA. Also up to two additional
-CRL distribution points (CDPs) can be defined
-
-       crluri=http://crl.strongswan.org/strongswan.crl'
-       crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList"
-
-which are added to any CDPs already present in the received certificates
-themselves. The last parameter
-
-       ldaphost=ldap.strongswan.org
-
-can be used to fill in the actual server name in LDAP CDPs where the host is missing
-as e.g. in the crluri2 above. In future releases this ldaphost parameter might be used
-to retrieve user, host and attribute certificates.
-
-
-With the auto=add statement the ca definition is automatically loaded into Pluto during
-system startup. Setting auto=ignore will ignore the ca section. Additional ca definitions
-can be loaded from ipsec.conf during runtime with the command
-
-      ipsec auto --type ca --add strongswan-sales
-
-and
-
-      ipsec auto --type ca --delete strongswan-sales
-
-deletes the labeled ca entry. And finally the command
-
-    ipsec auto --type ca --replace strongswan
-
-first deletes the old definition in Pluto's memory and then loads the updated version
-from ipsec.conf. Any parameters which appear in several ca definitions can be put in
-a common ca %default section
-
-    ca %default
-       ldaphost=ldap.strongswan.org
-
-
-8. Smartcard support
-   -----------------
-
-8.1 Configuring a smartcard-based connection
-    ----------------------------------------
-
-Defining a smartcard-based connection in ipsec.conf is easy:
-
-    conn sun
-         right=192.168.0.2
-        rightid=@sun.strongswan.org
-        left=%defaultroute
-        leftcert=%smartcard
-        auto=add
-
-In most cases there is a single smartcard reader or cryptotoken and only one
-RSA private key safely stored on the crypto device. Thus usually the entry
-
-    leftcert=%smartcard
-
-which stands for the full notation
-
-    leftcert=%smartcard#1
-
-is sufficient where the first certificate/private key object enumerated by
-the PKCS#11 module is used. If several certificate/private key objects are
-present then the nth object can be selected using
-
-    leftcert=%smartcard#<n>
-
-The command
-
-    ipsec listcards
-
-gives an overview over all certificate objects made available by the PKCS#11
-module.CA certificates are automatically available as trust anchors.
-
-As an alternative the certificate ID and/or the slot number defined by
-the PKCS#11 standard can be specified using the notation
-
-   leftcert=%smartcard<optional slot nr>:<key id in hex format>
-
-Thus
-
-    leftcert=%smartcard:50
-
-will look in all available slots for ID 0x50 starting with the first slot
-(usually slot 0) whereas
-
-    leftcert=%smartcard4:50
-
-will directly check slot 4 (which is usually the first slot on the second
-reader/token when using the OpenSC library) for a key with ID 0x50.
-
-
-8.2 Entering the PIN code
-    ---------------------
-
-Since the smartcard signing operation needed to sign the hash with the
-RSA private key during IKE Main Mode is protected by a PIN code,
-the secret PIN must be made available to Pluto.
-
-For gateways that must be able to start IPsec tunnels automatically in
-unattended mode after a reboot, the secret PIN  can be stored statically
-in ipsec.secrets
-
-   : PIN %smartcard "12345678"
-  
-or with the general notation
-
-   : PIN %smartcard#<n> "<PIN code>"
-
-or alternatively
-
-   : PIN %smartcard<optional slot nr>:<key id> "<PIN code>"
-  
-On personal notebooks that could get stolen, you wouldn't want to store
-your PIN in ipsec.secrets. Thus the alternative form
-
-   : PIN %smartcard %prompt
-  
-will prompt you for the PIN when you start up the first IPsec connection
-using the command
-
-   ipsec up sun
-  
-The auto command calls the whack function which in turn communicates with
-Pluto over a socket. Since the whack function call is executed from a command
-window, Pluto can prompt you for the PIN over this socket connection.
-Unfortunately roadwarrior connections which just wait passively for peers
-cannot be initiated via the command window:
-
-   conn rw
-         right=%any
-        left=%defaultroute
-        leftcert=%smartcard4:50
-        auto=add
-
-But if there is a corresponding entry
-
-   : PIN %smartcard4:50 %prompt
-  
-in ipsec.secrets, then the standard command
-
-   ipsec rereadsecrets
-  
-or the alias
-
-   ipsec secrets
-   
-can be used to enter the PIN code for this connection interactively.
-
-The command
-
-   ipsec listcards
-
-can be executed at any time to check the current status of the PIN code[s].
-
-
-8.3 PIN-pad equipped smartcard readers
-    ----------------------------------
-
-Smartcard readers with an integrated PIN-pad offer an increased security
-level because the PIN entry cannot be sniffed on the host computer e.g.
-by a surrepticiously installed key logger. In order to tell pluto not to
-prompt for the PIN on the host itself, the entry
-
-   : PIN %smartcard:50 %pinpad
-
-can be used in ipsec.secrets. Because the key pad does not cache the PIN in
-the smartcard reader, it must be entered for every PKCS #11 session login.
-By default pluto does a session logout after every RSA signature. In order
-to avoid the repeated entry of the PIN code during the periodic IKE main
-mode rekeyings, the following parameter can be set in the config setup
-section of ipsec.conf:
-
-   config setup
-        pkcs11keepstate=yes
-
-The default setting is pkcs11keepstate=no. 
-
-
-8.4 Configuring a smartcard with pkcsc15-init
-    -----------------------------------------
-
-strongSwan's smartcard solution is based on the PKCS#15 "Cryptographic Token
-Information Format Standard" fully supported by OpenSC library functions.
-Using the command
-
-    pkcs15-init --erase-card --create-pkcs15
-
-a fresh PKCS#15 file structure is created on a smartcard or cryptotoken.
-With the next command
-
-    pkcs15-init --auth-id 1 --store-pin --pin "12345678" --puk "87654321"
-                --label "my PIN"
-
-a secret PIN code with auth-id 1 is stored in an unretrievable location on
-the smart card. The PIN will protect the RSA signing operation. If the PIN
-is entered incorrectly more than three times the smartcard will be locked
-and the PUK code can be used to unlock the card again.
-
-Next the RSA private key is transferred to the smartcard
-
-    pkcs15-init --auth-id 1 --store-private-key myKey.pem [--id 45]
-
-By default the PKCS#15 smartcard record will be assigned the id 45.
-Using the --id option multiple key records can be stored on a smartcard.
-
-At last we load the matching X.509 certificate onto the smartcard
-
-    pkcs15-init --auth-id 1 --store-certificate myCert.pem [--id 45]
-
-The pkcs15-tool can now be used to verify the contents of the smartcard.
-
-   pkcs15-tool --list-pins --list-keys --list-certificates
-
-If everything is ok then you are ready to use the generated PKCS#15
-structure with strongSwan.
-
-8.5 PKCS#11 proxy functions
-    -----------------------
-
-   With the setting pkcs11keepstate=yes some PKCS#11 implementations
-   (e.g. OpenSC) will lock the access to the smartcard as soon as pluto has
-   opened a session and will thus prevent other application from sharing the
-   smartcard resource. In order to solve this locking problem, strongSwan
-   offers a PKCS#11 proxy service making use of the whack socket communication
-   channel. The setting
-
-   config setup
-      pkcs11proxy=yes
-
-will enable the proxy mode that is disabled by default. 
-
-Currently two smartcard operations are supported: RSA encryption and
-RSA decryption. The notation is as follows:
-
-   ipsec scdecrypt <encrypted data>
-                   [--inbase  16|hex|64|base64|256|text|ascii]
-                   [--outbase 16|hex|64|base64|256|text|ascii]
-                   [--keyid <id>]
-
-The default settings for inbase and outbase is hexadecimal.
-Thus the simplest call has the form
-
-   ipsec scdecrypt bb952b71920094ce0696ef9b8b26...12e6
-
-and the returned result might be a decrypted 128 bit AES key
-
-   000 8836362e030e6707c32ffaa0bdad5540
-
-The leading three characters represent the return code of the whack channel
-with 000 signifying that no error has occured. Here is another example showing
-the use of the inbase and outbase attributes
-
-   ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text
-
-where the result has the form
-
-   000 This is a secret
-
-By default the first RSA private key found by the PKCS#11 enumeration is
-used. If a different key should be selected then the notation introduced
-in sections 8.1 and 8.2 can be used:
-
-  --keyid %smartcard:50
-  --keyid %smartcard4:50
-  --keyid %smartcard#3
-
-with --keyid %smartcard#1 being the default. If supported by the smartcard
-and PKCS#11 library RSA encryption can be used with the notation
-
-   ipsec scencrypt <plaintext data>
-                   [--inbase  16|hex|64|base64|256|text|ascii]
-                   [--outbase 16|hex|64|base64|256|text|ascii]
-                   [--keyid <id>]
-
-with the example
-
-   ipsec scencrypt "This is a secret" --inbase ascii --outbase 64
-
-returning the expected output
-
-   000 m/ewDnTs0k...woE=
-
-
-9. Configuring the clients
-   -----------------------
-
-9.1 strongSwan
-    ----------
-
-A strongSwan to strongSwan connection is symmetrical. Any of the four defined
-ID types can be used, even different types on either end of the connection,
-although this wouldn't make much sense.
-
-+--------------------------------------------------------------+
-| Connection Definition        ID type          subjectAltName |
-|--------------------------------------------------------------|
-| rightid  (strongSwan)        DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-|--------------------------------------------------------------|
-| leftid   (strongSwan)        DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-+--------------------------------------------------------------+
-
-
-9.2 PGPnet
-    ------
-
-Use the file peerCert.p12 to import PGPnet's X.509 certificate, the CA
-certificate, plus the encrypted private key in binary PKCS#12 format into the
-PGPkey tool. You will be prompted for the passphrase securing the private key.
-
-Use the file myCert.pem to import the X.509 certificate of the strongSwan
-security gateway into the PGPkey tool. The PGPkeyTool does not accept X.509
-certificates in binary DER format, so it must be imported in base64 format:
-
-     -----BEGIN CERTIFICATE-----
-     M...
-
-     ...
-     -----END CERTIFICATE-----
-
-Make sure that there is no human-readable listing of the X.509 certificate in
-front of the line
-
-     -----BEGIN CERTIFICATE-----
-
-otherwise PGPnet will refuse to load the *.PEM file. Any surplus lines can
-either be deleted by loading the certificate into a text editor or you can
-apply the command
-
-     openssl x509 -in myCert.pem -out myCert.pem
-
-to achieve the same effect.
-
-With authentication based on X.509 certificates, PGPnet always sends the ID
-type DER_ASN1_DN, therefore rightid in the connection definition of the
-strongSwan security gateway must be an ASN.1 distinguished name.
-
-In the receiving direction PGPnet accepts all four ID types from strongSwan.
-
-+--------------------------------------------------------------+
-| Connection Definition        ID type          subjectAltName |
-|--------------------------------------------------------------|
-| rightid  (PGPnet)            DER_ASN1_DN      -              |
-|--------------------------------------------------------------|
-| leftid   (strongSwan)        DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-+--------------------------------------------------------------+
-
-
-9.3 SafeNet/Soft-PK/Soft-Remote
-    ---------------------------
-
-SafeNet/Soft-PK and SafeNet/Soft-Remote can be configured to send their
-identity either as DER_ASN1_DN, IPV4_ADDR, FQDN, or USER_FQDN.
-In the receiving direction SafeNet/Soft-PK and SafeNet/Soft-Remote
-accept all four ID types coming from strongSwan.
-
-+--------------------------------------------------------------+
-| Connection Definition        ID type          subjectAltName |
-|--------------------------------------------------------------|
-| rightid  (SafeNet/Soft-PK)   DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-|--------------------------------------------------------------|
-| leftid  (strongSwan)         DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-+--------------------------------------------------------------+
-
-
-9.4 SSH Sentinel
-    ------------
-
-SSH Sentinel sends its identity as DER_ASN1_DN if the subjectAltName field of
-its certificate is empty. If a subjectAltName field is present, then the
-corresponding type IPV4_ADDR, FQDN, or USER_FQDN is automatically chosen.
-With several subjectAltName entries, the precedence of the different ID types
-is not quite clear. In the receiving direction SSH Sentinel accepts all four
-ID types from strongSwan.
-
-+--------------------------------------------------------------+
-| Connection Definition        ID type          subjectAltName |
-|--------------------------------------------------------------|
-| rightid  (SSH Sentinel)      DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-|--------------------------------------------------------------|
-| leftid  (strongSwan)         DER_ASN1_DN      -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-+--------------------------------------------------------------+
-
-
-9.5 Windows 2000/XP
-    ---------------
-
-Windows 2000 and Windows XP always send the ID type DER_ASN1_DN,
-therefore rightid in the connection definition of the strongSwan
-security gateway must be an ASN.1 distinguished name.In the
-receiving direction Windows 2000/XP accepts all four ID types
-from strongSwan.
-
-+--------------------------------------------------------------+
-| Connection Definition        ID type          subjectAltName |
-|--------------------------------------------------------------|
-| rightid  (Windows 2000/XP)   DER_ASN1_DN      -              |
-|--------------------------------------------------------------|
-| leftid   (strongSwan)        DER_ASN1_D       -              |
-|                              FQDN             DNS:           |
-|                              USER_FQDN        email:         |
-|                              IPV4_ADDR        IP:            |
-+--------------------------------------------------------------+
-
-
-10. Monitoring functions
-    --------------------
-
-strongSwan offers the following monitoring functions:
-
-
-    ipsec listalgs
-
-lists all IKE and ESP cryptographic algorithms that are currently
-registered with strongSwan.
-
-The a listing has the following form:
-
-  List of registered IKE Encryption Algorithms:
-
-  #3     OAKLEY_BLOWFISH_CBC, blocksize: 64, keylen: 128-128-256
-  #5     OAKLEY_3DES_CBC, blocksize: 64, keylen: 192-192-192
-  #7     OAKLEY_AES_CBC, blocksize: 128, keylen: 128-128-256
-  #65004 OAKLEY_SERPENT_CBC, blocksize: 128, keylen: 128-128-256
-  #65005 OAKLEY_TWOFISH_CBC, blocksize: 128, keylen: 128-128-256
-  #65289 OAKLEY_TWOFISH_CBC_SSH, blocksize: 128, keylen: 128-128-256
-
-  List of registered IKE Hash Algorithms:
-
-  #1     OAKLEY_MD5, hashsize: 128
-  #2     OAKLEY_SHA, hashsize: 160
-  #4     OAKLEY_SHA2_256, hashsize: 256
-  #6     OAKLEY_SHA2_512, hashsize: 512
-
-  List of registered IKE DH Groups:
-
-  #2     OAKLEY_GROUP_MODP1024, groupsize: 1024
-  #5     OAKLEY_GROUP_MODP1536, groupsize: 1536
-  #14    OAKLEY_GROUP_MODP2048, groupsize: 2048
-  #15    OAKLEY_GROUP_MODP3072, groupsize: 3072
-  #16    OAKLEY_GROUP_MODP4096, groupsize: 4096
-  #17    OAKLEY_GROUP_MODP6144, groupsize: 6144
-  #18    OAKLEY_GROUP_MODP8192, groupsize: 8192
-
-  List of registered ESP Encryption Algorithms:
-
-  #3     ESP_3DES, blocksize: 64, keylen: 168-168
-  #7     ESP_BLOWFISH, blocksize: 64, keylen: 96-128
-  #12    ESP_AES, blocksize: 128, keylen: 128-256
-  #252   ESP_SERPENT, blocksize: 128, keylen: 128-256
-  #253   ESP_TWOFISH, blocksize: 128, keylen: 128-256
-
-  List of registered ESP Authentication Algorithms:
-
-  #1     AUTH_ALGORITHM_HMAC_MD5, keylen: 128-128
-  #2     AUTH_ALGORITHM_HMAC_SHA1, keylen: 160-160
-  #5     AUTH_ALGORITHM_HMAC_SHA2_256, keylen: 256-256
-  #7     AUTH_ALGORITHM_HMAC_SHA2_512, keylen: 512-512
-
-
-The command
-
-    ipsec listpubkeys [--utc]
-
-lists all public keys currently installed in the chained list of public
-keys. These keys were statically loaded from ipsec.conf or aquired either
-from received certificates or retrieved from secure DNS servers using
-opportunistic mode.
-
-The public key listing has the following form:
-
-  Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL,
-         until Sep 09 13:17:25 2009 ok
-         ID_FQDN '@moon.strongswan.org'
-         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial: '03'
-  Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL,
-         until Sep 09 13:17:25 2009 ok
-         ID_DER_ASN1_DN 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org'
-         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial: '03'
-  Feb 11 13:36:53 2005, 2048 RSA Key AwEAAbgbh,
-         until Dec 31 22:43:18 2009 ok
-         ID_USER_FQDN 'carol@strongswan.org'
-         issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial: '0a'
-
-It consists of
-
- - the date the public key was installed either in local time or UTC (--utc)
- - the modulus size of the RSA key in bits
- - a keyID consisting of 9 base64 symbols representing the public exponent
-   and the most significant bits of the modulus
- - the expiration date of the public key (extracted from the certificate)
- - the type and value of the ID associated with the public key.
- - the issuer of the certificate the public key was extracted from.
- - the serial number of the certificate the public key was extracted from.
-
-A public key can be associated with several IDs, e.g. using subjectAltNames
-in certificates and an ID can possess several public keys, e.g. retrieved
-from a secure DNS server.
-
-
-The command
-
-    ipsec listcerts [--utc]
-
-lists all local certificates, both strongSwan's own and those of
-trusted peer loaded via leftcert and rightcert, respectively.
-
-The output has the form
-
-  Feb 11 13:36:47 2005, count: 4
-         subject:  'C=CH, O=Linux strongSwan, CN=moon.strongswan.org'
-         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial:    03
-         pubkey:    2048 RSA Key AwEAAa+uL, has private key
-         validity:  not before Sep 10 13:17:25 2004 ok
-                    not after  Sep 09 13:17:25 2009 ok
-         subjkey:   e5:e4:10:87:6c:2a:c4:be:ad:85:49:42:a6:de:76:58:30:3a:9f:c1
-         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         aserial:   00
-
-and shows
-
- - the date the certificate was installed either in local time or UTC (--utc)
- - the count shows how many connections refer to this certificate
- - the subject of the certificate
- - the issuer of the certificate
- - the serial number of the certificate
- - the size and keyid of the RSA public key contained in the certificate.
-   the label "has private key" indicates that a matching RSA private key
-   has been found, defined or loaded in ipsec.secrets.
- - the label "on smartcard" indicates that the certificate was loaded from
-   a smartcard or cryptotoken and that most probably a matching RSA private
-   key also resides on-card.
- - the validity of the CA certificate expressed either in local time or
-   UTC (--utc). The validity is checked automatically resulting either
-   in an "ok" message or a "fatal" error message.
- - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the certificate's public key.
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the issuer who signed the certificate.
- - the serial number of the issuer's certificate.
-
-
-The command
-
-    ipsec listcacerts [--utc]
-
-lists all CA certificates that have been either been loaded from the directory
-/etc/ipsec.d/cacerts/ or received via the IKE protocol. The output has the form
-
-  Feb 11 13:36:52 2005, count: 1
-         subject:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial:    00
-         pubkey:    2048 RSA Key AwEAAb/yX
-         validity:  not before Sep 10 13:01:45 2004 ok
-                    not after  Sep 08 13:01:45 2014 ok
-         subjkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         aserial:   00
-
-and shows
-
- - the date the CA certificate was installed either in local time or UTC (--utc)
- - the count is always set to 1
- - the subject of the CA certificate
- - the issuer of the CA certificate
- - the serial number of the CA certificate
- - the size and keyid of the RSA public key contained in the certificate.
- - the validity of the CA certificate expressed either in local time or
-   UTC (--utc). The validity is checked automatically resulting either
-   in an "ok" message or a "fatal" error message.
- - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the CA certificate's public key.
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash 
-   over the public key of the issuer who signed the CA certificate.
-   For Root CA certificates the authorityKeyIdentifier and subjectKeyIdentifier
-   fields must be equal.
- - the serial number of the issuer's certificate.
-
-
-The command
-
-    ipsec listaacerts [--utc]
-
-lists all Authorization Authority certificates that have been loaded from
-the directory /etc/ipsec.d/aacerts/.
-The output has the form
-
-  Dec 20 13:29:55 2004, count: 1
-         subject:  'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority'
-         issuer:   'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
-         serial:    0f
-         pubkey:    2048 RSA Key AwEAAfazH
-         validity:  not before Aug 24 13:41:56 2003 ok
-                    not after  Aug 23 13:41:56 2005 ok
-         subjkey:   56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90
-         authkey:   af:80:d5:c6:02:1c:96:78:b3:85:a5:65:a2:23:fd:ad:cf:e2:55:b2
-         aserial:   00
-
-and shows
-
- - the date the AA certificate was installed either in local time or UTC (--utc)
- - the count is always set to 1
- - the subject of the AA certificate
- - the issuer of the AA certificate
- - the serial number of the AA certificate
- - the size and keyid of the RSA public key contained in the certificate.
- - the validity of the AA certificate expressed either in local time or
-   UTC (--utc). The validity is checked automatically resulting either
-   in an "ok" message or a "fatal" error message.
- - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the AA certificate's public key.
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the issuer who signed the AA certificate.
- - the serial number of the issuer's certificate.
-
-
-The command
-
-    ipsec listocspcerts [--utc]
-
-lists all OCSO signer certificates that have been either loaded from
-/etc/ipsec.d/ocspcerts/ or have been received included in the OCSP server
-response. The output has the form
-
-  Feb 09 22:56:17 2005, count: 1
-         subject:  'C=CH, O=Linux strongSwan, OU=OCSP, CN=ocsp.strongswan.org'
-         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         serial:    09
-         pubkey:    2048 RSA Key AwEAAaonT
-         validity:  not before Nov 19 17:29:28 2004 ok
-                    not after  Nov 18 17:29:28 2009 ok
-         subjkey:   88:07:0a:b8:ae:c7:c1:07:5c:be:68:6a:c4:a5:7f:81:1f:37:b5:56
-         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         aserial:   00
-
-and shows
-
- - the date the OCSP signer certificate was installed either in local time
-   or UTC (--utc)
- - the count is always set to 1
- - the subject of the OCSP signer certificate
- - the issuer of the OCSP signer certificate
- - the serial number of the OCSP signer certificate
- - the size and keyid of the RSA public key contained in the certificate.
- - the validity of the OCSP signer certificate expressed either in local time
-   or UTC (--utc). The validity is checked automatically resulting either
-   in an "ok" message or a "fatal" error message.
- - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the OCSP signer certificate's public key.
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the issuer who signed the OCSP certificate.
- - the serial number of the issuer's certificate.
-
-
-The command
-
-    ipsec listacerts [--utc]
-
-lists all X.509 attribute certificates that have been loaded from the directory
-/etc/ipsec.d/acerts/.
-The output has the form
-
-  Dec 20 13:29:56 2004
-         holder:   'C=CH, O=strongSec GmbH, CN=Andreas Steffen'
-         hissuer:  'C=CH, O=strongSec GmbH, CN=strongSec Root CA'
-         hserial:   1e
-         groups:    Research, Sales
-         issuer:   'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority'
-         serial:    2c
-         validity:  not before Dec 19 14:51:38 2004 ok
-                    not after  Dec 20 14:51:38 2004 fatal (expired)
-         authkey:   56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90
-         aserial:   0f
-
-and shows
-
- - the date the attribute certificate was installed either in local time
-   or UTC (--utc)
- - the holder of the attribute certificate
- - the issuer of holder's certificate
- - the serial number of the holder's certificate
- - the group attributes
- - the issuing Authorization Authority of the attribute certificate
- - the serial number of the attribute certificate
- - the validity of the attribute certificate expressed either in local time or
-   UTC (--utc). The validity is checked automatically resulting either
-   in an "ok" message or a "fatal" error message.
- - an authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the issuing Authorization Authority
- - the serial number of the AA certificate.
-
-
-The command
-
-    ipsec listgroups [--utc]
-
-lists all group attributes either defined in right|leftgroups statements
-in ipsec.conf or contained in loaded X.509 attribute certificates.
-The output has the form
-
-  Dec 20 13:29:55 2004, count: 4
-         Research
-  Dec 20 13:30:04 2004, count: 1
-         Research New York
-  Dec 20 13:29:55 2004, count: 3
-         Sales
-
-and shows
-
- - the date the group attribute was first installed either in local time
-   or UTC (--utc)
- - the count shows how many times the attribute is used
- - the group name
-
-
-The command
-
-    ipsec listcainfos [--utc]
-
-lists the properties defined by the ca definition sections in ipsec.conf.
-The output has the form
-
-  Jun 08 22:31:37 2004, "strongswan"
-         authname: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         ldaphost: 'ldap.strongswan.org'
-         ocspuri:  'http://ocsp.strongswan.org:8880'
-         distPts:  'http://crl.strongswan.org/strongswan.crl'
-                   'ldap:///O=Linux strongSwan, C=CH?certificateRevocationList'
-         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         aserial:   00
-
-and shows
-
- - the date the CA definition was loaded either in local time or UTC (--utc)
- - the name of the ca section
- - the distinguished name of the CA
- - an optional default ldap host for the CA
- - an optional OCSP URI
- - a maximum of two optional CRL distribution points
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the CA.
- - the serial number of the CA.
-
-
-The command
-
-    ipsec listcrls [--utc]
-
-lists all CRLs that have been loaded from /etc/ipsec.d/crls/.
-The output has the form
-
-  Feb 11 13:37:00 2005, revoked certs: 1
-         issuer:   'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         distPts:  'http://crl.strongswan.org/strongswan.crl'
-         updates:   this Feb 08 07:46:29 2005
-                    next Mar 10 07:46:29 2005 ok
-         authkey:   5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef 
-         aserial:   00
-
-and shows
-
- - the date the CRL was installed either in local time or UTC (--utc)
- - the number revoked certificates
- - the issuer of the CRL
- - the URLs of the distribution points where the CRL can be fetched from.
- - the dates when the CRL was issued and when the next update
-   is expected, respectively, expressed either in local time or
-   UTC (--utc). It is automatically checked if the next update
-   deadline has passed, resulting either in an "ok" message, a
-   a "warning" message when strictcrlpolicy=no or a "fatal" message when
-   strictcrlpolicy=yes.
- - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash
-   over the public key of the issuer who signed the CRL. This extension is 
-   present in version 2 CRLs, only.
- - the serial number of the issuer's certificate.
-
-
-The command
-
-
-    ipsec listocsp [--utc]
-
-lists the contents of the OCSP response cache. The output has the form
-
-         issuer:  'C=CH, O=Linux strongSwan, CN=strongSwan Root CA'
-         uri:     'http://ocsp.strongswan.org:8880'
-         authname: 13:9d:a0:9e:f4:32:ab:8f:e2:89:56:67:fa:d0:d4:e3:35:86:71:b9
-         authkey:  5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef
-         aserial:  00
-  Feb 09 22:56:17 2005, until Feb 09 23:01:17 2005 warning (expires in 4 minutes)
-         serial:   0a, good
-
-and shows
-
- - the distinguished name of the CA handled by the OCSP server
- - the http URI of the OCSP server.
- - the 20 byte SHA-1 hash of the CA's distinguished name
- - the 20 byte SHA-1 hash of the CA's public key
- - the serial number of the CA's certificate
- - a certificate status list showing
-    - the time the OCSP status was received
-    - an optional nextUpdate deadline (if missing the OCSP status will be
-      onetime with a lifetime of 2 minutes only).
-    - the serial number of the certificate
-    - the status of the certificate (good, revoked, unknown)
-
-
-The command
-
-    ipsec listcards [--utc]
-
-lists all smartcard records that are currently in use by Pluto.
-The output has the form
-
-  Aug 17 16:47:59 2005, #1, count: 6
-         slot:     0, session closed, logged out, has valid pin
-         id:       45
-         label:   'strongSwan'
-         subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org'
-
-with pkcs11keepstate=no and
-
-  Aug 17 16:47:59 2005, #1, count: 6
-         slot:     0, session opened, logged in, has pin pad
-         id:       45
-         label:   'strongSwan'
-         subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org'
-
-with pkcs11keepstate=yes and shows
-
-- the date the certificate was read from the smartcard record
-- the certificate objects are numbered starting from #1
-- the count shows how many connections and secret pin entries point
-  to the smartcard record
-- the PKCS #11 slot number
-- the PKCS #11 session state: closed | opened
-- the PKCS #11 session login state: logged out | logged in
-- the status of the PIN: no pin | valid pin | invalid pin | pin pad
-- the ID of the certificate object
-- the label of the certificate object
-- the subject distinguished name of the certificate
-
-
-The command
-
-    ipsec auto --listall [--utc]
-
-is equivalent to
-
-    ipsec listalgs
-    ipsec listpubkeys [--utc]
-    ipsec listcerts [--utc]
-    ipsec listcacerts [--utc]
-    ipsec listaacerts [--utc]
-    ipsec listocspcerts [--utc]
-    ipsec listacerts [--utc]
-    ipsec listgroups [--utc]
-    ipsec listcainfos [--utc]
-    ipsec listcrls [--utc]
-    ipsec listocsp [--utc]
-    ipsec listcards [--utc]
-
-
-11. Firewall support functions
-    --------------------------
-
-
-11.1 Environment variables in the updown script
-     ------------------------------------------
-
-strongSwan makes the following environment variables available
-in the updown script indicated by the leftupdown option:
-
-+------------------------------------------------------------------+
-| Variable               Example                    Comment        |
-|------------------------------------------------------------------|
-| $PLUTO_PEER_ID         carol@strongswan.org       USER_FQDN  (1) |
-|------------------------------------------------------------------|
-| $PLUTO_PEER_PROTOCOL   17                         udp        (2) |
-|------------------------------------------------------------------|
-| $PLUTO_PEER_PORT       68                         bootpc     (3) |
-|------------------------------------------------------------------|
-| $PLUTO_PEER_CA         C=CH, O=ACME, CN=Sales CA             (4) |
-|------------------------------------------------------------------|
-| $PLUTO_MY_ID           @moon.strongswan.org       FQDN       (1) |
-|------------------------------------------------------------------|
-| $PLUTO_MY_PROTOCOL     17                         udp        (2) |
-|------------------------------------------------------------------|
-| $PLUTO_MY_PORT         67                         bootps     (3) |
-+------------------------------------------------------------------+
-
-(1) $PLUTO_PEER_ID/$PLUTO_MY_ID contain the IDs of the two ends
-    of an established connection. In our examples these
-    correspond to the strings defined by rightid and leftid,
-    respectively.
-
-(2) $PLUTO_PEER_PROTOCOL/$PLUTO_MY_PROTOCOL contain the protocol
-    defined by the rightprotoport and leftprotoport options,
-    respectively. Both variables contain the same protocol value.
-    The variables take on the value '0' if no protocol has been defined.
-
-(3) $PLUTO_PEER_PORT/$PLUTO_MY_PORT contain the ports defined by
-    the rightprotoport and leftprotoport options, respectively.
-    The variables take on the value '0' if no port has been defined.
-
-(4) $PLUTO_PEER_CA contains the distinguished name of the CA that
-    issued the peer's certificate.
-
-
-11.2 Automatic insertion and deletion of iptables firewall rules
-     -----------------------------------------------------------
-
-Starting with strongswan-2.7.0, the default _updown script automatically inserts
-and deletes dynamic iptables firewall rules upon the establishment or teardown,
-respectively, of an IPsec security association. This new feature is activated
-with the line
-
-   leftfirewall=yes
-
-and can be used when the following prerequisites are fulfilled:
-
-  - Linux 2.4.x kernel, KLIPS IPsec stack, and arbitrary iptables version.
-    Filtering of tunneled traffic is based on ipsecN interfaces.
-
-  - Linux 2.6.16 kernel or newer, native NETKEY IPsec stack, and
-    iptables-1.3.5 or newer. Filtering of tunneled traffic is based on
-    IPsec policy matching rules.
-
-If you define a local client subnet with a netmask larger than /32 behind
-the gateway then the automatically inserted FORWARD iptables rules will
-not allow to access the internal IP address of the host although it is
-part of the client subnet definition. If you want additional INPUT and
-OUTPUT iptables rules to be inserted, so that the host itself can be accessed
-then add the following line:
-
-   lefthostaccess=yes
-
-The _updown script also features a logging facility which will register the
-creation (+) and the expiration (-) of each successfully established VPN
-connection in a special syslog file in the following concise and easily
-readable format:
-
-Jul 19 18:58:38 moon vpn:
-    + @carol.strongswan.org  192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16
-Jul 19 22:15:17 moon vpn:
-    - @carol.strongswan.org  192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16
-
-
-11.3 Sample Linux 2.6 updown script for iptables < 1.3.5
-     ---------------------------------------------------
-
-If you are using a Linux 2.6 kernel older than 2.6.16 or an iptables version
-older than 1.3.5 then the IPsec policy matching rules will not be available.
-In order to make sure that only tunneled packets are accepted, a mark can be
-set on incoming ESP packets. This "ESP" mark will be retained on the
-decapsulated packet so that iptables rules inserted by the updown script can
-check on the presence of this mark. For this purpose the template located in
-
-   programs/_updown_espmark
-
-can be used. Store a copy of _updown_espmark e.g. in /etc/ipsec.updown and load
-the script with the line
-
-  leftupdown=/etc/updown.ipsec.
-
-In addition for the dynamic updown script to work the following static iptables rules
-must be applied:
-
-   iptables -t mangle -A INPUT -p 50 -j MARK --set-mark 50
-
-
-12. Authentication with raw RSA public keys
-    ---------------------------------------
-
-FreeS/WAN, as it is available from www.freeswan.org does public key 
-authentication with raw RSA public keys that are directly defined in
-/etc/ipsec.conf
-
-    rightrsasigkey=0sAq4c....
-
-When version 1.x of standard FreeS/WAN receives a certificate request (CR),
-it immediately drops the negotiation because it does not know how to answer
-the request. As a workaround strongSwan does not send a CR if the RSA
-key has been statically loaded using [right/left]rsasigkey. A problem
-remains with roadwarriors initiating a connection. Since strongSwan
-does not know the identity of the initiating peer in advance, it will always
-send a CR, causing the rupture of the IKE negotiation if the peer is a
-version 1.x  FreeS/WAN host. To circumvent this problem the configuration
-parameter 'nocrsend' can be set in the config setup section of /etc/ipsec.conf:
-
-    config setup:
-        nocrsend=yes
-
-With this entry no certificate request is sent in any connection.
-The default setting is nocrsend=no.
-
-
-13. Authentication with OpenPGP certificates
-    ----------------------------------------
-
-strongSwan also supports RSA based authentication using OpenPGP
-certificates and OpenPGP V3 fingerprints used as an KEY_ID identifier.
-
-
-13.1 OpenPGP certificates
-     --------------------
-     
-OpenPGP certificates containing RSA public keys can now directly be loaded
-in ASCII armored PGP format using the leftcert and rightcert parameters
-in /etc/ipsec.conf:
-
-  conn pgp
-       right=%any
-       righcert=peerCert.asc
-       left=%defaultroute
-       leftcert=gatewayCert.asc
-
-The peer certificate must be stored locally (the default directory is
-/etc/ipsec.d/certs) since currently no trust can be established for
-PGP certificates received from a peer via the IKE protocol.
-
-
-13.2 OpenPGP private keys
-     --------------------
-     
-PGP private keys in unencrypted form can now directly be loaded in ASCII
-armored PGP format via an entry in /etc/ipsec.secrets:
-
-  : RSA gatewayKey.asc
-
-Existing IDEA-encrypted RSA private keys can be unlocked with GnuPG and
-the IDEA extension (see http://www.gnupg.org/gph/en/pgp2x.html) using
-the commands
-
-  gpg --import gatewayCert.asc
-
-  gpg --allow-secret-key-import --import gatewayKey.asc
-
-  gpg --edit-key <gateway ID>
-  > passwd                    #change to empty password
-  > save
-
-  gpg -a --export-secret-key <gateway ID> gatewayKey.asc
-
-
-13.3 Monitoring functions
-     --------------------
-
-The command ipsec listcerts shows all loaded PGP certificates
-in the following format:
-
-  Aug 28 09:51:55 2002, count: 1
-         fingerprint:  0x1ccfca12d93467ffa9d5093d87a465dc
-         pubkey:   1024 RSA Key ARHso6uKQ
-         created:  Aug 27 08:51:39 2002
-         until:    --- -- --:--:-- ---- ok (expires never)
-
-The entries are
-
- - the date the certificate was loaded either in local time or UTC (--utc)
- - the V3 fingerprint consisting of the 16 byte MD5 hash of the public key
-   which is used as an ID of type KEY_ID
- - the modulus size of the RSA key in bits
- - a keyID consisting of 9 base64 symbols representing the public exponent
-   and the most significant bits of the modulus
- - the creation date of the public key (extracted from the certificate)
- - the optional expiration date of the public key (extracted from the
-   certificate)
-
-
-13.4 Suppression of certificate request messages
-     -------------------------------------------
-
-PGPnet configured to work with OpenPGP certificates aborts the IKE
-negotiation when it receives a X.509 certificate. Therefore it is recommended
-(mandatory for roadwarrior connections) to set
-
-    config setup:
-        nocrsend=yes
-
-in /etc/ipsec.conf.
-
-
-14. Additional Features
-    -------------------
-
-
-14.1 Authentication and encryption algorithms
-     ----------------------------------------
-
-strongSwan supports the following suite of encryption and authentication
-algorithms for both IKE and ESP payloads.
-
-+------------------------------------------------------------------+
-| IKE algorithms (negotiated in Phase 1 Main Mode)                 |
-+------------------------------------------------------------------+
-| Encryption algorithms:  3des, aes, serpent, twofish, blowfish    |
-|------------------------------------------------------------------|
-| Hash algorithms:        md5, sha, sha2                           |
-|------------------------------------------------------------------|
-| DH groups:              1024, 1536, 2048, 3072, 4096, 6144, 8192 |
-+------------------------------------------------------------------+
-
-NOTE: For IKE the SHA-1 algorithm is denoted by "sha"
-
-The cryptographic IKE algorithms listed above are a fixed part of the
-strongSwan distribution. Particular algorithms can be added or removed
-in the "programs/pluto/alg" directory.
-  
-+------------------------------------------------------------------+
-| ESP algorithms (negotiated in Phase 2 Quick Mode)                |
-+------------------------------------------------------------------+
-| Encryption algorithms:  3des, aes, serpent, twofish, blowfish    |
-|------------------------------------------------------------------|
-| Hash algorithms:        md5, sha1, sha2                          |
-|------------------------------------------------------------------|
-| PFS groups:             1024, 1536, 2048, 3072, 4096, 6144, 8192 |
-+------------------------------------------------------------------+
-
-The cryptographic ESP algorithms listed above are a fixed part of the
-strongSwan distribution. If your Linux 2.4 or 2.6 kernel includes the
-CryptoAPI then additional ESP algorithms can be added or deleted as
-kernel modules.
-
-The IKE and ESP cryptographic algorithms to be proposed to the peer
-as an initiator can be specified on a per connection basis in the form
-
-conn normal
-     ...
-     ike=aes128-sha-modp1536,3des-sha-modp1536
-     esp=aes128-sha1,3des-sha1
-     ...
-
-or if you are more paranoid
-
-conn paranoid
-     ...
-     ike=aes256-sha2_512-modp2048
-     esp=aes256-sha2_512
-     ...
-
-If the the "ike" and "esp" configuration parameters are missing in
-ipsec.conf, then the default settings
-   
-    ike=3des-md5-modp1536,3des-sha-modp1536,\
-        3des-md5-modp1024,3des-sha-modp1024
-    esp=3des-md5,3des-sha1
-
-arre implicitly assumed. The 3DES encryption algorithm and the MD5 and
-SHA-1 hash algorithms are hardcoded into strongSwan and cannot be removed.
-
-If Perfect Forward Secrecy (PFS is desired), then a PFS group can be
-optionally specified:
-
-conn make_sure
-     ...
-     pfs=yes
-     pfsgroup=modp2048,modp1536
-     ...
-
-If the "pfs" parameter is missing then "pfs=yes" is assumed by default.
-This means that PFS must be disabled explicitly by setting "pfs=no".
-
-If the "pfsgroup" parameter is missing then the default is
-
-    pfsgroup=<Phase1 DH group>
-    
-The "ike" and "esp" parameters are used to formulate one or several
-transform proposals to the peer if the strongSwan VPN host is the initiator.
-Attention! As a responder the first proposal from the peer is accepted that
-is supported the by one of the registered algorithms listed by the command
-
-    ipsec listalgs
-    
-If the responder wants to restrict the allowed cipher suites the '!' flag
-can be used to do so. The configuration
-
-conn normal_but_strict
-     ...
-     ike=aes128-sha-modp1536,3des-sha-modp1536!
-     esp=aes128-sha1,3des-sha1!
-     ...
-
-will only permit the listed algorithms defined above but no other methods
-even if they might be supported by the responder.
-
-
-14.2 NAT traversal
-     -------------
-
-Currently please refer to README.NAT-Traversal document in the strongSwan
-distribution.
-     
-     
-14.3 Dead peer detection
-    --------------------
-
-strongSwan implements the RFC 3706 Dead Peer Detection (DPD) keep-alive
-scheme. If an established IPsec SA has been idle (i.e. without any traffic)
-for N seconds (dpddelay=N) then strongSwan side sends a "hello" message
-(R_U_THERE) and the peer replies with an acknowledge message (R_U_THERE_ACK).
-If no response is received, the R_U_THERE messages are repeated until a DPD
-timeout of M seconds (dpdtimeout=M) has elapsed. If still no traffic or 
-R_U_THERE_ACK packets were received, the peer is declared to be dead and all
-SAs belonging to a common Phase 1 SA are deleted.
-
-DPD support is tuneable on a per connection basis by using the dpdaction,
-dpddelay and dpdtimeout directives:
-
-   conn roadwarrior
-       right=%any
-       left=%defaultroute
-       leftsubnet=10.1.0.0/16
-       dpdaction=clear
-
-   conn net-to-net
-       right=192.168.0.2
-       rightsubnet=10.2.0.0/16
-       left=%defaultroute
-       leftsubnet=10.1.0.0/16
-       dpdaction=hold
-       dpddelay=60
-       dpdtimeout=500
-
-In the first example dpdaction=clear activates the DPD mechanism under the
-condition that the peer supports RFC 3706. The values dpddelay=30s and
-dpdtimeout=120s are assumed by default in the absence of these parameters, so
-that during idle periods an R_U_THERE packet is sent every 30 seconds. If no
-traffic or a no R_U_THERE_ACK packet is received from the peer within a
-120 second time span, the peer will be declared dead and all SAs and associated
-eroutes will be cleared.
-
-In the second example R_U_THERE packets are sent every 60 seconds and the
-parameter setting dpdaction=hold will put the eroute of the ruptured connection
-into a %trap state, so that when new outgoing traffic will occur, the
-correspondig connection will be automatically renegotiated as soon as the
-peer is up again.
-
-It is recommended to use dpdaction=hold for statically defined connections and
-dpdaction=clear for dynamic roadwarrior connections. The default value is
-dpdaction=none, which disables DPD.
-
-
-14.4 IKE Mode Config
-     ---------------
-     
-The IKE Mode Config protocol <draft-ietf-ipsec-isakmp-mode-cfg-04.txt> allows
-the dynamic assignment of virtual IP addresses and optional DNS and WINS server
-information to IPsec clients. Currently only "Mode Config Pull Mode" is
-implemented where the client actively sends a Mode Config request to the server
-in order to obtain a virtual IP.
-
-Client side configuration (carol):
-
-  conn home
-       right=192.168.0.1
-       rightsubnet=10.1.0.0/16
-       rightid=@moon.strongswan.org
-       left=%defaultroute
-       leftsourceip=%modeconfig
-       leftcert=carolCert.pem
-       leftid=carol@strongswan.org
-       auto=start
-
-Server side configuration (moon):
-
-  conn roadwarrior
-       right=%any
-       rightid=carol@strongswan.org
-       rightsourceip=10.3.0.1
-       left=%defaultroute
-       leftsubnet=10.1.0.0/16
-       leftcert=moonCert.pem
-       leftid=@moon.strongswan.org
-       auto=add
-
-The wildcard %modeconfig or %modecfg used in the leftsourceip parameter of the
-client will trigger a Mode Config request. Currently the server will return
-the virtual IP address defined by the rightsourceip parameter. In the future
-an LDAP-based lookup mechanism will be supported.
-
-
-15. Copyright statement and acknowledgements
-    ----------------------------------------
-
-
-                    FreeS/WAN version base system:
-
-                       Copyright (c) 1999-2004
-                    Henry Spencer, Richard Guy Briggs,
-           D. Hugh Redelmeier, Sandy Harris, Claudia Schmeing,
-        Michael Richardson, Angelos D. Keromytis, John Ioannidis,
-
-     NAT-Traversal, ipsec starter, Delete SA and Notification messages:
-
-                Copyright (c) 2002-2003, Mathieu Lafon
-
-                Additional cryptoalgorithms (AES, etc):
-
-               Copyright (c) 2002-2003, JuanJo Ciarlante
-               
-                        Dead Peer Detection:
-
-                        Copyright (c) 2002-2004
-               Ken Bantoft, JuanJo Ciarlante, Philip Craig,
-                 Pawel Krawczyk, Srinvasan Venkataraman
-
-                     Porting to Linux 2.6 kernel:
-
-                    Copyright (c) 2003, Herbert Xu
-
-                         Dynamic CRL fetching:
-
-                  Copyright (c) 2002, Stephane Laroche
-
-                       IKE Mode Config protocol:
-
-                  Copyright (c) 2001-2002, Colubris Networks
-
-                       Virtual IP and source routing: 
-
-                    Copyright (c) 2003, Tuomo Soini
-
-             Port and protocol selectors for outbound traffic:
-
-                  Copyright (c) 2002, Stephen J. Bevan
-
-                         PGPnet-RSA parts of patch:
-
-                      Copyright (c) 2000, Kai Martius
-
-                  X.509, OCSP and smartcard functionality:
-
-  Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann
-  Copyright (c) 2001, Marco Bertossa, Andreas Schleiss
-  Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser
-  Copyright (c) 2002, Martin Berner, Lukas Suter
-  Copyright (c) 2003, Christoph Gysin, Simon Zwahlen
-  Copyright (c) 2004, David Buechi, Michael Meier
-  Copyright (c) 2000-2005, Andreas Steffen
-
-      Zurich University of Applied Sciences in Winterthur, Switzerland
-
-                               scepclient:
-
-               Copyright (c) 2005, Jan Hutter, Martin Willi
-               Copyright (c) 2005-2006, Andreas Steffen
-
-        University of Applied Sciences in Rapperswil, Switzerland
-
-  This program is free software; you can redistribute it and/or modify
-  it under the terms of the GNU General Public License as published by
-  the Free Software Foundation; either version 2 of the License, or
-  (at your option) any later version. See http://www.fsf.org/copyleft/gpl.txt.
-
-  This program is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-  or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-  for more details.
------------------------------------------------------------------------------
-
-This file is RCSID $Id: README,v 1.33 2006/04/24 21:27:49 as Exp $
-
diff --git a/configure.in b/configure.in
new file mode 100644 (file)
index 0000000..21a5e6e
--- /dev/null
@@ -0,0 +1,139 @@
+dnl  configure.in for linux strongSwan
+dnl  Copyright (C) 2006 Martin Willi
+dnl  Hochschule fuer Technik Rapperswil
+dnl 
+dnl  This program is free software; you can redistribute it and/or modify it
+dnl  under the terms of the GNU General Public License as published by the
+dnl  Free Software Foundation; either version 2 of the License, or (at your
+dnl  option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
+dnl 
+dnl  This program is distributed in the hope that it will be useful, but
+dnl  WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+dnl  or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+dnl  for more details.
+
+dnl ===========================
+dnl  initialize & set some vars
+dnl ===========================
+
+AC_INIT(strongSwan,4.0.0)
+AM_INIT_AUTOMAKE
+AC_C_BIGENDIAN
+AC_SUBST(ipsecdir, '${libexecdir}/ipsec')
+AC_SUBST(confdir, '${sysconfdir}')
+AC_SUBST(piddir, '/var/run')
+
+dnl ===========================
+dnl  check --enable-xxx params
+dnl ===========================
+
+AC_ARG_ENABLE(
+    [http],
+    AS_HELP_STRING([--enable-http],[enable OCSP and fetching of Certificates and CRLs over HTTP (default is NO). Requires libcurl.]),
+    http=true
+    AC_DEFINE(LIBCURL)
+)
+AM_CONDITIONAL(USE_LIBCURL, test x$http = xtrue)
+
+AC_ARG_ENABLE(
+    [ldap],
+    AS_HELP_STRING([--enable-ldap],[enable fetching of CRLs from LDAP (default is NO). Requires openldap. \
+                                    Protocol version 2 or 3 are supported, use --with-ldap=version to specify \
+                                    explicitly.]),
+    ldap=true
+    [case "${enableval}" in
+        2) AC_DEFINE(LDAP_VER, 2) ;;
+        3) AC_DEFINE(LDAP_VER, 3) ;;
+        *) AC_MSG_ERROR([Invalid LDAP protocol version specified!]) ;;
+        esac
+    ]
+)
+AM_CONDITIONAL(USE_LDAP, test x$ldap = xtrue)
+
+AC_ARG_ENABLE(
+    [pkcs11],
+    AS_HELP_STRING([--enable-pkcs11],[enable PKCS11 smartcard support (default is NO). \
+                                      Set the default PKCS11 library using \
+                                      --enable-pkcs11=/path/to/default-pkcs11.so]),
+    smartcard=true
+    AC_DEFINE(SMARTCARD)
+    AC_DEFINE(PKCS11_DEFAULT_LIB, ${enableval})
+)
+AM_CONDITIONAL(USE_SMARTCARD, test x$smartcard = xtrue)
+
+AC_ARG_ENABLE(
+    [leak-detective],
+    AS_HELP_STRING([--enable-leak-detective],[enable malloc hooks to find memory leaks (default is NO).]),
+    leak_detective=true
+    AC_DEFINE(USE_LEAK_DETECTIVE)
+)
+AM_CONDITIONAL(USE_LEAK_DETECTIVE, test x$leak_detective = xtrue)
+
+dnl =========================
+dnl  check required programs
+dnl =========================
+
+AC_PROG_INSTALL
+AC_PROG_LIBTOOL
+AC_PROG_LEX
+AC_PROG_YACC
+AC_PROG_CC(intel)
+
+dnl ==========================
+dnl  check required libraries
+dnl ==========================
+
+AC_HAVE_LIBRARY([gmp],,[AC_MSG_ERROR([GNU Multi Precision library gmp not found])])    
+if test "$ldap" = "true"; then
+    AC_HAVE_LIBRARY([ldap],,[AC_MSG_ERROR([LDAP enabled, but library ldap not found])])
+    AC_HAVE_LIBRARY([lber],,[AC_MSG_ERROR([LDAP enabled, but library lber not found])])
+fi
+if test "$http" = "true"; then
+    AC_HAVE_LIBRARY([curl],,[AC_MSG_ERROR([HTTP enabled, but library curl not found])])
+fi
+
+
+dnl =============================
+dnl  check required header files
+dnl =============================
+
+
+AC_MSG_CHECKING([gmp.h version >= 4.1.4])
+AC_TRY_COMPILE(
+    [#include "gmp.h"],
+    [
+        #if (__GNU_MP_VERSION*100 +  __GNU_MP_VERSION_MINOR*10 + __GNU_MP_VERSION_PATCHLEVEL) < 414
+            #error bad gmp
+        #endif
+    ], 
+    [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); AC_MSG_ERROR([No usable gmp.h found!])]
+)
+if test "$ldap" = "true"; then
+    AC_CHECK_HEADER([ldap.h],,[AC_MSG_ERROR([LDAP enabled, but ldap.h not found!])])
+fi
+if test "$http" = "true"; then
+    AC_CHECK_HEADER([curl/curl.h],,[AC_MSG_ERROR([HTTP enabled, but curl.h not found!])])
+fi
+
+dnl ==============================
+dnl  build Makefiles
+dnl ==============================
+
+AC_OUTPUT(
+       Makefile
+       src/Makefile
+       src/libstrongswan/Makefile
+       src/libcrypto/Makefile
+       src/libfreeswan/Makefile
+       src/pluto/Makefile
+       src/whack/Makefile
+       src/charon/Makefile
+       src/stroke/Makefile
+       src/ipsec/Makefile
+       src/starter/Makefile
+       src/_updown/Makefile
+       src/_updown_espmark/Makefile
+       src/_copyright/Makefile
+       src/openac/Makefile
+       src/scepclient/Makefile
+)
diff --git a/src/Makefile b/src/Makefile
deleted file mode 100644 (file)
index 790756b..0000000
+++ /dev/null
@@ -1,465 +0,0 @@
-# Makefile.in generated by automake 1.9.6 from Makefile.am.
-# src/Makefile.  Generated from Makefile.in by configure.
-
-# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005  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.
-
-
-srcdir = .
-top_srcdir = ..
-
-pkgdatadir = $(datadir)/strongSwan
-pkglibdir = $(libdir)/strongSwan
-pkgincludedir = $(includedir)/strongSwan
-top_builddir = ..
-am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
-INSTALL = /usr/bin/install -c
-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 = i686-pc-linux-gnu
-host_triplet = i686-pc-linux-gnu
-subdir = src
-DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in
-ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/configure.in
-am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
-       $(ACLOCAL_M4)
-mkinstalldirs = $(install_sh) -d
-CONFIG_CLEAN_FILES =
-SOURCES =
-DIST_SOURCES =
-RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
-       html-recursive info-recursive install-data-recursive \
-       install-exec-recursive install-info-recursive \
-       install-recursive installcheck-recursive installdirs-recursive \
-       pdf-recursive ps-recursive uninstall-info-recursive \
-       uninstall-recursive
-ETAGS = etags
-CTAGS = ctags
-DIST_SUBDIRS = $(SUBDIRS)
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-ACLOCAL = ${SHELL} /home/mwilli/strongswan/trunk/missing --run aclocal-1.9
-AMDEP_FALSE = #
-AMDEP_TRUE = 
-AMTAR = ${SHELL} /home/mwilli/strongswan/trunk/missing --run tar
-AR = ar
-AUTOCONF = ${SHELL} /home/mwilli/strongswan/trunk/missing --run autoconf
-AUTOHEADER = ${SHELL} /home/mwilli/strongswan/trunk/missing --run autoheader
-AUTOMAKE = ${SHELL} /home/mwilli/strongswan/trunk/missing --run automake-1.9
-AWK = gawk
-CC = gcc
-CCDEPMODE = depmode=gcc3
-CFLAGS = -g -O2
-CPP = gcc -E
-CPPFLAGS = 
-CXX = g++
-CXXCPP = g++ -E
-CXXDEPMODE = depmode=gcc3
-CXXFLAGS = -g -O2
-CYGPATH_W = echo
-DEFS = -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"strongSwan\" -DVERSION=\"4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DEPDIR = .deps
-ECHO = echo
-ECHO_C = 
-ECHO_N = -n
-ECHO_T = 
-EGREP = grep -E
-EXEEXT = 
-F77 = 
-FFLAGS = 
-INSTALL_DATA = ${INSTALL} -m 644
-INSTALL_PROGRAM = ${INSTALL}
-INSTALL_SCRIPT = ${INSTALL}
-INSTALL_STRIP_PROGRAM = ${SHELL} $(install_sh) -c -s
-LDFLAGS = 
-LIBOBJS = 
-LIBS = 
-LIBTOOL = $(SHELL) $(top_builddir)/libtool
-LN_S = ln -s
-LTLIBOBJS = 
-MAKEINFO = ${SHELL} /home/mwilli/strongswan/trunk/missing --run makeinfo
-OBJEXT = o
-PACKAGE = strongSwan
-PACKAGE_BUGREPORT = 
-PACKAGE_NAME = 
-PACKAGE_STRING = 
-PACKAGE_TARNAME = 
-PACKAGE_VERSION = 
-PATH_SEPARATOR = :
-RANLIB = ranlib
-SET_MAKE = 
-SHELL = /bin/sh
-STRIP = strip
-VERSION = 4.0
-ac_ct_AR = ar
-ac_ct_CC = gcc
-ac_ct_CXX = g++
-ac_ct_F77 = 
-ac_ct_RANLIB = ranlib
-ac_ct_STRIP = strip
-am__fastdepCC_FALSE = #
-am__fastdepCC_TRUE = 
-am__fastdepCXX_FALSE = #
-am__fastdepCXX_TRUE = 
-am__include = include
-am__leading_dot = .
-am__quote = 
-am__tar = ${AMTAR} chof - "$$tardir"
-am__untar = ${AMTAR} xf -
-bindir = ${exec_prefix}/bin
-build = i686-pc-linux-gnu
-build_alias = 
-build_cpu = i686
-build_os = linux-gnu
-build_vendor = pc
-datadir = ${prefix}/share
-exec_prefix = ${prefix}
-host = i686-pc-linux-gnu
-host_alias = 
-host_cpu = i686
-host_os = linux-gnu
-host_vendor = pc
-includedir = ${prefix}/include
-infodir = ${prefix}/info
-install_sh = /home/mwilli/strongswan/trunk/install-sh
-libdir = ${exec_prefix}/lib
-libexecdir = ${exec_prefix}/libexec
-localstatedir = ${prefix}/var
-mandir = ${prefix}/man
-mkdir_p = mkdir -p --
-oldincludedir = /usr/include
-prefix = /usr/local
-program_transform_name = s,x,x,
-sbindir = ${exec_prefix}/sbin
-sharedstatedir = ${prefix}/com
-sysconfdir = ${prefix}/etc
-target_alias = 
-SUBDIRS = libstrongswan stroke charon whack
-all: all-recursive
-
-.SUFFIXES:
-$(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 \
-               && exit 0; \
-             exit 1;; \
-         esac; \
-       done; \
-       echo ' cd $(top_srcdir) && $(AUTOMAKE) --gnu  src/Makefile'; \
-       cd $(top_srcdir) && \
-         $(AUTOMAKE) --gnu  src/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
-
-mostlyclean-libtool:
-       -rm -f *.lo
-
-clean-libtool:
-       -rm -rf .libs _libs
-
-distclean-libtool:
-       -rm -f libtool
-uninstall-info-am:
-
-# This directory's subdirectories are mostly independent; you can cd
-# into them and run `make' without going through this Makefile.
-# To change the values of `make' variables: instead of editing Makefiles,
-# (1) if the variable is set in `config.status', edit `config.status'
-#     (which will cause the Makefiles to be regenerated when you run `make');
-# (2) otherwise, pass the desired values on the `make' command line.
-$(RECURSIVE_TARGETS):
-       @failcom='exit 1'; \
-       for f in x $$MAKEFLAGS; do \
-         case $$f in \
-           *=* | --[!k]*);; \
-           *k*) failcom='fail=yes';; \
-         esac; \
-       done; \
-       dot_seen=no; \
-       target=`echo $@ | sed s/-recursive//`; \
-       list='$(SUBDIRS)'; for subdir in $$list; do \
-         echo "Making $$target in $$subdir"; \
-         if test "$$subdir" = "."; then \
-           dot_seen=yes; \
-           local_target="$$target-am"; \
-         else \
-           local_target="$$target"; \
-         fi; \
-         (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
-         || eval $$failcom; \
-       done; \
-       if test "$$dot_seen" = "no"; then \
-         $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
-       fi; test -z "$$fail"
-
-mostlyclean-recursive clean-recursive distclean-recursive \
-maintainer-clean-recursive:
-       @failcom='exit 1'; \
-       for f in x $$MAKEFLAGS; do \
-         case $$f in \
-           *=* | --[!k]*);; \
-           *k*) failcom='fail=yes';; \
-         esac; \
-       done; \
-       dot_seen=no; \
-       case "$@" in \
-         distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
-         *) list='$(SUBDIRS)' ;; \
-       esac; \
-       rev=''; for subdir in $$list; do \
-         if test "$$subdir" = "."; then :; else \
-           rev="$$subdir $$rev"; \
-         fi; \
-       done; \
-       rev="$$rev ."; \
-       target=`echo $@ | sed s/-recursive//`; \
-       for subdir in $$rev; do \
-         echo "Making $$target in $$subdir"; \
-         if test "$$subdir" = "."; then \
-           local_target="$$target-am"; \
-         else \
-           local_target="$$target"; \
-         fi; \
-         (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
-         || eval $$failcom; \
-       done && test -z "$$fail"
-tags-recursive:
-       list='$(SUBDIRS)'; for subdir in $$list; do \
-         test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
-       done
-ctags-recursive:
-       list='$(SUBDIRS)'; for subdir in $$list; do \
-         test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
-       done
-
-ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
-       list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
-       unique=`for i in $$list; do \
-           if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
-         done | \
-         $(AWK) '    { files[$$0] = 1; } \
-              END { for (i in files) print i; }'`; \
-       mkid -fID $$unique
-tags: TAGS
-
-TAGS: tags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
-               $(TAGS_FILES) $(LISP)
-       tags=; \
-       here=`pwd`; \
-       if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
-         include_option=--etags-include; \
-         empty_fix=.; \
-       else \
-         include_option=--include; \
-         empty_fix=; \
-       fi; \
-       list='$(SUBDIRS)'; for subdir in $$list; do \
-         if test "$$subdir" = .; then :; else \
-           test ! -f $$subdir/TAGS || \
-             tags="$$tags $$include_option=$$here/$$subdir/TAGS"; \
-         fi; \
-       done; \
-       list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
-       unique=`for i in $$list; do \
-           if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
-         done | \
-         $(AWK) '    { files[$$0] = 1; } \
-              END { for (i in files) print i; }'`; \
-       if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
-         test -n "$$unique" || unique=$$empty_fix; \
-         $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
-           $$tags $$unique; \
-       fi
-ctags: CTAGS
-CTAGS: ctags-recursive $(HEADERS) $(SOURCES)  $(TAGS_DEPENDENCIES) \
-               $(TAGS_FILES) $(LISP)
-       tags=; \
-       here=`pwd`; \
-       list='$(SOURCES) $(HEADERS)  $(LISP) $(TAGS_FILES)'; \
-       unique=`for i in $$list; do \
-           if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
-         done | \
-         $(AWK) '    { files[$$0] = 1; } \
-              END { for (i in files) print i; }'`; \
-       test -z "$(CTAGS_ARGS)$$tags$$unique" \
-         || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
-            $$tags $$unique
-
-GTAGS:
-       here=`$(am__cd) $(top_builddir) && pwd` \
-         && cd $(top_srcdir) \
-         && gtags -i $(GTAGS_ARGS) $$here
-
-distclean-tags:
-       -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
-
-distdir: $(DISTFILES)
-       @srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
-       topsrcdirstrip=`echo "$(top_srcdir)" | sed 's|.|.|g'`; \
-       list='$(DISTFILES)'; for file in $$list; do \
-         case $$file in \
-           $(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
-           $(top_srcdir)/*) file=`echo "$$file" | sed "s|^$$topsrcdirstrip/|$(top_builddir)/|"`;; \
-         esac; \
-         if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
-         dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
-         if test "$$dir" != "$$file" && test "$$dir" != "."; then \
-           dir="/$$dir"; \
-           $(mkdir_p) "$(distdir)$$dir"; \
-         else \
-           dir=''; \
-         fi; \
-         if test -d $$d/$$file; then \
-           if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
-             cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
-           fi; \
-           cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
-         else \
-           test -f $(distdir)/$$file \
-           || cp -p $$d/$$file $(distdir)/$$file \
-           || exit 1; \
-         fi; \
-       done
-       list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
-         if test "$$subdir" = .; then :; else \
-           test -d "$(distdir)/$$subdir" \
-           || $(mkdir_p) "$(distdir)/$$subdir" \
-           || exit 1; \
-           distdir=`$(am__cd) $(distdir) && pwd`; \
-           top_distdir=`$(am__cd) $(top_distdir) && pwd`; \
-           (cd $$subdir && \
-             $(MAKE) $(AM_MAKEFLAGS) \
-               top_distdir="$$top_distdir" \
-               distdir="$$distdir/$$subdir" \
-               distdir) \
-             || exit 1; \
-         fi; \
-       done
-check-am: all-am
-check: check-recursive
-all-am: Makefile
-installdirs: installdirs-recursive
-installdirs-am:
-install: install-recursive
-install-exec: install-exec-recursive
-install-data: install-data-recursive
-uninstall: uninstall-recursive
-
-install-am: all-am
-       @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
-
-installcheck: installcheck-recursive
-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:
-
-distclean-generic:
-       -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_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-recursive
-
-clean-am: clean-generic clean-libtool mostlyclean-am
-
-distclean: distclean-recursive
-       -rm -f Makefile
-distclean-am: clean-am distclean-generic distclean-libtool \
-       distclean-tags
-
-dvi: dvi-recursive
-
-dvi-am:
-
-html: html-recursive
-
-info: info-recursive
-
-info-am:
-
-install-data-am:
-
-install-exec-am:
-
-install-info: install-info-recursive
-
-install-man:
-
-installcheck-am:
-
-maintainer-clean: maintainer-clean-recursive
-       -rm -f Makefile
-maintainer-clean-am: distclean-am maintainer-clean-generic
-
-mostlyclean: mostlyclean-recursive
-
-mostlyclean-am: mostlyclean-generic mostlyclean-libtool
-
-pdf: pdf-recursive
-
-pdf-am:
-
-ps: ps-recursive
-
-ps-am:
-
-uninstall-am: uninstall-info-am
-
-uninstall-info: uninstall-info-recursive
-
-.PHONY: $(RECURSIVE_TARGETS) CTAGS GTAGS all all-am check check-am \
-       clean clean-generic clean-libtool clean-recursive ctags \
-       ctags-recursive distclean distclean-generic distclean-libtool \
-       distclean-recursive distclean-tags distdir dvi dvi-am html \
-       html-am info info-am install install-am install-data \
-       install-data-am install-exec install-exec-am install-info \
-       install-info-am install-man install-strip installcheck \
-       installcheck-am installdirs installdirs-am maintainer-clean \
-       maintainer-clean-generic maintainer-clean-recursive \
-       mostlyclean mostlyclean-generic mostlyclean-libtool \
-       mostlyclean-recursive pdf pdf-am ps ps-am tags tags-recursive \
-       uninstall uninstall-am uninstall-info-am
-
-# 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/src/Makefile.am b/src/Makefile.am
new file mode 100644 (file)
index 0000000..a3f90f3
--- /dev/null
@@ -0,0 +1 @@
+SUBDIRS = libfreeswan libcrypto libstrongswan pluto whack charon stroke starter openac scepclient ipsec _updown _updown_espmark _copyright 
diff --git a/src/Makefile.program b/src/Makefile.program
deleted file mode 100644 (file)
index bfb01e5..0000000
+++ /dev/null
@@ -1,144 +0,0 @@
-
-include ${FREESWANSRCDIR}/Makefile.ver
-
-CFLAGS+=$(USERCOMPILE) -I${KLIPSINC}
-
-CFLAGS+= -Wall
-CFLAGS+= -Wpointer-arith
-CFLAGS+= -Wcast-qual
-CFLAGS+= -Wstrict-prototypes
-CFLAGS+= -Wbad-function-cast 
-
-# die if there are any warnings
-ifndef WERROR
-WERROR:= -Werror
-endif
-
-#CFLAGS+= ${WERROR}
-
-ifneq ($(LD_LIBRARY_PATH),)
-LDFLAGS=-L$(LD_LIBRARY_PATH)
-endif
-
-MANDIR8=$(MANTREE)/man8
-MANDIR5=$(MANTREE)/man5
-
-ifndef PROGRAMDIR
-PROGRAMDIR=${LIBEXECDIR}
-endif
-
-ifndef MANPROGPREFIX
-MANPROGPREFIX=ipsec_
-endif
-
-ifndef CONFDSUBDIR
-CONFDSUBDIR=.
-endif
-
-all: $(PROGRAM)
-
-programs: all
-
-ifneq ($(PROGRAM),check)
-check: $(PROGRAM)
-endif
-
-
-ifneq ($(NOINSTALL),true)
-
-install:: $(PROGRAM) $(CONFFILES) $(EXTRA8MAN) $(EXTRA5MAN) $(EXTRA5PROC) $(LIBFILES) $(CONFDFILES)
-       @mkdir -p $(PROGRAMDIR) $(MANDIR8) $(MANDIR5) $(LIBDIR) $(CONFDIR) $(CONFDDIR) $(CONFDDIR)/$(CONFDSUBDIR) $(EXAMPLECONFDIR)
-       @if [ -n "$(PROGRAM)" ]; then $(INSTALL) $(INSTBINFLAGS) $(PROGRAM) $(PROGRAMDIR); fi
-       @$(foreach f, $(addsuffix .8, $(PROGRAM)), \
-               $(INSTALL) $(INSTMANFLAGS) $f $(MANDIR8)/$(MANPROGPREFIX)$f || exit 1; \
-       )
-       @$(foreach f, $(EXTRA8MAN), \
-               $(INSTALL) $(INSTMANFLAGS) $f $(MANDIR8)/ipsec_$f || exit 1; \
-       )
-       @$(foreach f, $(EXTRA5MAN), \
-               $(INSTALL) $(INSTMANFLAGS) $f $(MANDIR5)/$f || exit 1 ;\
-       )
-       @$(foreach f, $(EXTRA5PROC), \
-               $(INSTALL) $(INSTMANFLAGS) $f $(MANDIR5)/ipsec_$f || exit 1 ;\
-       )
-       @$(foreach f, $(LIBFILES), \
-               $(INSTALL) $(INSTCONFFLAGS) $f $(LIBDIR)/$f || exit 1 ;\
-       )
-       @$(foreach f, $(CONFFILES), \
-               if [ ! -f $(CONFDIR)/$f ]; then $(INSTALL) $(INSTCONFFLAGS) $f $(CONFDIR)/$f || exit 1; fi;\
-               $(INSTALL) $(INSTCONFFLAGS) $f $(EXAMPLECONFDIR)/$f-sample || exit 1; \
-       )
-       @$(foreach f, $(CONFDFILES), \
-               if [ ! -f $(CONFDDIR)/$(CONFDSUBDIR)/$f ]; then $(INSTALL) $(INSTCONFFLAGS) $f $(CONFDDIR)/$(CONFDSUBDIR)/$f || exit 1; fi;\
-       )
-
-install_file_list::
-       @if [ -n "$(PROGRAM)" ]; then echo $(PROGRAMDIR)/$(PROGRAM); fi
-       @$(foreach f, $(addsuffix .8, $(PROGRAM)), \
-               echo $(MANDIR8)/${MANPROGPREFIX}$f; \
-       )
-       @$(foreach f, $(EXTRA8MAN), \
-               echo $(MANDIR8)/ipsec_$f; \
-       )
-       @$(foreach f, $(EXTRA5MAN), \
-               echo $(MANDIR5)/$f;\
-       )
-       @$(foreach f, $(EXTRA5PROC), \
-               echo $(MANDIR5)/ipsec_$f; \
-       )
-       @$(foreach f, $(LIBFILES), \
-               echo $(LIBDIR)/$f;\
-       )
-       @$(foreach f, $(CONFFILES), \
-               echo $(CONFDIR)/$f;\
-               echo $(EXAMPLECONFDIR)/$f-sample;\
-       )
-       @$(foreach f, $(CONFDFILES), \
-               echo $(CONFDDIR)/${CONFDSUBDIR}/$f;\
-       )
-
-endif
-
-# cancel the rule that compiles directly
-%: %.c 
-
-%: %.o $(OBJS)
-       $(CC) $(CFLAGS) -o $@ $@.o ${OBJS} $(LDFLAGS) $(LIBS)
-
-%: %.in ${FREESWANSRCDIR}/Makefile.inc ${FREESWANSRCDIR}/Makefile.ver
-       cat $< | sed -e "s/xxx/$(IPSECVERSION)/" \
-                       -e "s:@IPSEC_DIR@:$(FINALBINDIR):" \
-                       -e "s:@IPSEC_EXECDIR@:$(FINALLIBEXECDIR):" \
-                       -e "s:@IPSEC_SBINDIR@:$(FINALSBINDIR):" \
-                       -e "s:@IPSEC_LIBDIR@:$(FINALLIBDIR):" \
-                       -e "s:@FINALCONFDIR@:$(FINALCONFDIR):" \
-                       -e "s:@EXAMPLECONFDIR@:$(EXAMPLECONFDIR):" \
-                       -e "s:@FINALDOCDIR@:$(FINALDOCDIR):" \
-                       -e "s:@FINALEXAMPLECONFDIR@:$(FINALEXAMPLECONFDIR):" \
-                       -e "s:@MODULE_GOO_LIST@:$(MODULE_GOO_LIST):" \
-                       -e "s:@IPSEC_CONFS@:$(FINALCONFDIR):" \
-                       -e "s:@IPSEC_CONFDDIR@:$(FINALCONFDDIR):" \
-                       -e "s:@USE_IPROUTE2@:$(USE_IPROUTE2):" \
-                       -e "s:@IPSEC_FIREWALLTYPE@:$(IPSEC_FIREWALLTYPE):" \
-       | cat >$@
-       if [ -x $< ]; then chmod +x $@; fi
-       if [ "${PROGRAM}.in" = $< ]; then chmod +x $@; fi
-
-cleanall: clean
-
-distclean: clean
-
-mostlyclean: clean
-
-realclean: clean
-
-clean::
-ifneq ($(strip $(PROGRAM)),)
-       @if [ -r $(PROGRAM).in ]; then rm -f $(PROGRAM); fi
-       @if [ -r $(PROGRAM).c ];  then rm -f $(PROGRAM); fi
-       @if [ -n "$(OBJS)" ];     then rm -f $(PROGRAM); fi
-endif
-       @rm -f *.o
-
-checkprograms:
-
diff --git a/src/_copyright/Makefile b/src/_copyright/Makefile
deleted file mode 100644 (file)
index 52c594b..0000000
+++ /dev/null
@@ -1,44 +0,0 @@
-# Makefile for miscelaneous programs
-# Copyright (C) 2002  Michael Richardson       <mcr@freeswan.org>
-# 
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2 of the License, or (at your
-# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# RCSID $Id: Makefile,v 1.1 2004/03/15 20:35:27 as Exp $
-
-FREESWANSRCDIR=../..
-include ${FREESWANSRCDIR}/Makefile.inc
-
-PROGRAM=_copyright
-PROGRAMDIR=${LIBDIR}
-LIBS=${FREESWANLIB}
-
-include ../Makefile.program
-
-#
-# $Log: Makefile,v $
-# Revision 1.1  2004/03/15 20:35:27  as
-# added files from freeswan-2.04-x509-1.5.3
-#
-# Revision 1.3  2002/08/02 16:01:07  mcr
-#      moved user visible programs to $PREFIX/libexec, while moving
-#      private files to $PREFIX/lib.
-#
-# Revision 1.2  2002/06/02 22:02:14  mcr
-#      changed TOPDIR->FREESWANSRCDIR in all Makefiles.
-#      (note that linux/net/ipsec/Makefile uses TOPDIR because this is the
-#      kernel sense.)
-#
-# Revision 1.1  2002/04/24 07:55:32  mcr
-#      #include patches and Makefiles for post-reorg compilation.
-#
-#
-#
-
diff --git a/src/_copyright/Makefile.am b/src/_copyright/Makefile.am
new file mode 100644 (file)
index 0000000..d8dcfb3
--- /dev/null
@@ -0,0 +1,6 @@
+ipsec_PROGRAMS = _copyright
+_copyright_SOURCES = _copyright.c
+dist_man8_MANS = _copyright.8
+
+INCLUDES = -I$(top_srcdir)/src/libfreeswan
+_copyright_LDADD = $(top_srcdir)/src/libfreeswan/libfreeswan.a
diff --git a/src/_updown/Makefile b/src/_updown/Makefile
deleted file mode 100644 (file)
index e0aaab4..0000000
+++ /dev/null
@@ -1,22 +0,0 @@
-# Makefile for miscelaneous programs
-# Copyright (C) 2002  Michael Richardson       <mcr@freeswan.org>
-# 
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2 of the License, or (at your
-# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# RCSID $Id: Makefile,v 1.3 2006/04/17 06:48:49 as Exp $
-
-FREESWANSRCDIR=../..
-include ${FREESWANSRCDIR}/Makefile.inc
-
-PROGRAM=_updown
-PROGRAMDIR=${LIBDIR}
-
-include ../Makefile.program
diff --git a/src/_updown/Makefile.am b/src/_updown/Makefile.am
new file mode 100644 (file)
index 0000000..27a467c
--- /dev/null
@@ -0,0 +1,3 @@
+dist_ipsec_SCRIPTS = _updown
+dist_man8_MANS = _updown.8
+
diff --git a/src/_updown/_updown b/src/_updown/_updown
new file mode 100755 (executable)
index 0000000..8db74f7
--- /dev/null
@@ -0,0 +1,503 @@
+#! /bin/sh
+# iproute2 version, default updown script
+#
+# Copyright (C) 2003-2004 Nigel Meteringham
+# Copyright (C) 2003-2004 Tuomo Soini
+# Copyright (C) 2002-2004 Michael Richardson
+# Copyright (C) 2005-2006 Andreas Steffen <andreas.steffen@strongswan.org>
+# 
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; either version 2 of the License, or (at your
+# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
+# 
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+#
+# RCSID $Id: _updown.in,v 1.2 2006/04/17 15:06:29 as Exp $
+
+# CAUTION:  Installing a new version of strongSwan will install a new
+# copy of this script, wiping out any custom changes you make.  If
+# you need changes, make a copy of this under another name, and customize
+# that, and use the (left/right)updown parameters in ipsec.conf to make
+# strongSwan use yours instead of this default one.
+
+# things that this script gets (from ipsec_pluto(8) man page)
+#
+#      PLUTO_VERSION
+#              indicates  what  version of this interface is being
+#              used.  This document describes version  1.1.   This
+#              is upwardly compatible with version 1.0.
+#
+#       PLUTO_VERB
+#              specifies the name of the operation to be performed
+#              (prepare-host, prepare-client, up-host, up-client,
+#              down-host, or down-client).  If the address family
+#              for security gateway to security gateway communica­
+#              tions is IPv6, then a suffix of -v6 is added to the
+#              verb.
+#
+#       PLUTO_CONNECTION
+#              is the name of the  connection  for  which  we  are
+#              routing.
+#
+#       PLUTO_NEXT_HOP
+#              is the next hop to which packets bound for the peer
+#              must be sent.
+#
+#       PLUTO_INTERFACE
+#              is the name of the ipsec interface to be used.
+#
+#       PLUTO_REQID
+#              is the requid of the ESP policy
+#
+#       PLUTO_ME
+#              is the IP address of our host.
+#
+#       PLUTO_MY_ID
+#              is the ID of our host.
+#
+#       PLUTO_MY_CLIENT
+#              is the IP address / count of our client subnet.  If
+#              the  client  is  just  the  host,  this will be the
+#              host's own IP address / max (where max  is  32  for
+#              IPv4 and 128 for IPv6).
+#
+#       PLUTO_MY_CLIENT_NET
+#              is the IP address of our client net.  If the client
+#              is just the host, this will be the  host's  own  IP
+#              address.
+#
+#       PLUTO_MY_CLIENT_MASK
+#              is  the  mask for our client net.  If the client is
+#              just the host, this will be 255.255.255.255.
+#
+#       PLUTO_MY_SOURCEIP
+#              if non-empty, then the source address for the route will be
+#              set to this IP address.
+#
+#       PLUTO_MY_PROTOCOL
+#              is the IP protocol that will be transported.
+#
+#       PLUTO_MY_PORT
+#              is  the  UDP/TCP  port  to  which  the IPsec SA  is
+#              restricted on our side.
+#
+#       PLUTO_PEER
+#              is the IP address of our peer.
+#
+#       PLUTO_PEER_ID
+#              is the ID of our peer.
+#
+#       PLUTO_PEER_CA
+#              is the CA which issued the cert of our peer.
+#
+#       PLUTO_PEER_CLIENT
+#              is the IP address / count of the peer's client sub­
+#              net.   If the client is just the peer, this will be
+#              the peer's own IP address / max (where  max  is  32
+#              for IPv4 and 128 for IPv6).
+#
+#       PLUTO_PEER_CLIENT_NET
+#              is the IP address of the peer's client net.  If the
+#              client is just the peer, this will  be  the  peer's
+#              own IP address.
+#
+#       PLUTO_PEER_CLIENT_MASK
+#              is  the  mask  for  the  peer's client net.  If the
+#              client   is   just   the   peer,   this   will   be
+#              255.255.255.255.
+#
+#       PLUTO_PEER_PROTOCOL
+#              is the IP protocol that will be transported.
+#
+#       PLUTO_PEER_PORT
+#              is  the  UDP/TCP  port  to  which  the IPsec SA  is
+#              restricted on the peer side.
+#
+
+# uncomment to log VPN connections
+VPN_LOGGING=1
+#
+# tag put in front of each log entry:
+TAG=vpn
+#
+# syslog facility and priority used:
+FAC_PRIO=local0.notice
+#
+# to create a special vpn logging file, put the following line into
+# the syslog configuration file /etc/syslog.conf:
+#
+# local0.notice                   -/var/log/vpn
+#
+
+# check interface version
+case "$PLUTO_VERSION" in
+1.[0|1])       # Older Pluto?!?  Play it safe, script may be using new features.
+       echo "$0: obsolete interface version \`$PLUTO_VERSION'," >&2
+       echo "$0:       called by obsolete Pluto?" >&2
+       exit 2
+       ;;
+1.*)   ;;
+*)     echo "$0: unknown interface version \`$PLUTO_VERSION'" >&2
+       exit 2
+       ;;
+esac
+
+# check parameter(s)
+case "$1:$*" in
+':')                   # no parameters
+       ;;
+iptables:iptables)     # due to (left/right)firewall; for default script only
+       ;;
+custom:*)              # custom parameters (see above CAUTION comment)
+       ;;
+*)     echo "$0: unknown parameters \`$*'" >&2
+       exit 2
+       ;;
+esac
+
+# utility functions for route manipulation
+# Meddling with this stuff should not be necessary and requires great care.
+uproute() {
+       doroute add
+       ip route flush cache
+}
+downroute() {
+       doroute delete
+       ip route flush cache
+}
+
+addsource() {
+       st=0
+       if ! ip -o route get ${PLUTO_MY_SOURCEIP%/*} | grep -q ^local
+       then
+           it="ip addr add ${PLUTO_MY_SOURCEIP%/*}/32 dev $PLUTO_INTERFACE"
+           oops="`eval $it 2>&1`"
+           st=$?
+           if test " $oops" = " " -a " $st" != " 0"
+           then
+               oops="silent error, exit status $st"
+           fi
+           if test " $oops" != " " -o " $st" != " 0"
+           then
+               echo "$0: addsource \`$it' failed ($oops)" >&2
+           fi
+       fi
+       return $st
+}
+
+doroute() {
+       st=0
+       parms="$PLUTO_PEER_CLIENT"
+
+       parms2=
+       if [ -n "$PLUTO_NEXT_HOP" ]
+       then
+          parms2="via $PLUTO_NEXT_HOP"
+       fi
+       parms2="$parms2 dev $PLUTO_INTERFACE"
+
+       if [ -z "$PLUTO_MY_SOURCEIP" ]
+       then
+           if [ -f /etc/sysconfig/defaultsource ]
+           then
+               . /etc/sysconfig/defaultsource
+           fi
+
+           if [ -f /etc/conf.d/defaultsource ]
+           then
+               . /etc/conf.d/defaultsource
+           fi
+
+           if [ -n "$DEFAULTSOURCE" ]
+           then
+               PLUTO_MY_SOURCEIP=$DEFAULTSOURCE
+           fi
+        fi
+
+       parms3=
+       if test "$1" = "add" -a -n "$PLUTO_MY_SOURCEIP"
+       then
+           addsource
+           parms3="$parms3 src ${PLUTO_MY_SOURCEIP%/*}"
+       fi
+
+       case "$PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK" in
+       "0.0.0.0/0.0.0.0")
+               # opportunistic encryption work around
+               # need to provide route that eclipses default, without 
+               # replacing it.
+               it="ip route $1 0.0.0.0/1 $parms2 $parms3 &&
+                       ip route $1 128.0.0.0/1 $parms2 $parms3"
+               ;;
+       *)      it="ip route $1 $parms $parms2 $parms3"
+               ;;
+       esac
+       oops="`eval $it 2>&1`"
+       st=$?
+       if test " $oops" = " " -a " $st" != " 0"
+       then
+           oops="silent error, exit status $st"
+       fi
+       if test " $oops" != " " -o " $st" != " 0"
+       then
+           echo "$0: doroute \`$it' failed ($oops)" >&2
+       fi
+       return $st
+}
+# in the presence of KLIPS and ipsecN interfaces do not use IPSEC_POLICY 
+if [ `echo "$PLUTO_INTERFACE" | grep "ipsec"` ]
+then
+       IPSEC_POLICY_IN=""
+       IPSEC_POLICY_OUT=""
+else
+       IPSEC_POLICY="-m policy --pol ipsec --proto esp --reqid $PLUTO_REQID"
+       IPSEC_POLICY_IN="$IPSEC_POLICY --dir in"
+       IPSEC_POLICY_OUT="$IPSEC_POLICY --dir out"
+fi
+
+# are there port numbers?
+if [ "$PLUTO_MY_PORT" != 0 ]
+then
+       S_MY_PORT="--sport $PLUTO_MY_PORT"
+       D_MY_PORT="--dport $PLUTO_MY_PORT"
+fi
+if [ "$PLUTO_PEER_PORT" != 0 ]
+then
+       S_PEER_PORT="--sport $PLUTO_PEER_PORT"
+       D_PEER_PORT="--dport $PLUTO_PEER_PORT"
+fi
+
+# the big choice
+case "$PLUTO_VERB:$1" in
+prepare-host:*|prepare-client:*)
+       # delete possibly-existing route (preliminary to adding a route)
+       case "$PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK" in
+       "0.0.0.0/0.0.0.0")
+               # need to provide route that eclipses default, without 
+               # replacing it.
+               parms1="0.0.0.0/1"
+               parms2="128.0.0.0/1"
+               it="ip route delete $parms1 2>&1 ; ip route delete $parms2 2>&1"
+               oops="`ip route delete $parms1 2>&1 ; ip route delete $parms2 2>&1`"
+               ;;
+       *)
+               parms="$PLUTO_PEER_CLIENT"
+               it="ip route delete $parms 2>&1"
+               oops="`ip route delete $parms 2>&1`"
+               ;;
+       esac
+       status="$?"
+       if test " $oops" = " " -a " $status" != " 0"
+       then
+               oops="silent error, exit status $status"
+       fi
+       case "$oops" in
+       *'RTNETLINK answers: No such process'*) 
+               # This is what route (currently -- not documented!) gives
+               # for "could not find such a route".
+               oops=
+               status=0
+               ;;
+       esac
+       if test " $oops" != " " -o " $status" != " 0"
+       then
+               echo "$0: \`$it' failed ($oops)" >&2
+       fi
+       exit $status
+       ;;
+route-host:*|route-client:*)
+       # connection to me or my client subnet being routed
+       uproute
+       ;;
+unroute-host:*|unroute-client:*)
+       # connection to me or my client subnet being unrouted
+       downroute
+       ;;
+up-host:)
+       # connection to me coming up
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+down-host:)
+       # connection to me going down
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+up-client:)
+       # connection to my client subnet coming up
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+down-client:)
+       # connection to my client subnet going down
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+up-host:iptables)
+       # connection to me, with (left/right)firewall=yes, coming up
+       # This is used only by the default updown script, not by your custom
+       # ones, so do not mess with it; see CAUTION comment up at top.
+       iptables -I INPUT 1 -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+           -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+           -d $PLUTO_ME $D_MY_PORT $IPSEC_POLICY_IN -j ACCEPT
+       iptables -I OUTPUT 1 -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+           -s $PLUTO_ME $S_MY_PORT $IPSEC_POLICY_OUT \
+           -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT -j ACCEPT
+       #
+       # log IPsec host connection setup
+       if [ $VPN_LOGGING ]
+       then
+         if [ "$PLUTO_PEER_CLIENT" == "$PLUTO_PEER/32" ]
+         then
+           logger -t $TAG -p $FAC_PRIO \
+             "+ `echo -e $PLUTO_PEER_ID` $PLUTO_PEER -- $PLUTO_ME"
+         else
+           logger -t $TAG -p $FAC_PRIO \
+             "+ `echo -e $PLUTO_PEER_ID` $PLUTO_PEER_CLIENT == $PLUTO_PEER -- $PLUTO_ME"
+         fi
+       fi      
+       ;;
+down-host:iptables)
+       # connection to me, with (left/right)firewall=yes, going down
+       # This is used only by the default updown script, not by your custom
+       # ones, so do not mess with it; see CAUTION comment up at top.
+       iptables -D INPUT -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+           -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+           -d $PLUTO_ME $D_MY_PORT $IPSEC_POLICY_IN -j ACCEPT
+       iptables -D OUTPUT -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+           -s $PLUTO_ME $S_MY_PORT $IPSEC_POLICY_OUT \
+           -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT -j ACCEPT
+       #
+       # log IPsec host connection teardown
+       if [ $VPN_LOGGING ]
+       then
+         if [ "$PLUTO_PEER_CLIENT" == "$PLUTO_PEER/32" ]
+         then
+           logger -t $TAG -p $FAC_PRIO -- \
+             "- `echo -e $PLUTO_PEER_ID` $PLUTO_PEER -- $PLUTO_ME"
+         else
+           logger -t $TAG -p $FAC_PRIO -- \
+           "- `echo -e $PLUTO_PEER_ID` $PLUTO_PEER_CLIENT == $PLUTO_PEER -- $PLUTO_ME"
+         fi
+       fi
+       ;;
+up-client:iptables)
+       # connection to client subnet, with (left/right)firewall=yes, coming up
+       # This is used only by the default updown script, not by your custom
+       # ones, so do not mess with it; see CAUTION comment up at top.
+       if [ "$PLUTO_PEER_CLIENT" != "$PLUTO_MY_SOURCEIP/32" ]
+       then
+         iptables -I FORWARD 1 -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+             -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $S_MY_PORT \
+             -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT \
+                $IPSEC_POLICY_OUT -j ACCEPT
+         iptables -I FORWARD 1 -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+             -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+             -d $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $D_MY_PORT \
+                $IPSEC_POLICY_IN -j ACCEPT
+       fi
+       #
+       # a virtual IP requires an INPUT and OUTPUT rule on the host
+       # or sometimes host access via the internal IP is needed
+       if [ -n "$PLUTO_MY_SOURCEIP" -o -n "$PLUTO_HOST_ACCESS" ]
+       then
+         iptables -I INPUT 1 -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+             -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+             -d $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $D_MY_PORT \
+                $IPSEC_POLICY_IN -j ACCEPT
+         iptables -I OUTPUT 1 -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+             -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $S_MY_PORT \
+             -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT \
+                $IPSEC_POLICY_OUT -j ACCEPT
+       fi
+       #
+       # log IPsec client connection setup
+       if [ $VPN_LOGGING ]
+       then
+         if [ "$PLUTO_PEER_CLIENT" == "$PLUTO_PEER/32" ]
+         then
+           logger -t $TAG -p $FAC_PRIO \
+             "+ `echo -e $PLUTO_PEER_ID` $PLUTO_PEER -- $PLUTO_ME == $PLUTO_MY_CLIENT"
+         else
+           logger -t $TAG -p $FAC_PRIO \
+             "+ `echo -e $PLUTO_PEER_ID` $PLUTO_PEER_CLIENT == $PLUTO_PEER -- $PLUTO_ME == $PLUTO_MY_CLIENT"
+         fi
+       fi
+       ;;
+down-client:iptables)
+       # connection to client subnet, with (left/right)firewall=yes, going down
+       # This is used only by the default updown script, not by your custom
+       # ones, so do not mess with it; see CAUTION comment up at top.
+       if [ "$PLUTO_PEER_CLIENT" != "$PLUTO_MY_SOURCEIP/32" ]
+       then
+         iptables -D FORWARD -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+             -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $S_MY_PORT \
+             -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT \
+                $IPSEC_POLICY_OUT -j ACCEPT
+         iptables -D FORWARD -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+             -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+             -d $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $D_MY_PORT \
+                $IPSEC_POLICY_IN -j ACCEPT
+       fi
+       #
+       # a virtual IP requires an INPUT and OUTPUT rule on the host
+       # or sometimes host access via the internal IP is needed
+       if [ -n "$PLUTO_MY_SOURCEIP" -o -n "$PLUTO_HOST_ACCESS" ]
+       then
+         iptables -D INPUT -i $PLUTO_INTERFACE -p $PLUTO_MY_PROTOCOL \
+             -s $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $S_PEER_PORT \
+             -d $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $D_MY_PORT \
+                $IPSEC_POLICY_IN -j ACCEPT
+         iptables -D OUTPUT -o $PLUTO_INTERFACE -p $PLUTO_PEER_PROTOCOL \
+             -s $PLUTO_MY_CLIENT_NET/$PLUTO_MY_CLIENT_MASK $S_MY_PORT \
+             -d $PLUTO_PEER_CLIENT_NET/$PLUTO_PEER_CLIENT_MASK $D_PEER_PORT \
+                $IPSEC_POLICY_OUT -j ACCEPT
+       fi
+       #
+       # log IPsec client connection teardown
+       if [ $VPN_LOGGING ]
+       then
+         if [ "$PLUTO_PEER_CLIENT" == "$PLUTO_PEER/32" ]
+         then
+           logger -t $TAG -p $FAC_PRIO -- \
+             "- `echo -e $PLUTO_PEER_ID` $PLUTO_PEER -- $PLUTO_ME == $PLUTO_MY_CLIENT"
+         else
+           logger -t $TAG -p $FAC_PRIO -- \
+             "- `echo -e $PLUTO_PEER_ID` $PLUTO_PEER_CLIENT == $PLUTO_PEER -- $PLUTO_ME == $PLUTO_MY_CLIENT"
+         fi
+       fi
+       ;;
+#
+# IPv6
+#
+prepare-host-v6:*|prepare-client-v6:*)
+       ;;
+route-host-v6:*|route-client-v6:*)
+       # connection to me or my client subnet being routed
+       #uproute_v6
+       ;;
+unroute-host-v6:*|unroute-client-v6:*)
+       # connection to me or my client subnet being unrouted
+       #downroute_v6
+       ;;
+up-host-v6:*)
+       # connection to me coming up
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+down-host-v6:*)
+       # connection to me going down
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+up-client-v6:)
+       # connection to my client subnet coming up
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+down-client-v6:)
+       # connection to my client subnet going down
+       # If you are doing a custom version, firewall commands go here.
+       ;;
+*)     echo "$0: unknown verb \`$PLUTO_VERB' or parameter \`$1'" >&2
+       exit 1
+       ;;
+esac
diff --git a/src/_updown/_updown.in b/src/_updown/_updown.in
deleted file mode 100755 (executable)
index 8db74f7..0000000
+++ /dev/null
@@ -1,503 +0,0 @@
-#! /bin/sh
-# iproute2 version, default updown script
-#
-# Copyright (C) 2003-2004 Nigel Meteringham
-# Copyright (C) 2003-2004 Tuomo Soini
-# Copyright (C) 2002-2004 Michael Richardson
-# Copyright (C) 2005-2006 Andreas Steffen <andreas.steffen@strongswan.org>
-# 
-# This program is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; either version 2 of the License, or (at your
-# option) any later version.  See <http://www.fsf.org/copyleft/gpl.txt>.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-# or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-# for more details.
-#
-# RCSID $Id: _updown.in,v 1.2 2006/04/17 15:06:29 as Exp $
-
-# CAUTION:  Installing a new version of strongSwan will install a new
-# copy of this script, wiping out any custom changes you make.  If
-# you need changes, make a copy of this under another name, and customize
-# that, and use the (left/right)updown parameters in ipsec.conf to make
-# strongSwan use yours instead of this default one.
-
-# things that this script gets (from ipsec_pluto(8) man page)
-#
-#      PLUTO_VERSION
-#              indicates  what  version of this interface is being
-#              used.  This document describes version  1.1.   This
-#              is upwardly compatible with version 1.0.
-#
-#       PLUTO_VERB
-#              specifies the name of the operation to be performed
-#              (prepare-host, prepare-client, up-host, up-client,
-#              down-host, or down-client).  If the address family
-#              for security gateway to security gateway communica­
-#              tions is IPv6, then a suffix of -v6 is added to the
-#              verb.
-#
-#       PLUTO_CONNECTION
-#              is the name of the  connection  for  which  we  are
-#              routing.
-#
-#       PLUTO_NEXT_HOP
-#              is the next hop to which packets bound for the peer
-#              must be sent.
-#
-#       PLUTO_INTERFACE
-#              is the name of the ipsec interface to be used.
-#
-#       PLUTO_REQID
-#              is the requid of the ESP policy
-#
-#       PLUTO_ME
-#              is the IP address of our host.
-#
-#       PLUTO_MY_ID
-#              is the ID of our host.
-#
-#       PLUTO_MY_CLIENT
-#              is the IP address / count of our client subnet.  If
-#              the  client  is  just  the  host,  this will be the
-#              host's own IP address / max (where max  is  32  for
-#              IPv4 and 128 for IPv6).
-#
-#       PLUTO_MY_CLIENT_NET
-#              is the IP address of our client net.  If the client
-#              is just the host, this will be the  host's  own  IP
-#              address.
-#
-#       PLUTO_MY_CLIENT_MASK
-#              is  the  mask for our client net.  If the client is
-#              just the host, this will be 255.255.255.255.
-#
-#       PLUTO_MY_SOURCEIP
-#              if non-empty, then the source address for the route will be
-#              set to this IP address.
-#
-#       PLUTO_MY_PROTOCOL
-#              is the IP protocol that will be transported.
-#
-#       PLUTO_MY_PORT
-#              is  the  UDP/TCP  port  to  which  the IPsec SA  is
-#              restricted on our side.
-#
-#       PLUTO_PEER
-#              is the IP address of our peer.
-#
-#       PLUTO_PEER_ID
-#              is the ID of our peer.
-#
-#       PLUTO_PEER_CA
-#              is the CA which issued the cert of our peer.
-#
-#       PLUTO_PEER_CLIENT
-#              is the IP address / count of the peer's client sub­
-#              net.   If the client is just the peer, this will be
-#              the peer's own IP address / max (where  max  is  32
-#