Back to the standard "app" module.

This return to "app" instead of "bitmask_android" is due to this reading: https://developer.android.com/sdk/installing/studio-build.html#projectStructure
I'll have to tweak the final apk name in build.gradle.

20 files changed, 9468 insertions, 0 deletions

diff --git a/app/openvpn/doc/Makefile.am b/app/openvpn/doc/Makefile.am
new file mode 100644
index 00000000..d33e1edd
--- /dev/null
+++ b/app/openvpn/doc/Makefile.am
@@ -0,0 +1,31 @@
+#
+#  OpenVPN -- An application to securely tunnel IP networks
+#             over a single UDP port, with support for SSL/TLS-based
+#             session authentication and key exchange,
+#             packet encryption, packet authentication, and
+#             packet compression.
+#
+#  Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
+#  Copyright (C) 2006-2012 Alon Bar-Lev <alon.barlev@gmail.com>
+#
+
+MAINTAINERCLEANFILES = \
+	$(srcdir)/Makefile.in
+
+CLEANFILES = openvpn.8.html
+
+dist_doc_DATA = \
+	management-notes.txt
+
+dist_noinst_DATA = \
+	README.plugins
+
+if WIN32
+dist_noinst_DATA += openvpn.8
+nodist_html_DATA = openvpn.8.html
+openvpn.8.html: $(srcdir)/openvpn.8
+	$(MAN2HTML) < $(srcdir)/openvpn.8 > openvpn.8.html
+else
+dist_man_MANS = openvpn.8
+endif
+
diff --git a/app/openvpn/doc/README.plugins b/app/openvpn/doc/README.plugins
new file mode 100644
index 00000000..6e490c5a
--- /dev/null
+++ b/app/openvpn/doc/README.plugins
@@ -0,0 +1,47 @@
+OpenVPN Plugins
+---------------
+
+Starting with OpenVPN 2.0-beta17, compiled plugin modules are
+supported on any *nix OS which includes libdl or on Windows.
+One or more modules may be loaded into OpenVPN using
+the --plugin directive, and each plugin module is capable of
+intercepting any of the script callbacks which OpenVPN supports:
+
+(1) up
+(2) down
+(3) route-up
+(4) ipchange
+(5) tls-verify
+(6) auth-user-pass-verify
+(7) client-connect
+(8) client-disconnect
+(9) learn-address
+
+See the openvpn-plugin.h file in the top-level directory of the
+OpenVPN source distribution for more detailed information
+on the plugin interface.
+
+Included Plugins
+----------------
+
+auth-pam -- Authenticate using PAM and a split privilege
+            execution model which functions even if
+            root privileges or the execution environment
+            have been altered with --user/--group/--chroot.
+            Tested on Linux only.
+
+down-root -- Enable the running of down scripts with root privileges
+             even if --user/--group/--chroot have been used
+             to drop root privileges or change the execution
+             environment.  Not applicable on Windows.
+
+examples -- A simple example that demonstrates a portable
+            plugin, i.e. one which can be built for *nix
+            or Windows from the same source.
+
+Building Plugins
+----------------
+
+cd to the top-level directory of a plugin, and use the
+"make" command to build it.  The examples plugin is
+built using a build script, not a makefile.
diff --git a/app/openvpn/doc/doxygen/doc_compression.h b/app/openvpn/doc/doxygen/doc_compression.h
new file mode 100644
index 00000000..bdc4a7ed
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_compression.h
@@ -0,0 +1,92 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file Data Channel Compression module documentation file.
+ */
+
+/**
+ * @defgroup compression Data Channel Compression module
+ *
+ * This module offers compression of data channel packets.
+ *
+ * @par State structures
+ * The Data Channel Compression module stores its internal state in a \c
+ * lzo_compress_workspace structure.  This state includes flags which
+ * control the module's behavior and preallocated working memory.  One
+ * such structure is present for each VPN tunnel, and is stored in the \c
+ * context.c2.lzo_compwork of the \c context associated with that VPN
+ * tunnel.
+ *
+ * @par Initialization and cleanup
+ * Every time a new \c lzo_compress_workspace is needed, it must be
+ * initialized using the \c lzo_compress_init() function.  Similarly,
+ * every time a \c lzo_compress_workspace is no longer needed, it must be
+ * cleaned up using the \c lzo_compress_uninit() function.  These
+ * functions take care of the allocation and freeing of internal working
+ * memory, but not of the \c lzo_compress_workspace structures themselves.
+ *
+ * @par
+ * Because of the one-to-one relationship between \c
+ * lzo_compress_workspace structures and VPN tunnels, the above-mentioned
+ * initialization and cleanup functions are called directly from the \c
+ * init_instance() and \c close_instance() functions, which control the
+ * initialization and cleanup of VPN tunnel instances and their associated
+ * \c context structures.
+ *
+ * @par Packet processing functions
+ * This module receives data channel packets from the \link data_control
+ * Data Channel Control module\endlink and processes them according to the
+ * settings of the packet's VPN tunnel.  The \link data_control Data
+ * Channel Control module\endlink uses the following interface functions:
+ * - For packets which will be sent to a remote OpenVPN peer: \c
+ *   lzo_compress()
+ * - For packets which have been received from a remote OpenVPN peer: \c
+ *   lzo_decompress()
+ *
+ * @par Settings that control this module's activity
+ * Whether or not the Data Channel Compression module is active depends on
+ * the compile-time \c ENABLE_LZO preprocessor macro and the runtime flags
+ * stored in \c lzo_compress_workspace.flags of the associated VPN tunnel.
+ * The latter are initialized from \c options.lzo, which gets its value
+ * from the process's configuration sources, such as its configuration
+ * file or command line %options.
+ *
+ * @par Adaptive compression
+ * The compression module supports adaptive compression.  If this feature
+ * is enabled, the compression routines monitor their own performance and
+ * turn compression on or off depending on whether it is leading to
+ * significantly reduced payload size.
+ *
+ * @par Compression algorithms
+ * This module uses the Lempel-Ziv-Oberhumer (LZO) compression algorithms.
+ * These offer lossless compression and are designed for high-performance
+ * decompression.  This module uses the external \c lzo library's
+ * implementation of the algorithms.
+ *
+ * @par
+ * For more information on the LZO library, see:\n
+ * http://www.oberhumer.com/opensource/lzo/
+ */
diff --git a/app/openvpn/doc/doxygen/doc_control_processor.h b/app/openvpn/doc/doxygen/doc_control_processor.h
new file mode 100644
index 00000000..072dc372
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_control_processor.h
@@ -0,0 +1,189 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Control Channel Processor module documentation file.
+ */
+
+/**
+ * @defgroup control_processor Control Channel Processor module
+ *
+ * This module controls the setup and maintenance of VPN tunnels and the
+ * associated security parameters.
+ *
+ * @par This module's role
+ * The Control Channel Processor module lies at the core of OpenVPN's
+ * activities.  It handles the setup of new VPN tunnels, the negotiation
+ * of data channel security parameters, the managing of active VPN
+ * tunnels, and finally the cleanup of expired VPN tunnels.
+ *
+ * @par State structures
+ * A large amount of VPN tunnel state information must be stored within an
+ * OpenVPN process.  A wide variety of container structures are used by
+ * this module for that purpose.  Several of these structures are listed
+ * below, and the function of the first three VPN tunnel state containers
+ * is described in more detail later.
+ *  - VPN tunnel state containers:
+ *     - \c tls_multi, security parameter state for a single VPN tunnel.
+ *       Contains three instances of the \c tls_session structure.
+ *     - \c tls_session, security parameter state of a single session
+ *       within a VPN tunnel.  Contains two instances of the \c key_state
+ *       structure.
+ *     - \c key_state, security parameter state of one TLS and data
+ *       channel %key set.
+ *  - Data channel security parameter containers:
+ *     - \c key_ctx_bi, container for two sets of OpenSSL cipher and/or
+ *       HMAC context (both directions).  Contains two instances of the \c
+ *       key_ctx structure.
+ *     - \c key_ctx, container for one set of OpenSSL cipher and/or HMAC
+ *       context (one directions.
+ *  - Key material containers:
+ *     - \c key2, container for two sets of cipher and/or HMAC %key
+ *       material (both directions).  Contains two instances of the \c key
+ *       structure.
+ *     - \c key, container for one set of cipher and/or HMAC %key material
+ *       (one direction).
+ *     - \c key_direction_state, ordering of %key material within the \c
+ *       key2.key array.
+ *  - Key method 2 random material containers:
+ *     - \c key_source2, container for both halves of random material used
+ *       for %key method 2.  Contains two instances of the \c key_source
+ *       structure.
+ *     - \c key_source, container for one half of random material used for
+ *       %key method 2.
+ *
+ * @par The life of a \c tls_multi object
+ * A \c tls_multi structure contains all the security parameter state
+ * information related to the control and data channels of one VPN tunnel.
+ * Its life cycle can be summarized as follows:
+ *  -# Initialization: \c tls_multi_init() and \c
+ *     tls_multi_init_finalize(), which are called (indirectly) from \c
+ *     init_instance() when initializing a new \c context structure.
+ *     - Initializes a \c tls_multi structure.
+ *     - Allocates the three \c tls_session objects contained by the \c
+ *       tls_multi structure, and initializes as appropriate.
+ *  -# Management: \c tls_multi_process() and \c tls_pre_decrypt()
+ *     - If a new session is initiated by the remote peer, then \c
+ *       tls_pre_decrypt() starts the new session negotiation in the
+ *       un-trusted \c tls_session.
+ *     - If the, as yet, un-trusted \c tls_session authenticates
+ *       successfully, then \c tls_multi_process() moves it so as to be
+ *       the active \c tls_session.
+ *     - If an error occurs during processing of a \c key_state object,
+ *       then \c tls_multi_process() cleans up and initializes the
+ *       associated \c tls_session object.  If the error occurred in the
+ *       active \c key_state of the active \c tls_session and the
+ *       lame-duck \c key_state of that \c tls_session has not yet
+ *       expired, it is preserved as fallback.
+ *  -# Cleanup: \c tls_multi_free(), which is called (indirectly) from \c
+ *     close_instance() when cleaning up a \c context structure.
+ *     - Cleans up a \c tls_multi structure.
+ *     - Cleans up the three \c tls_session objects contained by the \c
+ *       tls_multi structure.
+ *
+ * @par The life of a \c tls_session object
+ * A \c tls_session structure contains the state information related to an
+ * active and a lame-duck \c key_state.  Its life cycle can be summarized
+ * as follows:
+ *  -# Initialization: \c tls_session_init()
+ *     - Initializes a \c tls_session structure.
+ *     - Initializes the primary \c key_state by calling \c
+ *       key_state_init().
+ *  -# Renegotiation: \c key_state_soft_reset()
+ *     - Cleans up the old lame-duck \c key_state by calling \c
+ *       key_state_free().
+ *     - Moves the old primary \c key_state to be the new lame-duck \c
+ *       key_state.
+ *     - Initializes a new primary \c key_state by calling \c
+ *       key_state_init().
+ *  -# Cleanup: \c tls_session_free()
+ *     - Cleans up a \c tls_session structure.
+ *     - Cleans up all \c key_state objects associated with the session by
+ *       calling \c key_state_free() for each.
+ *
+ * @par The life of a \c key_state object
+ * A \c key_state structure represents one control and data channel %key
+ * set.  It contains an OpenSSL TLS object that encapsulates the control
+ * channel, and the data channel security parameters needed by the \link
+ * data_crypto Data Channel Crypto module\endlink to perform cryptographic
+ * operations on data channel packets.  Its life cycle can be summarized
+ * as follows:
+ *  -# Initialization: \c key_state_init()
+ *     - Initializes a \c key_state structure.
+ *     - Creates a new OpenSSL TLS object to encapsulate this new control
+ *       channel session.
+ *     - Sets \c key_state.state to \c S_INITIAL.
+ *     - Allocates several internal buffers.
+ *     - Initializes new reliability layer structures for this key set.
+ *  -# Negotiation: \c tls_process()
+ *     - The OpenSSL TLS object negotiates a TLS session between itself
+ *       and the remote peer's TLS object.
+ *     - Key material is generated and exchanged through the TLS session
+ *       between OpenVPN peers.
+ *     - Both peers initialize their data channel cipher and HMAC key
+ *       contexts.
+ *     - On successful negotiation, the \c key_state.state will progress
+ *       from \c S_INITIAL to \c S_ACTIVE and \c S_NORMAL.
+ *  -# Active tunneling: \link data_crypto Data Channel Crypto
+ *     module\endlink
+ *     - Data channel packet to be sent to a remote OpenVPN peer:
+ *        - \c tls_pre_encrypt() loads the security parameters from the \c
+ *          key_state into a \c crypto_options structure.
+ *        - \c openvpn_encrypt() uses the \c crypto_options to an encrypt
+ *          and HMAC sign the data channel packet.
+ *     - Data channel packet received from a remote OpenVPN peer:
+ *        - \c tls_pre_decrypt() loads the security parameters from the \c
+ *          key_state into a \c crypto_options structure.
+ *        - \c openvpn_encrypt() uses the \c crypto_options to
+ *          authenticate and decrypt the data channel packet.
+ *  -# Cleanup: \c key_state_free()
+ *     - Cleans up a \c key_state structure together with its OpenSSL TLS
+ *       object, key material, internal buffers, and reliability layer
+ *       structures.
+ *
+ * @par Control functions
+ * The following two functions drive the Control Channel Processor's
+ * activities.
+ *  - \c tls_multi_process(), iterates through the \c tls_session objects
+ *    within a given \c tls_multi of a VPN tunnel, and calls \c
+ *    tls_process() for each \c tls_session which is being set up, is
+ *    already active, or is busy expiring.
+ *  - \c tls_process(), performs the Control Channel Processor module's
+ *    core handling of received control channel messages, and generates
+ *    appropriate messages to be sent.
+ *
+ * @par Functions which control data channel key generation
+ *  - Key method 1 key exchange functions:
+ *     - \c key_method_1_write(), generates and processes key material to
+ *       be sent to the remote OpenVPN peer.
+ *     - \c key_method_1_read(), processes key material received from the
+ *       remote OpenVPN peer.
+ *  - Key method 2 key exchange functions:
+ *     - \c key_method_2_write(), generates and processes key material to
+ *       be sent to the remote OpenVPN peer.
+ *     - \c key_method_2_read(), processes key material received from the
+ *       remote OpenVPN peer.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_control_tls.h b/app/openvpn/doc/doxygen/doc_control_tls.h
new file mode 100644
index 00000000..aba55f77
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_control_tls.h
@@ -0,0 +1,105 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Control Channel TLS module documentation file.
+ */
+
+/**
+ * @defgroup control_tls Control Channel TLS module
+ *
+ * This module provides secure encapsulation of control channel messages
+ * exchanged between OpenVPN peers.
+ *
+ * The Control Channel TLS module uses the Transport Layer Security (TLS)
+ * protocol to provide an encrypted communication channel between the
+ * local OpenVPN process and a remote peer.  This protocol simultaneously
+ * offers certificate-based authentication of the communicating parties.
+ *
+ * @par This module's roles
+ * The Control Channel TLS module is essential for the security of any
+ * OpenVPN-based system.  On the one hand, it performs the security
+ * operations necessary to protect control channel messages exchanged
+ * between OpenVPN peers.  On the other hand, before the control and data
+ * channels are even setup, it controls the exchange of certificates and
+ * verification of the remote's identity during negotiation of VPN
+ * tunnels.
+ *
+ * @par
+ * The former role is described below.  The latter is described in the
+ * documentation for the \c verify_callback() function.
+ *
+ * @par
+ * In other words, this module takes care of the confidentiality and
+ * integrity of data channel communications, and the authentication of
+ * both the communicating parties and the control channel messages
+ * exchanged.
+ *
+ * @par Initialization and cleanup
+ * Because of the one-to-one relationship between control channel TLS
+ * state and \c key_state structures, the initialization and cleanup of an
+ * instance of the Control Channel TLS module's state happens within the
+ * \c key_state_init() and \c key_state_free() functions.  In other words,
+ * each \c key_state object contains exactly one OpenSSL SSL-BIO object,
+ * which is initialized and cleaned up together with the rest of the \c
+ * key_state object.
+ *
+ * @par Packet processing functions
+ * This object behaves somewhat like a black box with a ciphertext and a
+ * plaintext I/O port. Its interaction with OpenVPN's control channel
+ * during operation takes place within the \c tls_process() function of
+ * the \link control_processor Control Channel Processor\endlink.  The
+ * following functions are available for processing packets:
+ * - If ciphertext received from the remote peer is available in the \link
+ *   reliable Reliability Layer\endlink:
+ *   - Insert it into the ciphertext-side of the SSL-BIO.
+ *   - Use function: \c key_state_write_ciphertext()
+ * - If ciphertext can be extracted from the ciphertext-side of the
+ *   SSL-BIO:
+ *   - Pass it to the \link reliable Reliability Layer\endlink for sending
+ *     to the remote peer.
+ *   - Use function: \c key_state_read_ciphertext()
+ * - If plaintext can be extracted from the plaintext-side of the SSL-BIO:
+ *   - Pass it on to the \link control_processor Control Channel
+ *     Processor\endlink for local processing.
+ *   - Use function: \c key_state_read_plaintext()
+ * - If plaintext from the \link control_processor Control Channel
+ *   Processor\endlink is available to be sent to the remote peer:
+ *   - Insert it into the plaintext-side of the SSL-BIO.
+ *   - Use function: \c key_state_write_plaintext() or \c
+ *     key_state_write_plaintext_const()
+ *
+ * @par Transport Layer Security protocol implementation
+ * This module uses the OpenSSL library's implementation of the TLS
+ * protocol in the form of an OpenSSL SSL-BIO object.
+ *
+ * @par
+ * For more information on the OpenSSL library's BIO objects, please see:
+ *  - OpenSSL's generic BIO objects:
+ *    http://www.openssl.org/docs/crypto/bio.html
+ *  - OpenSSL's SSL-BIO object:
+ *    http://www.openssl.org/docs/crypto/BIO_f_ssl.html
+ */
diff --git a/app/openvpn/doc/doxygen/doc_data_control.h b/app/openvpn/doc/doxygen/doc_data_control.h
new file mode 100644
index 00000000..d0f65ba3
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_data_control.h
@@ -0,0 +1,103 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Data Channel Control module documentation file.
+ */
+
+/**
+ * @defgroup data_control Data Channel Control module
+ *
+ * This module controls the processing of packets as they pass through the
+ * data channel.
+ *
+ * The Data Channel Control module controls the processing of packets as
+ * they pass through the data channel.  The processing includes packet
+ * compression, fragmentation, and the performing of security operations
+ * on the packets.  This module does not do the processing itself, but
+ * passes the packet to other data channel modules to perform the
+ * appropriate actions.
+ *
+ * Packets can travel in two directions through the data channel.  They
+ * can be going to a remote destination which is reachable through a VPN
+ * tunnel, in which case this module prepares them to be sent out through
+ * a VPN tunnel.  On the other hand, they can have been received through a
+ * VPN tunnel from a remote OpenVPN peer, in which case this module
+ * retrieves the packet in its original form as it was before entering the
+ * VPN tunnel on the remote OpenVPN peer.  How this module processes
+ * packets traveling in the two directions is discussed in more detail
+ * below.
+ *
+ * @par Packets to be sent to a remote OpenVPN peer
+ * This module's main function for processing packets traveling in this
+ * direction is \c encrypt_sign(), which performs the following processing
+ * steps:
+ * - Call the \link compression Data Channel Compression module\endlink to
+ *   perform packet compression if necessary.
+ * - Call the \link fragmentation Data Channel Fragmentation
+ *   module\endlink to perform packet fragmentation if necessary.
+ * - Call the \link data_crypto Data Channel Crypto module\endlink to
+ *   perform the required security operations.
+ *
+ * @par
+ * See the \c encrypt_sign() documentation for details of these
+ * interactions.
+ *
+ * @par
+ * After the above processing is complete, the packet is ready to be sent
+ * to a remote OpenVPN peer as a VPN tunnel packet.  The actual sending of
+ * the packet is handled by the \link external_multiplexer External
+ * Multiplexer\endlink.
+ *
+ * @par Packets received from a remote OpenVPN peer
+ * The function that controls how packets traveling in this direction are
+ * processed is \c process_incoming_link().  That function, however, also
+ * performs some of the tasks required for the \link external_multiplexer
+ * External Multiplexer\endlink and is therefore listed as part of that
+ * module, instead of here.
+ *
+ * @par
+ * After the \c process_incoming_link() function has determined that a
+ * received packet is a data channel packet, it performs the following
+ * processing steps:
+ * - Call the \link data_crypto Data Channel Crypto module\endlink to
+ *   perform the required security operations.
+ * - Call the \link fragmentation Data Channel Fragmentation
+ *   module\endlink to perform packet reassembly if necessary.
+ * - Call the \link compression Data Channel Compression module\endlink to
+ *   perform packet decompression if necessary.
+ *
+ * @par
+ * See the \c process_incoming_link() documentation for details of these
+ * interactions.
+ *
+ * @par
+ * After the above processing is complete, the packet is in its original
+ * form again as it was received by the remote OpenVPN peer.  It can now
+ * be routed further to its final destination.  If that destination is a
+ * locally reachable host, then the \link internal_multiplexer Internal
+ * Multiplexer\endlink will send it there.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_data_crypto.h b/app/openvpn/doc/doxygen/doc_data_crypto.h
new file mode 100644
index 00000000..ee72b8cd
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_data_crypto.h
@@ -0,0 +1,75 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Data Channel Crypto module documentation file.
+ */
+
+/**
+ * @addtogroup data_crypto Data Channel Crypto module
+ *
+ * The Data Channel Crypto Module performs cryptographic operations on
+ * data channel packets.
+ *
+ * @par Security parameters
+ * This module is merely the user of a VPN tunnel's security parameters.
+ * It does not perform the negotiation and setup of the security
+ * parameters, nor the %key generation involved.  These actions are done
+ * by the \link control_processor Control Channel Processor\endlink.  This
+ * module receives the appropriate security parameters from that module in
+ * the form of a \c crypto_options structure when they are necessary for
+ * processing a packet.
+ *
+ * @par Packet processing functions
+ * This module receives data channel packets from the \link data_control
+ * Data Channel Control module\endlink and processes them according to the
+ * security parameters of the packet's VPN tunnel.  The \link data_control
+ * Data Channel Control module\endlink uses the following interface
+ * functions:
+ *  - For packets which will be sent to a remote OpenVPN peer:
+ *     - \c tls_pre_encrypt()
+ *     - \c openvpn_encrypt()
+ *     - \c tls_post_encrypt()
+ *  - For packets which have been received from a remote OpenVPN peer:
+ *     - \c tls_pre_decrypt() (documented as part of the \link
+ *       external_multiplexer External Multiplexer\endlink)
+ *     - \c openvpn_decrypt()
+ *
+ * @par Settings that control this module's activity
+ * Whether or not the Data Channel Crypto module is active depends on the
+ * compile-time \c ENABLE_CRYPTO and \c ENABLE_SSL preprocessor macros.  How it
+ * processes packets received from the \link data_control Data Channel
+ * Control module\endlink at runtime depends on the associated \c
+ * crypto_options structure.  To perform cryptographic operations, the \c
+ * crypto_options.key_ctx_bi must contain the correct cipher and HMAC
+ * security parameters for the direction the packet is traveling in.
+ *
+ * @par Crypto algorithms
+ * This module uses the crypto algorithm implementations of the external
+ * OpenSSL library.  More precisely, it uses the OpenSSL library's \c
+ * EVP_Cipher* and \c HMAC_* set of functions to perform cryptographic
+ * operations on data channel packets.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_eventloop.h b/app/openvpn/doc/doxygen/doc_eventloop.h
new file mode 100644
index 00000000..a860db68
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_eventloop.h
@@ -0,0 +1,67 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Main Event Loop module documentation file.
+ */
+
+/**
+ * @defgroup eventloop Main Event Loop module
+ *
+ * This main event loop module drives the packet processing of OpenVPN.
+ *
+ * OpenVPN is an event driven system.  Its activities are driven by a main
+ * event loop, which repeatedly waits for one of several predefined events
+ * to occur, and then calls the appropriate module to handle the event.
+ * The major types of network events that OpenVPN processes are:
+ * - A packet can be read from the external network interface.
+ *   - The main event loop activates the \link external_multiplexer
+ *     External Multiplexer\endlink to read and process the packet.
+ * - A packet can be read from the virtual tun/tap network interface.
+ *   - The main event loop activates the \link internal_multiplexer
+ *     Internal Multiplexer\endlink to read and process the packet.
+ * - If a packet is ready to be sent out as a VPN tunnel packet: the
+ *   external network interface can be written to.
+ *   - The main event loop activates the \link external_multiplexer
+ *     External Multiplexer\endlink to send the packet.
+ * - If a packet is ready to be sent to a locally reachable destination:
+ *   the virtual tun/tap network interface can be written to.
+ *   - The main event loop activates the \link internal_multiplexer
+ *     Internal Multiplexer\endlink to send the packet.
+ *
+ * Beside these external events, OpenVPN also processes other types of
+ * internal events.  These include scheduled events, such as resending of
+ * non-acknowledged control channel messages.
+ *
+ * @par Main event loop implementations
+ *
+ * Depending on the mode in which OpenVPN is running, a different main
+ * event loop function is called to drive the event processing.  The
+ * following implementations are available:
+ * - Client mode using UDP or TCP: \c tunnel_point_to_point()
+ * - Server mode using UDP: \c tunnel_server_udp_single_threaded()
+ * - Server mode using TCP: \c tunnel_server_tcp()
+ */
diff --git a/app/openvpn/doc/doxygen/doc_external_multiplexer.h b/app/openvpn/doc/doxygen/doc_external_multiplexer.h
new file mode 100644
index 00000000..76532557
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_external_multiplexer.h
@@ -0,0 +1,46 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * External Multiplexer module documentation file.
+ */
+
+/**
+ * @addtogroup external_multiplexer External Multiplexer module
+ *
+ * The External Multiplexer is the link between the external network
+ * interface and the other OpenVPN modules.  It reads packets from the
+ * external network interface, determines which remote OpenVPN peer and
+ * VPN tunnel they are associated with, and whether they are data channel
+ * or control channel packets.  It then passes the packets on to the
+ * appropriate processing module.
+ *
+ * This module also handles packets traveling in the reverse direction,
+ * which have been generated by the local control channel or which have
+ * already been processed by the \link data_control Data Channel Control
+ * module\endlink and are destined for a remote host reachable through a
+ * VPN tunnel.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_fragmentation.h b/app/openvpn/doc/doxygen/doc_fragmentation.h
new file mode 100644
index 00000000..ef34cdb2
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_fragmentation.h
@@ -0,0 +1,96 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Data Channel Fragmentation module documentation file.
+ */
+
+/**
+ * @defgroup fragmentation Data Channel Fragmentation module
+ *
+ * The Data Channel Fragmentation module offers fragmentation of data
+ * channel packets.
+ *
+ * @par State structures
+ * The Data Channel Fragmentation module stores its internal state in a \c
+ * fragment_master structure.  One such structure is present for each VPN
+ * tunnel, and is stored in \c context.c2.fragment of the \c context
+ * associated with that VPN tunnel.
+ *
+ * @par
+ * The \c fragment_master structure contains one \c fragment_list
+ * structure \c fragment_master.incoming.  This is a list of \c fragment
+ * structures, each of which can store the parts of one fragmented packet
+ * while it is being reassembled.  The \c fragment_master structure also
+ * contains one \c buffer called \c fragment_master.outgoing, in which a
+ * data channel large packet to be sent to a remote OpenVPN peer can be
+ * broken up into parts to be sent one by one.
+ *
+ * @par Initialization and cleanup
+ * Every time a new \c fragment_master is needed, it must be allocated and
+ * initialized by the \c fragment_init() function.  Similarly, every time
+ * a \c fragment_master is no longer needed, it must be cleaned up using
+ * the \c fragment_free() function.  These functions take care of the
+ * allocation and freeing of the \c fragment_master structure itself and
+ * all internal memory required for the use of that structure.  Note that
+ * this behavior is different from that displayed by the \link compression
+ * Data Channel Compression module\endlink.
+ *
+ * @par
+ * Because of the one-to-one relationship between \c fragment_master
+ * structures and VPN tunnels, the above-mentioned initialization and
+ * cleanup functions are called directly from the \c init_instance() and
+ * \c close_instance() functions, which control the initialization and
+ * cleanup of VPN tunnel instances and their associated \c context
+ * structures.
+ *
+ * @par Packet processing functions
+ * This module receives data channel packets from the \link data_control
+ * Data Channel Control module\endlink and processes them according to the
+ * settings of the packet's VPN tunnel.  The \link data_control Data
+ * Channel Control module\endlink uses the following interface functions:
+ * - For packets which will be sent to a remote OpenVPN peer: \c
+ *   fragment_outgoing() \n This function inspects data channel packets as
+ *   they are being made ready to be sent as VPN tunnel packets to a
+ *   remote OpenVPN peer.  If a packet's size is larger than its
+ *   destination VPN tunnel's maximum transmission unit (MTU), then this
+ *   module breaks that packet up into smaller parts, each of which is
+ *   smaller than or equal to the VPN tunnel's MTU.  See \c
+ *   fragment_outgoing() for details.
+ * - For packets which have been received from a remote OpenVPN peer: \c
+ *   fragment_incoming() \n This function inspects data channel packets
+ *   that have been received from a remote OpenVPN peer through a VPN
+ *   tunnel.  It reads the fragmentation header of the packet, and
+ *   depending on its value performs the appropriate action.  See \c
+ *   fragment_incoming() for details.
+ *
+ * @par Settings that control this module's activity
+ * Whether the Data Channel Fragmentation module is active or not depends
+ * on the compile-time \c ENABLE_FRAGMENT preprocessor macro and the
+ * runtime flag \c options.fragment, which gets its value from the
+ * process's configuration sources, such as the configuration file and
+ * commandline %options.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_internal_multiplexer.h b/app/openvpn/doc/doxygen/doc_internal_multiplexer.h
new file mode 100644
index 00000000..5142dd0d
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_internal_multiplexer.h
@@ -0,0 +1,44 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Internal Multiplexer module documentation file.
+ */
+
+/**
+ * @addtogroup internal_multiplexer Internal Multiplexer module
+ *
+ * The Internal Multiplexer is the link between the virtual tun/tap
+ * network interface and the \link data_control Data Channel Control
+ * module\endlink.  It reads packets from the virtual network interface,
+ * determines for which remote OpenVPN peer they are destined, and then
+ * passes the packets on to the Data Channel Control module together with
+ * information about their destination VPN tunnel instance.
+ *
+ * This module also handles packets traveling in the reverse direction,
+ * which have already been processed by the Data Channel Control module
+ * and are destined for a locally reachable host.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_key_generation.h b/app/openvpn/doc/doxygen/doc_key_generation.h
new file mode 100644
index 00000000..903a4652
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_key_generation.h
@@ -0,0 +1,153 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Key generation documentation file.
+ */
+
+/**
+ * @page key_generation Data channel %key generation
+ *
+ * This section describes how OpenVPN peers generate and exchange %key
+ * material necessary for the security operations performed on data
+ * channel packets.
+ *
+ * The %key generation and exchange process between OpenVPN client and
+ * server occurs every time data channel security parameters are
+ * negotiated, for example during the initial setup of a VPN tunnel or
+ * when the active security parameters expire.  In source code terms, this
+ * is when a new key_state structure is initialized.
+ *
+ * @section key_generation_method Key methods
+ *
+ * OpenVPN supports two different ways of generating and exchanging %key
+ * material between client and server.  These are known as %key method 1
+ * and %key method 2.  %Key method 2 is the recommended method. Both are
+ * explained below.
+ *
+ * @subsection key_generation_method_1 Key method 1
+ *
+ * -# Each host generates its own random material.
+ * -# Each host uses its locally generated random material as %key data
+ *    for encrypting and signing packets sent to the remote peer.
+ * -# Each host then sends its random material to the remote peer, so that
+ *    the remote peer can use that %key data for authenticating and
+ *    decrypting received packets.
+ *
+ * @subsection key_generation_method_2 Key method 2
+ *
+ * -# The client generates random material in the following amounts:
+ *    - Pre-master secret: 48 bytes
+ *    - Client's PRF seed for master secret: 32 bytes
+ *    - Client's PRF seed for %key expansion: 32 bytes
+ * -# The client sends its share of random material to the server.
+ * -# The server generates random material in the following amounts:
+ *    - Server's PRF seed for master secret: 32 bytes
+ *    - Server's PRF seed for %key expansion: 32 bytes
+ * -# The server computes the %key expansion using its own and the
+ *    client's random material.
+ * -# The server sends its share of random material to the client.
+ * -# The client computes the %key expansion using its own and the
+ *    server's random material.
+ *
+ * %Key method 2 %key expansion is performed by the \c
+ * generate_key_expansion() function.  Please refer to its source code for
+ * details of the %key expansion process.
+ *
+ * @subsection key_generation_random Source of random material
+ *
+ * OpenVPN uses the either the OpenSSL library or the PolarSSL library as its
+ * source of random material.
+ *
+ * In OpenSSL, the \c RAND_bytes() function is called
+ * to supply cryptographically strong pseudo-random data.  The following links
+ * contain more information on this subject:
+ * - For OpenSSL's \c RAND_bytes() function:
+ *   http://www.openssl.org/docs/crypto/RAND_bytes.html
+ * - For OpenSSL's pseudo-random number generating system:
+ *   http://www.openssl.org/docs/crypto/rand.html
+ * - For OpenSSL's support for external crypto modules:
+ *   http://www.openssl.org/docs/crypto/engine.html
+ *
+ * In PolarSSL, the Havege random number generator is used. For details, see
+ * the PolarSSL documentation.
+ *
+ * @section key_generation_exchange Key exchange:
+ *
+ * The %key exchange process is initiated by the OpenVPN process running
+ * in client mode.  After the initial three-way handshake has successfully
+ * completed, the client sends its share of random material to the server,
+ * after which the server responds with its part.  This process is
+ * depicted below:
+ *
+@verbatim
+  Client           Client                           Server          Server
+  State            Action                           Action          State
+----------  --------------------            --------------------  ----------
+
+             ... waiting until three-way handshake complete ...
+S_START                                                              S_START
+            key_method_?_write()
+            send to server  --> --> --> -->  receive from client
+S_SENT_KEY                                   key_method_?_read()
+                                                                   S_GOT_KEY
+                                            key_method_?_write()
+            receive from server  <-- <-- <-- <--  send to client
+            key_method_?_read()                                   S_SENT_KEY
+S_GOT_KEY
+          ... waiting until control channel fully synchronized ...
+S_ACTIVE                                                            S_ACTIVE
+@endverbatim
+ *
+ * For more information about the client and server state values, see the
+ * \link control_processor Control Channel Processor module\endlink.
+ *
+ * Depending on which %key method is used, the \c ? in the function names
+ * of the diagram above is a \c 1 or a \c 2.  For example, if %key method
+ * 2 is used, that %key exchange would be started by the client calling \c
+ * key_method_2_write().  These functions are called from the \link
+ * control_processor Control Channel Processor module's\endlink \c
+ * tls_process() function and control the %key generation and exchange
+ * process as follows:
+ * - %Key method 1:
+ *   - \c key_method_1_write(): generate random material locally, and load
+ *     as "sending" keys.
+ *   - \c key_method_1_read(): read random material received from remote
+ *     peer, and load as "receiving" keys.
+ * - %Key method 2:
+ *   - \c key_method_2_write(): generate random material locally, and if
+ *     in server mode generate %key expansion.
+ *   - \c key_method_2_read(): read random material received from remote
+ *     peer, and if in client mode generate %key expansion.
+ *
+ * @subsection key_generation_encapsulation Transmission of key material
+ *
+ * The OpenVPN client and server communicate with each other through their
+ * control channel.  This means that all of the data transmitted over the
+ * network, such as random material for %key generation, is encapsulated
+ * in a TLS layer.  For more details, see the \link control_tls Control
+ * Channel TLS module\endlink documentation.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_mainpage.h b/app/openvpn/doc/doxygen/doc_mainpage.h
new file mode 100644
index 00000000..821b2e87
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_mainpage.h
@@ -0,0 +1,162 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Main page documentation file.
+ */
+
+/**
+ * @mainpage OpenVPN v2.1 source code documentation
+ *
+ * This documentation describes the internal structure of OpenVPN.  It was
+ * automatically generated from specially formatted comment blocks in
+ * OpenVPN's source code using Doxygen.  (See
+ * http://www.stack.nl/~dimitri/doxygen/ for more information on Doxygen)
+ *
+ * The \ref mainpage_modules "Modules section" below gives an introduction
+ * into the high-level module concepts used throughout this documentation.
+ * The \ref mainpage_relatedpages "Related Pages section" below describes
+ * various special subjects related to OpenVPN's implementation which are
+ * discussed in the related pages section.
+ *
+ * @section mainpage_modules Modules
+ *
+ * For the purpose of describing the internal structure of OpenVPN, this
+ * documentation and the underlying source code has been broken up into a
+ * number of conceptually well-defined parts, known as modules. Each
+ * module plays a specific role within the OpenVPN process, and in most
+ * cases each module has a clear interfacing strategy for interacting with
+ * other modules.
+ *
+ * The following modules have been defined:
+ * - Driver module:
+ *   - The \link eventloop Main Event Loop\endlink: this module drives the
+ *     event handling of OpenVPN.  It implements various types of
+ *     select-loop which wait until an event happens, and then delegate
+ *     the handling of that event to the appropriate module.
+ * - Network interface modules:
+ *   - The \link external_multiplexer External Multiplexer\endlink: this
+ *     module sends and receives packets to and from remote OpenVPN peers
+ *     over the external network interface.  It also takes care of
+ *     demultiplexing received packets to their appropriate VPN tunnel and
+ *     splitting control channel and data channel packets.
+ *   - The \link internal_multiplexer Internal Multiplexer\endlink: this
+ *     module sends and receives packets to and from locally reachable
+ *     posts over the virtual tun/tap network interface.  It also takes
+ *     care of determining through which VPN tunnel a received packet must
+ *     be sent to reach its destination.
+ * - Control channel modules:
+ *   - The \link reliable Reliability Layer\endlink: this module offers a
+ *     %reliable and sequential transport layer for control channel
+ *     messages.
+ *   - The \link control_tls Control Channel TLS module\endlink: this
+ *     module offers a secure encapsulation of control channel messages
+ *     using the TLS protocol.
+ *   - The \link control_processor Control Channel Processor\endlink: his
+ *     module manages the setup, maintenance, and shut down of VPN
+ *     tunnels.
+ * - Data channel modules:
+ *   - The \link data_control Data Channel Control module\endlink: this
+ *     module controls the processing of data channel packets and,
+ *     depending on the settings of the packet's VPN tunnel, passes the
+ *     packet to the three modules below for handling.
+ *   - The \link data_crypto Data Channel Crypto module\endlink: this
+ *     module performs security operations on data channel packets.
+ *   - The \link fragmentation Data Channel Fragmentation module\endlink:
+ *     this module offers fragmentation of data channel packets larger
+ *     than the VPN tunnel's MTU.
+ *   - The \link compression Data Channel Compression module\endlink: this
+ *     module offers compression of data channel packets.
+ *
+ * @subsection mainpage_modules_example Example event: receiving a packet
+ *
+ * OpenVPN handles many types of events during operation.  These include
+ * external events, such as network traffic being received, and internal
+ * events, such as a %key session timing out causing renegotiation.  An
+ * example event, receiving a packet over the network, is described here
+ * together with which modules play what roles:
+ * -# The \link eventloop Main Event Loop\endlink detects that a packet
+ *    can be read from the external or the virtual tun/tap network
+ *    interface.
+ * -# The \link eventloop Main Event Loop\endlink calls the \link
+ *    external_multiplexer External Multiplexer\endlink or \link
+ *    internal_multiplexer Internal Multiplexer\endlink to read and
+ *    process the packet.
+ * -# The multiplexer module determines the type of packet and its
+ *    destination, and passes the packet on to the appropriate handling
+ *    module:
+ *    - A control channel packet received by the \link
+ *      external_multiplexer External Multiplexer\endlink is passed on
+ *      through the \link reliable Reliability Layer\endlink and the \link
+ *      control_tls Control Channel TLS module\endlink to the \link
+ *      control_processor Control Channel Processor\endlink.
+ *    - A data channel packet received by either multiplexer module is
+ *      passed on to the \link data_control Data Channel Control
+ *      module\endlink.
+ * -# The packet is processed by the appropriate control channel or data
+ *    channel modules.
+ * -# If, after processing the packet, a resulting packet is generated
+ *    that needs to be sent to a local or remote destination, it is given
+ *    to the \link external_multiplexer External Multiplexer\endlink or
+ *    \link internal_multiplexer Internal Multiplexer\endlink for sending.
+ * -# If a packet is waiting to be sent by either multiplexer module and
+ *    the \link eventloop Main Event Loop\endlink detects that data can be
+ *    written to the associated network interface, it calls the
+ *    multiplexer module to send the packet.
+ *
+ * @section mainpage_relatedpages Related pages
+ *
+ * This documentation includes a number of descriptions of various aspects
+ * of OpenVPN and its implementation.  These are not directly related to
+ * one module, function, or data structure, and are therefore listed
+ * separately under "Related Pages".
+ *
+ * @subsection mainpage_relatedpages_key_generation Data channel key generation
+ *
+ * The @ref key_generation "Data channel key generation" related page
+ * describes how, during VPN tunnel setup and renegotiation, OpenVPN peers
+ * generate and exchange the %key material required for the symmetric
+ * encryption/decryption and HMAC signing/verifying security operations
+ * performed on data channel packets.
+ *
+ * @subsection mainpage_relatedpages_tunnel_state VPN tunnel state
+ *
+ * The @ref tunnel_state "Structure of VPN tunnel state storage" related
+ * page describes how an OpenVPN process manages the state information
+ * associated with its active VPN tunnels.
+ *
+ * @subsection mainpage_relatedpages_network_protocol Network protocol
+ *
+ * The @ref network_protocol "Network protocol" related page describes the
+ * format and content of VPN tunnel packets exchanged between OpenVPN
+ * peers.
+ *
+ * @subsection mainpage_relatedpages_memory_management Memory management
+ *
+ * The @ref memory_management "Memory management strategies" related page
+ * gives a brief introduction into OpenVPN's memory %buffer library and
+ * garbage collection facilities.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_memory_management.h b/app/openvpn/doc/doxygen/doc_memory_management.h
new file mode 100644
index 00000000..f948783e
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_memory_management.h
@@ -0,0 +1,99 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Memory management strategies documentation file.
+ */
+
+/**
+ * @page memory_management OpenVPN's memory management strategies
+ *
+ * This section describes several implementation details relating to
+ * OpenVPN's memory management strategies.
+ *
+ * During operation, the OpenVPN process performs all kinds of operations
+ * on blocks of data.  Receiving packets, encrypting content, prepending
+ * headers, etc.  To make the programmer's job easier and to decrease the
+ * likelihood of memory-related bugs, OpenVPN uses its own memory %buffer
+ * library and garbage collection facilities.  These are described in
+ * brief here.
+ *
+ * @section memory_management_buffer The buffer structure
+ *
+ * The \c buffer structure is a wrapper around a block of dynamically
+ * allocated memory which keeps track of the block's capacity \c
+ * buffer.capacity and location in memory \c buffer.data.  This structure
+ * supports efficient prepending and appending within the allocated memory
+ * through the use of offset \c buffer.offset and length \c buffer.len
+ * fields.  See the \c buffer documentation for more details on the
+ * structure itself.
+ *
+ * OpenVPN's %buffer library, implemented in the \c buffer.h and \c
+ * buffer.c files, contains many utility functions for working with \c
+ * buffer structures.  These functions facilitate common operations, such
+ * as allocating, freeing, reading and writing to \c buffer structures,
+ * and even offer several more advanced operations, such as string
+ * matching and creating sub-buffers.
+ *
+ * Not only do these utility functions make working with \c buffer
+ * structures easy, they also perform extensive error checking.  Each
+ * function, where necessary, checks whether enough space is available
+ * before performing its actions.  This minimizes the chance of bugs
+ * leading to %buffer overflows and other vulnerabilities.
+ *
+ * @section memory_management_frame The frame structure
+ *
+ * The \c frame structure keeps track of the maximum allowed packet
+ * geometries of a network connection.
+ *
+ * It is used, for example, to determine the size of \c buffer structures
+ * in which to store data channel packets.  This is done by having each
+ * data channel processing module register the maximum amount of extra
+ * space it will need for header prepending and content expansion in the
+ * \c frame structure. Once these parameters are known, \c buffer
+ * structures can be allocated, based on the \c frame parameters, so that
+ * they are large enough to allow efficient prepending of headers and
+ * processing of content.
+ *
+ * @section memory_management_garbage Garbage collection
+ *
+ * OpenVPN has many sizable functions which perform various actions
+ * depending on their %context.  This makes it difficult to know in advance
+ * exactly how much memory must be allocated.  The garbage collection
+ * facilities are used to keep track of dynamic allocations, thereby
+ * allowing easy collective freeing of the allocated memory.
+ *
+ * The garbage collection system is implemented by the \c gc_arena and \c
+ * gc_entry structures.  The arena represents a garbage collecting unit,
+ * and contains a linked list of entries.  Each entry represents one block
+ * of dynamically allocated memory.
+ *
+ * The garbage collection system also contains various utility functions
+ * for working with the garbage collection structures.  These include
+ * functions for initializing new arenas, allocating memory of a given
+ * size and registering the allocation in an arena, and freeing all the
+ * allocated memory associated with an arena.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_protocol_overview.h b/app/openvpn/doc/doxygen/doc_protocol_overview.h
new file mode 100644
index 00000000..26fed331
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_protocol_overview.h
@@ -0,0 +1,199 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file Network protocol overview documentation file.
+ */
+
+/**
+ * @page network_protocol OpenVPN's network protocol
+ *
+ * Description of packet structure in OpenVPN's network protocol.
+ *
+ * This document describes the structure of packets exchanged between
+ * OpenVPN peers.  It is based on the protocol description in the \c ssl.h
+ * file.
+ *
+ * @section network_protocol_external Outer structure of packets exchanged between OpenVPN peers
+ *
+ * VPN tunnel packets are transported between OpenVPN peers using the UDP
+ * or TCP protocols.  Their structure is described below.
+ *
+ * @subsection network_protocol_external_structure External packet structure
+ *
+ *  - packet length (16 bits, unsigned) [TCP-mode only]: always sent as
+ *    plain text.  Since TCP is a stream protocol, this packet length
+ *    defines the packetization of the stream.
+ *  - packet opcode and key_id (8 bits) [TLS-mode only]:
+ *     - package message type (high 5 bits)
+ *     - key_id (low 3 bits): the key_id refers to an already negotiated
+ *       TLS session.  OpenVPN seamlessly renegotiates the TLS session by
+ *       using a new key_id for the new session.  Overlap (controlled by
+ *       user definable parameters) between old and new TLS sessions is
+ *       allowed, providing a seamless transition during tunnel operation.
+ *  - payload (n bytes)
+ *
+ * @subsection network_protocol_external_types Message types
+ *
+ * The type of a VPN tunnel packet is indicated by its opcode.  The
+ * following describes the various opcodes available.
+ *
+ *  - Control channel messages:
+ *     - \c P_CONTROL_HARD_RESET_CLIENT_V1 -- %Key method 1, initial %key
+ *       from client, forget previous state.
+ *     - \c P_CONTROL_HARD_RESET_SERVER_V1 -- %Key method 1, initial %key
+ *       from server, forget previous state.
+ *     - \c P_CONTROL_HARD_RESET_CLIENT_V2 -- %Key method 2, initial %key
+ *       from client, forget previous state.
+ *     - \c P_CONTROL_HARD_RESET_SERVER_V2 -- %Key method 2, initial %key
+ *       from server, forget previous state.
+ *     - \c P_CONTROL_SOFT_RESET_V1 -- New %key, with a graceful
+ *       transition from old to new %key in the sense that a transition
+ *       window exists where both the old or new key_id can be used.
+ *     - \c P_CONTROL_V1 -- Control channel packet (usually TLS
+ *       ciphertext).
+ *     - \c P_ACK_V1 -- Acknowledgement for control channel packets
+ *       received.
+ *  - Data channel messages:
+ *     - \c P_DATA_V1 -- Data channel packet containing data channel
+ *       ciphertext.
+ *
+ * @subsection network_protocol_external_key_id Session IDs and Key IDs
+ *
+ * OpenVPN uses two different forms of packet identifiers:
+ *  - The first form is 64 bits and is used for all control channel
+ *    messages.  This form is referred to as a \c session_id.
+ *  - Data channel messages on the other hand use a shortened form of 3
+ *    bits for efficiency reasons since the vast majority of OpenVPN
+ *    packets in an active tunnel will be data channel messages.  This
+ *    form is referred to as a \c key_id.
+ *
+ * The control and data channels use independent packet-id sequences,
+ * because the data channel is an unreliable channel while the control
+ * channel is a %reliable channel.  Each use their own independent HMAC
+ * keys.
+ *
+ * @subsection network_protocol_external_reliable Control channel reliability layer
+ *
+ * Control channel messages (\c P_CONTROL_* and \c P_ACK_* message types)
+ * are TLS ciphertext packets which have been encapsulated inside of a
+ * reliability layer.  The reliability layer is implemented as a
+ * straightforward acknowledge and retransmit model.
+ *
+ * Acknowledgments of received messages can be encoded in either the
+ * dedicated \c P_ACK_* record or they can be prepended to a \c
+ * P_CONTROL_* message.
+ *
+ * See the \link reliable Reliability Layer\endlink module for a detailed
+ * description.
+ *
+ * @section network_protocol_control Structure of control channel messages
+ *
+ * @subsection network_protocol_control_ciphertext Structure of ciphertext control channel messages
+ *
+ * Control channel packets in ciphertext form consist of the following
+ * parts:
+ *
+ *  - local \c session_id (random 64 bit value to identify TLS session).
+ *  - HMAC signature of entire encapsulation header for HMAC firewall
+ *    [only if \c --tls-auth is specified] (usually 16 or 20 bytes).
+ *  - packet-id for replay protection (4 or 8 bytes, includes sequence
+ *    number and optional \c time_t timestamp).
+ *  - acknowledgment packet-id array length (1 byte).
+ *  - acknowledgment packet-id array (if length > 0).
+ *  - acknowledgment remote session-id (if length > 0).
+ *  - packet-id of this message (4 bytes).
+ *  - TLS payload ciphertext (n bytes) (only for \c P_CONTROL_V1).
+ *
+ * Note that when \c --tls-auth is used, all message types are protected
+ * with an HMAC signature, even the initial packets of the TLS handshake.
+ * This makes it easy for OpenVPN to throw away bogus packets quickly,
+ * without wasting resources on attempting a TLS handshake which will
+ * ultimately fail.
+ *
+ * @subsection network_protocol_control_key_methods Control channel key methods and
+ *
+ * Once the TLS session has been initialized and authenticated, the TLS
+ * channel is used to exchange random %key material for bidirectional
+ * cipher and HMAC keys which will be used to secure data channel packets.
+ * OpenVPN currently implements two %key methods.  %Key method 1 directly
+ * derives keys using random bits obtained from the \c RAND_bytes()
+ * OpenSSL function.  %Key method 2 mixes random %key material from both
+ * sides of the connection using the TLS PRF mixing function.  %Key method
+ * 2 is the preferred method and is the default for OpenVPN 2.0.
+ *
+ * The @ref key_generation "Data channel key generation" related page
+ * describes the %key methods in more detail.
+ *
+ * @subsection network_protocol_control_plaintext Structure of plaintext control channel messages
+ *
+ *  - %Key method 1:
+ *     - Cipher %key length in bytes (1 byte).
+ *     - Cipher %key (n bytes).
+ *     - HMAC %key length in bytes (1 byte).
+ *     - HMAC %key (n bytes).
+ *     - %Options string (n bytes, null terminated, client/server %options
+ *       string should match).
+ *  - %Key method 2:
+ *     - Literal 0 (4 bytes).
+ *     - %Key method (1 byte).
+ *     - \c key_source structure (\c key_source.pre_master only defined
+ *       for client -> server).
+ *     - %Options string length, including null (2 bytes).
+ *     - %Options string (n bytes, null terminated, client/server %options
+ *       string must match).
+ *     - [The username/password data below is optional, record can end at
+ *       this point.]
+ *     - Username string length, including null (2 bytes).
+ *     - Username string (n bytes, null terminated).
+ *     - Password string length, including null (2 bytes).
+ *     - Password string (n bytes, null terminated).
+ *
+ * @section network_protocol_data Structure of data channel messages
+ *
+ * @subsection network_protocol_data_ciphertext Structure of ciphertext data channel messages
+ *
+ * The P_DATA_* payload represents encrypted, encapsulated tunnel packets
+ * which tend to be either IP packets or Ethernet frames. This is
+ * essentially the "payload" of the VPN.
+ *
+ * Data channel packets in ciphertext form consist of the following parts:
+ *  - HMAC of ciphertext IV + ciphertext (if not disabled by \c --auth
+ *    none).
+ *  - Ciphertext IV (size is cipher-dependent, if not disabled by \c
+ *    --no-iv).
+ *  - Tunnel packet ciphertext.
+ *
+ * @subsection network_protocol_data_plaintext Structure of plaintext data channel messages
+ *
+ * Data channel packets in plaintext form consist of the following parts:
+ *  - packet-id (4 or 8 bytes, if not disabled by --no-replay).
+ *     - In TLS mode, 4 bytes are used because the implementation can
+ *       force a TLS renegotation before \c 2^32 packets are sent.
+ *     - In pre-shared %key mode, 8 bytes are used (sequence number and \c
+ *       time_t value) to allow long-term %key usage without packet-id
+ *       collisions.
+ *  - User plaintext (n bytes).
+ */
diff --git a/app/openvpn/doc/doxygen/doc_reliable.h b/app/openvpn/doc/doxygen/doc_reliable.h
new file mode 100644
index 00000000..5264906a
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_reliable.h
@@ -0,0 +1,49 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Reliability Layer module documentation file.
+ */
+
+/**
+ * @defgroup reliable Reliability Layer module
+ *
+ * The Reliability Layer is part of OpenVPN's control channel.  It
+ * provides a reliable and sequential transport mechanism for control
+ * channel messages between OpenVPN peers.  This module forms the
+ * interface between the \link external_multiplexer External
+ * Multiplexer\endlink and the \link control_tls Control Channel TLS
+ * module\endlink.
+ *
+ * @par UDP or TCP as VPN tunnel transport
+ *
+ * This is especially important when OpenVPN is configured to communicate
+ * over UDP, because UDP does not offer a reliable and sequential
+ * transport.  OpenVPN endpoints can also communicate over TCP which does
+ * provide a reliable and sequential transport.  In both cases, using UDP
+ * or TCP as an external transport, the internal Reliability Layer is
+ * active.
+ */
diff --git a/app/openvpn/doc/doxygen/doc_tunnel_state.h b/app/openvpn/doc/doxygen/doc_tunnel_state.h
new file mode 100644
index 00000000..6c93e71b
--- /dev/null
+++ b/app/openvpn/doc/doxygen/doc_tunnel_state.h
@@ -0,0 +1,155 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  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.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * VPN tunnel state documentation file.
+ */
+
+/**
+ * @page tunnel_state Structure of the VPN tunnel state storage
+ *
+ * This section describes how OpenVPN stores its VPN tunnel state during
+ * operation.
+ *
+ * OpenVPN uses several data structures as storage containers for state
+ * information of active VPN tunnels.  These are described in this
+ * section, together with a little bit of history to help understand the
+ * origin of the current architecture.
+ *
+ * Whether an OpenVPN process is running in client-mode or server-mode
+ * determines whether it can support only one or multiple simultaneously
+ * active VPN tunnels.  This consequently also determines how the
+ * associated state information is wrapped up internally.  This section
+ * gives an overview of the differences.
+ *
+ * @section tunnel_state_history Historic developments
+ *
+ * In the old v1.x series, an OpenVPN process managed only one single VPN
+ * tunnel.  This allowed the VPN tunnel state to be stored together with
+ * process-global information in one single \c context structure.
+ *
+ * This changed, however, in the v2.x series, as new OpenVPN versions
+ * running in server-mode can support multiple simultaneously active VPN
+ * tunnels.  This necessitated a redesign of the VPN tunnel state
+ * container structures, and modification of the \link
+ * external_multiplexer External Multiplexer\endlink and \link
+ * internal_multiplexer Internal Multiplexer\endlink systems.  The
+ * majority of these changes are only relevant for OpenVPN processes
+ * running in server-mode, and the client-mode structure has remained very
+ * similar to the v1.x single-tunnel form.
+ *
+ * @section tunnel_state_client Client-mode state
+ *
+ * An OpenVPN process running in client-mode can manage at most one single
+ * VPN tunnel at any one time.  The state information for a client's VPN
+ * tunnel is stored in a \c context structure.
+ *
+ * The \c context structure is created in the \c main() function.  That is
+ * also where process-wide initialization takes place, such as parsing
+ * command line %options and reading configuration files.  The \c context
+ * is then passed to \c tunnel_point_to_point() which drives OpenVPN's
+ * main event processing loop.  These functions are both part of the \link
+ * eventloop Main Event Loop\endlink module.
+ *
+ * @subsection tunnel_state_client_init Initialization and cleanup
+ *
+ * Because there is only one \c context structure present, it can be
+ * initialized and cleaned up from the client's main event processing
+ * function.  Before the \c tunnel_point_to_point() function enters its
+ * event loop, it calls \c init_instance_handle_signals() which calls \c
+ * init_instance() to initialize the single \c context structure.  After
+ * the event loop stops, it calls \c close_instance() to clean up the \c
+ * context.
+ *
+ * @subsection tunnel_state_client_event Event processing
+ *
+ * When the main event processing loop activates the external or internal
+ * multiplexer to handle a network event, it is not necessary to determine
+ * which VPN tunnel the event is associated with, because there is only
+ * one VPN tunnel active.
+ *
+ * @section tunnel_state_server Server-mode state
+ *
+ * An OpenVPN process running in server-mode can manage multiple
+ * simultaneously active VPN tunnels.  For every VPN tunnel active, in
+ * other words for every OpenVPN client which is connected to a server,
+ * the OpenVPN server has one \c context structure in which it stores that
+ * particular VPN tunnel's state information.
+ *
+ * @subsection tunnel_state_server_multi Multi_context and multi_instance structures
+ *
+ * To support multiple \c context structures, each is wrapped in a \c
+ * multi_instance structure, and all the \c multi_instance structures are
+ * registered in one single \c multi_context structure.  The \link
+ * external_multiplexer External Multiplexer\endlink and \link
+ * internal_multiplexer Internal Multiplexer\endlink then use the \c
+ * multi_context to retrieve the correct \c multi_instance and \c context
+ * associated with a given network address.
+ *
+ * @subsection tunnel_state_server_init Startup and initialization
+ *
+ * An OpenVPN process running in server-mode starts in the same \c main()
+ * function as it would in client-mode.  The same process-wide
+ * initialization is performed, and the resulting state and configuration
+ * is stored in a \c context structure. The server-mode and client-mode
+ * processes diverge when the \c main() function calls one of \c
+ * tunnel_point_to_point() or \c tunnel_server().
+ *
+ * In server-mode, \c main() calls the \c tunnel_server() function, which
+ * transfers control to \c tunnel_server_udp_single_threaded() or \c
+ * tunnel_server_tcp() depending on the external transport protocol.
+ *
+ * These functions receive the \c context created in \c main().  This
+ * object has a special status in server-mode, as it does not represent an
+ * active VPN tunnel, but does contain process-wide configuration
+ * parameters.  In the source code, it is often stored in "top" variables.
+ * To distinguish this object from other instances of the same type, its
+ * \c context.mode value is set to \c CM_TOP.  Other \c context objects,
+ * which do represent active VPN tunnels, have a \c context.mode set to \c
+ * CM_CHILD_UDP or \c CM_CHILD_TCP, depending on the external transport
+ * protocol.
+ *
+ * Both \c tunnel_server_udp_single_threaded() and \c tunnel_server_tcp()
+ * perform similar initialization.  In either case, a \c multi_context
+ * structure is created, and it is initialized according to the
+ * configuration stored in the top \c context by the \c multi_init() and
+ * \c multi_top_init() functions.
+ *
+ * @subsection tunnel_state_server_tunnels Creating and destroying VPN tunnels
+ *
+ * When an OpenVPN client makes a new connection to a server, the server
+ * creates a new \c context and \c multi_instance.  The latter is
+ * registered in the \c multi_context, which makes it possible for the
+ * external and internal multiplexers to retrieve the correct \c
+ * multi_instance and \c context when a network event occurs.
+ *
+ * @subsection tunnel_state_server_cleanup Final cleanup
+ *
+ * After the main event loop exits, both \c
+ * tunnel_server_udp_single_threaded() and \c tunnel_server_tcp() perform
+ * similar cleanup.  They call \c multi_uninit() followed by \c
+ * multi_top_free() to clean up the \c multi_context structure.
+ */
diff --git a/app/openvpn/doc/doxygen/openvpn.doxyfile b/app/openvpn/doc/doxygen/openvpn.doxyfile
new file mode 100644
index 00000000..5d87172c
--- /dev/null
+++ b/app/openvpn/doc/doxygen/openvpn.doxyfile
@@ -0,0 +1,279 @@
+# Doxyfile 1.5.5
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+DOXYFILE_ENCODING      = UTF-8
+PROJECT_NAME           = "OpenVPN"
+PROJECT_NUMBER         =
+OUTPUT_DIRECTORY       = doxygen
+CREATE_SUBDIRS         = NO
+OUTPUT_LANGUAGE        = English
+BRIEF_MEMBER_DESC      = YES
+REPEAT_BRIEF           = YES
+ABBREVIATE_BRIEF       = "The $name class" \
+                         "The $name widget" \
+                         "The $name file" \
+                         is \
+                         provides \
+                         specifies \
+                         contains \
+                         represents \
+                         a \
+                         an \
+                         the
+ALWAYS_DETAILED_SEC    = NO
+INLINE_INHERITED_MEMB  = NO
+FULL_PATH_NAMES        = YES
+STRIP_FROM_PATH        = ""
+STRIP_FROM_INC_PATH    =
+SHORT_NAMES            = NO
+JAVADOC_AUTOBRIEF      = YES # NO
+QT_AUTOBRIEF           = NO
+MULTILINE_CPP_IS_BRIEF = NO
+DETAILS_AT_TOP         = NO
+INHERIT_DOCS           = YES
+SEPARATE_MEMBER_PAGES  = NO
+TAB_SIZE               = 8
+ALIASES                =
+OPTIMIZE_OUTPUT_FOR_C  = YES
+OPTIMIZE_OUTPUT_JAVA   = NO
+OPTIMIZE_FOR_FORTRAN   = NO
+OPTIMIZE_OUTPUT_VHDL   = NO
+BUILTIN_STL_SUPPORT    = NO
+CPP_CLI_SUPPORT        = NO
+SIP_SUPPORT            = NO
+DISTRIBUTE_GROUP_DOC   = NO
+SUBGROUPING            = YES
+TYPEDEF_HIDES_STRUCT   = NO
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+EXTRACT_ALL            = YES
+EXTRACT_PRIVATE        = YES
+EXTRACT_STATIC         = YES
+EXTRACT_LOCAL_CLASSES  = YES
+EXTRACT_LOCAL_METHODS  = YES
+EXTRACT_ANON_NSPACES   = YES
+HIDE_UNDOC_MEMBERS     = NO
+HIDE_UNDOC_CLASSES     = NO
+HIDE_FRIEND_COMPOUNDS  = NO
+HIDE_IN_BODY_DOCS      = NO
+INTERNAL_DOCS          = NO
+CASE_SENSE_NAMES       = NO
+HIDE_SCOPE_NAMES       = NO
+SHOW_INCLUDE_FILES     = YES
+INLINE_INFO            = YES
+SORT_MEMBER_DOCS       = YES
+SORT_BRIEF_DOCS        = NO
+SORT_GROUP_NAMES       = NO
+SORT_BY_SCOPE_NAME     = NO
+GENERATE_TODOLIST      = YES
+GENERATE_TESTLIST      = YES
+GENERATE_BUGLIST       = YES
+GENERATE_DEPRECATEDLIST= YES
+ENABLED_SECTIONS       =
+MAX_INITIALIZER_LINES  = 30
+SHOW_USED_FILES        = YES
+SHOW_DIRECTORIES       = NO
+FILE_VERSION_FILTER    =
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+QUIET                  = NO
+WARNINGS               = YES
+WARN_IF_UNDOCUMENTED   = YES
+WARN_IF_DOC_ERROR      = YES
+WARN_NO_PARAMDOC       = NO
+WARN_FORMAT            = "$file:$line: $text"
+WARN_LOGFILE           =
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+INPUT                  = .
+INPUT_ENCODING         = UTF-8
+FILE_PATTERNS          = *.c \
+                         *.cc \
+                         *.cxx \
+                         *.cpp \
+                         *.c++ \
+                         *.d \
+                         *.java \
+                         *.ii \
+                         *.ixx \
+                         *.ipp \
+                         *.i++ \
+                         *.inl \
+                         *.h \
+                         *.hh \
+                         *.hxx \
+                         *.hpp \
+                         *.h++ \
+                         *.idl \
+                         *.odl \
+                         *.cs \
+                         *.php \
+                         *.php3 \
+                         *.inc \
+                         *.m \
+                         *.mm \
+                         *.dox \
+                         *.py \
+                         *.f90 \
+                         *.f \
+                         *.vhd \
+                         *.vhdl
+RECURSIVE              = YES
+EXCLUDE                =
+EXCLUDE_SYMLINKS       = NO
+EXCLUDE_PATTERNS       =
+EXCLUDE_SYMBOLS        =
+EXAMPLE_PATH           =
+EXAMPLE_PATTERNS       = *
+EXAMPLE_RECURSIVE      = NO
+IMAGE_PATH             =
+INPUT_FILTER           =
+FILTER_PATTERNS        =
+FILTER_SOURCE_FILES    = NO
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+SOURCE_BROWSER         = YES
+INLINE_SOURCES         = NO
+STRIP_CODE_COMMENTS    = YES
+REFERENCED_BY_RELATION = YES
+REFERENCES_RELATION    = YES
+REFERENCES_LINK_SOURCE = YES
+USE_HTAGS              = NO
+VERBATIM_HEADERS       = YES
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+ALPHABETICAL_INDEX     = NO
+COLS_IN_ALPHA_INDEX    = 5
+IGNORE_PREFIX          =
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+GENERATE_HTML          = YES
+HTML_OUTPUT            = html
+HTML_FILE_EXTENSION    = .html
+HTML_HEADER            =
+HTML_FOOTER            =
+HTML_STYLESHEET        =
+HTML_ALIGN_MEMBERS     = YES
+GENERATE_HTMLHELP      = NO
+GENERATE_DOCSET        = NO
+DOCSET_FEEDNAME        = "Doxygen generated docs"
+DOCSET_BUNDLE_ID       = org.doxygen.Project
+HTML_DYNAMIC_SECTIONS  = NO
+CHM_FILE               =
+HHC_LOCATION           =
+GENERATE_CHI           = NO
+BINARY_TOC             = NO
+TOC_EXPAND             = NO
+DISABLE_INDEX          = NO
+ENUM_VALUES_PER_LINE   = 4
+GENERATE_TREEVIEW      = NO
+TREEVIEW_WIDTH         = 250
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+GENERATE_LATEX         = YES
+LATEX_OUTPUT           = latex
+LATEX_CMD_NAME         = latex
+MAKEINDEX_CMD_NAME     = makeindex
+COMPACT_LATEX          = YES # NO
+PAPER_TYPE             = a4wide
+EXTRA_PACKAGES         =
+LATEX_HEADER           =
+PDF_HYPERLINKS         = YES
+USE_PDFLATEX           = YES
+LATEX_BATCHMODE        = NO
+LATEX_HIDE_INDICES     = NO
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+GENERATE_RTF           = NO
+RTF_OUTPUT             = rtf
+COMPACT_RTF            = NO
+RTF_HYPERLINKS         = NO
+RTF_STYLESHEET_FILE    =
+RTF_EXTENSIONS_FILE    =
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+GENERATE_MAN           = NO
+MAN_OUTPUT             = man
+MAN_EXTENSION          = .3
+MAN_LINKS              = NO
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+GENERATE_XML           = NO
+XML_OUTPUT             = xml
+XML_SCHEMA             =
+XML_DTD                =
+XML_PROGRAMLISTING     = YES
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+GENERATE_AUTOGEN_DEF   = NO
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+GENERATE_PERLMOD       = NO
+PERLMOD_LATEX          = NO
+PERLMOD_PRETTY         = YES
+PERLMOD_MAKEVAR_PREFIX =
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+ENABLE_PREPROCESSING   = YES
+MACRO_EXPANSION        = NO
+EXPAND_ONLY_PREDEF     = NO
+SEARCH_INCLUDES        = YES
+INCLUDE_PATH           =
+INCLUDE_FILE_PATTERNS  =
+PREDEFINED             = WIN32 NTLM USE_LZO ENABLE_FRAGMENT P2MP P2MP_SERVER USE_CRYPTO USE_SSL ENABLE_PLUGIN ENABLE_MANAGEMENT ENABLE_OCC HAVE_GETTIMEOFDAY
+EXPAND_AS_DEFINED      =
+SKIP_FUNCTION_MACROS   = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+TAGFILES               =
+GENERATE_TAGFILE       =
+ALLEXTERNALS           = NO
+EXTERNAL_GROUPS        = YES
+PERL_PATH              = /usr/bin/perl
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+CLASS_DIAGRAMS         = NO
+MSCGEN_PATH            =
+HIDE_UNDOC_RELATIONS   = YES
+HAVE_DOT               = YES
+CLASS_GRAPH            = YES
+COLLABORATION_GRAPH    = YES
+GROUP_GRAPHS           = YES
+UML_LOOK               = NO
+TEMPLATE_RELATIONS     = NO
+INCLUDE_GRAPH          = YES
+INCLUDED_BY_GRAPH      = YES
+CALL_GRAPH             = NO # YES
+CALLER_GRAPH           = NO # YES
+GRAPHICAL_HIERARCHY    = YES
+DIRECTORY_GRAPH        = YES
+DOT_IMAGE_FORMAT       = png
+DOT_PATH               = "/usr/bin/dot"
+DOTFILE_DIRS           =
+DOT_GRAPH_MAX_NODES    = 50
+MAX_DOT_GRAPH_DEPTH    = 1000
+DOT_TRANSPARENT        = YES
+DOT_MULTI_TARGETS      = NO
+GENERATE_LEGEND        = YES
+DOT_CLEANUP            = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine
+#---------------------------------------------------------------------------
+SEARCHENGINE           = NO
diff --git a/app/openvpn/doc/management-notes.txt b/app/openvpn/doc/management-notes.txt
new file mode 100644
index 00000000..ef39b855
--- /dev/null
+++ b/app/openvpn/doc/management-notes.txt
@@ -0,0 +1,1039 @@
+OpenVPN Management Interface Notes
+----------------------------------
+
+The OpenVPN Management interface allows OpenVPN to
+be administratively controlled from an external program via
+a TCP or unix domain socket.
+
+The interface has been specifically designed for developers
+who would like to programmatically or remotely control
+an OpenVPN daemon, and can be used when OpenVPN is running
+as a client or server.
+
+The management interface is implemented using a client/server TCP
+connection or unix domain socket where OpenVPN will listen on a
+provided IP address and port for incoming management client connections.
+
+The management protocol is currently cleartext without an explicit
+security layer.  For this reason, it is recommended that the
+management interface either listen on a unix domain socket,
+localhost (127.0.0.1), or on the local VPN address.  It's possible
+to remotely connect to the management interface over the VPN itself,
+though some capabilities will be limited in this mode, such as the
+ability to provide private key passwords.
+
+The management interface is enabled in the OpenVPN
+configuration file using the following directive:
+
+--management
+
+See the man page for documentation on this and related
+directives.
+
+Once OpenVPN has started with the management layer enabled,
+you can telnet to the management port (make sure to use
+a telnet client which understands "raw" mode).
+
+Once connected to the management port, you can use
+the "help" command to list all commands.
+
+COMMAND -- bytecount
+--------------------
+
+The bytecount command is used to request real-time notification
+of OpenVPN bandwidth usage.
+
+Command syntax:
+
+  bytecount n (where n > 0) -- set up automatic notification of
+                               bandwidth usage once every n seconds
+  bytecount 0 -- turn off bytecount notifications
+
+If OpenVPN is running as a client, the bytecount notification
+will look like this:
+
+  >BYTECOUNT:{BYTES_IN},{BYTES_OUT}
+
+BYTES_IN is the number of bytes that have been received from
+the server and BYTES_OUT is the number of bytes that have been
+sent to the server.
+
+If OpenVPN is running as a server, the bytecount notification
+will look like this:
+
+  >BYTECOUNT_CLI:{CID},{BYTES_IN},{BYTES_OUT}
+ 
+CID is the Client ID, BYTES_IN is the number of bytes that have
+been received from the client and BYTES_OUT is the number of
+bytes that have been sent to the client.
+
+Note that when the bytecount command is used on the server, every
+connected client will report its bandwidth numbers once every n
+seconds.
+
+When the client disconnects, the final bandwidth numbers will be
+placed in the 'bytes_received' and 'bytes_sent' environmental variables
+as included in the >CLIENT:DISCONNECT notification.
+
+COMMAND -- echo
+---------------
+
+The echo capability is used to allow GUI-specific
+parameters to be either embedded in the OpenVPN config file
+or pushed to an OpenVPN client from a server.
+
+Command examples:
+
+  echo on      -- turn on real-time notification of echo messages
+  echo all     -- print the current echo history list
+  echo off     -- turn off real-time notification of echo messages
+  echo on all  -- atomically enable real-time notification,
+                  plus show any messages in history buffer
+
+For example, suppose you are developing a OpenVPN GUI and
+you want to give the OpenVPN server the ability to ask
+the GUI to forget any saved passwords.
+
+In the OpenVPN server config file, add:
+
+  push "echo forget-passwords"
+
+When the OpenVPN client receives its pulled list of directives
+from the server, the "echo forget-passwords" directive will
+be in the list, and it will cause the management interface
+to save the "forget-passwords" string in its list of echo
+parameters.
+
+The management client can use "echo all" to output the full
+list of echoed parameters, "echo on" to turn on real-time
+notification of echoed parameters via the ">ECHO:" prefix,
+or "echo off" to turn off real-time notification.
+
+When the GUI connects to the OpenVPN management socket, it
+can issue an "echo all" command, which would produce output
+like this:
+
+  1101519562,forget-passwords
+  END
+
+Essentially the echo command allowed us to pass parameters from
+the OpenVPN server to the OpenVPN client, and then to the
+management client (such as a GUI).  The large integer is the
+unix date/time when the echo parameter was received.
+
+If the management client had issued the command "echo on",
+it would have enabled real-time notifications of echo
+parameters.  In this case, our "forget-passwords" message
+would be output like this:
+
+  >ECHO:1101519562,forget-passwords
+
+Like the log command, the echo command can atomically show
+history while simultaneously activating real-time updates:
+
+  echo on all
+
+The size of the echo buffer is currently hardcoded to 100
+messages.
+
+COMMAND -- exit, quit
+---------------------
+
+Close the managment session, and resume listening on the
+management port for connections from other clients. Currently,
+the OpenVPN daemon can at most support a single management client
+any one time.
+
+COMMAND -- help
+---------------
+
+Print a summary of commands.
+
+COMMAND -- hold
+---------------
+
+The hold command can be used to manipulate the hold flag,
+or release OpenVPN from a hold state.
+
+If the hold flag is set on initial startup or
+restart, OpenVPN will hibernate prior to initializing
+the tunnel until the management interface receives
+a "hold release" command.
+
+The --management-hold directive of OpenVPN can be used
+to start OpenVPN with the hold flag set.
+
+The hold flag setting is persistent and will not
+be reset by restarts.
+
+OpenVPN will indicate that it is in a hold state by
+sending a real-time notification to the management
+client:
+
+  >HOLD:Waiting for hold release
+
+Command examples:
+
+  hold         -- show current hold flag, 0=off, 1=on.
+  hold on      -- turn on hold flag so that future restarts
+                  will hold.
+  hold off     -- turn off hold flag so that future restarts will
+                  not hold.
+  hold release -- leave hold state and start OpenVPN, but
+                  do not alter the current hold flag setting.
+
+COMMAND -- kill
+---------------
+
+In server mode, kill a particlar client instance.
+
+Command examples:
+
+  kill Test-Client -- kill the client instance having a
+                      common name of "Test-Client".
+  kill 1.2.3.4:4000 -- kill the client instance having a
+                       source address and port of 1.2.3.4:4000
+
+Use the "status" command to see which clients are connected.
+
+COMMAND -- log
+--------------
+
+Show the OpenVPN log file.  Only the most recent n lines
+of the log file are cached by the management interface, where
+n is controlled by the OpenVPN --management-log-cache directive.
+
+Command examples:
+
+  log on     -- Enable real-time output of log messages.
+  log all    -- Show currently cached log file history.
+  log on all -- Atomically show all currently cached log file
+                history then enable real-time notification of
+                new log file messages.
+  log off    -- Turn off real-time notification of log messages.
+  log 20     -- Show the most recent 20 lines of log file history.
+
+Real-time notification format:
+
+Real-time log messages begin with the ">LOG:" prefix followed
+by the following comma-separated fields:
+
+  (a) unix integer date/time,
+  (b) zero or more message flags in a single string:
+      I -- informational
+      F -- fatal error
+      N -- non-fatal error
+      W -- warning
+      D -- debug, and
+  (c) message text.
+
+COMMAND -- mute
+---------------
+
+Change the OpenVPN --mute parameter.  The mute parameter is
+used to silence repeating messages of the same message
+category.
+
+Command examples:
+
+  mute 40 -- change the mute parameter to 40
+  mute    -- show the current mute setting
+
+COMMAND -- net
+--------------
+
+(Windows Only) Produce output equivalent to the OpenVPN
+--show-net directive.  The output includes OpenVPN's view
+of the system network adapter list and routing table based
+on information returned by the Windows IP helper API.
+
+COMMAND -- pid
+--------------
+
+Shows the process ID of the current OpenVPN process.
+
+COMMAND -- password and username
+--------------------------------
+
+  The password command is used to pass passwords to OpenVPN.
+
+  If OpenVPN is run with the --management-query-passwords
+  directive, it will query the management interface for RSA
+  private key passwords and the --auth-user-pass
+  username/password.
+
+  When OpenVPN needs a password from the management interface,
+  it will produce a real-time ">PASSWORD:" message.
+
+  Example 1:
+
+    >PASSWORD:Need 'Private Key' password
+
+  OpenVPN is indicating that it needs a password of type
+  "Private Key".
+
+  The management client should respond to this query as follows:
+
+    password "Private Key" foo
+
+  Example 2:
+
+    >PASSWORD:Need 'Auth' username/password
+
+  OpenVPN needs a --auth-user-pass password.  The management
+  client should respond:
+
+    username "Auth" foo
+    password "Auth" bar
+
+  The username/password itself can be in quotes, and special
+  characters such as double quote or backslash must be escaped,
+  for example,
+
+    password "Private Key" "foo\"bar"
+
+  The escaping rules are the same as for the config file.
+  See the "Command Parsing" section below for more info.
+
+  The PASSWORD real-time message type can also be used to
+  indicate password or other types of authentication failure:
+
+  Example 3: The private key password is incorrect and OpenVPN
+  is exiting:
+
+    >PASSWORD:Verification Failed: 'Private Key'
+
+  Example 4: The --auth-user-pass username/password failed,
+  and OpenVPN is exiting:
+
+    >PASSWORD:Verification Failed: 'Auth'
+
+  Example 5: The --auth-user-pass username/password failed,
+  and the server provided a custom client-reason-text string
+  using the client-deny server-side management interface command.
+
+    >PASSWORD:Verification Failed: 'custom server-generated string'
+
+COMMAND -- forget-passwords
+---------------------------
+
+The forget-passwords command will cause the daemon to forget passwords
+entered during the session.
+
+Command example:
+
+  forget-passwords -- forget passwords entered so far.
+
+COMMAND -- signal
+-----------------
+
+The signal command will send a signal to the OpenVPN daemon.
+The signal can be one of SIGHUP, SIGTERM, SIGUSR1, or SIGUSR2.
+
+Command example:
+
+  signal SIGUSR1 -- send a SIGUSR1 signal to daemon
+
+COMMAND -- state
+----------------
+
+Show the current OpenVPN state, show state history, or
+enable real-time notification of state changes.
+
+These are the OpenVPN states:
+
+CONNECTING    -- OpenVPN's initial state.
+WAIT          -- (Client only) Waiting for initial response
+                 from server.
+AUTH          -- (Client only) Authenticating with server.
+GET_CONFIG    -- (Client only) Downloading configuration options
+                 from server.
+ASSIGN_IP     -- Assigning IP address to virtual network
+                 interface.
+ADD_ROUTES    -- Adding routes to system.
+CONNECTED     -- Initialization Sequence Completed.
+RECONNECTING  -- A restart has occurred.
+EXITING       -- A graceful exit is in progress.
+
+Command examples:
+
+  state        -- Print current OpenVPN state.
+  state on     -- Enable real-time notification of state changes.
+  state off    -- Disable real-time notification of state changes.
+  state all    -- Print current state history.
+  state 3      -- Print the 3 most recent state transitions.
+  state on all -- Atomically show state history while at the
+                  same time enable real-time state notification
+		  of future state transitions.
+
+The output format consists of 4 comma-separated parameters: 
+  (a) the integer unix date/time,
+  (b) the state name,
+  (c) optional descriptive string (used mostly on RECONNECTING
+      and EXITING to show the reason for the disconnect),
+  (d) optional TUN/TAP local IP address (shown for ASSIGN_IP
+      and CONNECTED), and
+  (e) optional address of remote server (OpenVPN 2.1 or higher).
+
+Real-time state notifications will have a ">STATE:" prefix
+prepended to them.
+
+COMMAND -- status
+-----------------
+
+Show current daemon status information, in the same format as
+that produced by the OpenVPN --status directive.
+
+Command examples:
+
+status   -- Show status information using the default status
+            format version.
+
+status 3 -- Show status information using the format of
+            --status-version 3.
+
+COMMAND -- username
+-------------------
+
+See the "password" section above.
+
+COMMAND -- verb
+---------------
+
+Change the OpenVPN --verb parameter.  The verb parameter
+controls the output verbosity, and may range from 0 (no output)
+to 15 (maximum output).  See the OpenVPN man page for additional
+info on verbosity levels.
+
+Command examples:
+
+  verb 4  -- change the verb parameter to 4
+  mute    -- show the current verb setting
+
+COMMAND -- version
+------------------
+
+Show the current OpenVPN and Management Interface versions.
+
+
+COMMAND -- auth-retry
+---------------------
+
+Set the --auth-retry setting to control how OpenVPN responds to
+username/password authentication errors.  See the manual page
+for more info.
+
+Command examples:
+
+  auth-retry interact -- Don't exit when bad username/passwords are entered.
+                         Query for new input and retry.
+
+COMMAND -- needok  (OpenVPN 2.1 or higher)
+------------------------------------------
+
+Confirm a ">NEED-OK" real-time notification, normally used by
+OpenVPN to block while waiting for a specific user action.
+
+Example:
+
+  OpenVPN needs the user to insert a cryptographic token,
+  so it sends a real-time notification:
+
+    >NEED-OK:Need 'token-insertion-request' confirmation MSG:Please insert your cryptographic token
+
+  The management client, if it is a GUI, can flash a dialog
+  box containing the text after the "MSG:" marker to the user.
+  When the user acknowledges the dialog box,
+  the management client can issue this command:
+
+     needok token-insertion-request ok
+  or
+     needok token-insertion-request cancel
+
+COMMAND -- needstr  (OpenVPN 2.1 or higher)
+-------------------------------------------
+
+Confirm a ">NEED-STR" real-time notification, normally used by
+OpenVPN to block while waiting for a specific user input.
+
+Example:
+
+  OpenVPN needs the user to specify some input, so it sends a
+  real-time notification:
+
+    >NEED-STR:Need 'name' input MSG:Please specify your name
+
+  The management client, if it is a GUI, can flash a dialog
+  box containing the text after the "MSG:" marker to the user.
+  When the user acknowledges the dialog box,
+  the management client can issue this command:
+
+     needstr name "John"
+
+COMMAND -- pkcs11-id-count  (OpenVPN 2.1 or higher)
+---------------------------------------------------
+
+Retrieve available number of certificates.
+
+Example:
+
+     pkcs11-id-count
+     >PKCS11ID-COUNT:5
+
+COMMAND -- pkcs11-id-get  (OpenVPN 2.1 or higher)
+-------------------------------------------------
+
+Retrieve certificate by index, the ID string should be provided
+as PKCS#11 identity, the blob is BASE64 encoded certificate.
+
+Example:
+
+     pkcs11-id-get 1
+     PKCS11ID-ENTRY:'1', ID:'<snip>', BLOB:'<snip>'
+
+COMMAND -- client-auth  (OpenVPN 2.1 or higher)
+-----------------------------------------------
+
+Authorize a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request and specify
+"client-connect" configuration directives in a subsequent text block.
+
+The OpenVPN server should have been started with the
+--management-client-auth directive so that it will ask the management
+interface to approve client connections.
+
+
+  client-auth {CID} {KID}
+  line_1
+  line_2
+  ...
+  line_n
+  END
+
+CID,KID -- client ID and Key ID.  See documentation for ">CLIENT:"
+notification for more info.
+
+line_1 to line_n -- client-connect configuration text block, as would be
+returned by a --client-connect script.  The text block may be null, with
+"END" immediately following the "client-auth" line (using a null text
+block is equivalent to using the client-auth-nt command).
+
+A client-connect configuration text block contains OpenVPN directives
+that will be applied to the client instance object representing a newly
+connected client.
+
+COMMAND -- client-auth-nt  (OpenVPN 2.1 or higher)
+--------------------------------------------------
+
+Authorize a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request without specifying
+client-connect configuration text.
+
+The OpenVPN server should have been started with the
+--management-client-auth directive so that it will ask the management
+interface to approve client connections.
+
+  client-auth-nt {CID} {KID}
+
+CID,KID -- client ID and Key ID.  See documentation for ">CLIENT:"
+notification for more info.
+
+COMMAND -- client-deny  (OpenVPN 2.1 or higher)
+-----------------------------------------------
+
+Deny a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request.
+
+  client-deny {CID} {KID} "reason-text" ["client-reason-text"]
+
+CID,KID -- client ID and Key ID.  See documentation for ">CLIENT:"
+notification for more info.
+
+reason-text: a human-readable message explaining why the authentication
+request was denied.  This message will be output to the OpenVPN log
+file or syslog.
+
+client-reason-text: a message that will be sent to the client as
+part of the AUTH_FAILED message.
+
+Note that client-deny denies a specific Key ID (pertaining to a
+TLS renegotiation).  A client-deny command issued in response to
+an initial TLS key negotiation (notified by ">CLIENT:CONNECT") will
+terminate the client session after returning "AUTH-FAILED" to the client.
+On the other hand, a client-deny command issued in response to
+a TLS renegotiation (">CLIENT:REAUTH") will invalidate the renegotiated
+key, however the TLS session associated with the currently active
+key will continue to live for up to --tran-window seconds before
+expiration.
+
+To immediately kill a client session, use "client-kill".
+
+COMMAND -- client-kill  (OpenVPN 2.1 or higher)
+-----------------------------------------------
+
+Immediately kill a client instance by CID.
+
+  client-kill {CID}
+
+CID -- client ID.  See documentation for ">CLIENT:" notification for more
+info.
+
+COMMAND -- client-pf  (OpenVPN 2.1 or higher)
+---------------------------------------------
+
+Push a packet filter file to a specific client.
+
+The OpenVPN server should have been started with the
+--management-client-pf directive so that it will require that
+VPN tunnel packets sent or received by client instances must
+conform to that client's packet filter configuration.
+
+  client-pf {CID}
+  line_1
+  line_2
+  ...
+  line_n
+  END
+
+CID -- client ID.  See documentation for ">CLIENT:" notification for
+more info.
+
+line_1 to line_n -- the packet filter configuration file for this
+client.
+
+Packet filter file grammar:
+
+ [CLIENTS DROP|ACCEPT]
+ {+|-}common_name1
+ {+|-}common_name2
+ . . .
+ [SUBNETS DROP|ACCEPT]
+ {+|-}subnet1
+ {+|-}subnet2
+ . . .
+ [END]
+
+ Subnet: IP-ADDRESS | IP-ADDRESS/NUM_NETWORK_BITS | "unknown"
+
+ CLIENTS refers to the set of clients (by their common-name) which
+ this instance is allowed ('+') to connect to, or is excluded ('-')
+ from connecting to.  Note that in the case of client-to-client
+ connections, such communication must be allowed by the packet filter
+ configuration files of both clients AND the --client-to-client
+ directive must have been specified in the OpenVPN server config.
+
+ SUBNETS refers to IP addresses or IP address subnets which this
+ client instance may connect to ('+') or is excluded ('-') from
+ connecting to, and applies to IPv4 and ARP packets.  The special
+ "unknown" tag refers to packets of unknown type, i.e. a packet that
+ is not IPv4 or ARP.
+
+ DROP or ACCEPT defines default policy when there is no explicit match
+ for a common-name or subnet.  The [END] tag must exist.
+
+ Notes:
+
+ * The SUBNETS section currently only supports IPv4 addresses and
+   subnets.
+
+ * A given client or subnet rule applies to both incoming and
+   outgoing packets.
+
+ * The CLIENTS list is order-invariant.  Because the list is stored
+   as a hash-table, the order of the list does not affect its function.
+
+ * The SUBNETS table is scanned sequentially, and the first item to
+   match is chosen.  Therefore the SUBNETS table is NOT order-invariant.
+
+ * No client-to-client communication is allowed unless the
+   --client-to-client configuration directive is enabled AND
+   the CLIENTS list of BOTH clients allows the communication.
+
+Example packet filter spec, as transmitted to the management interface:
+
+ client-pf 42
+ [CLIENTS ACCEPT]
+ -accounting
+ -enigma
+ [SUBNETS DROP]
+ -10.46.79.9
+ +10.0.0.0/8
+ [END]
+ END
+
+The above example sets the packet filter policy for the client
+identified by CID=42.  This client may connect to all other clients
+except those having a common name of "accounting" or "enigma".
+The client may only interact with external IP addresses in the
+10.0.0.0/8 subnet, however access to 10.46.79.9 is specifically
+excluded.
+
+Another example packet filter spec, as transmitted to the
+management interface:
+
+ client-pf 99
+ [CLIENTS DENY]
+ +public
+ [SUBNETS ACCEPT]
+ +10.10.0.1
+ -10.0.0.0/8
+ -unknown
+ [END]
+ END
+
+The above example sets the packet filter policy for the client
+identified by CID=99.  This client may not connect to any other
+clients except those having a common name of "public".  It may
+interact with any external IP address except those in the
+10.0.0.0/8 netblock.  However interaction with one address in
+the 10.0.0.0/8 netblock is allowed: 10.10.0.1.  Also, the client
+may not interact with external IP addresses using an "unknown"
+protocol (i.e. one that is not IPv4 or ARP).
+
+COMMAND -- remote  (OpenVPN AS 2.1.5/OpenVPN 2.3 or higher)
+--------------------------------------------
+
+Provide remote host/port in response to a >REMOTE notification
+(client only).  Requires that the --management-query-remote
+directive is used.
+
+  remote ACTION [HOST PORT]
+
+The "remote" command should only be given in response to a >REMOTE
+notification.  For example, the following >REMOTE notification
+indicates that the client config file would ordinarily connect
+to vpn.example.com port 1194 (UDP):
+
+  >REMOTE:vpn.example.com,1194,udp
+
+Now, suppose we want to override the host and port, connecting
+instead to vpn.otherexample.com port 1234.  After receiving
+the above notification, use this command:
+
+  remote MOD vpn.otherexample.com 1234
+
+To accept the same host and port as the client would ordinarily
+have connected to, use this command:
+
+  remote ACCEPT
+
+To skip the current connection entry and advance to the next one,
+use this command:
+
+  remote SKIP
+
+COMMAND -- proxy  (OpenVPN 2.3 or higher)
+--------------------------------------------
+
+Provide proxy server host/port and flags in response to a >PROXY
+notification (client only).  Requires that the --management-query-proxy
+directive is used.
+
+  proxy TYPE HOST PORT ["nct"]
+
+The "proxy" command must only be given in response to a >PROXY
+notification.  Use the "nct" flag if you only want to allow
+non-cleartext auth with the proxy server.  The following >PROXY
+notification indicates that the client config file would ordinarily
+connect to the first --remote configured, vpn.example.com using TCP:
+
+  >PROXY:1,TCP,vpn.example.com
+
+Now, suppose we want to connect to the remote host using the proxy server
+proxy.intranet port 8080 with secure authentication only, if required.
+After receiving the above notification, use this command:
+
+  proxy HTTP proxy.intranet 8080 nct
+
+You can also use the SOCKS keyword to pass a SOCKS server address, like:
+
+  proxy SOCKS fe00::1 1080
+
+To accept connecting to the host and port directly, use this command:
+
+  proxy NONE
+
+COMMAND -- rsa-sig (OpenVPN 2.3 or higher)
+------------------------------------------
+Provides support for external storage of the private key. Requires the
+--management-external-key option. This option can be used instead of "key"
+in client mode, and allows the client to run without the need to load the
+actual private key. When the SSL protocol needs to perform an RSA sign
+operation, the data to be signed will be sent to the management interface
+via a notification as follows:
+
+>RSA_SIGN:[BASE64_DATA]
+
+The management interface client should then sign BASE64_DATA
+using the private key and return the SSL signature as follows:
+
+rsa-sig
+[BASE64_SIG_LINE]
+.
+.
+.
+END
+
+Base64 encoded output of RSA_sign(NID_md5_sha1,... will provide a
+correct signature.
+
+This capability is intended to allow the use of arbitrary cryptographic
+service providers with OpenVPN via the management interface.
+
+
+OUTPUT FORMAT
+-------------
+
+(1) Command success/failure indicated by "SUCCESS: [text]" or
+    "ERROR: [text]".
+
+(2) For commands which print multiple lines of output,
+    the last line will be "END".
+
+(3) Real-time messages will be in the form ">[source]:[text]",
+    where source is "CLIENT", "ECHO", "FATAL", "HOLD", "INFO", "LOG",
+    "NEED-OK", "PASSWORD", or "STATE".
+
+REAL-TIME MESSAGE FORMAT
+------------------------
+
+The OpenVPN management interface produces two kinds of
+output: (a) output from a command, or (b) asynchronous,
+real-time output which can be generated at any time.
+
+Real-time messages start with a '>' character in the first
+column and are immediately followed by a type keyword
+indicating the type of real-time message.  The following
+types are currently defined:
+
+BYTECOUNT -- Real-time bandwidth usage notification, as enabled
+             by "bytecount" command when OpenVPN is running as
+             a client.
+
+BYTECOUNT_CLI -- Real-time bandwidth usage notification per-client,
+	         as enabled by "bytecount" command when OpenVPN is
+                 running as a server.
+
+CLIENT   -- Notification of client connections and disconnections
+            on an OpenVPN server.  Enabled when OpenVPN is started
+            with the --management-client-auth option.  CLIENT
+            notifications may be multi-line.  See "The CLIENT
+            notification" section below for detailed info.
+
+ECHO     -- Echo messages as controlled by the "echo" command.
+
+FATAL    -- A fatal error which is output to the log file just
+            prior to OpenVPN exiting.
+
+HOLD     -- Used to indicate that OpenVPN is in a holding state
+            and will not start until it receives a
+            "hold release" command.
+
+INFO     -- Informational messages such as the welcome message.
+
+LOG      -- Log message output as controlled by the "log" command.
+
+NEED-OK  -- OpenVPN needs the end user to do something, such as
+            insert a cryptographic token.  The "needok" command can
+            be used to tell OpenVPN to continue.
+
+NEED-STR -- OpenVPN needs information from end, such as
+            a certificate to use.  The "needstr" command can
+            be used to tell OpenVPN to continue.
+
+PASSWORD -- Used to tell the management client that OpenVPN
+            needs a password, also to indicate password
+            verification failure.
+
+STATE    -- Shows the current OpenVPN state, as controlled
+            by the "state" command.
+
+The CLIENT notification
+-----------------------
+
+The ">CLIENT:" notification is enabled by the --management-client-auth
+OpenVPN configuration directive that gives the management interface client
+the responsibility to authenticate OpenVPN clients after their client
+certificate has been verified.  CLIENT notifications may be multi-line, and
+the sequentiality of a given CLIENT notification, its associated environmental
+variables, and the terminating ">CLIENT:ENV,END" line are guaranteed to be
+atomic.
+
+CLIENT notification types:
+
+(1) Notify new client connection ("CONNECT") or existing client TLS session
+    renegotiation ("REAUTH").  Information about the client is provided
+    by a list of environmental variables which are documented in the OpenVPN
+    man page.  The environmental variables passed are equivalent to those
+    that would be passed to an --auth-user-pass-verify script.
+
+    >CLIENT:CONNECT|REAUTH,{CID},{KID}
+    >CLIENT:ENV,name1=val1
+    >CLIENT:ENV,name2=val2
+    >CLIENT:ENV,...
+    >CLIENT:ENV,END
+
+(2) Notify successful client authentication and session initiation.
+    Called after CONNECT.
+
+    >CLIENT:ESTABLISHED,{CID}
+    >CLIENT:ENV,name1=val1
+    >CLIENT:ENV,name2=val2
+    >CLIENT:ENV,...
+    >CLIENT:ENV,END
+
+(3) Notify existing client disconnection.  The environmental variables passed
+    are equivalent to those that would be passed to a --client-disconnect
+    script.
+
+    >CLIENT:DISCONNECT,{CID}
+    >CLIENT:ENV,name1=val1
+    >CLIENT:ENV,name2=val2
+    >CLIENT:ENV,...
+    >CLIENT:ENV,END
+
+(4) Notify that a particular virtual address or subnet
+    is now associated with a specific client.
+
+    >CLIENT:ADDRESS,{CID},{ADDR},{PRI}
+
+Variables:
+
+CID --  Client ID, numerical ID for each connecting client, sequence = 0,1,2,...
+KID --  Key ID, numerical ID for the key associated with a given client TLS session,
+        sequence = 0,1,2,...
+PRI --  Primary (1) or Secondary (0) VPN address/subnet.  All clients have at least
+        one primary IP address.  Secondary address/subnets are associated with
+        client-specific "iroute" directives.
+ADDR -- IPv4 address/subnet in the form 1.2.3.4 or 1.2.3.0/255.255.255.0
+
+In the unlikely scenario of an extremely long-running OpenVPN server,
+CID and KID should be assumed to recycle to 0 after (2^32)-1, however this
+recycling behavior is guaranteed to be collision-free.
+
+Command Parsing
+---------------
+
+The management interface uses the same command line lexical analyzer
+as is used by the OpenVPN config file parser.
+
+Whitespace is a parameter separator.
+
+Double quotation or single quotation characters ("", '') can be used
+to enclose parameters containing whitespace.
+
+Backslash-based shell escaping is performed, using the following
+mappings, when not in single quotations:
+
+\\       Maps to a single backslash character (\).
+\"       Pass a literal doublequote character ("), don't
+         interpret it as enclosing a parameter.
+\[SPACE] Pass a literal space or tab character, don't
+         interpret it as a parameter delimiter.
+
+Challenge/Response Protocol
+---------------------------
+
+The OpenVPN Challenge/Response Protocol allows an OpenVPN server to
+generate challenge questions that are shown to the user, and to see
+the user's responses to those challenges.  Based on the responses, the
+server can allow or deny access.
+
+In this way, the OpenVPN Challenge/Response Protocol can be used
+to implement multi-factor authentication.  Two different
+variations on the challenge/response protocol are supported: the
+"Dynamic" and "Static" protocols.
+
+The basic idea of Challenge/Response is that the user must enter an
+additional piece of information, in addition to the username and
+password, to successfully authenticate.  Normally, this information
+is used to prove that the user posesses a certain key-like device
+such as cryptographic token or a particular mobile phone.
+
+Dynamic protocol:
+
+The OpenVPN dynamic challenge/response protocol works by returning
+a specially formatted error message after initial successful
+authentication.  This error message contains the challenge question,
+and is formatted as such:
+
+  CRV1:<flags>:<state_id>:<username_base64>:<challenge_text>
+
+flags: a series of optional, comma-separated flags:
+ E : echo the response when the user types it
+ R : a response is required
+
+state_id: an opaque string that should be returned to the server
+ along with the response.
+
+username_base64 : the username formatted as base64
+
+challenge_text : the challenge text to be shown to the user
+
+Example challenge:
+
+  CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN
+
+After showing the challenge_text and getting a response from the user
+(if R flag is specified), the client should submit the following
+auth creds back to the OpenVPN server:
+
+Username: [username decoded from username_base64]
+Password: CRV1::<state_id>::<response_text>
+
+Where state_id is taken from the challenge request and response_text
+is what the user entered in response to the challenge_text.
+If the R flag is not present, response_text may be the empty
+string.
+
+Example response (suppose the user enters "8675309" for the token PIN):
+
+  Username: cr1 ("Y3Ix" base64 decoded)
+  Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
+
+Static protocol:
+
+The static protocol differs from the dynamic protocol in that the
+challenge question and response field is given to the user in the
+initial username/password dialog, and the username, password, and
+response are delivered back to the server in a single transaction.
+
+The "static-challenge" directive is used to give the challenge text
+to OpenVPN and indicate whether or not the response should be echoed.
+
+When the "static-challenge" directive is used, the management
+interface will respond as such when credentials are needed:
+
+  >PASSWORD:Need 'Auth' username/password SC:<ECHO>,<TEXT>
+
+  ECHO: "1" if response should be echoed, "0" to not echo
+  TEXT: challenge text that should be shown to the user to
+      facilitate their response
+
+For example:
+
+  >PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN
+
+The above notification indicates that OpenVPN needs a --auth-user-pass
+password plus a response to a static challenge ("Please enter token PIN").
+The "1" after the "SC:" indicates that the response should be echoed.
+
+The management interface client in this case should add the static
+challenge text to the auth dialog followed by a field for the user to
+enter a response.  Then the client should pack the password and response
+together into an encoded password:
+
+  username "Auth" foo
+  password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>"
+
+For example, if the user entered "bar" as the password and 8675309
+as the PIN, the following management interface commands should be
+issued:
+
+  username "Auth" foo
+  password "Auth" "SCRV1:Zm9v:ODY3NTMwOQ=="
+
+Client-side support for challenge/response protocol:
+
+Currently, the Access Server client and standalone OpenVPN
+client support both static and dynamic challenge/response
+protocols.  However, any OpenVPN client UI that drives OpenVPN
+via the management interface needs to add explicit support
+for the challenge/response protocol.
diff --git a/app/openvpn/doc/openvpn.8 b/app/openvpn/doc/openvpn.8
new file mode 100644
index 00000000..d66bd665
--- /dev/null
+++ b/app/openvpn/doc/openvpn.8
@@ -0,0 +1,6438 @@
+.\"  OpenVPN -- An application to securely tunnel IP networks
+.\"             over a single TCP/UDP port, with support for SSL/TLS-based
+.\"             session authentication and key exchange,
+.\"             packet encryption, packet authentication, and
+.\"             packet compression.
+.\"
+.\"  Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
+.\"
+.\"  This program is free software; you can redistribute it and/or modify
+.\"  it under the terms of the GNU General Public License version 2
+.\"  as published by the Free Software Foundation.
+.\"
+.\"  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.
+.\"
+.\"  You should have received a copy of the GNU General Public License
+.\"  along with this program (see the file COPYING included with this
+.\"  distribution); if not, write to the Free Software Foundation, Inc.,
+.\"  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+.\"
+.\" Manual page for openvpn
+.\
+.\" SH section heading
+.\" SS subsection heading
+.\" LP paragraph
+.\" IP indented paragraph
+.\" TP hanging label
+.\
+.\" .nf -- no formatting
+.\" .fi -- resume formatting
+.\" .ft 3 -- boldface
+.\" .ft -- normal face
+.\" .in +|-{n} -- indent
+.\"
+.TH openvpn 8 "17 November 2008"
+.\"*********************************************************
+.SH NAME
+openvpn \- secure IP tunnel daemon.
+.\"*********************************************************
+.SH SYNOPSIS
+.ft 3
+openvpn [ options ... ]
+.ft
+.\"*********************************************************
+.SH INTRODUCTION
+.LP
+OpenVPN is an open source VPN daemon by James Yonan.
+Because OpenVPN tries to
+be a universal VPN tool offering a great deal of flexibility,
+there are a lot of options on this manual page.
+If you're new to OpenVPN, you might want to skip ahead to the
+examples section where you will see how to construct simple
+VPNs on the command line without even needing a configuration file.
+
+Also note that there's more documentation and examples on
+the OpenVPN web site:
+.I http://openvpn.net/
+
+And if you would like to see a shorter version of this manual,
+see the openvpn usage message which can be obtained by
+running
+.B openvpn
+without any parameters.
+.\"*********************************************************
+.SH DESCRIPTION
+.LP
+OpenVPN is a robust and highly flexible VPN daemon.
+OpenVPN supports SSL/TLS security, ethernet bridging,
+TCP or UDP tunnel transport through proxies or NAT,
+support for dynamic IP addresses and DHCP,
+scalability to hundreds or thousands of users,
+and portability to most major OS platforms.
+
+OpenVPN is tightly bound to the OpenSSL library, and derives much
+of its crypto capabilities from it.
+
+OpenVPN supports
+conventional encryption
+using a pre-shared secret key
+.B (Static Key mode)
+or
+public key security
+.B (SSL/TLS mode)
+using client & server certificates.
+OpenVPN also
+supports non-encrypted TCP/UDP tunnels.  
+
+OpenVPN is designed to work with the
+.B TUN/TAP
+virtual networking interface that exists on most platforms.
+
+Overall, OpenVPN aims to offer many of the key features of IPSec but
+with a relatively lightweight footprint.
+.\"*********************************************************
+.SH OPTIONS
+OpenVPN allows any option to be placed either on the command line
+or in a configuration file.  Though all command line options are preceded
+by a double-leading-dash ("\-\-"), this prefix can be removed when
+an option is placed in a configuration file.
+.\"*********************************************************
+.TP
+.B \-\-help
+Show options.
+.\"*********************************************************
+.TP
+.B \-\-config file
+Load additional config options from
+.B file
+where each line corresponds to one command line option,
+but with the leading '\-\-' removed.
+
+If
+.B \-\-config file
+is the only option to the openvpn command,
+the
+.B \-\-config
+can be removed, and the command can be given as
+.B openvpn file
+
+Note that
+configuration files can be nested to a reasonable depth.
+
+Double quotation or single quotation characters ("", '')
+can be used to enclose single parameters containing whitespace,
+and "#" or ";" characters in the first column
+can be used to denote comments.
+
+Note that OpenVPN 2.0 and higher performs backslash-based shell
+escaping for characters not in single quotations,
+so the following mappings should be observed:
+
+.nf
+.ft 3
+.in +4
+\\\\       Maps to a single backslash character (\\).
+\\"       Pass a literal doublequote character ("), don't
+         interpret it as enclosing a parameter.
+\\[SPACE] Pass a literal space or tab character, don't
+         interpret it as a parameter delimiter.
+.in -4
+.ft
+.fi
+
+For example on Windows, use double backslashes to
+represent pathnames:
+
+.nf
+.ft 3
+.in +4
+secret "c:\\\\OpenVPN\\\\secret.key"
+.in -4
+.ft
+.fi
+
+For examples of configuration files,
+see
+.I http://openvpn.net/examples.html
+
+Here is an example configuration file:
+
+.nf
+.ft 3
+.in +4
+#
+# Sample OpenVPN configuration file for
+# using a pre-shared static key.
+#
+# '#' or ';' may be used to delimit comments.
+
+# Use a dynamic tun device.
+dev tun
+
+# Our remote peer
+remote mypeer.mydomain
+
+# 10.1.0.1 is our local VPN endpoint
+# 10.1.0.2 is our remote VPN endpoint
+ifconfig 10.1.0.1 10.1.0.2
+
+# Our pre-shared static key
+secret static.key
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.SS Tunnel Options:
+.TP
+.B \-\-mode m
+Set OpenVPN major mode.  By default, OpenVPN runs in
+point-to-point mode ("p2p").  OpenVPN 2.0 introduces
+a new mode ("server") which implements a multi-client
+server capability.
+.\"*********************************************************
+.TP
+.B \-\-local host
+Local host name or IP address for bind.
+If specified, OpenVPN will bind to this address only.
+If unspecified, OpenVPN will bind to all interfaces.
+.\"*********************************************************
+.TP
+.B \-\-remote host [port] [proto]
+Remote host name or IP address.  On the client, multiple
+.B \-\-remote
+options may be specified for redundancy, each referring
+to a different OpenVPN server.  Specifying multiple
+.B \-\-remote
+options for this purpose is a special case of the more
+general connection-profile feature.  See the
+.B <connection>
+documentation below.
+
+The OpenVPN client will try to connect to a server at
+.B host:port
+in the order specified by the list of
+.B \-\-remote
+options.
+
+.B proto
+indicates the protocol to use when connecting with the
+remote, and may be "tcp" or "udp".
+
+The client will move on to the next host in the list,
+in the event of connection failure.
+Note that at any given time, the OpenVPN client
+will at most be connected to
+one server.
+
+Note that since UDP is connectionless, connection failure
+is defined by the
+.B \-\-ping
+and
+.B \-\-ping-restart
+options.
+
+Note the following corner case:  If you use multiple
+.B \-\-remote
+options, AND you are dropping root privileges on
+the client with
+.B \-\-user
+and/or
+.B \-\-group,
+AND the client is running a non-Windows OS, if the client needs
+to switch to a different server, and that server pushes
+back different TUN/TAP or route settings, the client may lack
+the necessary privileges to close and reopen the TUN/TAP interface.
+This could cause the client to exit with a fatal error.
+
+If
+.B \-\-remote
+is unspecified, OpenVPN will listen
+for packets from any IP address, but will not act on those packets unless
+they pass all authentication tests.  This requirement for authentication
+is binding on all potential peers, even those from known and supposedly
+trusted IP addresses (it is very easy to forge a source IP address on
+a UDP packet).
+
+When used in TCP mode, 
+.B \-\-remote
+will act as a filter, rejecting connections from any host which does
+not match
+.B host.
+
+If
+.B host
+is a DNS name which resolves to multiple IP addresses,
+one will be randomly
+chosen, providing a sort of basic load-balancing and
+failover capability.
+.\"*********************************************************
+.TP
+.B \-\-remote-random-hostname
+Add a random string (6 characters) to first DNS label of hostname to prevent
+DNS caching.  For example, "foo.bar.gov" would be modified to
+"<random-chars>.foo.bar.gov".
+.\"*********************************************************
+.TP
+.B <connection>
+Define a client connection
+profile.  Client connection profiles are groups of OpenVPN options that
+describe how to connect to a given OpenVPN server.  Client connection
+profiles are specified within an OpenVPN configuration file, and
+each profile is bracketed by
+.B <connection>
+and
+.B </connection>.
+
+An OpenVPN client will try each connection profile sequentially
+until it achieves a successful connection.  
+
+.B \-\-remote-random
+can be used to initially "scramble" the connection
+list.
+
+Here is an example of connection profile usage:
+
+.nf
+.ft 3
+.in +4
+client
+dev tun
+
+<connection>
+remote 198.19.34.56 1194 udp
+</connection>
+
+<connection>
+remote 198.19.34.56 443 tcp
+</connection>
+
+<connection>
+remote 198.19.34.56 443 tcp
+http-proxy 192.168.0.8 8080
+http-proxy-retry
+</connection>
+
+<connection>
+remote 198.19.36.99 443 tcp
+http-proxy 192.168.0.8 8080
+http-proxy-retry
+</connection>
+
+persist-key
+persist-tun
+pkcs12 client.p12
+ns-cert-type server
+verb 3
+.in -4
+.ft
+.fi
+
+First we try to connect to a server at 198.19.34.56:1194 using UDP.
+If that fails, we then try to connect to 198.19.34.56:443 using TCP.
+If that also fails, then try connecting through an HTTP proxy at 
+192.168.0.8:8080 to 198.19.34.56:443 using TCP.  Finally, try to
+connect through the same proxy to a server at 198.19.36.99:443
+using TCP.
+
+The following OpenVPN options may be used inside of
+a
+.B <connection>
+block:
+
+.B bind,
+.B connect-retry,
+.B connect-retry-max,
+.B connect-timeout,
+.B float,
+.B http-proxy,
+.B http-proxy-option,
+.B http-proxy-retry,
+.B http-proxy-timeout,
+.B local,
+.B lport,
+.B nobind,
+.B port,
+.B proto,
+.B remote,
+.B rport,
+.B socks-proxy, and
+.B socks-proxy-retry.
+
+A defaulting mechanism exists for specifying options to apply to
+all
+.B <connection>
+profiles.  If any of the above options (with the exception of
+.B remote
+) appear outside of a
+.B <connection>
+block, but in a configuration file which has one or more
+.B <connection>
+blocks, the option setting will be used as a default for
+.B <connection>
+blocks which follow it in the configuration file.
+
+For example, suppose the
+.B nobind
+option were placed in the sample configuration file above, near
+the top of the file, before the first
+.B <connection>
+block.  The effect would be as if
+.B nobind
+were declared in all
+.B <connection>
+blocks below it.
+.\"*********************************************************
+.TP
+.B \-\-proto-force p
+When iterating through connection profiles,
+only consider profiles using protocol
+.B p
+('tcp'|'udp'). 
+.\"*********************************************************
+.TP
+.B \-\-remote-random
+When multiple
+.B \-\-remote
+address/ports are specified, or if connection profiles are being
+used, initially randomize the order of the list
+as a kind of basic load-balancing measure.
+.\"*********************************************************
+.TP
+.B \-\-proto p
+Use protocol
+.B p
+for communicating with remote host.
+.B p
+can be
+.B udp,
+.B tcp-client,
+or
+.B tcp-server.
+
+The default protocol is
+.B udp
+when
+.B \-\-proto
+is not specified.
+
+For UDP operation,
+.B \-\-proto udp
+should be specified on both peers.
+
+For TCP operation, one peer must use
+.B \-\-proto tcp-server
+and the other must use
+.B \-\-proto tcp-client.
+A peer started with
+.B tcp-server
+will wait indefinitely for an incoming connection.  A peer
+started with
+.B tcp-client
+will attempt to connect, and if that fails, will sleep for 5
+seconds (adjustable via the
+.B \-\-connect-retry
+option) and try again infinite or up to N retries (adjustable via the
+.B \-\-connect-retry-max
+option).  Both TCP client and server will simulate
+a SIGUSR1 restart signal if either side resets the connection.
+
+OpenVPN is designed to operate optimally over UDP, but TCP capability is provided
+for situations where UDP cannot be used.
+In comparison with UDP, TCP will usually be
+somewhat less efficient and less robust when used over unreliable or congested
+networks.
+
+This article outlines some of problems with tunneling IP over TCP:
+
+.I http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
+
+There are certain cases, however, where using TCP may be advantageous from
+a security and robustness perspective, such as tunneling non-IP or
+application-level UDP protocols, or tunneling protocols which don't
+possess a built-in reliability layer.
+.\"*********************************************************
+.TP
+.B \-\-connect-retry n
+Wait
+.B n
+seconds  between connection attempts (default=5).
+.\"*********************************************************
+.TP
+.B \-\-connect-timeout n
+For
+.B \-\-proto tcp-client,
+set connection timeout to
+.B n
+seconds (default=10).
+.\"*********************************************************
+.TP
+.B \-\-connect-retry-max n
+.B n
+specifies the number of times all 
+.B \-\-remote 
+respectively 
+.B <connection>
+statements are tried. Specifiying 
+.B n
+as one would try each entry exactly once. A sucessful connection 
+resets the counter. (default=umlimited).
+.\"*********************************************************
+.TP
+.B \-\-show-proxy-settings
+Show sensed HTTP or SOCKS proxy settings. Currently, only Windows clients
+support this option.
+.\"*********************************************************
+.TP
+.B \-\-http-proxy server port [authfile|'auto'|'auto-nct'] [auth-method]
+Connect to remote host through an HTTP proxy at address
+.B server
+and port
+.B port.
+If HTTP Proxy-Authenticate is required,
+.B authfile
+is a file containing a username and password on 2 lines, or
+"stdin" to prompt from console.
+
+.B auth-method
+should be one of "none", "basic", or "ntlm".
+
+HTTP Digest authentication is supported as well, but only via
+the
+.B auto
+or
+.B auto-nct
+flags (below).
+
+The
+.B auto
+flag causes OpenVPN to automatically determine the
+.B auth-method
+and query stdin or the management interface for
+username/password credentials, if required.  This flag
+exists on OpenVPN 2.1 or higher.
+
+The
+.B auto-nct
+flag (no clear-text auth) instructs OpenVPN to automatically
+determine the authentication method, but to reject weak
+authentication protocols such as HTTP Basic Authentication.
+.\"*********************************************************
+.TP
+.B \-\-http-proxy-retry
+Retry indefinitely on HTTP proxy errors.  If an HTTP proxy error
+occurs, simulate a SIGUSR1 reset.
+.\"*********************************************************
+.TP
+.B \-\-http-proxy-timeout n
+Set proxy timeout to
+.B n
+seconds, default=5.
+.\"*********************************************************
+.TP
+.B \-\-http-proxy-option type [parm]
+Set extended HTTP proxy options.
+Repeat to set multiple options.
+
+.B VERSION version \-\-
+Set HTTP version number to
+.B version
+(default=1.0).
+
+.B AGENT user-agent \-\-
+Set HTTP "User-Agent" string to
+.B user-agent.
+.\"*********************************************************
+.TP
+.B \-\-socks-proxy server [port]
+Connect to remote host through a Socks5 proxy at address
+.B server
+and port
+.B port
+(default=1080).
+.\"*********************************************************
+.TP
+.B \-\-socks-proxy-retry
+Retry indefinitely on Socks proxy errors.  If a Socks proxy error
+occurs, simulate a SIGUSR1 reset.
+.\"*********************************************************
+.TP
+.B \-\-resolv-retry n
+If hostname resolve fails for
+.B \-\-remote,
+retry resolve for
+.B n
+seconds before failing.
+
+Set
+.B n
+to "infinite" to retry indefinitely.
+
+By default,
+.B \-\-resolv-retry infinite
+is enabled.  You can disable by setting n=0.
+.\"*********************************************************
+.TP
+.B \-\-float
+Allow remote peer to change its IP address and/or port number, such as due to
+DHCP (this is the default if
+.B \-\-remote
+is not used).
+.B \-\-float
+when specified with
+.B \-\-remote
+allows an OpenVPN session to initially connect to a peer
+at a known address, however if packets arrive from a new
+address and pass all authentication tests, the new address
+will take control of the session.  This is useful when
+you are connecting to a peer which holds a dynamic address
+such as a dial-in user or DHCP client.
+
+Essentially,
+.B \-\-float
+tells OpenVPN to accept authenticated packets
+from any address, not only the address which was specified in the
+.B \-\-remote
+option.
+.\"*********************************************************
+.TP
+.B \-\-ipchange cmd
+Run command
+.B cmd
+when our remote ip-address is initially authenticated or
+changes.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+When
+.B cmd
+is executed two arguments are appended after any arguments specified in
+.B cmd
+, as follows:
+
+.B cmd ip_address port_number
+
+Don't use
+.B \-\-ipchange
+in
+.B \-\-mode server
+mode.  Use a
+.B \-\-client-connect
+script instead.
+
+See the "Environmental Variables" section below for
+additional parameters passed as environmental variables.
+
+If you are running in a dynamic IP address environment where
+the IP addresses of either peer could change without notice,
+you can use this script, for example, to edit the
+.I /etc/hosts
+file with the current address of the peer.  The script will
+be run every time the remote peer changes its IP address.
+
+Similarly if
+.I our
+IP address changes due to DHCP, we should configure
+our IP address change script (see man page for
+.BR dhcpcd (8)
+) to deliver a
+.B SIGHUP
+or
+.B SIGUSR1
+signal to OpenVPN.  OpenVPN will then
+reestablish a connection with its most recently authenticated
+peer on its new IP address.
+.\"*********************************************************
+.TP
+.B \-\-port port
+TCP/UDP port number or port name for both local and remote.  The current
+default of 1194 represents the official IANA port number
+assignment for OpenVPN and has been used since version 2.0-beta17.
+Previous versions used port 5000 as the default.
+.\"*********************************************************
+.TP
+.B \-\-lport port
+TCP/UDP port number or name for bind.
+.\"*********************************************************
+.TP
+.B \-\-rport port
+TCP/UDP port number or name for remote.
+.\"*********************************************************
+.TP
+.B \-\-bind
+Bind to local address and port. This is the default unless any of 
+.B \-\-proto tcp-client
+,
+.B \-\-http-proxy
+or
+.B \-\-socks-proxy
+are used.
+.\"*********************************************************
+.TP
+.B \-\-nobind
+Do not bind to local address and port.  The IP stack will allocate
+a dynamic port for returning packets.  Since the value of the dynamic port
+could not be known in advance by a peer, this option is only suitable for
+peers which will be initiating connections by using the
+.B \-\-remote
+option.
+.\"*********************************************************
+.TP
+.B \-\-dev tunX | tapX | null
+TUN/TAP virtual network device (
+.B X
+can be omitted for a dynamic device.)
+
+See examples section below
+for an example on setting up a TUN device.
+
+You must use either tun devices on both ends of the connection
+or tap devices on both ends.  You cannot mix them, as they
+represent different underlying network layers.
+
+.B tun
+devices encapsulate IPv4 or IPv6 (OSI Layer 3) while
+.B tap
+devices encapsulate Ethernet 802.3 (OSI Layer 2).
+.\"*********************************************************
+.TP
+.B \-\-dev-type device-type
+Which device type are we using?
+.B device-type
+should be
+.B tun
+(OSI Layer 3)
+or
+.B tap
+(OSI Layer 2).
+Use this option only if the TUN/TAP device used with
+.B \-\-dev
+does not begin with
+.B tun
+or
+.B tap.
+.\"*********************************************************
+.TP
+.B \-\-topology mode
+Configure virtual addressing topology when running in
+.B \-\-dev tun
+mode.  This directive has no meaning in
+.B \-\-dev tap
+mode, which always uses a
+.B subnet
+topology.
+
+If you set this directive on the server, the
+.B \-\-server
+and
+.B \-\-server-bridge
+directives will automatically push your chosen topology setting to clients
+as well.  This directive can also be manually pushed to clients.  Like the
+.B \-\-dev
+directive, this directive must always be compatible between client and server.
+
+.B mode
+can be one of:
+
+.B net30 \-\-
+Use a point-to-point topology, by allocating one /30 subnet per client.
+This is designed to allow point-to-point semantics when some
+or all of the connecting clients might be Windows systems.  This is the
+default on OpenVPN 2.0.
+
+.B p2p \-\-
+Use a point-to-point topology where the remote endpoint of the client's
+tun interface always points to the local endpoint of the server's tun interface.
+This mode allocates a single IP address per connecting client.
+Only use
+when none of the connecting clients are Windows systems.  This mode
+is functionally equivalent to the
+.B \-\-ifconfig-pool-linear
+directive which is available in OpenVPN 2.0 and is now deprecated.
+
+.B subnet \-\-
+Use a subnet rather than a point-to-point topology by
+configuring the tun interface with a local IP address and subnet mask,
+similar to the topology used in
+.B \-\-dev tap
+and ethernet bridging mode.
+This mode allocates a single IP address per connecting client and works on
+Windows as well.  Only available when server and clients are OpenVPN 2.1 or
+higher, or OpenVPN 2.0.x which has been manually patched with the
+.B \-\-topology
+directive code.  When used on Windows, requires version 8.2 or higher
+of the TAP-Win32 driver.  When used on *nix, requires that the tun
+driver supports an
+.BR ifconfig (8)
+command which sets a subnet instead of a remote endpoint IP address.
+
+This option exists in OpenVPN 2.1 or higher.
+.\"*********************************************************
+.TP
+.B \-\-tun-ipv6
+Build a tun link capable of forwarding IPv6 traffic.
+Should be used in conjunction with
+.B \-\-dev tun
+or
+.B \-\-dev tunX.
+A warning will be displayed
+if no specific IPv6 TUN support for your OS has been compiled into OpenVPN.
+
+See below for further IPv6-related configuration options.
+.\"*********************************************************
+.TP
+.B \-\-dev-node node
+Explicitly set the device node rather than using
+/dev/net/tun, /dev/tun, /dev/tap, etc.  If OpenVPN
+cannot figure out whether
+.B node
+is a TUN or TAP device based on the name, you should
+also specify
+.B \-\-dev-type tun
+or
+.B \-\-dev-type tap.
+
+On Windows systems, select the TAP-Win32 adapter which
+is named
+.B node
+in the Network Connections Control Panel or the
+raw GUID of the adapter enclosed by braces.
+The
+.B \-\-show-adapters
+option under Windows can also be used
+to enumerate all available TAP-Win32
+adapters and will show both the network
+connections control panel name and the GUID for
+each TAP-Win32 adapter.
+.TP
+.B \-\-lladdr address
+Specify the link layer address, more commonly known as the MAC address.
+Only applied to TAP devices.
+.\"*********************************************************
+.TP
+.B \-\-iproute cmd
+Set alternate command to execute instead of default iproute2 command.
+May be used in order to execute OpenVPN in unprivileged environment.
+.\"*********************************************************
+.TP
+.B \-\-ifconfig l rn
+Set TUN/TAP adapter parameters. 
+.B l
+is the IP address of the local VPN endpoint.
+For TUN devices,
+.B rn
+is the IP address of the remote VPN endpoint.
+For TAP devices,
+.B rn
+is the subnet mask of the virtual ethernet segment
+which is being created or connected to.
+
+For TUN devices, which facilitate virtual
+point-to-point IP connections,
+the proper usage of
+.B \-\-ifconfig
+is to use two private IP addresses
+which are not a member of any
+existing subnet which is in use.
+The IP addresses may be consecutive
+and should have their order reversed
+on the remote peer.  After the VPN
+is established, by pinging
+.B rn,
+you will be pinging across the VPN.
+
+For TAP devices, which provide
+the ability to create virtual
+ethernet segments,
+.B \-\-ifconfig
+is used to set an IP address and
+subnet mask just as a physical
+ethernet adapter would be
+similarly configured.  If you are
+attempting to connect to a remote
+ethernet bridge, the IP address
+and subnet should be set to values
+which would be valid on the
+the bridged ethernet segment (note
+also that DHCP can be used for the
+same purpose).
+
+This option, while primarily a proxy for the
+.BR ifconfig (8)
+command, is designed to simplify TUN/TAP
+tunnel configuration by providing a
+standard interface to the different
+ifconfig implementations on different
+platforms.
+
+.B \-\-ifconfig
+parameters which are IP addresses can
+also be specified as a DNS or /etc/hosts
+file resolvable name.
+
+For TAP devices,
+.B \-\-ifconfig
+should not be used if the TAP interface will be
+getting an IP address lease from a DHCP
+server.
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-noexec
+Don't actually execute ifconfig/netsh commands, instead
+pass
+.B \-\-ifconfig
+parameters to scripts using environmental variables.
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-nowarn
+Don't output an options consistency check warning
+if the
+.B \-\-ifconfig
+option on this side of the
+connection doesn't match the remote side.  This is useful
+when you want to retain the overall benefits of the
+options consistency check (also see
+.B \-\-disable-occ
+option) while only disabling the ifconfig component of
+the check.
+
+For example,
+if you have a configuration where the local host uses
+.B \-\-ifconfig
+but the remote host does not, use
+.B \-\-ifconfig-nowarn
+on the local host.
+
+This option will also silence warnings about potential
+address conflicts which occasionally annoy more experienced
+users by triggering "false positive" warnings.
+.\"*********************************************************
+.TP
+.B \-\-route network/IP [netmask] [gateway] [metric]
+Add route to routing table after connection is established.
+Multiple routes can be specified.  Routes will be
+automatically torn down in reverse order prior to
+TUN/TAP device close.
+
+This option is intended as
+a convenience proxy for the
+.BR route (8)
+shell command,
+while at the same time providing portable semantics
+across OpenVPN's platform space.
+
+.B netmask
+default \-\- 255.255.255.255
+
+.B gateway
+default \-\- taken from
+.B \-\-route-gateway
+or the second parameter to
+.B \-\-ifconfig
+when
+.B \-\-dev tun
+is specified.
+
+.B metric
+default \-\- taken from
+.B \-\-route-metric
+otherwise 0.
+
+The default can be specified by leaving an option blank or setting
+it to "default".
+
+The
+.B network
+and
+.B gateway
+parameters can
+also be specified as a DNS or /etc/hosts
+file resolvable name, or as one of three special keywords:
+
+.B vpn_gateway
+\-\- The remote VPN endpoint address
+(derived either from
+.B \-\-route-gateway
+or the second parameter to
+.B \-\-ifconfig
+when
+.B \-\-dev tun
+is specified).
+
+.B net_gateway
+\-\- The pre-existing IP default gateway, read from the routing
+table (not supported on all OSes).
+
+.B remote_host
+\-\- The
+.B \-\-remote
+address if OpenVPN is being run in client mode, and is undefined in server mode.
+.\"*********************************************************
+.TP
+.B \-\-max-routes n
+Allow a maximum number of n
+.B \-\-route
+options to be specified, either in the local configuration file,
+or pulled from an OpenVPN server.  By default, n=100.
+.\"*********************************************************
+.TP
+.B \-\-route-gateway gw|'dhcp'
+Specify a default gateway
+.B gw
+for use with
+.B \-\-route.
+
+If
+.B dhcp
+is specified as the parameter,
+the gateway address will be extracted from a DHCP
+negotiation with the OpenVPN server-side LAN.
+.\"*********************************************************
+.TP
+.B \-\-route-metric m
+Specify a default metric
+.B m
+for use with
+.B \-\-route.
+.\"*********************************************************
+.TP
+.B \-\-route-delay [n] [w]
+Delay
+.B n
+seconds (default=0) after connection
+establishment, before adding routes. If
+.B n
+is 0, routes will be added immediately upon connection
+establishment.  If
+.B \-\-route-delay
+is omitted, routes will be added immediately after TUN/TAP device
+open and
+.B \-\-up
+script execution, before any
+.B \-\-user
+or 
+.B \-\-group
+privilege downgrade (or
+.B \-\-chroot
+execution.)
+
+This option is designed to be useful in scenarios where DHCP is
+used to set
+tap adapter addresses.  The delay will give the DHCP handshake
+time to complete before routes are added.
+
+On Windows,
+.B \-\-route-delay
+tries to be more intelligent by waiting
+.B w
+seconds (w=30 by default)
+for the TAP-Win32 adapter to come up before adding routes.
+.\"*********************************************************
+.TP
+.B \-\-route-up cmd
+Run command
+.B cmd
+after routes are added, subject to
+.B \-\-route-delay.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+See the "Environmental Variables" section below for
+additional parameters passed as environmental variables.
+.\"*********************************************************
+.TP
+.B \-\-route-pre-down cmd
+Run command
+.B cmd
+before routes are removed upon disconnection.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+See the "Environmental Variables" section below for
+additional parameters passed as environmental variables.
+.\"*********************************************************
+.TP
+.B \-\-route-noexec
+Don't add or remove routes automatically.  Instead pass routes to
+.B \-\-route-up
+script using environmental variables.
+.\"*********************************************************
+.TP
+.B \-\-route-nopull
+When used with
+.B \-\-client
+or
+.B \-\-pull,
+accept options pushed by server EXCEPT for routes and dhcp options
+like DNS servers.
+
+When used on the client, this option effectively bars the
+server from adding routes to the client's routing table,
+however note that this option still allows the server
+to set the TCP/IP properties of the client's TUN/TAP interface.
+.\"*********************************************************
+.TP
+.B \-\-allow-pull-fqdn
+Allow client to pull DNS names from server (rather than being limited
+to IP address) for
+.B \-\-ifconfig,
+.B \-\-route,
+and
+.B \-\-route-gateway.
+.\"*********************************************************
+.TP
+.B \-\-client-nat snat|dnat network netmask alias
+This pushable client option sets up a stateless one-to-one NAT
+rule on packet addresses (not ports), and is useful in cases
+where routes or ifconfig settings pushed to the client would
+create an IP numbering conflict.
+
+.B network/netmask
+(for example 192.168.0.0/255.255.0.0)
+defines the local view of a resource from the client perspective, while
+.B alias/netmask
+(for example 10.64.0.0/255.255.0.0)
+defines the remote view from the server perspective.
+
+Use
+.B snat
+(source NAT) for resources owned by the client and
+.B dnat
+(destination NAT) for remote resources.
+
+Set
+.B \-\-verb 6
+for debugging info showing the transformation of src/dest
+addresses in packets.
+.\"*********************************************************
+.TP
+.B \-\-redirect-gateway flags...
+Automatically execute routing commands to cause all outgoing IP traffic
+to be redirected over the VPN.  This is a client-side option.
+
+This option performs three steps:
+
+.B (1)
+Create a static route for the
+.B \-\-remote
+address which forwards to the pre-existing default gateway.
+This is done so that
+.B (3)
+will not create a routing loop.
+
+.B (2)
+Delete the default gateway route.
+
+.B (3)
+Set the new default gateway to be the VPN endpoint address (derived either from
+.B \-\-route-gateway
+or the second parameter to
+.B \-\-ifconfig
+when
+.B \-\-dev tun
+is specified).
+
+When the tunnel is torn down, all of the above steps are reversed so
+that the original default route is restored.
+
+Option flags:
+
+.B local \-\-
+Add the
+.B local
+flag if both OpenVPN servers are directly connected via a common subnet,
+such as with wireless.  The
+.B local
+flag will cause step
+.B 1
+above to be omitted.
+
+.B autolocal \-\-
+Try to automatically determine whether to enable
+.B local
+flag above.
+
+.B def1 \-\-
+Use this flag to override
+the default gateway by using 0.0.0.0/1 and 128.0.0.0/1
+rather than 0.0.0.0/0.  This has the benefit of overriding
+but not wiping out the original default gateway. 
+
+.B bypass-dhcp \-\-
+Add a direct route to the DHCP server (if it is non-local) which
+bypasses the tunnel
+(Available on Windows clients, may not be available
+on non-Windows clients).
+
+.B bypass-dns \-\-
+Add a direct route to the DNS server(s) (if they are non-local) which
+bypasses the tunnel
+(Available on Windows clients, may not be available
+on non-Windows clients).
+
+.B block-local \-\-
+Block access to local LAN when the tunnel is active, except for
+the LAN gateway itself.  This is accomplished by routing the local
+LAN (except for the LAN gateway address) into the tunnel.
+.\"*********************************************************
+.TP
+.B \-\-link-mtu n
+Sets an upper bound on the size of UDP packets which are sent
+between OpenVPN peers.  It's best not to set this parameter unless
+you know what you're doing.
+.\"*********************************************************
+.\"*********************************************************
+.TP
+.B \-\-redirect-private [flags]
+Like \-\-redirect-gateway, but omit actually changing the default
+gateway.  Useful when pushing private subnets.
+.\"*********************************************************
+.TP
+.B \-\-tun-mtu n
+Take the TUN device MTU to be
+.B n
+and derive the link MTU
+from it (default=1500).  In most cases, you will probably want to
+leave this parameter set to its default value.
+
+The MTU (Maximum Transmission Units) is
+the maximum datagram size in bytes that can be sent unfragmented
+over a particular network path.  OpenVPN requires that packets
+on the control or data channels be sent unfragmented.
+
+MTU problems often manifest themselves as connections which
+hang during periods of active usage.
+
+It's best to use the
+.B \-\-fragment
+and/or
+.B \-\-mssfix
+options to deal with MTU sizing issues.
+.\"*********************************************************
+.TP
+.B \-\-tun-mtu-extra n
+Assume that the TUN/TAP device might return as many as
+.B n
+bytes more than the
+.B \-\-tun-mtu
+size on read.  This parameter defaults to 0, which is sufficient for
+most TUN devices.  TAP devices may introduce additional overhead in excess
+of the MTU size, and a setting of 32 is the default when TAP devices are used.
+This parameter only controls internal OpenVPN buffer sizing,
+so there is no transmission overhead associated with using a larger value.
+.\"*********************************************************
+.TP
+.B \-\-mtu-disc type
+Should we do Path MTU discovery on TCP/UDP channel?  Only supported on OSes such
+as Linux that supports the necessary system call to set.
+
+.B 'no'
+\-\- Never send DF (Don't Fragment) frames
+.br
+.B 'maybe'
+\-\- Use per-route hints
+.br
+.B 'yes'
+\-\- Always DF (Don't Fragment)
+.br
+.\"*********************************************************
+.TP
+.B \-\-mtu-test
+To empirically measure MTU on connection startup,
+add the
+.B \-\-mtu-test
+option to your configuration.
+OpenVPN will send ping packets of various sizes
+to the remote peer and measure the largest packets
+which were successfully received.  The
+.B \-\-mtu-test
+process normally takes about 3 minutes to complete.
+.\"*********************************************************
+.TP
+.B \-\-fragment max
+Enable internal datagram fragmentation so
+that no UDP datagrams are sent which
+are larger than
+.B max
+bytes.
+
+The
+.B max
+parameter is interpreted in the same way as the
+.B \-\-link-mtu
+parameter, i.e. the UDP packet size after encapsulation
+overhead has been added in, but not including
+the UDP header itself.
+
+The
+.B \-\-fragment
+option only makes sense when you are using the UDP protocol (
+.B \-\-proto udp
+).
+
+.B \-\-fragment
+adds 4 bytes of overhead per datagram.
+
+See the
+.B \-\-mssfix
+option below for an important related option to
+.B \-\-fragment.
+
+It should also be noted that this option is not meant to replace
+UDP fragmentation at the IP stack level.  It is only meant as a
+last resort when path MTU discovery is broken.  Using this option
+is less efficient than fixing path MTU discovery for your IP link and
+using native IP fragmentation instead.
+
+Having said that, there are circumstances where using OpenVPN's
+internal fragmentation capability may be your only option, such
+as tunneling a UDP multicast stream which requires fragmentation.
+.\"*********************************************************
+.TP
+.B \-\-mssfix max
+Announce to TCP sessions running over the tunnel that they should limit
+their send packet sizes such that after OpenVPN has encapsulated them,
+the resulting UDP packet size that OpenVPN sends to its peer will not
+exceed
+.B max
+bytes. The default value is
+.B 1450.
+
+The
+.B max
+parameter is interpreted in the same way as the
+.B \-\-link-mtu
+parameter, i.e. the UDP packet size after encapsulation
+overhead has been added in, but not including
+the UDP header itself.
+
+The
+.B \-\-mssfix
+option only makes sense when you are using the UDP protocol
+for OpenVPN peer-to-peer communication, i.e.
+.B \-\-proto udp.
+
+.B \-\-mssfix
+and
+.B \-\-fragment
+can be ideally used together, where
+.B \-\-mssfix
+will try to keep TCP from needing
+packet fragmentation in the first place,
+and if big packets come through anyhow
+(from protocols other than TCP),
+.B \-\-fragment
+will internally fragment them.
+
+Both
+.B \-\-fragment
+and
+.B \-\-mssfix
+are designed to work around cases where Path MTU discovery
+is broken on the network path between OpenVPN peers.
+
+The usual symptom of such a breakdown is an OpenVPN
+connection which successfully starts, but then stalls
+during active usage.
+
+If
+.B \-\-fragment
+and
+.B \-\-mssfix
+are used together,
+.B \-\-mssfix
+will take its default
+.B max
+parameter from the
+.B \-\-fragment max
+option.
+
+Therefore, one could lower the maximum UDP packet size
+to 1300 (a good first try for solving MTU-related
+connection problems) with the following options:
+
+.B \-\-tun-mtu 1500 \-\-fragment 1300 \-\-mssfix
+.\"*********************************************************
+.TP
+.B \-\-sndbuf size
+Set the TCP/UDP socket send buffer size.
+Currently defaults to 65536 bytes.
+.\"*********************************************************
+.TP
+.B \-\-rcvbuf size
+Set the TCP/UDP socket receive buffer size.
+Currently defaults to 65536 bytes.
+.\"*********************************************************
+.TP
+.B \-\-mark value
+Mark encrypted packets being sent with value. The mark value can be
+matched in policy routing and packetfilter rules. This option is
+only supported in Linux and does nothing on other operating systems.
+.\"*********************************************************
+.TP
+.B \-\-socket-flags flags...
+Apply the given flags to the OpenVPN transport socket.
+Currently, only
+.B TCP_NODELAY
+is supported.
+
+The
+.B TCP_NODELAY
+socket flag is useful in TCP mode, and causes the kernel
+to send tunnel packets immediately over the TCP connection without
+trying to group several smaller packets into a larger packet.
+This can result in a considerably improvement in latency.
+
+This option is pushable from server to client, and should be used
+on both client and server for maximum effect.
+.\"*********************************************************
+.TP
+.B \-\-txqueuelen n
+(Linux only) Set the TX queue length on the TUN/TAP interface.
+Currently defaults to 100.
+.\"*********************************************************
+.TP
+.B \-\-shaper n
+Limit bandwidth of outgoing tunnel data to
+.B n
+bytes per second on the TCP/UDP port.
+If you want to limit the bandwidth
+in both directions, use this option on both peers.
+
+OpenVPN uses the following algorithm to implement
+traffic shaping: Given a shaper rate of
+.I n
+bytes per second, after a datagram write of
+.I b
+bytes is queued on the TCP/UDP port, wait a minimum of
+.I (b / n)
+seconds before queuing the next write.
+
+It should be noted that OpenVPN supports multiple
+tunnels between the same two peers, allowing you
+to construct full-speed and reduced bandwidth tunnels
+at the same time,
+routing low-priority data such as off-site backups
+over the reduced bandwidth tunnel, and other data
+over the full-speed tunnel.
+
+Also note that for low bandwidth tunnels
+(under 1000 bytes per second), you should probably
+use lower MTU values as well (see above), otherwise
+the packet latency will grow so large as to trigger
+timeouts in the TLS layer and TCP connections running
+over the tunnel.
+
+OpenVPN allows
+.B n
+to be between 100 bytes/sec and 100 Mbytes/sec.
+.\"*********************************************************
+.TP
+.B \-\-inactive n [bytes]
+Causes OpenVPN to exit after
+.B n
+seconds of inactivity on the TUN/TAP device. The time length of
+inactivity is measured since the last incoming or outgoing tunnel
+packet.  The default value is 0 seconds, which disables this feature.
+
+If the optional
+.B bytes
+parameter is included,
+exit if less than
+.B bytes
+of combined in/out traffic are produced on the tun/tap device
+in
+.B n
+seconds.
+
+In any case, OpenVPN's internal ping packets (which are just
+keepalives) and TLS control packets are not considered
+"activity", nor are they counted as traffic, as they are used
+internally by OpenVPN and are not an indication of actual user
+activity.
+.\"*********************************************************
+.TP
+.B \-\-ping n
+Ping remote over the TCP/UDP control channel
+if no packets have been sent for at least
+.B n
+seconds (specify
+.B \-\-ping
+on both peers to cause ping packets to be sent in both directions since
+OpenVPN ping packets are not echoed like IP ping packets).
+When used in one of OpenVPN's secure modes (where
+.B \-\-secret, \-\-tls-server,
+or
+.B \-\-tls-client
+is specified), the ping packet
+will be cryptographically secure.
+
+This option has two intended uses:
+
+(1) Compatibility
+with stateful firewalls.  The periodic ping will ensure that
+a stateful firewall rule which allows OpenVPN UDP packets to
+pass will not time out.
+
+(2) To provide a basis for the remote to test the existence
+of its peer using the
+.B \-\-ping-exit
+option.
+.\"*********************************************************
+.TP
+.B \-\-ping-exit n
+Causes OpenVPN to exit after
+.B n
+seconds pass without reception of a ping
+or other packet from remote.
+This option can be combined with
+.B \-\-inactive, \-\-ping,
+and
+.B \-\-ping-exit
+to create a two-tiered inactivity disconnect.
+
+For example,
+
+.B openvpn [options...] \-\-inactive 3600 \-\-ping 10 \-\-ping-exit 60
+
+when used on both peers will cause OpenVPN to exit within 60
+seconds if its peer disconnects, but will exit after one
+hour if no actual tunnel data is exchanged.
+.\"*********************************************************
+.TP
+.B \-\-ping-restart n
+Similar to
+.B \-\-ping-exit,
+but trigger a
+.B SIGUSR1
+restart after
+.B n
+seconds pass without reception of a ping
+or other packet from remote.
+
+This option is useful in cases
+where the remote peer has a dynamic IP address and
+a low-TTL DNS name is used to track the IP address using
+a service such as
+.I http://dyndns.org/
++ a dynamic DNS client such
+as
+.B ddclient.
+
+If the peer cannot be reached, a restart will be triggered, causing
+the hostname used with
+.B \-\-remote
+to be re-resolved (if
+.B \-\-resolv-retry
+is also specified).
+
+In server mode,
+.B \-\-ping-restart, \-\-inactive,
+or any other type of internally generated signal will always be
+applied to
+individual client instance objects, never to whole server itself.
+Note also in server mode that any internally generated signal
+which would normally cause a restart, will cause the deletion
+of the client instance object instead.
+
+In client mode, the
+.B \-\-ping-restart
+parameter is set to 120 seconds by default.  This default will
+hold until the client pulls a replacement value from the server, based on
+the
+.B \-\-keepalive
+setting in the server configuration.
+To disable the 120 second default, set
+.B \-\-ping-restart 0
+on the client.
+
+See the signals section below for more information
+on
+.B SIGUSR1.
+
+Note that the behavior of
+.B SIGUSR1
+can be modified by the
+.B \-\-persist-tun, \-\-persist-key, \-\-persist-local-ip,
+and
+.B \-\-persist-remote-ip
+options.
+
+Also note that
+.B \-\-ping-exit
+and
+.B \-\-ping-restart
+are mutually exclusive and cannot be used together.
+.\"*********************************************************
+.TP
+.B \-\-keepalive n m
+A helper directive designed to simplify the expression of
+.B \-\-ping
+and
+.B \-\-ping-restart
+in server mode configurations.
+
+The server timeout is set twice the value of the second argument.
+This ensures that a timeout is dectected on client side
+before the server side drops the connection.
+
+For example,
+.B \-\-keepalive 10 60
+expands as follows:
+
+.nf
+.ft 3
+.in +4
+ if mode server:
+   ping 10
+   ping-restart 120
+   push "ping 10"
+   push "ping-restart 60"
+ else
+   ping 10
+   ping-restart 60
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.TP
+.B \-\-ping-timer-rem
+Run the
+.B \-\-ping-exit
+/
+.B \-\-ping-restart
+timer only if we have a remote address.  Use this option if you are
+starting the daemon in listen mode (i.e. without an explicit
+.B \-\-remote
+peer), and you don't want to start clocking timeouts until a remote
+peer connects.
+.\"*********************************************************
+.TP
+.B \-\-persist-tun
+Don't close and reopen TUN/TAP device or run up/down scripts
+across
+.B SIGUSR1
+or
+.B \-\-ping-restart
+restarts.
+
+.B SIGUSR1
+is a restart signal similar to
+.B SIGHUP,
+but which offers finer-grained control over
+reset options.
+.\"*********************************************************
+.TP
+.B \-\-persist-key
+Don't re-read key files across
+.B SIGUSR1
+or
+.B \-\-ping-restart.
+
+This option can be combined with
+.B \-\-user nobody
+to allow restarts triggered by the
+.B SIGUSR1
+signal.
+Normally if you drop root privileges in OpenVPN,
+the daemon cannot be restarted since it will now be unable to re-read protected
+key files.
+
+This option solves the problem by persisting keys across
+.B SIGUSR1
+resets, so they don't need to be re-read.
+.\"*********************************************************
+.TP
+.B \-\-persist-local-ip
+Preserve initially resolved local IP address and port number
+across
+.B SIGUSR1
+or
+.B \-\-ping-restart
+restarts.
+.\"*********************************************************
+.TP
+.B \-\-persist-remote-ip
+Preserve most recently authenticated remote IP address and port number
+across
+.B SIGUSR1
+or
+.B \-\-ping-restart
+restarts.
+.\"*********************************************************
+.TP
+.B \-\-mlock
+Disable paging by calling the POSIX mlockall function.
+Requires that OpenVPN be initially run as root (though
+OpenVPN can subsequently downgrade its UID using the
+.B \-\-user
+option).
+
+Using this option ensures that key material and tunnel
+data are never written to disk due to virtual
+memory paging operations which occur under most
+modern operating systems.  It ensures that even if an
+attacker was able to crack the box running OpenVPN, he
+would not be able to scan the system swap file to
+recover previously used
+ephemeral keys, which are used for a period of time
+governed by the
+.B \-\-reneg
+options (see below), then are discarded.
+
+The downside
+of using
+.B \-\-mlock
+is that it will reduce the amount of physical
+memory available to other applications.
+.\"*********************************************************
+.TP
+.B \-\-up cmd
+Run command
+.B cmd
+after successful TUN/TAP device open
+(pre
+.B \-\-user
+UID change).
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+The up command is useful for specifying route
+commands which route IP traffic destined for
+private subnets which exist at the other
+end of the VPN connection into the tunnel.
+
+For
+.B \-\-dev tun
+execute as:
+
+.B cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart ]
+
+For
+.B \-\-dev tap
+execute as:
+
+.B cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask [ init | restart ]
+
+See the "Environmental Variables" section below for
+additional parameters passed as environmental variables.
+
+Note that if
+.B cmd
+includes arguments, all OpenVPN-generated arguments will be appended
+to them to build an argument list with which the executable will be
+called.
+
+Typically,
+.B cmd
+will run a script to add routes to the tunnel.
+
+Normally the up script is called after the TUN/TAP device is opened.
+In this context, the last command line parameter passed to the script
+will be
+.I init.
+If the
+.B \-\-up-restart
+option is also used, the up script will be called for restarts as
+well.  A restart is considered to be a partial reinitialization
+of OpenVPN where the TUN/TAP instance is preserved (the
+.B \-\-persist-tun
+option will enable such preservation).  A restart
+can be generated by a SIGUSR1 signal, a
+.B \-\-ping-restart
+timeout, or a connection reset when the TCP protocol is enabled
+with the
+.B \-\-proto
+option.  If a restart occurs, and
+.B \-\-up-restart
+has been specified, the up script will be called with
+.I restart
+as the last parameter.
+
+The following standalone example shows how the
+.B \-\-up
+script can be called in both an initialization and restart context.
+(NOTE: for security reasons, don't run the following example unless UDP port
+9999 is blocked by your firewall.  Also, the example will run indefinitely,
+so you should abort with control-c).
+
+.B openvpn \-\-dev tun \-\-port 9999 \-\-verb 4 \-\-ping-restart 10 \-\-up 'echo up' \-\-down 'echo down' \-\-persist-tun \-\-up-restart
+
+Note that OpenVPN also provides the
+.B \-\-ifconfig
+option to automatically ifconfig the TUN device,
+eliminating the need to define an
+.B \-\-up
+script, unless you also want to configure routes
+in the
+.B \-\-up
+script.
+
+If
+.B \-\-ifconfig
+is also specified, OpenVPN will pass the ifconfig local
+and remote endpoints on the command line to the
+.B \-\-up
+script so that they can be used to configure routes such as:
+
+.B route add -net 10.0.0.0 netmask 255.255.255.0 gw $5
+.\"*********************************************************
+.TP
+.B \-\-up-delay
+Delay TUN/TAP open and possible
+.B \-\-up
+script execution
+until after TCP/UDP connection establishment with peer.
+
+In
+.B \-\-proto udp
+mode, this option normally requires the use of
+.B \-\-ping
+to allow connection initiation to be sensed in the absence
+of tunnel data, since UDP is a "connectionless" protocol.
+
+On Windows, this option will delay the TAP-Win32 media state
+transitioning to "connected" until connection establishment,
+i.e. the receipt of the first authenticated packet from the peer.
+.\"*********************************************************
+.TP
+.B \-\-down cmd
+Run command
+.B cmd
+after TUN/TAP device close
+(post
+.B \-\-user
+UID change and/or
+.B \-\-chroot
+).
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+Called with the same parameters and environmental
+variables as the
+.B \-\-up
+option above.
+
+Note that if you reduce privileges by using
+.B \-\-user
+and/or
+.B \-\-group,
+your
+.B \-\-down
+script will also run at reduced privilege.
+.\"*********************************************************
+.TP
+.B \-\-down-pre
+Call
+.B \-\-down
+cmd/script before, rather than after, TUN/TAP close.
+.\"*********************************************************
+.TP
+.B \-\-up-restart
+Enable the
+.B \-\-up
+and
+.B \-\-down
+scripts to be called for restarts as well as initial program start.
+This option is described more fully above in the
+.B \-\-up
+option documentation.
+.\"*********************************************************
+.TP
+.B \-\-setenv name value
+Set a custom environmental variable
+.B name=value
+to pass to script.
+.\"*********************************************************
+.TP
+.B \-\-setenv FORWARD_COMPATIBLE 1
+Relax config file syntax checking so that unknown directives
+will trigger a warning but not a fatal error,
+on the assumption that a given unknown directive might be valid
+in future OpenVPN versions.
+
+This option should be used with caution, as there are good security
+reasons for having OpenVPN fail if it detects problems in a
+config file.  Having said that, there are valid reasons for wanting
+new software features to gracefully degrade when encountered by
+older software versions.
+.\"*********************************************************
+.TP
+.B \-\-setenv-safe name value
+Set a custom environmental variable
+.B OPENVPN_name=value
+to pass to script.
+
+This directive is designed to be pushed by the server to clients,
+and the prepending of "OPENVPN_" to the environmental variable
+is a safety precaution to prevent a LD_PRELOAD style attack
+from a malicious or compromised server.
+.\"*********************************************************
+.TP
+.B \-\-script-security level
+This directive offers policy-level control over OpenVPN's usage of external programs
+and scripts.  Lower
+.B level
+values are more restrictive, higher values are more permissive.  Settings for
+.B level:
+
+.B 0 \-\-
+Strictly no calling of external programs.
+.br
+.B 1 \-\-
+(Default) Only call built-in executables such as ifconfig, ip, route, or netsh.
+.br
+.B 2 \-\-
+Allow calling of built-in executables and user-defined scripts.
+.br
+.B 3 \-\-
+Allow passwords to be passed to scripts via environmental variables (potentially unsafe).
+
+OpenVPN releases before v2.3 also supported a
+.B method
+flag which indicated how OpenVPN should call external commands and scripts.  This
+could be either
+.B execve
+or 
+.B system. 
+As of OpenVPN v2.3, this flag is no longer accepted.  In most *nix environments the execve()
+approach has been used without any issues.
+
+To run scripts in Windows in earlier OpenVPN
+versions you needed to either add a full path to the script interpreter which can parse the
+script or use the
+.B system
+flag to run these scripts.  As of OpenVPN v2.3 it is now a strict requirement to have
+full path to the script interpreter when running non-executables files.
+This is not needed for executable files, such as .exe, .com, .bat or .cmd files.  For
+example, if you have a Visual Basic script, you must use this syntax now:
+
+.nf
+.ft 3
+.in +4
+\-\-up 'C:\\\\Windows\\\\System32\\\\wscript.exe C:\\\\Program\\ Files\\\\OpenVPN\\\\config\\\\my-up-script.vbs'
+.in -4
+.ft
+.fi
+
+Please note the single quote marks and the escaping of the backslashes (\\) and
+the space character.
+
+The reason the support for the
+.B system
+flag was removed is due to the security implications with shell expansions
+when executing scripts via the system() call.
+.\"*********************************************************
+.TP
+.B \-\-disable-occ
+Don't output a warning message if option inconsistencies are detected between
+peers.  An example of an option inconsistency would be where one peer uses
+.B \-\-dev tun
+while the other peer uses
+.B \-\-dev tap.
+
+Use of this option is discouraged, but is provided as
+a temporary fix in situations where a recent version of OpenVPN must
+connect to an old version.
+.\"*********************************************************
+.TP
+.B \-\-user user
+Change the user ID of the OpenVPN process to
+.B user
+after initialization, dropping privileges in the process.
+This option is useful to protect the system
+in the event that some hostile party was able to gain control of
+an OpenVPN session.  Though OpenVPN's security features make
+this unlikely, it is provided as a second line of defense.
+
+By setting
+.B user
+to
+.I nobody
+or somebody similarly unprivileged, the hostile party would be
+limited in what damage they could cause.  Of course once
+you take away privileges, you cannot return them
+to an OpenVPN session.  This means, for example, that if
+you want to reset an OpenVPN daemon with a
+.B SIGUSR1
+signal
+(for example in response
+to a DHCP reset), you should make use of one or more of the
+.B \-\-persist
+options to ensure that OpenVPN doesn't need to execute any privileged
+operations in order to restart (such as re-reading key files
+or running
+.BR ifconfig
+on the TUN device).
+.\"*********************************************************
+.TP
+.B \-\-group group
+Similar to the
+.B \-\-user
+option,
+this option changes the group ID of the OpenVPN process to
+.B group
+after initialization.
+.\"*********************************************************
+.TP
+.B \-\-cd dir
+Change directory to
+.B dir
+prior to reading any files such as
+configuration files, key files, scripts, etc.
+.B dir
+should be an absolute path, with a leading "/",
+and without any references
+to the current directory such as "." or "..".
+
+This option is useful when you are running
+OpenVPN in 
+.B \-\-daemon
+mode, and you want to consolidate all of
+your OpenVPN control files in one location.
+.\"*********************************************************
+.TP
+.B \-\-chroot dir
+Chroot to
+.B dir
+after initialization.  
+.B \-\-chroot
+essentially redefines
+.B dir
+as being the top
+level directory tree (/).  OpenVPN will therefore
+be unable to access any files outside this tree.
+This can be desirable from a security standpoint.
+
+Since the chroot operation is delayed until after
+initialization, most OpenVPN options that reference
+files will operate in a pre-chroot context.
+
+In many cases, the
+.B dir
+parameter can point to an empty directory, however
+complications can result when scripts or restarts
+are executed after the chroot operation.
+.\"*********************************************************
+.TP
+.B \-\-setcon context
+Apply SELinux
+.B context
+after initialization. This
+essentially provides the ability to restrict OpenVPN's
+rights to only network I/O operations, thanks to
+SELinux. This goes further than
+.B \-\-user
+and
+.B \-\-chroot
+in that those two, while being great security features,
+unfortunately do not protect against privilege escalation
+by exploitation of a vulnerable system call. You can of
+course combine all three, but please note that since
+setcon requires access to /proc you will have to provide
+it inside the chroot directory (e.g. with mount \-\-bind).
+
+Since the setcon operation is delayed until after
+initialization, OpenVPN can be restricted to just
+network-related system calls, whereas by applying the
+context before startup (such as the OpenVPN one provided
+in the SELinux Reference Policies) you will have to
+allow many things required only during initialization.
+
+Like with chroot, complications can result when scripts
+or restarts are executed after the setcon operation,
+which is why you should really consider using the
+.B \-\-persist-key
+and
+.B \-\-persist-tun
+options.
+.\"*********************************************************
+.TP
+.B \-\-daemon [progname]
+Become a daemon after all initialization functions are completed.
+This option will cause all message and error output to
+be sent to the syslog file (such as /var/log/messages),
+except for the output of scripts and
+ifconfig commands,
+which will go to /dev/null unless otherwise redirected.
+The syslog redirection occurs immediately at the point
+that
+.B \-\-daemon
+is parsed on the command line even though
+the daemonization point occurs later.  If one of the
+.B \-\-log
+options is present, it will supercede syslog
+redirection.
+
+The optional
+.B progname
+parameter will cause OpenVPN to report its program name
+to the system logger as
+.B progname.
+This can be useful in linking OpenVPN messages
+in the syslog file with specific tunnels.
+When unspecified,
+.B progname
+defaults to "openvpn".
+
+When OpenVPN is run with the
+.B \-\-daemon
+option, it will try to delay daemonization until the majority of initialization
+functions which are capable of generating fatal errors are complete.  This means
+that initialization scripts can test the return status of the
+openvpn command for a fairly reliable indication of whether the command
+has correctly initialized and entered the packet forwarding event loop.
+
+In OpenVPN, the vast majority of errors which occur after initialization are non-fatal.
+.\"*********************************************************
+.TP
+.B \-\-syslog [progname]
+Direct log output to system logger, but do not become a daemon.
+See
+.B \-\-daemon
+directive above for description of
+.B progname
+parameter.
+.TP
+.B \-\-errors-to-stderr
+Output errors to stderr instead of stdout unless log output is redirected by one of the
+.B \-\-log
+options.
+.\"*********************************************************
+.TP
+.B \-\-passtos
+Set the TOS field of the tunnel packet to what the payload's TOS is.
+.\"*********************************************************
+.TP
+.B \-\-inetd [wait|nowait] [progname]
+Use this option when OpenVPN is being run from the inetd or
+.BR xinetd(8)
+server.
+
+The
+.B wait/nowait
+option must match what is specified in the inetd/xinetd
+config file.  The
+.B nowait
+mode can only be used with
+.B \-\-proto tcp-server.
+The default is
+.B wait.
+The
+.B nowait
+mode can be used to instantiate the OpenVPN daemon as a classic TCP server,
+where client connection requests are serviced on a single
+port number.  For additional information on this kind of configuration,
+see the OpenVPN FAQ:
+.I http://openvpn.net/faq.html#oneport
+
+This option precludes the use of
+.B \-\-daemon, \-\-local,
+or
+.B \-\-remote.
+Note that this option causes message and error output to be handled in the same
+way as the
+.B \-\-daemon
+option.  The optional
+.B progname
+parameter is also handled exactly as in
+.B \-\-daemon.
+
+Also note that in
+.B wait
+mode, each OpenVPN tunnel requires a separate TCP/UDP port and
+a separate inetd or xinetd entry.  See the OpenVPN 1.x HOWTO for an example
+on using OpenVPN with xinetd:
+.I http://openvpn.net/1xhowto.html
+.\"*********************************************************
+.TP
+.B \-\-log file
+Output logging messages to
+.B file,
+including output to stdout/stderr which
+is generated by called scripts.
+If
+.B file
+already exists it will be truncated.
+This option takes effect
+immediately when it is parsed in the command line
+and will supercede syslog output if
+.B \-\-daemon
+or
+.B \-\-inetd
+is also specified.
+This option is persistent over the entire course of
+an OpenVPN instantiation and will not be reset by SIGHUP,
+SIGUSR1, or
+.B \-\-ping-restart.
+
+Note that on Windows, when OpenVPN is started as a service,
+logging occurs by default without the need to specify
+this option.
+.\"*********************************************************
+.TP
+.B \-\-log-append file
+Append logging messages to
+.B file.
+If
+.B file
+does not exist, it will be created.
+This option behaves exactly like
+.B \-\-log
+except that it appends to rather
+than truncating the log file.
+.\"*********************************************************
+.TP
+.B \-\-suppress-timestamps
+Avoid writing timestamps to log messages, even when they
+otherwise would be prepended. In particular, this applies to
+log messages sent to stdout.
+.\"*********************************************************
+.TP
+.B \-\-writepid file
+Write OpenVPN's main process ID to
+.B file.
+.\"*********************************************************
+.TP
+.B \-\-nice n
+Change process priority after initialization
+(
+.B n
+greater than 0 is lower priority,
+.B n
+less than zero is higher priority).
+.\"*********************************************************
+.\".TP
+.\".B \-\-nice-work n
+.\"Change priority of background TLS work thread.  The TLS thread
+.\"feature is enabled when OpenVPN is built
+.\"with pthread support, and you are running OpenVPN
+.\"in TLS mode (i.e. with
+.\".B \-\-tls-client
+.\"or
+.\".B \-\-tls-server
+.\"specified).
+.\"
+.\"Using a TLS thread offloads the CPU-intensive process of SSL/TLS-based
+.\"key exchange to a background thread so that it does not become
+.\"a latency bottleneck in the tunnel packet forwarding process.
+.\"
+.\"The parameter
+.\".B n
+.\"is interpreted exactly as with the
+.\".B \-\-nice
+.\"option above, but in relation to the work thread rather
+.\"than the main thread.
+.\"*********************************************************
+.TP
+.B \-\-fast-io
+(Experimental) Optimize TUN/TAP/UDP I/O writes by avoiding
+a call to poll/epoll/select prior to the write operation.  The purpose
+of such a call would normally be to block until the device
+or socket is ready to accept the write.  Such blocking is unnecessary
+on some platforms which don't support write blocking on UDP sockets
+or TUN/TAP devices.  In such cases, one can optimize the event loop
+by avoiding the poll/epoll/select call, improving CPU efficiency
+by 5% to 10%.
+
+This option can only be used on non-Windows systems, when
+.B \-\-proto udp
+is specified, and when
+.B \-\-shaper
+is NOT specified.
+.\"*********************************************************
+.TP
+.B \-\-multihome
+Configure a multi-homed UDP server.  This option can be used when
+OpenVPN has been configured to listen on all interfaces, and will
+attempt to bind client sessions to the interface on which packets
+are being received, so that outgoing packets will be sent out
+of the same interface.  Note that this option is only relevant for
+UDP servers and currently is only implemented on Linux.
+
+Note: clients connecting to a
+.B \-\-multihome
+server should always use the
+.B \-\-nobind
+option.
+.\"*********************************************************
+.TP
+.B \-\-echo [parms...]
+Echo
+.B parms
+to log output.
+
+Designed to be used to send messages to a controlling application
+which is receiving the OpenVPN log output.
+.\"*********************************************************
+.TP
+.B \-\-remap-usr1 signal
+Control whether internally or externally
+generated SIGUSR1 signals are remapped to
+SIGHUP (restart without persisting state) or
+SIGTERM (exit).
+
+.B signal
+can be set to "SIGHUP" or "SIGTERM".  By default, no remapping
+occurs.
+.\"*********************************************************
+.TP
+.B \-\-verb n
+Set output verbosity to
+.B n
+(default=1).  Each level shows all info from the previous levels.
+Level 3 is recommended if you want a good summary
+of what's happening without being swamped by output.
+
+.B 0 \-\-
+No output except fatal errors.
+.br
+.B 1 to 4 \-\-
+Normal usage range.
+.br
+.B 5 \-\-
+Output
+.B R
+and
+.B W
+characters to the console for each packet read and write, uppercase is
+used for TCP/UDP packets and lowercase is used for TUN/TAP packets.
+.br
+.B 6 to 11 \-\-
+Debug info range (see errlevel.h for additional
+information on debug levels).
+.\"*********************************************************
+.TP
+.B \-\-status file [n]
+Write operational status to
+.B file
+every
+.B n
+seconds.
+
+Status can also be written to the syslog by sending a
+.B SIGUSR2
+signal.
+.\"*********************************************************
+.TP
+.B \-\-status-version [n]
+Choose the status file format version number.  Currently
+.B n
+can be 1, 2, or 3 and defaults to 1.
+.\"*********************************************************
+.TP
+.B \-\-mute n
+Log at most
+.B n
+consecutive messages in the same category.  This is useful to
+limit repetitive logging of similar message types.
+.\"*********************************************************
+.TP
+.B \-\-comp-lzo [mode]
+Use fast LZO compression \-\- may add up to 1 byte per
+packet for incompressible data.
+.B mode
+may be "yes", "no", or "adaptive" (default).
+
+In a server mode setup, it is possible to selectively turn
+compression on or off for individual clients.
+
+First, make sure the client-side config file enables selective
+compression by having at least one
+.B \-\-comp-lzo
+directive, such as
+.B \-\-comp-lzo no.
+This will turn off compression by default,
+but allow a future directive push from the server to
+dynamically change the
+on/off/adaptive setting.
+
+Next in a
+.B \-\-client-config-dir
+file, specify the compression setting for the client,
+for example:
+
+.nf
+.ft 3
+.in +4
+comp-lzo yes
+push "comp-lzo yes"
+.in -4
+.ft
+.fi
+
+The first line sets the
+.B comp-lzo
+setting for the server
+side of the link, the second sets the client side.
+.\"*********************************************************
+.TP
+.B \-\-comp-noadapt
+When used in conjunction with
+.B \-\-comp-lzo,
+this option will disable OpenVPN's adaptive compression algorithm.
+Normally, adaptive compression is enabled with
+.B \-\-comp-lzo.
+
+Adaptive compression tries to optimize the case where you have
+compression enabled, but you are sending predominantly uncompressible
+(or pre-compressed) packets over the tunnel, such as an FTP or rsync transfer
+of a large, compressed file.  With adaptive compression,
+OpenVPN will periodically sample the compression process to measure its
+efficiency.  If the data being sent over the tunnel is already compressed,
+the compression efficiency will be very low, triggering openvpn to disable
+compression for a period of time until the next re-sample test.
+.\"*********************************************************
+.TP
+.B \-\-management IP port [pw-file]
+Enable a TCP server on
+.B IP:port
+to handle daemon management functions.
+.B pw-file,
+if specified,
+is a password file (password on first line)
+or "stdin" to prompt from standard input.  The password
+provided will set the password which TCP clients will need
+to provide in order to access management functions.
+
+The management interface can also listen on a unix domain socket,
+for those platforms that support it.  To use a unix domain socket, specify
+the unix socket pathname in place of
+.B IP
+and set
+.B port
+to 'unix'.  While the default behavior is to create a unix domain socket
+that may be connected to by any process, the
+.B \-\-management-client-user
+and
+.B \-\-management-client-group
+directives can be used to restrict access.
+
+The management interface provides a special mode where the TCP
+management link can operate over the tunnel itself.  To enable this mode,
+set
+.B IP
+= "tunnel".  Tunnel mode will cause the management interface
+to listen for a TCP connection on the local VPN address of the
+TUN/TAP interface.
+
+While the management port is designed for programmatic control
+of OpenVPN by other applications, it is possible to telnet
+to the port, using a telnet client in "raw" mode.  Once connected,
+type "help" for a list of commands.
+
+For detailed documentation on the management interface, see
+the management-notes.txt file in the
+.B management
+folder of
+the OpenVPN source distribution.
+
+It is strongly recommended that
+.B IP
+be set to 127.0.0.1
+(localhost) to restrict accessibility of the management
+server to local clients. 
+.TP
+.B \-\-management-client
+Management interface will connect as a TCP/unix domain client to
+.B IP:port
+specified by
+.B \-\-management
+rather than listen as a TCP server or on a unix domain socket.
+
+If the client connection fails to connect or is disconnected,
+a SIGTERM signal will be generated causing OpenVPN to quit.
+.\"*********************************************************
+.TP
+.B \-\-management-query-passwords
+Query management channel for private key password and
+.B \-\-auth-user-pass
+username/password.  Only query the management channel
+for inputs which ordinarily would have been queried from the
+console.
+.\"*********************************************************
+.TP
+.B \-\-management-query-proxy
+Query management channel for proxy server information for a specific
+.B \-\-remote
+(client-only).
+.\"*********************************************************
+.TP
+.B \-\-management-query-remote
+Allow management interface to override
+.B \-\-remote
+directives (client-only).
+.\"*********************************************************
+.B \-\-management-external-key
+Allows usage for external private key file instead of
+.B \-\-key
+option (client-only).
+.\"*********************************************************
+.TP
+.B \-\-management-forget-disconnect
+Make OpenVPN forget passwords when management session
+disconnects.
+
+This directive does not affect the
+.B \-\-http-proxy
+username/password.  It is always cached.
+.\"*********************************************************
+.TP
+.B \-\-management-hold
+Start OpenVPN in a hibernating state, until a client
+of the management interface explicitly starts it
+with the
+.B hold release
+command.
+.\"*********************************************************
+.TP
+.B \-\-management-signal
+Send SIGUSR1 signal to OpenVPN if management session disconnects.
+This is useful when you wish to disconnect an OpenVPN session on
+user logoff. For --management-client this option is not needed since
+a disconnect will always generate a SIGTERM.
+.\"*********************************************************
+.TP
+.B \-\-management-log-cache n
+Cache the most recent
+.B n
+lines of log file history for usage
+by the management channel.
+.\"*********************************************************
+.TP
+.B \-\-management-up-down
+Report tunnel up/down events to management interface.
+.B 
+.\"*********************************************************
+.TP
+.B \-\-management-client-auth
+Gives management interface client the responsibility
+to authenticate clients after their client certificate
+has been verified.  See management-notes.txt in OpenVPN
+distribution for detailed notes.
+.\"*********************************************************
+.TP
+.B \-\-management-client-pf
+Management interface clients must specify a packet
+filter file for each connecting client.  See management-notes.txt
+in OpenVPN distribution for detailed notes.
+.\"*********************************************************
+.TP
+.B \-\-management-client-user u
+When the management interface is listening on a unix domain socket,
+only allow connections from user
+.B u.
+.\"*********************************************************
+.TP
+.B \-\-management-client-group g
+When the management interface is listening on a unix domain socket,
+only allow connections from group
+.B g.
+.\"*********************************************************
+.TP
+.B \-\-plugin module-pathname [init-string]
+Load plug-in module from the file
+.B module-pathname,
+passing
+.B init-string
+as an argument
+to the module initialization function.  Multiple
+plugin modules may be loaded into one OpenVPN
+process.
+
+For more information and examples on how to build OpenVPN
+plug-in modules, see the README file in the
+.B plugin
+folder of the OpenVPN source distribution.
+
+If you are using an RPM install of OpenVPN, see
+/usr/share/openvpn/plugin.  The documentation is
+in
+.B doc
+and the actual plugin modules are in
+.B lib.
+
+Multiple plugin modules can be cascaded, and modules can be
+used in tandem with scripts.  The modules will be called by
+OpenVPN in the order that they are declared in the config
+file.  If both a plugin and script are configured for the same
+callback, the script will be called last.  If the
+return code of the module/script controls an authentication
+function (such as tls-verify, auth-user-pass-verify, or
+client-connect), then
+every module and script must return success (0) in order for
+the connection to be authenticated.
+.\"*********************************************************
+.SS Server Mode
+Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode
+is supported, and can be enabled with the
+.B \-\-mode server
+option.  In server mode, OpenVPN will listen on a single
+port for incoming client connections.  All client
+connections will be routed through a single tun or tap
+interface.  This mode is designed for scalability and should
+be able to support hundreds or even thousands of clients
+on sufficiently fast hardware.  SSL/TLS authentication must
+be used in this mode.
+.\"*********************************************************
+.TP
+.B \-\-server network netmask
+A helper directive designed to simplify the configuration
+of OpenVPN's server mode.  This directive will set up an
+OpenVPN server which will allocate addresses to clients
+out of the given network/netmask.  The server itself
+will take the ".1" address of the given network
+for use as the server-side endpoint of the local
+TUN/TAP interface.
+
+For example,
+.B \-\-server 10.8.0.0 255.255.255.0
+expands as follows:
+
+.nf
+.ft 3
+.in +4
+ mode server
+ tls-server
+ push "topology [topology]"
+
+ if dev tun AND (topology == net30 OR topology == p2p):
+   ifconfig 10.8.0.1 10.8.0.2
+   if !nopool:
+     ifconfig-pool 10.8.0.4 10.8.0.251
+   route 10.8.0.0 255.255.255.0
+   if client-to-client:
+     push "route 10.8.0.0 255.255.255.0"
+   else if topology == net30:
+     push "route 10.8.0.1"
+
+ if dev tap OR (dev tun AND topology == subnet):
+   ifconfig 10.8.0.1 255.255.255.0
+   if !nopool:
+     ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
+   push "route-gateway 10.8.0.1"
+.in -4
+.ft
+.fi
+
+Don't use
+.B \-\-server
+if you are ethernet bridging.  Use
+.B \-\-server-bridge
+instead.
+.\"*********************************************************
+.TP
+.B \-\-server-bridge gateway netmask pool-start-IP pool-end-IP
+.TP
+.B \-\-server-bridge ['nogw']
+
+A helper directive similar to
+.B \-\-server
+which is designed to simplify the configuration
+of OpenVPN's server mode in ethernet bridging configurations.
+
+If
+.B \-\-server-bridge
+is used without any parameters, it will enable a DHCP-proxy
+mode, where connecting OpenVPN clients will receive an IP
+address for their TAP adapter from the DHCP server running
+on the OpenVPN server-side LAN.
+Note that only clients that support
+the binding of a DHCP client with the TAP adapter (such as
+Windows) can support this mode.  The optional 
+.B nogw
+flag (advanced) indicates that gateway information should not be
+pushed to the client.
+
+To configure ethernet bridging, you 
+must first use your OS's bridging capability
+to bridge the TAP interface with the ethernet
+NIC interface.  For example, on Linux this is done
+with the
+.B brctl
+tool, and with Windows XP it is done in the Network
+Connections Panel by selecting the ethernet and
+TAP adapters and right-clicking on "Bridge Connections".
+
+Next you you must manually set the
+IP/netmask on the bridge interface.  The
+.B gateway
+and
+.B netmask
+parameters to
+.B \-\-server-bridge
+can be set to either the IP/netmask of the
+bridge interface, or the IP/netmask of the
+default gateway/router on the bridged
+subnet.
+
+Finally, set aside a IP range in the bridged
+subnet,
+denoted by
+.B pool-start-IP
+and
+.B pool-end-IP,
+for OpenVPN to allocate to connecting
+clients.
+
+For example,
+.B server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254
+expands as follows:
+
+.nf
+.ft 3
+.in +4
+mode server
+tls-server
+
+ifconfig-pool 10.8.0.128 10.8.0.254 255.255.255.0
+push "route-gateway 10.8.0.4"
+.in -4
+.ft
+.fi
+
+In another example,
+.B \-\-server-bridge
+(without parameters) expands as follows:
+
+.nf
+.ft 3
+.in +4
+mode server
+tls-server
+
+push "route-gateway dhcp"
+.in -4
+.ft
+.fi
+
+Or
+.B \-\-server-bridge nogw
+expands as follows:
+
+.nf
+.ft 3
+.in +4
+mode server
+tls-server
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.TP
+.B \-\-push "option"
+Push a config file option back to the client for remote
+execution.  Note that
+.B
+option
+must be enclosed in double quotes ("").  The client must specify
+.B \-\-pull
+in its config file.  The set of options which can be
+pushed is limited by both feasibility and security.
+Some options such as those which would execute scripts
+are banned, since they would effectively allow a compromised
+server to execute arbitrary code on the client.
+Other options such as TLS or MTU parameters
+cannot be pushed because the client needs to know
+them before the connection to the server can be initiated.
+
+This is a partial list of options which can currently be pushed:
+.B \-\-route, \-\-route-gateway, \-\-route-delay, \-\-redirect-gateway,
+.B \-\-ip-win32, \-\-dhcp-option,
+.B \-\-inactive, \-\-ping, \-\-ping-exit, \-\-ping-restart,
+.B \-\-setenv,
+.B \-\-persist-key, \-\-persist-tun, \-\-echo,
+.B \-\-comp-lzo,
+.B \-\-socket-flags,
+.B \-\-sndbuf, \-\-rcvbuf
+.\"*********************************************************
+.TP
+.B \-\-push-reset
+Don't inherit the global push list for a specific client instance.
+Specify this option in a client-specific context such
+as with a
+.B \-\-client-config-dir
+configuration file.  This option will ignore
+.B \-\-push
+options at the global config file level.
+.TP
+.B \-\-push-peer-info
+Push additional information about the client to server.  The additional information
+consists of the following data:
+
+IV_VER=<version> -- the client OpenVPN version
+
+IV_PLAT=[linux|solaris|openbsd|mac|netbsd|freebsd|win] -- the client OS platform
+
+IV_HWADDR=<mac address> -- the MAC address of clients default gateway
+
+IV_LZO_STUB=1 -- if client was built with LZO stub capability
+
+UV_<name>=<value> -- client environment variables whose names start with "UV_"
+.\"*********************************************************
+.TP
+.B \-\-disable
+Disable a particular client (based on the common name)
+from connecting.  Don't use this option to disable a client
+due to key or password compromise.  Use a CRL (certificate
+revocation list) instead (see the
+.B \-\-crl-verify
+option).
+
+This option must be associated with a specific client instance,
+which means that it must be specified either in a client
+instance config file using
+.B \-\-client-config-dir
+or dynamically generated using a
+.B \-\-client-connect
+script.
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-pool start-IP end-IP [netmask]
+Set aside a pool of subnets to be
+dynamically allocated to connecting clients, similar
+to a DHCP server.  For tun-style
+tunnels, each client will be given a /30 subnet (for
+interoperability with Windows clients).  For tap-style
+tunnels, individual addresses will be allocated, and the
+optional
+.B netmask
+parameter will also be pushed to clients.
+
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-pool-persist file [seconds]
+Persist/unpersist ifconfig-pool
+data to
+.B file,
+at
+.B seconds
+intervals (default=600), as well as on program startup and
+shutdown.
+
+The goal of this option is to provide a long-term association
+between clients (denoted by their common name) and the virtual
+IP address assigned to them from the ifconfig-pool.
+Maintaining a long-term
+association is good for clients because it allows them
+to effectively use the
+.B \-\-persist-tun
+option.
+
+.B file
+is a comma-delimited ASCII file, formatted as
+<Common-Name>,<IP-address>.
+
+If
+.B seconds
+= 0,
+.B file
+will be treated as read-only.  This is useful if
+you would like to treat
+.B file
+as a configuration file.
+
+Note that the entries in this file are treated by OpenVPN as
+suggestions only, based on past associations between
+a common name and IP address.  They do not guarantee that the given common
+name will always receive the given IP address.  If you want guaranteed
+assignment, use
+.B \-\-ifconfig-push
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-pool-linear
+Modifies the
+.B \-\-ifconfig-pool
+directive to
+allocate individual TUN interface addresses for
+clients rather than /30 subnets.  NOTE:  This option
+is incompatible with Windows clients.
+
+This option is deprecated, and should be replaced with
+.B \-\-topology p2p
+which is functionally equivalent.
+.\"*********************************************************
+.TP
+.B \-\-ifconfig-push local remote-netmask [alias]
+Push virtual IP endpoints for client tunnel,
+overriding the \-\-ifconfig-pool dynamic allocation.
+
+The parameters
+.B local
+and
+.B remote-netmask
+are set according to the
+.B \-\-ifconfig
+directive which you want to execute on the client machine to
+configure the remote end of the tunnel.  Note that the parameters
+.B local
+and
+.B remote-netmask
+are from the perspective of the client, not the server.  They may be
+DNS names rather than IP addresses, in which case they will be resolved
+on the server at the time of client connection.
+
+The optional
+.B alias
+parameter may be used in cases where NAT causes the client view
+of its local endpoint to differ from the server view.  In this case
+.B local/remote-netmask
+will refer to the server view while
+.B alias/remote-netmask
+will refer to the client view.
+
+This option must be associated with a specific client instance,
+which means that it must be specified either in a client
+instance config file using
+.B \-\-client-config-dir
+or dynamically generated using a
+.B \-\-client-connect
+script.
+
+Remember also to include a
+.B \-\-route
+directive in the main OpenVPN config file which encloses
+.B local,
+so that the kernel will know to route it
+to the server's TUN/TAP interface.
+
+OpenVPN's internal client IP address selection algorithm works as
+follows:
+
+.B 1
+\-\- Use
+.B \-\-client-connect script
+generated file for static IP (first choice).
+.br
+.B 2
+\-\- Use
+.B \-\-client-config-dir
+file for static IP (next choice).
+.br
+.B 3
+\-\- Use
+.B \-\-ifconfig-pool
+allocation for dynamic IP (last choice).
+.br
+.\"*********************************************************
+.TP
+.B \-\-iroute network [netmask]
+Generate an internal route to a specific
+client. The
+.B netmask
+parameter, if omitted, defaults to 255.255.255.255.
+
+This directive can be used to route a fixed subnet from
+the server to a particular client, regardless
+of where the client is connecting from.  Remember
+that you must also add the route to the system
+routing table as well (such as by using the
+.B \-\-route
+directive).  The reason why two routes are needed
+is that the
+.B \-\-route
+directive routes the packet from the kernel
+to OpenVPN.  Once in OpenVPN, the
+.B \-\-iroute
+directive routes to the specific client.
+
+This option must be specified either in a client
+instance config file using
+.B \-\-client-config-dir
+or dynamically generated using a
+.B \-\-client-connect
+script.
+
+The
+.B \-\-iroute
+directive also has an important interaction with
+.B \-\-push
+"route ...".
+.B \-\-iroute
+essentially defines a subnet which is owned by a
+particular client (we will call this client A).
+If you would like other clients to be able to reach A's
+subnet, you can use
+.B \-\-push
+"route ..."
+together with
+.B \-\-client-to-client
+to effect this.  In order for all clients to see
+A's subnet, OpenVPN must push this route to all clients
+EXCEPT for A, since the subnet is already owned by A.
+OpenVPN accomplishes this by not
+not pushing a route to a client
+if it matches one of the client's iroutes.
+.\"*********************************************************
+.TP
+.B \-\-client-to-client
+Because the OpenVPN server mode handles multiple clients
+through a single tun or tap interface, it is effectively
+a router.  The
+.B \-\-client-to-client
+flag tells OpenVPN to internally route client-to-client
+traffic rather than pushing all client-originating traffic
+to the TUN/TAP interface.
+
+When this option is used, each client will "see" the other
+clients which are currently connected.  Otherwise, each
+client will only see the server.  Don't use this option
+if you want to firewall tunnel traffic using
+custom, per-client rules.
+.\"*********************************************************
+.TP
+.B \-\-duplicate-cn
+Allow multiple clients with the same common name to concurrently connect.
+In the absence of this option, OpenVPN will disconnect a client instance
+upon connection of a new client having the same common name.
+.\"*********************************************************
+.TP
+.B \-\-client-connect cmd
+Run
+.B command cmd
+on client connection.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+The command is passed the common name
+and IP address of the just-authenticated client
+as environmental variables (see environmental variable section
+below).  The command is also passed
+the pathname of a freshly created temporary file as the last argument
+(after any arguments specified in
+.B cmd
+), to be used by the command
+to pass dynamically generated config file directives back to OpenVPN.
+
+If the script wants to generate a dynamic config file
+to be applied on the server when the client connects,
+it should write it to the file named by the last argument.
+
+See the
+.B \-\-client-config-dir
+option below for options which
+can be legally used in a dynamically generated config file.
+
+Note that the return value of
+.B script
+is significant.  If
+.B script
+returns a non-zero error status, it will cause the client
+to be disconnected.
+.\"*********************************************************
+.TP
+.B \-\-client-disconnect cmd
+Like
+.B \-\-client-connect
+but called on client instance shutdown.  Will not be called
+unless the
+.B \-\-client-connect
+script and plugins (if defined)
+were previously called on this instance with
+successful (0) status returns.
+
+The exception to this rule is if the
+.B \-\-client-disconnect
+command or plugins are cascaded, and at least one client-connect
+function succeeded, then ALL of the client-disconnect functions for
+scripts and plugins will be called on client instance object deletion,
+even in cases where some of the related client-connect functions returned
+an error status.
+
+The
+.B \-\-client-disconnect
+command is passed the same pathname as the corresponding
+.B \-\-client-connect
+command as its last argument. (after any arguments specified in
+.B cmd
+).
+.B 
+.\"*********************************************************
+.TP
+.B \-\-client-config-dir dir
+Specify a directory
+.B dir
+for custom client config files.  After
+a connecting client has been authenticated, OpenVPN will
+look in this directory for a file having the same name
+as the client's X509 common name.  If a matching file
+exists, it will be opened and parsed for client-specific
+configuration options.  If no matching file is found, OpenVPN
+will instead try to open and parse a default file called
+"DEFAULT", which may be provided but is not required. Note that
+the configuration files must be readable by the OpenVPN process
+after it has dropped it's root privileges.
+
+This file can specify a fixed IP address for a given
+client using
+.B \-\-ifconfig-push,
+as well as fixed subnets owned by the client using
+.B \-\-iroute.
+
+One of the useful properties of this option is that it
+allows client configuration files to be conveniently
+created, edited, or removed while the server is live,
+without needing to restart the server.
+
+The following
+options are legal in a client-specific context:
+.B \-\-push, \-\-push-reset, \-\-iroute, \-\-ifconfig-push,
+and
+.B \-\-config.
+.\"*********************************************************
+.TP
+.B \-\-ccd-exclusive
+Require, as a
+condition of authentication, that a connecting client has a
+.B \-\-client-config-dir
+file.
+.\"*********************************************************
+.TP
+.B \-\-tmp-dir dir
+Specify a directory
+.B dir
+for temporary files.  This directory will be used by
+openvpn processes and script to communicate temporary
+data with openvpn main process. Note that
+the directory must be writable by the OpenVPN process
+after it has dropped it's root privileges.
+
+This directory will be used by in the following cases:
+
+*
+.B \-\-client-connect
+scripts to dynamically generate client-specific
+configuration files.
+
+*
+.B OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY
+plugin hook to return success/failure via auth_control_file
+when using deferred auth method
+
+*
+.B OPENVPN_PLUGIN_ENABLE_PF
+plugin hook to pass filtering rules via pf_file
+.\"*********************************************************
+.TP
+.B \-\-hash-size r v
+Set the size of the real address hash table to
+.B r
+and the virtual address table to
+.B v.
+By default, both tables are sized at 256 buckets.
+.\"*********************************************************
+.TP
+.B \-\-bcast-buffers n
+Allocate
+.B n
+buffers for broadcast datagrams (default=256).
+.\"*********************************************************
+.TP
+.B \-\-tcp-queue-limit n
+Maximum number of output packets queued before TCP (default=64).
+
+When OpenVPN is tunneling data from a TUN/TAP device to a
+remote client over a TCP connection, it is possible that the TUN/TAP device
+might produce data at a faster rate than the TCP connection
+can support.  When the number of output packets queued before sending to
+the TCP socket reaches this limit for a given client connection,
+OpenVPN will start to drop outgoing packets directed
+at this client.
+.\"*********************************************************
+.TP
+.B \-\-tcp-nodelay
+This macro sets the TCP_NODELAY socket flag on the server
+as well as pushes it to connecting clients.  The TCP_NODELAY
+flag disables the Nagle algorithm on TCP sockets causing
+packets to be transmitted immediately with low latency,
+rather than waiting a short period of time in order
+to aggregate several packets into a larger containing
+packet.  In VPN applications over TCP, TCP_NODELAY
+is generally a good latency optimization.
+
+The macro expands as follows:
+
+.nf
+.ft 3
+.in +4
+ if mode server:
+   socket-flags TCP_NODELAY
+   push "socket-flags TCP_NODELAY"
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.TP
+.B \-\-max-clients n
+Limit server to a maximum of
+.B n
+concurrent clients.
+.\"*********************************************************
+.TP
+.B \-\-max-routes-per-client n
+Allow a maximum of
+.B n
+internal routes per client (default=256).
+This is designed to
+help contain DoS attacks where an authenticated client floods the
+server with packets appearing to come from many unique MAC addresses,
+forcing the server to deplete
+virtual memory as its internal routing table expands.
+This directive can be used in a
+.B \-\-client-config-dir
+file or auto-generated by a
+.B \-\-client-connect
+script to override the global value for a particular client.
+
+Note that this
+directive affects OpenVPN's internal routing table, not the
+kernel routing table.
+.\"*********************************************************
+.TP
+.B \-\-stale-routes-check n [t]
+Remove routes haven't had activity for
+.B n
+seconds (i.e. the ageing time).
+
+This check is ran every
+.B t
+seconds (i.e. check interval).
+
+If
+.B t
+is not present it defaults to
+.B n
+
+This option helps to keep the dynamic routing table small.
+See also
+.B \-\-max-routes-per-client
+.\"*********************************************************
+.TP
+.B \-\-connect-freq n sec
+Allow a maximum of
+.B n
+new connections per
+.B sec 
+seconds from clients.  This is designed to contain DoS attacks which flood
+the server with connection requests using certificates which
+will ultimately fail to authenticate.
+
+This is an imperfect solution however, because in a real
+DoS scenario, legitimate connections might also be refused.
+
+For the best protection against DoS attacks in server mode,
+use
+.B \-\-proto udp
+and
+.B \-\-tls-auth.
+.\"*********************************************************
+.TP
+.B \-\-learn-address cmd
+Run command
+.B cmd
+to validate client virtual addresses or routes.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+Three arguments will be appended to any arguments in
+.B cmd
+as follows:
+
+.B [1] operation \-\-
+"add", "update", or "delete" based on whether or not
+the address is being added to, modified, or deleted from
+OpenVPN's internal routing table.
+.br
+.B [2] address \-\-
+The address being learned or unlearned.  This can be
+an IPv4 address such as "198.162.10.14", an IPv4 subnet
+such as "198.162.10.0/24", or an ethernet MAC address (when
+.B \-\-dev tap
+is being used) such as "00:FF:01:02:03:04".
+.br
+.B [3] common name \-\-
+The common name on the certificate associated with the
+client linked to this address.  Only present for "add"
+or "update" operations, not "delete".
+
+On "add" or "update" methods, if the script returns
+a failure code (non-zero), OpenVPN will reject the address
+and will not modify its internal routing table.
+
+Normally, the
+.B cmd
+script will use the information provided above to set
+appropriate firewall entries on the VPN TUN/TAP interface.
+Since OpenVPN provides the association between virtual IP
+or MAC address and the client's authenticated common name,
+it allows a user-defined script to configure firewall access
+policies with regard to the client's high-level common name,
+rather than the low level client virtual addresses.
+.\"*********************************************************
+.TP
+.B \-\-auth-user-pass-verify cmd method
+Require the client to provide a username/password (possibly
+in addition to a client certificate) for authentication.
+
+OpenVPN will run
+.B command cmd
+to validate the username/password
+provided by the client.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+If
+.B method
+is set to "via-env", OpenVPN will call
+.B script
+with the environmental variables
+.B username
+and
+.B password
+set to the username/password strings provided by the client.
+Be aware that this method is insecure on some platforms which
+make the environment of a process publicly visible to other
+unprivileged processes.
+
+If
+.B method
+is set to "via-file", OpenVPN will write the username and
+password to the first two lines of a temporary file.  The filename
+will be passed as an argument to
+.B script,
+and the file will be automatically deleted by OpenVPN after
+the script returns.  The location of the temporary file is
+controlled by the
+.B \-\-tmp-dir
+option, and will default to the current directory if unspecified.
+For security, consider setting 
+.B \-\-tmp-dir
+to a volatile storage medium such as
+.B /dev/shm
+(if available) to prevent the username/password file from touching the hard drive.
+
+The script should examine the username
+and password,
+returning a success exit code (0) if the
+client's authentication request is to be accepted, or a failure
+code (1) to reject the client.
+
+This directive is designed to enable a plugin-style interface
+for extending OpenVPN's authentication capabilities.
+
+To protect against a client passing a maliciously formed
+username or password string, the username string must
+consist only of these characters: alphanumeric, underbar
+('_'), dash ('-'), dot ('.'), or at ('@').  The password
+string can consist of any printable characters except for
+CR or LF.  Any illegal characters in either the username
+or password string will be converted to underbar ('_').
+
+Care must be taken by any user-defined scripts to avoid
+creating a security vulnerability in the way that these
+strings are handled.  Never use these strings in such a way
+that they might be escaped or evaluated by a shell interpreter.
+
+For a sample script that performs PAM authentication, see
+.B sample-scripts/auth-pam.pl
+in the OpenVPN source distribution.
+.\"*********************************************************
+.TP
+.B \-\-opt-verify
+Clients that connect with options that are incompatible
+with those of the server will be disconnected.
+
+Options that will be compared for compatibility include
+dev-type, link-mtu, tun-mtu, proto, tun-ipv6, ifconfig,
+comp-lzo, fragment, keydir, cipher, auth, keysize, secret,
+no-replay, no-iv, tls-auth, key-method, tls-server, and tls-client.
+
+This option requires that
+.B \-\-disable-occ
+NOT be used.
+.\"*********************************************************
+.TP
+.B \-\-auth-user-pass-optional
+Allow connections by clients that do not specify a username/password.
+Normally, when
+.B \-\-auth-user-pass-verify
+or
+.B \-\-management-client-auth
+is specified (or an authentication plugin module), the
+OpenVPN server daemon will require connecting clients to specify a
+username and password.  This option makes the submission of a username/password
+by clients optional, passing the responsibility to the user-defined authentication
+module/script to accept or deny the client based on other factors
+(such as the setting of X509 certificate fields).  When this option is used,
+and a connecting client does not submit a username/password, the user-defined
+authentication module/script will see the username and password as being set
+to empty strings ("").  The authentication module/script MUST have logic
+to detect this condition and respond accordingly.
+.\"*********************************************************
+.TP
+.B \-\-client-cert-not-required
+Don't require client certificate, client will authenticate
+using username/password only.  Be aware that using this directive
+is less secure than requiring certificates from all clients.
+
+If you use this directive, the
+entire responsibility of authentication will rest on your
+.B \-\-auth-user-pass-verify
+script, so keep in mind that bugs in your script
+could potentially compromise the security of your VPN.
+
+If you don't use this directive, but you also specify an
+.B \-\-auth-user-pass-verify
+script, then OpenVPN will perform double authentication.  The
+client certificate verification AND the
+.B \-\-auth-user-pass-verify
+script will need to succeed in order for a client to be
+authenticated and accepted onto the VPN.
+.\"*********************************************************
+.TP
+.B \-\-username-as-common-name
+For
+.B \-\-auth-user-pass-verify
+authentication, use
+the authenticated username as the common name,
+rather than the common name from the client cert.
+.\"*********************************************************
+.TP
+.B \-\-compat\-names [no\-remapping]
+Until OpenVPN v2.3 the format of the X.509 Subject fields was formatted
+like this:
+.IP
+.B
+/C=US/L=Somewhere/CN=John Doe/emailAddress=john@example.com
+.IP
+In addition the old behavivour was to remap any character other than
+alphanumeric, underscore ('_'), dash ('-'), dot ('.'), and slash ('/') to
+underscore ('_').  The X.509 Subject string as returned by the
+.B tls_id
+environmental variable, could additionally contain colon (':') or equal ('=').
+.IP
+When using the
+.B \-\-compat\-names
+option, this old formatting and remapping will be re-enabled again.  This is
+purely implemented for compatibility reasons when using older plug-ins or
+scripts which does not handle the new formatting or UTF-8 characters.
+.IP
+In OpenVPN v2.3 the formatting of these fields changed into a more
+standardised format.  It now looks like:
+.IP
+.B
+C=US, L=Somewhere, CN=John Doe, emailAddress=john@example.com
+.IP
+The new default format in OpenVPN v2.3 also does not do the character remapping
+which happened earlier.  This new format enables proper support for UTF\-8
+characters in the usernames, X.509 Subject fields and Common Name variables and
+it complies to the RFC 2253, UTF\-8 String Representation of Distinguished
+Names.
+
+As a backwards compatibility for the removed \-\-no\-name\-remapping feature in
+older OpenVPN versions, the
+.B no\-remapping
+mode flag can be used with the
+.B
+\-\-compat\-names
+option.
+When this mode flag is used, the Common Name, Subject, and username strings are
+allowed to include any printable character including space, but excluding
+control characters such as tab, newline, and carriage-return. It ensures
+compatibility with the
+.B \-\-no\-name\-remapping
+option of OpenVPN versions before v2.3.
+
+.B Please note:
+This option will not be around for a long time.  It is only implemented
+to make the transition to the new formatting less intrusive.  It will be
+removed either in OpenVPN v2.4 or v2.5.  So please make sure you start
+the process to support the new formatting as soon as possible.
+.\"*********************************************************
+.TP
+.B \-\-port-share host port [dir]
+When run in TCP server mode, share the OpenVPN port with
+another application, such as an HTTPS server.  If OpenVPN
+senses a connection to its port which is using a non-OpenVPN
+protocol, it will proxy the connection to the server at
+.B host:port.
+Currently only designed to work with HTTP/HTTPS,
+though it would be theoretically possible to extend to
+other protocols such as ssh.
+
+.B dir
+specifies an optional directory where a temporary file with name N
+containing content C will be dynamically generated for each proxy
+connection, where N is the source IP:port of the client connection
+and C is the source IP:port of the connection to the proxy
+receiver.  This directory can be used as a dictionary by
+the proxy receiver to determine the origin of the connection.
+Each generated file will be automatically deleted when the proxied
+connection is torn down.
+
+Not implemented on Windows.
+.\"*********************************************************
+.SS Client Mode
+Use client mode when connecting to an OpenVPN server
+which has
+.B \-\-server, \-\-server-bridge,
+or
+.B \-\-mode server
+in it's configuration.
+.\"*********************************************************
+.TP
+.B \-\-client
+A helper directive designed to simplify the configuration
+of OpenVPN's client mode.  This directive is equivalent to:
+
+.nf
+.ft 3
+.in +4
+ pull
+ tls-client
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.TP
+.B \-\-pull
+This option must be used on a client which is connecting
+to a multi-client server.  It indicates to OpenVPN that it
+should accept options pushed by the server, provided they
+are part of the legal set of pushable options (note that the
+.B \-\-pull
+option is implied by
+.B \-\-client
+).
+
+In particular,
+.B \-\-pull
+allows the server to push routes to the client, so you should
+not use
+.B \-\-pull
+or
+.B \-\-client
+in situations where you don't trust the server to have control
+over the client's routing table.
+.\"*********************************************************
+.TP
+.B \-\-auth-user-pass [up]
+Authenticate with server using username/password.
+.B up
+is a file containing username/password on 2 lines (Note: OpenVPN
+will only read passwords from a file if it has been built
+with the \-\-enable-password-save configure option, or on Windows
+by defining ENABLE_PASSWORD_SAVE in win/settings.in).
+
+If
+.B up
+is omitted, username/password will be prompted from the
+console.
+
+The server configuration must specify an
+.B \-\-auth-user-pass-verify
+script to verify the username/password provided by
+the client.
+.\"*********************************************************
+.TP
+.B \-\-auth-retry type
+Controls how OpenVPN responds to username/password verification
+errors such as the client-side response to an AUTH_FAILED message from the server
+or verification failure of the private key password.
+
+Normally used to prevent auth errors from being fatal
+on the client side, and to permit username/password requeries in case
+of error.
+
+An AUTH_FAILED message is generated by the server if the client
+fails
+.B \-\-auth-user-pass
+authentication, or if the server-side
+.B \-\-client-connect
+script returns an error status when the client
+tries to connect.
+
+.B type
+can be one of:
+
+.B none \-\-
+Client will exit with a fatal error (this is the default).
+.br
+.B nointeract \-\-
+Client will retry the connection without requerying for an
+.B \-\-auth-user-pass
+username/password.  Use this option for unattended clients.
+.br
+.B interact \-\-
+Client will requery for an
+.B \-\-auth-user-pass
+username/password and/or private key password before attempting a reconnection.
+
+Note that while this option cannot be pushed, it can be controlled
+from the management interface.
+.\"*********************************************************
+.TP
+.B \-\-static\-challenge t e
+Enable static challenge/response protocol using challenge text
+.B t,
+with
+echo flag given by
+.B e
+(0|1).
+
+The echo flag indicates whether or not the user's response
+to the challenge should be echoed.
+
+See management\-notes.txt in the OpenVPN distribution for a
+description of the OpenVPN challenge/response protocol.
+.\"*********************************************************
+.TP
+.B \-\-server-poll-timeout n
+when polling possible remote servers to connect to
+in a round-robin fashion, spend no more than
+.B n
+seconds waiting for a response before trying the next server.
+.\"*********************************************************
+.TP
+.B \-\-explicit-exit-notify [n]
+In UDP client mode or point-to-point mode, send server/peer an exit notification
+if tunnel is restarted or OpenVPN process is exited.  In client mode, on
+exit/restart, this
+option will tell the server to immediately close its client instance object
+rather than waiting for a timeout.  The
+.B n
+parameter (default=1) controls the maximum number of attempts that the client
+will try to resend the exit notification message.  OpenVPN will not send any exit
+notifications unless this option is enabled.
+.\"*********************************************************
+.SS Data Channel Encryption Options:
+These options are meaningful for both Static & TLS-negotiated key modes
+(must be compatible between peers).
+.\"*********************************************************
+.TP
+.B \-\-secret file [direction]
+Enable Static Key encryption mode (non-TLS).
+Use pre-shared secret
+.B file
+which was generated with
+.B \-\-genkey.
+
+The optional
+.B direction
+parameter enables the use of 4 distinct keys
+(HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt), so that
+each data flow direction has a different set of HMAC and cipher keys.
+This has a number of desirable security properties including
+eliminating certain kinds of DoS and message replay attacks.
+
+When the
+.B direction
+parameter is omitted, 2 keys are used bidirectionally, one for HMAC
+and the other for encryption/decryption.
+
+The
+.B direction
+parameter should always be complementary on either side of the connection,
+i.e. one side should use "0" and the other should use "1", or both sides
+should omit it altogether.
+
+The
+.B direction
+parameter requires that
+.B file
+contains a 2048 bit key.  While pre-1.5 versions of OpenVPN
+generate 1024 bit key files, any version of OpenVPN which
+supports the
+.B direction
+parameter, will also support 2048 bit key file generation
+using the
+.B \-\-genkey
+option.
+
+Static key encryption mode has certain advantages,
+the primary being ease of configuration.
+
+There are no certificates
+or certificate authorities or complicated negotiation handshakes and protocols.
+The only requirement is that you have a pre-existing secure channel with
+your peer (such as
+.B ssh
+) to initially copy the key.  This requirement, along with the
+fact that your key never changes unless you manually generate a new one,
+makes it somewhat less secure than TLS mode (see below).  If an attacker
+manages to steal your key, everything that was ever encrypted with
+it is compromised.  Contrast that to the perfect forward secrecy features of
+TLS mode (using Diffie Hellman key exchange), where even if an attacker
+was able to steal your private key, he would gain no information to help
+him decrypt past sessions.
+
+Another advantageous aspect of Static Key encryption mode is that
+it is a handshake-free protocol 
+without any distinguishing signature or feature
+(such as a header or protocol handshake sequence) 
+that would mark the ciphertext packets as being
+generated by OpenVPN.  Anyone eavesdropping on the wire
+would see nothing
+but random-looking data.
+.\"*********************************************************
+.TP
+.B \-\-key-direction
+Alternative way of specifying the optional direction parameter for the
+.B \-\-tls-auth
+and
+.B \-\-secret
+options. Useful when using inline files (See section on inline files).
+.\"*********************************************************
+.TP
+.B \-\-auth alg
+Authenticate packets with HMAC using message
+digest algorithm
+.B alg.
+(The default is
+.B SHA1
+).
+HMAC is a commonly used message authentication algorithm (MAC) that uses
+a data string, a secure hash algorithm, and a key, to produce
+a digital signature.
+
+OpenVPN's usage of HMAC is to first encrypt a packet, then HMAC the resulting ciphertext.
+
+In static-key encryption mode, the HMAC key
+is included in the key file generated by
+.B \-\-genkey.
+In TLS mode, the HMAC key is dynamically generated and shared
+between peers via the TLS control channel.  If OpenVPN receives a packet with
+a bad HMAC it will drop the packet.
+HMAC usually adds 16 or 20 bytes per packet.
+Set
+.B alg=none
+to disable authentication.
+
+For more information on HMAC see
+.I http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
+.\"*********************************************************
+.TP
+.B \-\-cipher alg
+Encrypt packets with cipher algorithm
+.B alg.
+The default is
+.B BF-CBC,
+an abbreviation for Blowfish in Cipher Block Chaining mode.
+Blowfish has the advantages of being fast, very secure, and allowing key sizes
+of up to 448 bits.  Blowfish is designed to be used in situations where
+keys are changed infrequently.
+
+For more information on blowfish, see
+.I http://www.counterpane.com/blowfish.html
+
+To see other ciphers that are available with
+OpenVPN, use the
+.B \-\-show-ciphers
+option.
+
+OpenVPN supports the CBC, CFB, and OFB cipher modes,
+however CBC is recommended and CFB and OFB should
+be considered advanced modes.
+
+Set
+.B alg=none
+to disable encryption.
+.\"*********************************************************
+.TP
+.B \-\-keysize n
+Size of cipher key in bits (optional).
+If unspecified, defaults to cipher-specific default.  The
+.B \-\-show-ciphers
+option (see below) shows all available OpenSSL ciphers,
+their default key sizes, and whether the key size can
+be changed.  Use care in changing a cipher's default
+key size.  Many ciphers have not been extensively
+cryptanalyzed with non-standard key lengths, and a
+larger key may offer no real guarantee of greater
+security, or may even reduce security.
+.\"*********************************************************
+.TP
+.B \-\-prng alg [nsl]
+(Advanced) For PRNG (Pseudo-random number generator),
+use digest algorithm
+.B alg
+(default=sha1), and set
+.B nsl
+(default=16)
+to the size in bytes of the nonce secret length (between 16 and 64).
+
+Set
+.B alg=none
+to disable the PRNG and use the OpenSSL RAND_bytes function
+instead for all of OpenVPN's pseudo-random number needs.
+.\"*********************************************************
+.TP
+.B \-\-engine [engine-name]
+Enable OpenSSL hardware-based crypto engine functionality.
+
+If
+.B engine-name
+is specified,
+use a specific crypto engine.  Use the
+.B \-\-show-engines
+standalone option to list the crypto engines which are
+supported by OpenSSL.
+.\"*********************************************************
+.TP
+.B \-\-no-replay
+(Advanced) Disable OpenVPN's protection against replay attacks.
+Don't use this option unless you are prepared to make
+a tradeoff of greater efficiency in exchange for less
+security.
+
+OpenVPN provides datagram replay protection by default.
+
+Replay protection is accomplished
+by tagging each outgoing datagram with an identifier
+that is guaranteed to be unique for the key being used.
+The peer that receives the datagram will check for
+the uniqueness of the identifier.  If the identifier
+was already received in a previous datagram, OpenVPN
+will drop the packet.  Replay protection is important
+to defeat attacks such as a SYN flood attack, where
+the attacker listens in the wire, intercepts a TCP
+SYN packet (identifying it by the context in which
+it occurs in relation to other packets), then floods
+the receiving peer with copies of this packet.
+
+OpenVPN's replay protection is implemented in slightly
+different ways, depending on the key management mode
+you have selected.
+
+In Static Key mode
+or when using an CFB or OFB mode cipher, OpenVPN uses a
+64 bit unique identifier that combines a time stamp with
+an incrementing sequence number.
+
+When using TLS mode for key exchange and a CBC cipher
+mode, OpenVPN uses only a 32 bit sequence number without
+a time stamp, since OpenVPN can guarantee the uniqueness
+of this value for each key.  As in IPSec, if the sequence number is
+close to wrapping back to zero, OpenVPN will trigger
+a new key exchange.
+
+To check for replays, OpenVPN uses
+the
+.I sliding window
+algorithm used
+by IPSec.
+.\"*********************************************************
+.TP
+.B \-\-replay-window n [t]
+Use a replay protection sliding-window of size
+.B n
+and a time window of
+.B t
+seconds.
+
+By default
+.B n
+is 64 (the IPSec default) and
+.B t
+is 15 seconds.
+
+This option is only relevant in UDP mode, i.e.
+when either
+.B \-\-proto udp
+is specifed, or no
+.B \-\-proto
+option is specified.
+
+When OpenVPN tunnels IP packets over UDP, there is the possibility that
+packets might be dropped or delivered out of order.  Because OpenVPN, like IPSec,
+is emulating the physical network layer,
+it will accept an out-of-order packet sequence, and
+will deliver such packets in the same order they were received to
+the TCP/IP protocol stack, provided they satisfy several constraints.
+
+.B (a)
+The packet cannot be a replay (unless
+.B \-\-no-replay
+is specified, which disables replay protection altogether).
+
+.B (b)
+If a packet arrives out of order, it will only be accepted if the difference
+between its sequence number and the highest sequence number received
+so far is less than
+.B n.
+
+.B (c)
+If a packet arrives out of order, it will only be accepted if it arrives no later
+than
+.B t
+seconds after any packet containing a higher sequence number.
+
+If you are using a network link with a large pipeline (meaning that
+the product of bandwidth and latency is high), you may want to use
+a larger value for
+.B n.
+Satellite links in particular often require this.
+
+If you run OpenVPN at
+.B \-\-verb 4,
+you will see the message "Replay-window backtrack occurred [x]"
+every time the maximum sequence number backtrack seen thus far
+increases.  This can be used to calibrate
+.B n.
+
+There is some controversy on the appropriate method of handling packet
+reordering at the security layer.
+
+Namely, to what extent should the
+security layer protect the encapsulated protocol from attacks which masquerade
+as the kinds of normal packet loss and reordering that occur over IP networks?
+
+The IPSec and OpenVPN approach is to allow packet reordering within a certain
+fixed sequence number window.
+
+OpenVPN adds to the IPSec model by limiting the window size in time as well as
+sequence space.
+
+OpenVPN also adds TCP transport as an option (not offered by IPSec) in which
+case OpenVPN can adopt a very strict attitude towards message deletion and
+reordering:  Don't allow it.  Since TCP guarantees reliability, any packet
+loss or reordering event can be assumed to be an attack.
+
+In this sense, it could be argued that TCP tunnel transport is preferred when
+tunneling non-IP or UDP application protocols which might be vulnerable to a
+message deletion or reordering attack which falls within the normal
+operational parameters of IP networks.
+
+So I would make the statement that one should never tunnel a non-IP protocol
+or UDP application protocol over UDP, if the protocol might be vulnerable to a
+message deletion or reordering attack that falls within the normal operating
+parameters of what is to be expected from the physical IP layer.  The problem
+is easily fixed by simply using TCP as the VPN transport layer.
+.\"*********************************************************
+.TP
+.B \-\-mute-replay-warnings
+Silence the output of replay warnings, which are a common
+false alarm on WiFi networks.  This option preserves
+the security of the replay protection code without
+the verbosity associated with warnings about duplicate
+packets.
+.\"*********************************************************
+.TP
+.B \-\-replay-persist file
+Persist replay-protection state across sessions using
+.B file
+to save and reload the state.
+
+This option will strengthen protection against replay attacks,
+especially when you are using OpenVPN in a dynamic context (such
+as with
+.B \-\-inetd)
+when OpenVPN sessions are frequently started and stopped. 
+
+This option will keep a disk copy of the current replay protection
+state (i.e. the most recent packet timestamp and sequence number
+received from the remote peer), so that if an OpenVPN session
+is stopped and restarted, it will reject any replays of packets
+which were already received by the prior session.
+
+This option only makes sense when replay protection is enabled
+(the default) and you are using either
+.B \-\-secret
+(shared-secret key mode) or TLS mode with
+.B \-\-tls-auth.
+.\"*********************************************************
+.TP
+.B \-\-no-iv
+(Advanced) Disable OpenVPN's use of IV (cipher initialization vector).
+Don't use this option unless you are prepared to make
+a tradeoff of greater efficiency in exchange for less
+security.
+
+OpenVPN uses an IV by default, and requires it for CFB and
+OFB cipher modes (which are totally insecure without it).
+Using an IV is important for security when multiple
+messages are being encrypted/decrypted with the same key.
+
+IV is implemented differently depending on the cipher mode used.
+
+In CBC mode, OpenVPN uses a pseudo-random IV for each packet.
+
+In CFB/OFB mode, OpenVPN uses a unique sequence number and time stamp
+as the IV.  In fact, in CFB/OFB mode, OpenVPN uses a datagram
+space-saving optimization that uses the unique identifier for
+datagram replay protection as the IV.
+.\"*********************************************************
+.TP
+.B \-\-use-prediction-resistance
+Enable prediction resistance on PolarSSL's RNG.
+
+Enabling prediction resistance causes the RNG to reseed in each
+call for random. Reseeding this often can quickly deplete the kernel
+entropy pool.
+
+If you need this option, please consider running a daemon that adds
+entropy to the kernel pool.
+
+Note that this option only works with PolarSSL versions greater
+than 1.1.
+.\"*********************************************************
+.TP
+.B \-\-test-crypto
+Do a self-test of OpenVPN's crypto options by encrypting and
+decrypting test packets using the data channel encryption options
+specified above.  This option does not require a peer to function,
+and therefore can be specified without
+.B \-\-dev
+or
+.B \-\-remote.
+
+The typical usage of
+.B \-\-test-crypto
+would be something like this:
+
+.B openvpn \-\-test-crypto \-\-secret key
+
+or
+
+.B openvpn \-\-test-crypto \-\-secret key \-\-verb 9
+
+This option is very useful to test OpenVPN after it has been ported to
+a new platform, or to isolate problems in the compiler, OpenSSL
+crypto library, or OpenVPN's crypto code.  Since it is a self-test mode,
+problems with encryption and authentication can be debugged independently
+of network and tunnel issues.
+.\"*********************************************************
+.SS TLS Mode Options:
+TLS mode is the most powerful crypto mode of OpenVPN in both security and flexibility.
+TLS mode works by establishing control and
+data channels which are multiplexed over a single TCP/UDP port.  OpenVPN initiates
+a TLS session over the control channel and uses it to exchange cipher
+and HMAC keys to protect the data channel.  TLS mode uses a robust reliability
+layer over the UDP connection for all control channel communication, while
+the data channel, over which encrypted tunnel data passes, is forwarded without
+any mediation.  The result is the best of both worlds: a fast data channel
+that forwards over UDP with only the overhead of encrypt,
+decrypt, and HMAC functions,
+and a control channel that provides all of the security features of TLS,
+including certificate-based authentication and Diffie Hellman forward secrecy.
+
+To use TLS mode, each peer that runs OpenVPN should have its own local
+certificate/key pair (
+.B \-\-cert
+and
+.B \-\-key
+), signed by the root certificate which is specified
+in
+.B \-\-ca.
+
+When two OpenVPN peers connect, each presents its local certificate to the
+other.  Each peer will then check that its partner peer presented a
+certificate which was signed by the master root certificate as specified in
+.B \-\-ca.
+
+If that check on both peers succeeds, then the TLS negotiation
+will succeed, both OpenVPN
+peers will exchange temporary session keys, and the tunnel will begin
+passing data.
+
+The OpenVPN distribution contains a set of scripts for
+managing RSA certificates & keys,
+located in the
+.I easy-rsa
+subdirectory.
+
+The easy-rsa package is also rendered in web form here:
+.I http://openvpn.net/easyrsa.html
+.\"*********************************************************
+.TP
+.B \-\-tls-server
+Enable TLS and assume server role during TLS handshake.  Note that
+OpenVPN is designed as a peer-to-peer application.  The designation
+of client or server is only for the purpose of negotiating the TLS
+control channel.
+.\"*********************************************************
+.TP
+.B \-\-tls-client
+Enable TLS and assume client role during TLS handshake.
+.\"*********************************************************
+.TP
+.B \-\-ca file
+Certificate authority (CA) file in .pem format, also referred to as the
+.I root
+certificate.  This file can have multiple
+certificates in .pem format, concatenated together.  You can construct your own
+certificate authority certificate and private key by using a command such as:
+
+.B openssl req -nodes -new -x509 -keyout ca.key -out ca.crt
+
+Then edit your openssl.cnf file and edit the
+.B certificate
+variable to point to your new root certificate
+.B ca.crt.
+
+For testing purposes only, the OpenVPN distribution includes a sample
+CA certificate (ca.crt).
+Of course you should never use
+the test certificates and test keys distributed with OpenVPN in a
+production environment, since by virtue of the fact that
+they are distributed with OpenVPN, they are totally insecure.
+.\"*********************************************************
+.TP
+.B \-\-capath dir
+Directory containing trusted certificates (CAs and CRLs).
+Available with OpenSSL version >= 0.9.7 dev.
+Not available with PolarSSL.
+.\"*********************************************************
+.TP
+.B \-\-dh file
+File containing Diffie Hellman parameters
+in .pem format (required for
+.B \-\-tls-server
+only). Use
+
+.B openssl dhparam -out dh1024.pem 1024
+
+to generate your own, or use the existing dh1024.pem file
+included with the OpenVPN distribution.  Diffie Hellman parameters
+may be considered public.
+.\"*********************************************************
+.TP
+.B \-\-cert file
+Local peer's signed certificate in .pem format \-\- must be signed
+by a certificate authority whose certificate is in
+.B \-\-ca file.
+Each peer in an OpenVPN link running in TLS mode should have its own
+certificate and private key file.  In addition, each certificate should
+have been signed by the key of a certificate
+authority whose public key resides in the
+.B \-\-ca
+certificate authority file.
+You can easily make your own certificate authority (see above) or pay money
+to use a commercial service such as thawte.com (in which case you will be
+helping to finance the world's second space tourist :).
+To generate a certificate,
+you can use a command such as:
+
+.B openssl req -nodes -new -keyout mycert.key -out mycert.csr
+
+If your certificate authority private key lives on another machine, copy
+the certificate signing request (mycert.csr) to this other machine (this can
+be done over an insecure channel such as email).  Now sign the certificate
+with a command such as:
+
+.B openssl ca -out mycert.crt -in mycert.csr
+
+Now copy the certificate (mycert.crt)
+back to the peer which initially generated the .csr file (this
+can be over a public medium).
+Note that the
+.B openssl ca
+command reads the location of the certificate authority key from its
+configuration file such as
+.B /usr/share/ssl/openssl.cnf
+\-\- note also
+that for certificate authority functions, you must set up the files
+.B index.txt
+(may be empty) and
+.B serial
+(initialize to
+.B 
+01
+).
+.\"*********************************************************
+.TP
+.B \-\-extra-certs file
+Specify a
+.B file
+containing one or more PEM certs (concatenated together)
+that complete the
+local certificate chain.
+
+This option is useful for "split" CAs, where the CA for server
+certs is different than the CA for client certs.  Putting certs
+in this file allows them to be used to complete the local
+certificate chain without trusting them to verify the peer-submitted
+certificate, as would be the case if the certs were placed in the
+.B ca
+file.
+.\"*********************************************************
+.TP
+.B \-\-key file
+Local peer's private key in .pem format.  Use the private key which was generated
+when you built your peer's certificate (see
+.B -cert file
+above).
+.\"*********************************************************
+.TP
+.B \-\-pkcs12 file
+Specify a PKCS #12 file containing local private key,
+local certificate, and root CA certificate.
+This option can be used instead of
+.B \-\-ca, \-\-cert,
+and
+.B \-\-key.
+Not available with PolarSSL.
+.\"*********************************************************
+.TP
+.B \-\-verify-hash hash
+Specify SHA1 fingerprint for level-1 cert.  The level-1 cert is the
+CA (or intermediate cert) that signs the leaf certificate, and is
+one removed from the leaf certificate in the direction of the root.
+When accepting a connection from a peer, the level-1 cert
+fingerprint must match
+.B hash
+or certificate verification will fail.  Hash is specified
+as XX:XX:...  For example: AD:B0:95:D8:09:C8:36:45:12:A9:89:C8:90:09:CB:13:72:A6:AD:16
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-cert-private [0|1]...
+Set if access to certificate object should be performed after login.
+Every provider has its own setting.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-id name
+Specify the serialized certificate id to be used. The id can be gotten
+by the standalone
+.B \-\-show-pkcs11-ids
+option.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-id-management
+Acquire PKCS#11 id from management interface. In this case a NEED-STR 'pkcs11-id-request'
+real-time message will be triggered, application may use pkcs11-id-count command to
+retrieve available number of certificates, and pkcs11-id-get command to retrieve certificate
+id and certificate body.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-pin-cache seconds
+Specify how many seconds the PIN can be cached, the default is until the token is removed.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-protected-authentication [0|1]...
+Use PKCS#11 protected authentication path, useful for biometric and external
+keypad devices.
+Every provider has its own setting.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-providers provider...
+Specify a RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) providers
+to load.
+This option can be used instead of
+.B \-\-cert, \-\-key,
+and
+.B \-\-pkcs12.
+.\"*********************************************************
+.TP
+.B \-\-pkcs11-private-mode mode...
+Specify which method to use in order to perform private key operations.
+A different mode can be specified for each provider.
+Mode is encoded as hex number, and can be a mask one of the following:
+
+.B 0
+(default) \-\- Try to determind automatically.
+.br
+.B 1
+\-\- Use sign.
+.br
+.B 2
+\-\- Use sign recover.
+.br
+.B 4
+\-\- Use decrypt.
+.br
+.B 8
+\-\- Use unwrap.
+.br
+.\"*********************************************************
+.TP
+.B \-\-cryptoapicert select-string
+Load the certificate and private key from the
+Windows Certificate System Store (Windows/OpenSSL Only).
+
+Use this option instead of
+.B \-\-cert
+and
+.B \-\-key.
+
+This makes
+it possible to use any smart card, supported by Windows, but also any
+kind of certificate, residing in the Cert Store, where you have access to
+the private key.  This option has been tested with a couple of different
+smart cards (GemSAFE, Cryptoflex, and Swedish Post Office eID) on the
+client side, and also an imported PKCS12 software certificate on the
+server side.
+
+To select a certificate, based on a substring search in the
+certificate's subject:
+
+.B cryptoapicert
+"SUBJ:Peter Runestig"
+
+To select a certificate, based on certificate's thumbprint:
+
+.B cryptoapicert
+"THUMB:f6 49 24 41 01 b4 ..."
+
+The thumbprint hex string can easily be copy-and-pasted from the Windows
+Certificate Store GUI.
+
+.\"*********************************************************
+.TP
+.B \-\-key-method m
+Use data channel key negotiation method
+.B m.
+The key method must match on both sides of the connection.
+
+After OpenVPN negotiates a TLS session, a new set of keys
+for protecting the tunnel data channel is generated and
+exchanged over the TLS session.
+
+In method 1 (the default for OpenVPN 1.x), both sides generate
+random encrypt and HMAC-send keys which are forwarded to
+the other host over the TLS channel.
+
+In method 2, (the default for OpenVPN 2.0)
+the client generates a random key.  Both client
+and server also generate some random seed material.  All key source
+material is exchanged over the TLS channel. The actual
+keys are generated using the TLS PRF function, taking source
+entropy from both client and server.  Method 2 is designed to
+closely parallel the key generation process used by TLS 1.0.
+
+Note that in TLS mode, two separate levels 
+of keying occur:
+
+(1) The TLS connection is initially negotiated, with both sides
+of the connection producing certificates and verifying the certificate
+(or other authentication info provided) of
+the other side.  The
+.B \-\-key-method
+parameter has no effect on this process.
+
+(2) After the TLS connection is established, the tunnel session keys are
+separately negotiated over the existing secure TLS channel.  Here,
+.B \-\-key-method
+determines the derivation of the tunnel session keys.
+.\"*********************************************************
+.TP
+.B \-\-tls-cipher l
+A list
+.B l
+of allowable TLS ciphers delimited by a colon (":").
+If you require a high level of security,
+you may want to set this parameter manually, to prevent a
+version rollback attack where a man-in-the-middle attacker tries
+to force two peers to negotiate to the lowest level
+of security they both support.
+Use
+.B \-\-show-tls
+to see a list of supported TLS ciphers.
+.\"*********************************************************
+.TP
+.B \-\-tls-timeout n
+Packet retransmit timeout on TLS control channel
+if no acknowledgment from remote within
+.B n
+seconds (default=2).  When OpenVPN sends a control
+packet to its peer, it will expect to receive an
+acknowledgement within
+.B n
+seconds or it will retransmit the packet, subject
+to a TCP-like exponential backoff algorithm.  This parameter
+only applies to control channel packets.  Data channel
+packets (which carry encrypted tunnel data) are never
+acknowledged, sequenced, or retransmitted by OpenVPN because
+the higher level network protocols running on top of the tunnel
+such as TCP expect this role to be left to them.
+.\"*********************************************************
+.TP
+.B \-\-reneg-bytes n
+Renegotiate data channel key after
+.B n
+bytes sent or received (disabled by default).
+OpenVPN allows the lifetime of a key
+to be expressed as a number of bytes encrypted/decrypted, a number of packets, or
+a number of seconds.  A key renegotiation will be forced
+if any of these three criteria are met by either peer.
+.\"*********************************************************
+.TP
+.B \-\-reneg-pkts n
+Renegotiate data channel key after
+.B n
+packets sent and received (disabled by default).
+.\"*********************************************************
+.TP
+.B \-\-reneg-sec n
+Renegotiate data channel key after
+.B n
+seconds (default=3600).
+
+When using dual-factor authentication, note that this default value may
+cause the end user to be challenged to reauthorize once per hour.
+
+Also, keep in mind that this option can be used on both the client and server,
+and whichever uses the lower value will be the one to trigger the renegotiation.
+A common mistake is to set
+.B \-\-reneg-sec
+to a higher value on either the client or server, while the other side of the connection
+is still using the default value of 3600 seconds, meaning that the renegotiation will
+still occur once per 3600 seconds.  The solution is to increase \-\-reneg-sec on both the
+client and server, or set it to 0 on one side of the connection (to disable), and to
+your chosen value on the other side.
+.\"*********************************************************
+.TP
+.B \-\-hand-window n
+Handshake Window \-\- the TLS-based key exchange must finalize within
+.B n
+seconds
+of handshake initiation by any peer (default = 60 seconds).
+If the handshake fails
+we will attempt to reset our connection with our peer and try again.
+Even in the event of handshake failure we will still use
+our expiring key for up to
+.B \-\-tran-window
+seconds to maintain continuity of transmission of tunnel
+data.
+.\"*********************************************************
+.TP
+.B \-\-tran-window n
+Transition window \-\- our old key can live this many seconds
+after a new a key renegotiation begins (default = 3600 seconds).
+This feature allows for a graceful transition from old to new
+key, and removes the key renegotiation sequence from the critical
+path of tunnel data forwarding.
+.\"*********************************************************
+.TP
+.B \-\-single-session
+After initially connecting to a remote peer, disallow any new connections.
+Using this
+option means that a remote peer cannot connect, disconnect, and then
+reconnect.
+
+If the daemon is reset by a signal or
+.B \-\-ping-restart,
+it will allow one new connection.
+
+.B \-\-single-session
+can be used with
+.B \-\-ping-exit
+or
+.B \-\-inactive
+to create a single dynamic session that will exit when finished.
+.\"*********************************************************
+.TP
+.B \-\-tls-exit
+Exit on TLS negotiation failure.
+.\"*********************************************************
+.TP
+.B \-\-tls-auth file [direction]
+Add an additional layer of HMAC authentication on top of the TLS
+control channel to protect against DoS attacks.
+
+In a nutshell,
+.B \-\-tls-auth
+enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port,
+where TLS control channel packets
+bearing an incorrect HMAC signature can be dropped immediately without
+response.
+
+.B file
+(required) is a key file which can be in one of two formats:
+
+.B (1)
+An OpenVPN static key file generated by
+.B \-\-genkey
+(required if
+.B direction
+parameter is used).
+
+.B (2)
+A freeform passphrase file.  In this case the HMAC key will
+be derived by taking a secure hash of this file, similar to
+the
+.BR md5sum (1)
+or
+.BR sha1sum (1)
+commands.
+
+OpenVPN will first try format (1), and if the file fails to parse as
+a static key file, format (2) will be used.
+
+See the
+.B \-\-secret
+option for more information on the optional
+.B direction
+parameter.
+
+.B \-\-tls-auth
+is recommended when you are running OpenVPN in a mode where
+it is listening for packets from any IP address, such as when
+.B \-\-remote
+is not specified, or
+.B \-\-remote
+is specified with
+.B \-\-float.
+
+The rationale for
+this feature is as follows.  TLS requires a multi-packet exchange
+before it is able to authenticate a peer.  During this time
+before authentication, OpenVPN is allocating resources (memory
+and CPU) to this potential peer.  The potential peer is also
+exposing many parts of OpenVPN and the OpenSSL library to the packets
+it is sending.  Most successful network attacks today seek
+to either exploit bugs in programs (such as buffer overflow attacks) or
+force a program to consume so many resources that it becomes unusable.
+Of course the first line of defense is always to produce clean,
+well-audited code.  OpenVPN has been written with buffer overflow
+attack prevention as a top priority.
+But as history has shown, many of the most widely used
+network applications have, from time to time,
+fallen to buffer overflow attacks.
+
+So as a second line of defense, OpenVPN offers
+this special layer of authentication on top of the TLS control channel so that
+every packet on the control channel is authenticated by an
+HMAC signature and a unique ID for replay protection.
+This signature will also help protect against DoS (Denial of Service) attacks.
+An important rule of thumb in reducing vulnerability to DoS attacks is to
+minimize the amount of resources a potential, but as yet unauthenticated,
+client is able to consume.
+
+.B \-\-tls-auth
+does this by signing every TLS control channel packet with an HMAC signature,
+including packets which are sent before the TLS level has had a chance
+to authenticate the peer.
+The result is that packets without
+the correct signature can be dropped immediately upon reception,
+before they have a chance to consume additional system resources
+such as by initiating a TLS handshake.
+.B \-\-tls-auth
+can be strengthened by adding the
+.B \-\-replay-persist
+option which will keep OpenVPN's replay protection state
+in a file so that it is not lost across restarts.
+
+It should be emphasized that this feature is optional and that the
+passphrase/key file used with
+.B \-\-tls-auth
+gives a peer nothing more than the power to initiate a TLS
+handshake.  It is not used to encrypt or authenticate any tunnel data.
+.\"*********************************************************
+.TP
+.B \-\-askpass [file]
+Get certificate password from console or
+.B file
+before we daemonize.
+
+For the extremely
+security conscious, it is possible to protect your private key with
+a password.  Of course this means that every time the OpenVPN
+daemon is started you must be there to type the password.  The
+.B \-\-askpass
+option allows you to start OpenVPN from the command line.  It will
+query you for a password before it daemonizes.  To protect a private
+key with a password you should omit the
+.B -nodes
+option when you use the
+.B openssl
+command line tool to manage certificates and private keys.
+
+If
+.B file
+is specified, read the password from the first line of
+.B file.
+Keep in mind that storing your password in a file
+to a certain extent invalidates the extra security provided by
+using an encrypted key (Note: OpenVPN
+will only read passwords from a file if it has been built
+with the \-\-enable-password-save configure option, or on Windows
+by defining ENABLE_PASSWORD_SAVE in win/settings.in).
+.\"*********************************************************
+.TP
+.B \-\-auth-nocache
+Don't cache
+.B \-\-askpass
+or
+.B \-\-auth-user-pass
+username/passwords in virtual memory.
+
+If specified, this directive will cause OpenVPN to immediately
+forget username/password inputs after they are used.  As a result,
+when OpenVPN needs a username/password, it will prompt for input
+from stdin, which may be multiple times during the duration of an
+OpenVPN session.
+
+This directive does not affect the
+.B \-\-http-proxy
+username/password.  It is always cached.
+.\"*********************************************************
+.TP
+.B \-\-tls-verify cmd
+Run command
+.B cmd
+to verify the X509 name of a
+pending TLS connection that has otherwise passed all other
+tests of certification (except for revocation via
+.B \-\-crl-verify
+directive; the revocation test occurs after the
+.B \-\-tls-verify
+test).
+
+.B cmd
+should return 0 to allow the TLS handshake to proceed, or 1 to fail.
+
+.B cmd
+consists of a path to script (or executable program), optionally
+followed by arguments. The path and arguments may be single- or double-quoted
+and/or escaped using a backslash, and should be separated by one or more spaces.
+
+When
+.B cmd
+is executed two arguments are appended after any arguments specified in
+.B cmd
+, as follows:
+
+.B cmd certificate_depth subject
+
+These arguments are, respectively, the current certificate depth and
+the X509 common name (cn) of the peer.
+
+This feature is useful if the peer you want to trust has a certificate
+which was signed by a certificate authority who also signed many
+other certificates, where you don't necessarily want to trust all of them,
+but rather be selective about which
+peer certificate you will accept.  This feature allows you to write a script
+which will test the X509 name on a certificate and decide whether or
+not it should be accepted.  For a simple perl script which will test
+the common name field on the certificate, see the file
+.B verify-cn
+in the OpenVPN distribution.
+
+See the "Environmental Variables" section below for
+additional parameters passed as environmental variables.
+.\"*********************************************************
+.TP
+.B \-\-tls-export-cert directory
+Store the certificates the clients uses upon connection to this
+directory. This will be done before \-\-tls-verify is called.  The
+certificates will use a temporary name and will be deleted when
+the tls-verify script returns.  The file name used for the certificate
+is available via the peer_cert environment variable.
+.\"*********************************************************
+.TP
+.B \-\-x509-username-field fieldname
+Field in x509 certificate subject to be used as username (default=CN).
+.B Fieldname
+will be uppercased before matching. When this option is used, the
+--tls-remote option will match against the chosen fieldname instead
+of the CN.
+.\"*********************************************************
+.TP
+.B \-\-tls-remote name
+Accept connections only from a host with X509 name
+or common name equal to
+.B name.
+The remote host must also pass all other tests
+of verification.
+
+.B NOTE:
+Because tls-remote may test against a common name prefix,
+only use this option when you are using OpenVPN with a custom CA
+certificate that is under your control.
+Never use this option when your client certificates are signed by
+a third party, such as a commercial web CA.
+
+Name can also be a common name prefix, for example if you
+want a client to only accept connections to "Server-1",
+"Server-2", etc., you can simply use
+.B \-\-tls-remote Server
+
+Using a common name prefix is a useful alternative to managing
+a CRL (Certificate Revocation List) on the client, since it allows the client
+to refuse all certificates except for those associated
+with designated servers.
+
+.B \-\-tls-remote
+is a useful replacement for the
+.B \-\-tls-verify
+option to verify the remote host, because
+.B \-\-tls-remote
+works in a
+.B \-\-chroot
+environment too.
+.\"*********************************************************
+.TP
+.B \-\-x509-track attribute
+Save peer X509
+.B attribute
+value in environment for use by plugins and management interface.
+Prepend a '+' to
+.B attribute
+to save values from full cert chain.  Values will be encoded
+as X509_<depth>_<attribute>=<value>.  Multiple
+.B \-\-x509-track
+options can be defined to track multiple attributes.
+Not available with PolarSSL.
+.\"*********************************************************
+.TP
+.B \-\-ns-cert-type client|server
+Require that peer certificate was signed with an explicit
+.B nsCertType
+designation of "client" or "server".
+
+This is a useful security option for clients, to ensure that
+the host they connect with is a designated server.
+
+See the easy-rsa/build-key-server script for an example
+of how to generate a certificate with the
+.B nsCertType
+field set to "server".
+
+If the server certificate's nsCertType field is set
+to "server", then the clients can verify this with
+.B \-\-ns-cert-type server.
+
+This is an important security precaution to protect against
+a man-in-the-middle attack where an authorized client
+attempts to connect to another client by impersonating the server.
+The attack is easily prevented by having clients verify
+the server certificate using any one of
+.B \-\-ns-cert-type, \-\-tls-remote,
+or
+.B \-\-tls-verify.
+.\"*********************************************************
+.TP
+.B \-\-remote-cert-ku v...
+Require that peer certificate was signed with an explicit
+.B key usage.
+
+This is a useful security option for clients, to ensure that
+the host they connect to is a designated server.
+
+The key usage should be encoded in hex, more than one key
+usage can be specified.
+.\"*********************************************************
+.TP
+.B \-\-remote-cert-eku oid
+Require that peer certificate was signed with an explicit
+.B extended key usage.
+
+This is a useful security option for clients, to ensure that
+the host they connect to is a designated server.
+
+The extended key usage should be encoded in oid notation, or
+OpenSSL symbolic representation.
+.\"*********************************************************
+.TP
+.B \-\-remote-cert-tls client|server
+Require that peer certificate was signed with an explicit
+.B key usage
+and
+.B extended key usage
+based on RFC3280 TLS rules.
+
+This is a useful security option for clients, to ensure that
+the host they connect to is a designated server.
+
+The
+.B \-\-remote-cert-tls client
+option is equivalent to
+.B
+\-\-remote-cert-ku 80 08 88 \-\-remote-cert-eku "TLS Web Client Authentication"
+
+The key usage is digitalSignature and/or keyAgreement.
+
+The
+.B \-\-remote-cert-tls server
+option is equivalent to
+.B
+\-\-remote-cert-ku a0 88 \-\-remote-cert-eku "TLS Web Server Authentication"
+
+The key usage is digitalSignature and ( keyEncipherment or keyAgreement ).
+
+This is an important security precaution to protect against
+a man-in-the-middle attack where an authorized client
+attempts to connect to another client by impersonating the server.
+The attack is easily prevented by having clients verify
+the server certificate using any one of
+.B \-\-remote-cert-tls, \-\-tls-remote,
+or
+.B \-\-tls-verify.
+.\"*********************************************************
+.TP
+.B \-\-crl-verify crl ['dir']
+Check peer certificate against the file
+.B crl
+in PEM format.
+
+A CRL (certificate revocation list) is used when a particular key is
+compromised but when the overall PKI is still intact.
+
+Suppose you had a PKI consisting of a CA, root certificate, and a number of
+client certificates.  Suppose a laptop computer containing a client key and
+certificate was stolen.  By adding the stolen certificate to the CRL file,
+you could reject any connection which attempts to use it, while preserving the
+overall integrity of the PKI.
+
+The only time when it would be necessary to rebuild the entire PKI from scratch would be
+if the root certificate key itself was compromised.
+
+If the optional
+.B dir
+flag is specified, enable a different mode where
+.B crl
+is a directory containing files named as revoked serial numbers
+(the files may be empty, the contents are never read).  If a client
+requests a connection, where the client certificate serial number
+(decimal string) is the name of a file present in the directory,
+it will be rejected.
+.\"*********************************************************
+.SS SSL Library information:
+.\"*********************************************************
+.TP
+.B \-\-show-ciphers
+(Standalone)
+Show all cipher algorithms to use with the
+.B \-\-cipher
+option.
+.\"*********************************************************
+.TP
+.B \-\-show-digests
+(Standalone)
+Show all message digest algorithms to use with the
+.B \-\-auth
+option.
+.\"*********************************************************
+.TP
+.B \-\-show-tls
+(Standalone)
+Show all TLS ciphers (TLS used only as a control channel).  The TLS
+ciphers will be sorted from highest preference (most secure) to
+lowest.
+.\"*********************************************************
+.TP
+.B \-\-show-engines
+(Standalone)
+Show currently available hardware-based crypto acceleration
+engines supported by the OpenSSL library.
+.\"*********************************************************
+.SS Generate a random key:
+Used only for non-TLS static key encryption mode.
+.\"*********************************************************
+.TP
+.B \-\-genkey
+(Standalone)
+Generate a random key to be used as a shared secret,
+for use with the
+.B \-\-secret
+option.  This file must be shared with the
+peer over a pre-existing secure channel such as
+.BR scp (1)
+.
+.\"*********************************************************
+.TP
+.B \-\-secret file
+Write key to
+.B file.
+.\"*********************************************************
+.SS TUN/TAP persistent tunnel config mode:
+Available with linux 2.4.7+.  These options comprise a standalone mode
+of OpenVPN which can be used to create and delete persistent tunnels.
+.\"*********************************************************
+.TP
+.B \-\-mktun
+(Standalone)
+Create a persistent tunnel on platforms which support them such
+as Linux.  Normally TUN/TAP tunnels exist only for
+the period of time that an application has them open.  This option
+takes advantage of the TUN/TAP driver's ability to build persistent
+tunnels that live through multiple instantiations of OpenVPN and die
+only when they are deleted or the machine is rebooted.
+
+One of the advantages of persistent tunnels is that they eliminate the
+need for separate
+.B \-\-up
+and
+.B \-\-down
+scripts to run the appropriate
+.BR ifconfig (8)
+and
+.BR route (8)
+commands.  These commands can be placed in the the same shell script
+which starts or terminates an OpenVPN session.
+
+Another advantage is that open connections through the TUN/TAP-based tunnel
+will not be reset if the OpenVPN peer restarts.  This can be useful to
+provide uninterrupted connectivity through the tunnel in the event of a DHCP
+reset of the peer's public IP address (see the
+.B \-\-ipchange
+option above).
+
+One disadvantage of persistent tunnels is that it is harder to automatically
+configure their MTU value (see
+.B \-\-link-mtu
+and
+.B \-\-tun-mtu
+above).
+
+On some platforms such as Windows, TAP-Win32 tunnels are persistent by
+default.
+.\"*********************************************************
+.TP
+.B \-\-rmtun
+(Standalone)
+Remove a persistent tunnel.
+.\"*********************************************************
+.TP
+.B \-\-dev tunX | tapX
+TUN/TAP device
+.\"*********************************************************
+.TP
+.B \-\-user user
+Optional user to be owner of this tunnel.
+.\"*********************************************************
+.TP
+.B \-\-group group
+Optional group to be owner of this tunnel.
+.\"*********************************************************
+.SS Windows-Specific Options:
+.\"*********************************************************
+.TP
+.B \-\-win-sys path
+Set the Windows system directory pathname to use when looking for system
+executables such as
+.B route.exe
+and
+.B netsh.exe.
+By default, if this directive is
+not specified, OpenVPN will use the SystemRoot environment variable.
+
+This option have changed behaviour in OpenVPN 2.3.  Earlier you had to
+define
+.B --win-sys env
+to use the SystemRoot environment variable, otherwise it defaulted to C:\\WINDOWS.
+It is not needed to use the
+.B env
+keyword any more, and it will just be ignored. A warning is logged when this
+is found in the configuration file.
+.\"*********************************************************
+.TP
+.B \-\-ip-win32 method
+When using
+.B \-\-ifconfig
+on Windows, set the TAP-Win32 adapter
+IP address and netmask using
+.B method.
+Don't use this option unless you are also using
+.B \-\-ifconfig.
+
+.B manual \-\-
+Don't set the IP address or netmask automatically.
+Instead output a message
+to the console telling the user to configure the
+adapter manually and indicating the IP/netmask which
+OpenVPN expects the adapter to be set to.
+
+.B dynamic [offset] [lease-time] \-\-
+Automatically set the IP address and netmask by replying to
+DHCP query messages generated by the kernel.  This mode is
+probably the "cleanest" solution
+for setting the TCP/IP properties since it uses the well-known
+DHCP protocol.  There are, however, two prerequisites for using
+this mode: (1) The TCP/IP properties for the TAP-Win32
+adapter must be set to "Obtain an IP address automatically," and
+(2) OpenVPN needs to claim an IP address in the subnet for use
+as the virtual DHCP server address.  By default in
+.B \-\-dev tap
+mode, OpenVPN will
+take the normally unused first address in the subnet.  For example,
+if your subnet is 192.168.4.0 netmask 255.255.255.0, then
+OpenVPN will take the IP address 192.168.4.0 to use as the
+virtual DHCP server address.  In
+.B \-\-dev tun
+mode, OpenVPN will cause the DHCP server to masquerade as if it were
+coming from the remote endpoint.  The optional offset parameter is
+an integer which is > -256 and < 256 and which defaults to 0.
+If offset is positive, the DHCP server will masquerade as the IP
+address at network address + offset.
+If offset is negative, the DHCP server will masquerade as the IP
+address at broadcast address + offset.  The Windows
+.B ipconfig /all
+command can be used to show what Windows thinks the DHCP server
+address is.  OpenVPN will "claim" this address, so make sure to
+use a free address.  Having said that, different OpenVPN instantiations,
+including different ends of the same connection, can share the same
+virtual DHCP server address.  The
+.B lease-time
+parameter controls the lease time of the DHCP assignment given to
+the TAP-Win32 adapter, and is denoted in seconds.
+Normally a very long lease time is preferred
+because it prevents routes involving the TAP-Win32 adapter from
+being lost when the system goes to sleep.  The default
+lease time is one year.
+
+.B netsh \-\-
+Automatically set the IP address and netmask using
+the Windows command-line "netsh"
+command.  This method appears to work correctly on
+Windows XP but not Windows 2000.
+
+.B ipapi \-\-
+Automatically set the IP address and netmask using the
+Windows IP Helper API.  This approach
+does not have ideal semantics, though testing has indicated
+that it works okay in practice.  If you use this option,
+it is best to leave the TCP/IP properties for the TAP-Win32
+adapter in their default state, i.e. "Obtain an IP address
+automatically."
+
+.B adaptive \-\-
+(Default) Try
+.B dynamic
+method initially and fail over to
+.B netsh
+if the DHCP negotiation with the TAP-Win32 adapter does
+not succeed in 20 seconds.  Such failures have been known
+to occur when certain third-party firewall packages installed
+on the client machine block the DHCP negotiation used by
+the TAP-Win32 adapter.
+Note that if the
+.B netsh
+failover occurs, the TAP-Win32 adapter
+TCP/IP properties will be reset from DHCP to static, and this
+will cause future OpenVPN startups using the
+.B adaptive
+mode to use
+.B netsh
+immediately, rather than trying
+.B dynamic
+first.  To "unstick" the
+.B adaptive
+mode from using
+.B netsh,
+run OpenVPN at least once using the
+.B dynamic
+mode to restore the TAP-Win32 adapter TCP/IP properties
+to a DHCP configuration.
+.\"*********************************************************
+.TP
+.B \-\-route-method m
+Which method
+.B m
+to use for adding routes on Windows?
+
+.B adaptive
+(default) \-\- Try IP helper API first.  If that fails, fall
+back to the route.exe shell command.
+.br
+.B ipapi
+\-\- Use IP helper API.
+.br
+.B exe
+\-\- Call the route.exe shell command.
+.\"*********************************************************
+.TP
+.B \-\-dhcp-option type [parm]
+Set extended TAP-Win32 TCP/IP properties, must
+be used with
+.B \-\-ip-win32 dynamic
+or
+.B \-\-ip-win32 adaptive.
+This option can be used to set additional TCP/IP properties
+on the TAP-Win32 adapter, and is particularly useful for
+configuring an OpenVPN client to access a Samba server
+across the VPN.
+
+.B DOMAIN name \-\-
+Set Connection-specific DNS Suffix.
+
+.B DNS addr \-\-
+Set primary domain name server address.  Repeat
+this option to set secondary DNS server addresses.
+
+.B WINS addr \-\-
+Set primary WINS server address (NetBIOS over TCP/IP Name Server).
+Repeat this option to set secondary WINS server addresses.
+
+.B NBDD addr \-\-
+Set primary NBDD server address (NetBIOS over TCP/IP Datagram Distribution Server)
+Repeat this option
+to set secondary NBDD server addresses.
+
+.B NTP addr \-\-
+Set primary NTP server address (Network Time Protocol).
+Repeat this option
+to set secondary NTP server addresses.
+
+.B NBT type \-\-
+Set NetBIOS over TCP/IP Node type.  Possible options:
+.B 1
+= b-node (broadcasts),
+.B 2
+= p-node (point-to-point
+name queries to a WINS server),
+.B 4
+= m-node (broadcast
+then query name server), and
+.B 8
+= h-node (query name server, then broadcast).
+
+.B NBS scope-id \-\-
+Set NetBIOS over TCP/IP Scope. A NetBIOS Scope ID provides an extended
+naming service for the NetBIOS over TCP/IP (Known as NBT) module. The
+primary purpose of a NetBIOS scope ID is to isolate NetBIOS traffic on
+a single network to only those nodes with the same NetBIOS scope ID.
+The NetBIOS scope ID is a character string that is appended to the NetBIOS
+name. The NetBIOS scope ID on two hosts must match, or the two hosts
+will not be able to communicate. The NetBIOS Scope ID also allows
+computers to use the same computer name, as they have different
+scope IDs. The Scope ID becomes a part of the NetBIOS name, making the name unique.
+(This description of NetBIOS scopes courtesy of NeonSurge@abyss.com)
+
+.B DISABLE-NBT \-\-
+Disable Netbios-over-TCP/IP.
+
+Note that if
+.B \-\-dhcp-option
+is pushed via
+.B \-\-push
+to a non-windows client, the option will be saved in the client's
+environment before the up script is called, under
+the name "foreign_option_{n}".
+.\"*********************************************************
+.TP
+.B \-\-tap-sleep n
+Cause OpenVPN to sleep for
+.B n
+seconds immediately after the TAP-Win32 adapter state
+is set to "connected".
+
+This option is intended to be used to troubleshoot problems
+with the
+.B \-\-ifconfig
+and
+.B \-\-ip-win32
+options, and is used to give
+the TAP-Win32 adapter time to come up before
+Windows IP Helper API operations are applied to it.
+.\"*********************************************************
+.TP
+.B \-\-show-net-up
+Output OpenVPN's view of the system routing table and network
+adapter list to the syslog or log file after the TUN/TAP adapter
+has been brought up and any routes have been added.
+.\"*********************************************************
+.TP
+.B \-\-dhcp-renew
+Ask Windows to renew the TAP adapter lease on startup.
+This option is normally unnecessary, as Windows automatically
+triggers a DHCP renegotiation on the TAP adapter when it
+comes up, however if you set the TAP-Win32 adapter
+Media Status property to "Always Connected", you may need this
+flag.
+.\"*********************************************************
+.TP
+.B \-\-dhcp-release
+Ask Windows to release the TAP adapter lease on shutdown.
+This option has the same caveats as
+.B \-\-dhcp-renew
+above.
+.\"*********************************************************
+.TP
+.B \-\-register-dns
+Run net stop dnscache, net start dnscache, ipconfig /flushdns
+and ipconfig /registerdns on connection initiation.
+This is known to kick Windows into
+recognizing pushed DNS servers.
+.\"*********************************************************
+.TP
+.B \-\-pause-exit
+Put up a "press any key to continue" message on the console prior
+to OpenVPN program exit.  This option is automatically used by the
+Windows explorer when OpenVPN is run on a configuration
+file using the right-click explorer menu.
+.\"*********************************************************
+.TP
+.B \-\-service exit-event [0|1]
+Should be used when OpenVPN is being automatically executed by another
+program in such
+a context that no interaction with the user via display or keyboard
+is possible.  In general, end-users should never need to explicitly
+use this option, as it is automatically added by the OpenVPN service wrapper
+when a given OpenVPN configuration is being run as a service.
+
+.B exit-event
+is the name of a Windows global event object, and OpenVPN will continuously
+monitor the state of this event object and exit when it becomes signaled.
+
+The second parameter indicates the initial state of
+.B exit-event
+and normally defaults to 0.
+
+Multiple OpenVPN processes can be simultaneously executed with the same
+.B exit-event
+parameter.  In any case, the controlling process can signal
+.B exit-event,
+causing all such OpenVPN processes to exit.
+
+When executing an OpenVPN process using the
+.B \-\-service
+directive, OpenVPN will probably not have a console
+window to output status/error
+messages, therefore it is useful to use
+.B \-\-log
+or
+.B \-\-log-append
+to write these messages to a file.
+.\"*********************************************************
+.TP
+.B \-\-show-adapters
+(Standalone)
+Show available TAP-Win32 adapters which can be selected using the
+.B \-\-dev-node
+option.  On non-Windows systems, the
+.BR ifconfig (8)
+command provides similar functionality.
+.\"*********************************************************
+.TP
+.B \-\-allow-nonadmin [TAP-adapter]
+(Standalone)
+Set
+.B TAP-adapter
+to allow access from non-administrative accounts.  If
+.B TAP-adapter
+is omitted, all TAP adapters on the system will be configured to allow
+non-admin access.
+The non-admin access setting will only persist for the length of time that
+the TAP-Win32 device object and driver remain loaded, and will need
+to be re-enabled after a reboot, or if the driver is unloaded
+and reloaded.
+This directive can only be used by an administrator.
+.\"*********************************************************
+.TP
+.B \-\-show-valid-subnets
+(Standalone)
+Show valid subnets for
+.B \-\-dev tun
+emulation.  Since the TAP-Win32 driver
+exports an ethernet interface to Windows, and since TUN devices are
+point-to-point in nature, it is necessary for the TAP-Win32 driver
+to impose certain constraints on TUN endpoint address selection.
+
+Namely, the point-to-point endpoints used in TUN device emulation
+must be the middle two addresses of a /30 subnet (netmask 255.255.255.252).
+.\"*********************************************************
+.TP
+.B \-\-show-net
+(Standalone)
+Show OpenVPN's view of the system routing table and network
+adapter list.
+.\"*********************************************************
+.SS PKCS#11 Standalone Options:
+.\"*********************************************************
+.TP
+.B \-\-show-pkcs11-ids provider [cert_private]
+(Standalone)
+Show PKCS#11 token object list. Specify cert_private as 1
+if certificates are stored as private objects.
+
+.B \-\-verb
+option can be used BEFORE this option to produce debugging information.
+.\"*********************************************************
+.SS IPv6 Related Options
+.\"*********************************************************
+The following options exist to support IPv6 tunneling in peer-to-peer
+and client-server mode.  As of now, this is just very basic
+documentation of the IPv6-related options. More documentation can be
+found on http://www.greenie.net/ipv6/openvpn.html.
+.TP
+.B --ifconfig-ipv6 ipv6addr/bits ipv6remote
+configure IPv6 address
+.B ipv6addr/bits
+on the ``tun'' device.  The second parameter is used as route target for
+.B --route-ipv6
+if no gateway is specified.
+.TP
+.B --route-ipv6 ipv6addr/bits [gateway] [metric]
+setup IPv6 routing in the system to send the specified IPv6 network
+into OpenVPN's ``tun'' device
+.TP
+.B --server-ipv6 ipv6addr/bits
+convenience-function to enable a number of IPv6 related options at
+once, namely
+.B --ifconfig-ipv6, --ifconfig-ipv6-pool, --tun-ipv6
+and
+.B --push tun-ipv6
+Is only accepted if ``--mode server'' or ``--server'' is set.
+.TP
+.B --ifconfig-ipv6-pool ipv6addr/bits
+Specify an IPv6 address pool for dynamic assignment to clients.  The
+pool starts at
+.B ipv6addr
+and increments by +1 for every new client (linear mode).  The
+.B /bits
+setting controls the size of the pool.
+.TP
+.B --ifconfig-ipv6-push ipv6addr/bits ipv6remote
+for ccd/ per-client static IPv6 interface configuration, see
+.B --client-config-dir
+and
+.B --ifconfig-push
+for more details.
+.TP
+.B --iroute-ipv6 ipv6addr/bits
+for ccd/ per-client static IPv6 route configuration, see
+.B --iroute
+for more details how to setup and use this, and how
+.B --iroute
+and
+.B --route
+interact.
+
+.\"*********************************************************
+.SH SCRIPTING AND ENVIRONMENTAL VARIABLES
+OpenVPN exports a series
+of environmental variables for use by user-defined scripts.
+.\"*********************************************************
+.SS Script Order of Execution
+.\"*********************************************************
+.TP
+.B \-\-up
+Executed after TCP/UDP socket bind and TUN/TAP open.
+.\"*********************************************************
+.TP
+.B \-\-tls-verify
+Executed when we have a still untrusted remote peer.
+.\"*********************************************************
+.TP
+.B \-\-ipchange
+Executed after connection authentication, or remote IP address change.
+.\"*********************************************************
+.TP
+.B \-\-client-connect
+Executed in
+.B \-\-mode server
+mode immediately after client authentication.
+.\"*********************************************************
+.TP
+.B \-\-route-up
+Executed after connection authentication, either
+immediately after, or some number of seconds after
+as defined by the
+.B \-\-route-delay
+option.
+.\"*********************************************************
+.TP
+.B \-\-route-pre-down
+Executed right before the routes are removed.
+.\"*********************************************************
+.TP
+.B \-\-client-disconnect
+Executed in
+.B \-\-mode server
+mode on client instance shutdown.
+.\"*********************************************************
+.TP
+.B \-\-down
+Executed after TCP/UDP and TUN/TAP close.
+.\"*********************************************************
+.TP
+.B \-\-learn-address
+Executed in
+.B \-\-mode server
+mode whenever an IPv4 address/route or MAC address is added to OpenVPN's
+internal routing table.
+.\"*********************************************************
+.TP
+.B \-\-auth-user-pass-verify
+Executed in
+.B \-\-mode server
+mode on new client connections, when the client is
+still untrusted.
+.\"*********************************************************
+.SS String Types and Remapping
+In certain cases, OpenVPN will perform remapping of characters
+in strings.  Essentially, any characters outside the set of
+permitted characters for each string type will be converted
+to underbar ('_').
+
+.B Q:
+Why is string remapping necessary?
+
+.B A:
+It's an important security feature to prevent the malicious coding of
+strings from untrusted sources to be passed as parameters to scripts,
+saved in the environment, used as a common name, translated to a filename,
+etc.
+
+.B Q:
+Can string remapping be disabled?
+
+.B A:
+Yes, by using the
+.B \-\-no-name-remapping
+option, however this should be considered an advanced option.
+
+Here is a brief rundown of OpenVPN's current string types and the 
+permitted character class for each string:
+
+.B X509 Names:
+Alphanumeric, underbar ('_'), dash ('-'), dot ('.'), at 
+('@'), colon (':'), slash ('/'), and equal ('=').  Alphanumeric is defined 
+as a character which will cause the C library isalnum() function to return 
+true.
+
+.B Common Names:
+Alphanumeric, underbar ('_'), dash ('-'), dot ('.'), and at                
+('@').
+
+.B \-\-auth-user-pass username:
+Same as Common Name, with one exception: starting with OpenVPN 2.0.1,
+the username is passed to the OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY plugin in its raw form,
+without string remapping.
+
+.B \-\-auth-user-pass password:
+Any "printable" character except CR or LF.  
+Printable is defined to be a character which will cause the C library 
+isprint() function to return true.
+
+.B \-\-client-config-dir filename as derived from common name or username:
+Alphanumeric, underbar ('_'), dash ('-'), and dot ('.') except for "." or 
+".." as standalone strings.  As of 2.0.1-rc6, the at ('@') character has
+been added as well for compatibility with the common name character class.
+
+.B Environmental variable names:
+Alphanumeric or underbar ('_').
+
+.B Environmental variable values:
+Any printable character.
+
+For all cases, characters in a string which are not members of the legal 
+character class for that string type will be remapped to underbar ('_').
+.\"*********************************************************
+.SS Environmental Variables
+Once set, a variable is persisted
+indefinitely until it is reset by a new value or a restart,
+
+As of OpenVPN 2.0-beta12, in server mode, environmental
+variables set by OpenVPN
+are scoped according to the client objects
+they are
+associated with, so there should not be any issues with
+scripts having access to stale, previously set variables
+which refer to different client instances.
+.\"*********************************************************
+.TP
+.B bytes_received
+Total number of bytes received from client during VPN session.
+Set prior to execution of the
+.B \-\-client-disconnect
+script.
+.\"*********************************************************
+.TP
+.B bytes_sent
+Total number of bytes sent to client during VPN session.
+Set prior to execution of the
+.B \-\-client-disconnect
+script.
+.\"*********************************************************
+.TP
+.B common_name
+The X509 common name of an authenticated client.
+Set prior to execution of
+.B \-\-client-connect, \-\-client-disconnect,
+and
+.B \-\-auth-user-pass-verify
+scripts.
+.\"*********************************************************
+.TP
+.B config
+Name of first
+.B \-\-config
+file.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B daemon
+Set to "1" if the
+.B \-\-daemon
+directive is specified, or "0" otherwise.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B daemon_log_redirect
+Set to "1" if the
+.B \-\-log
+or
+.B \-\-log-append
+directives are specified, or "0" otherwise.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B dev
+The actual name of the TUN/TAP device, including
+a unit number if it exists.
+Set prior to
+.B \-\-up
+or
+.B \-\-down
+script execution.
+.\"*********************************************************
+.TP
+.B foreign_option_{n}
+An option pushed via
+.B \-\-push
+to a client which does not natively support it,
+such as
+.B \-\-dhcp-option
+on a non-Windows system, will be recorded to this
+environmental variable sequence prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_broadcast
+The broadcast address for the virtual
+ethernet segment which is derived from the
+.B \-\-ifconfig
+option when
+.B \-\-dev tap
+is used.
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_ipv6_local
+The local VPN endpoint IPv6 address specified in the
+.B \-\-ifconfig-ipv6
+option (first parameter).
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_ipv6_netbits
+The prefix length of the IPv6 network on the VPN interface.  Derived from
+the /nnn parameter of the IPv6 address in the
+.B \-\-ifconfig-ipv6
+option (first parameter).
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_ipv6_remote
+The remote VPN endpoint IPv6 address specified in the
+.B \-\-ifconfig-ipv6
+option (second parameter).
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_local
+The local VPN endpoint IP address specified in the
+.B \-\-ifconfig
+option (first parameter).
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_remote
+The remote VPN endpoint IP address specified in the
+.B \-\-ifconfig
+option (second parameter) when
+.B \-\-dev tun
+is used.
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_netmask
+The subnet mask of the virtual ethernet segment
+that is specified as the second parameter to
+.B \-\-ifconfig
+when
+.B \-\-dev tap
+is being used.
+Set prior to OpenVPN calling the
+.I ifconfig
+or
+.I netsh
+(windows version of ifconfig) commands which
+normally occurs prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B ifconfig_pool_local_ip
+The local
+virtual IP address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-pool
+config file directive).
+Only set for
+.B \-\-dev tun
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*********************************************************
+.TP
+.B ifconfig_pool_netmask
+The
+virtual IP netmask for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-pool
+config file directive).
+Only set for
+.B \-\-dev tap
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*********************************************************
+.TP
+.B ifconfig_pool_remote_ip
+The remote
+virtual IP address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-pool
+config file directive).
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*********************************************************
+.TP
+.B link_mtu
+The maximum packet size (not including the IP header)
+of tunnel data in UDP tunnel transport mode.
+Set prior to
+.B \-\-up
+or
+.B \-\-down
+script execution.
+.\"*********************************************************
+.TP
+.B local
+The
+.B \-\-local
+parameter.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B local_port
+The local port number or name, specified by
+.B \-\-port
+or
+.B \-\-lport.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B password
+The password provided by a connecting client.
+Set prior to
+.B \-\-auth-user-pass-verify
+script execution only when the
+.B via-env
+modifier is specified, and deleted from the environment
+after the script returns.
+.\"*********************************************************
+.TP
+.B proto
+The
+.B \-\-proto
+parameter.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B remote_{n}
+The
+.B \-\-remote
+parameter.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B remote_port_{n}
+The remote port number, specified by
+.B \-\-port
+or
+.B \-\-rport.
+Set on program initiation and reset on SIGHUP.
+.\"*********************************************************
+.TP
+.B route_net_gateway
+The pre-existing default IP gateway in the system routing
+table.
+Set prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B route_vpn_gateway
+The default gateway used by
+.B \-\-route
+options, as specified in either the
+.B \-\-route-gateway
+option or the second parameter to
+.B \-\-ifconfig
+when
+.B \-\-dev tun
+is specified.
+Set prior to
+.B \-\-up
+script execution.
+.\"*********************************************************
+.TP
+.B route_{parm}_{n}
+A set of variables which define each route to be added, and
+are set prior to
+.B \-\-up
+script execution.
+
+.B parm
+will be one of "network", "netmask", "gateway", or "metric".
+
+.B n
+is the OpenVPN route number, starting from 1.
+
+If the network or gateway are resolvable DNS names,
+their IP address translations will be recorded rather
+than their names as denoted on the command line
+or configuration file.
+.\"*********************************************************
+.TP
+.B route_ipv6_{parm}_{n}
+A set of variables which define each IPv6 route to be added, and
+are set prior to
+.B \-\-up
+script execution.
+
+.B parm
+will be one of "network" or "gateway" ("netmask" is contained as "/nnn"
+in the route_ipv6_network_{n}, unlike IPv4 where it is passed in a separate
+environment variable).
+
+.B n
+is the OpenVPN route number, starting from 1.
+
+If the network or gateway are resolvable DNS names,
+their IP address translations will be recorded rather
+than their names as denoted on the command line
+or configuration file.
+.\"*********************************************************
+.TP
+.B peer_cert
+Temporary file name containing the client certificate upon
+connection.  Useful in conjunction with --tls-verify
+.\"*********************************************************
+.TP
+.B script_context
+Set to "init" or "restart" prior to up/down script execution.
+For more information, see
+documentation for
+.B \-\-up.
+.\"*********************************************************
+.TP
+.B script_type
+Prior to execution of any script, this variable is set to the type of
+script being run.  It can be one of the following:
+.B up, down, ipchange, route-up, tls-verify, auth-user-pass-verify,
+.B client-connect, client-disconnect, 
+or
+.B learn-address.
+Set prior to execution of any script.
+.\"*********************************************************
+.TP
+.B signal
+The reason for exit or restart.  Can be one of
+.B sigusr1, sighup, sigterm, sigint, inactive
+(controlled by
+.B \-\-inactive
+option),
+.B ping-exit
+(controlled by
+.B \-\-ping-exit
+option),
+.B ping-restart
+(controlled by
+.B \-\-ping-restart
+option),
+.B connection-reset
+(triggered on TCP connection reset),
+.B error,
+or
+.B unknown
+(unknown signal).  This variable is set just prior to down script execution.
+.\"*********************************************************
+.TP
+.B time_ascii
+Client connection timestamp, formatted as a human-readable
+time string.
+Set prior to execution of the
+.B \-\-client-connect
+script.
+.\"*********************************************************
+.TP
+.B time_duration
+The duration (in seconds) of the client session which is now
+disconnecting.
+Set prior to execution of the
+.B \-\-client-disconnect
+script.
+.\"*********************************************************
+.TP
+.B time_unix
+Client connection timestamp, formatted as a unix integer
+date/time value.
+Set prior to execution of the
+.B \-\-client-connect
+script.
+.\"*********************************************************
+.TP
+.B tls_id_{n}
+A series of certificate fields from the remote peer,
+where
+.B n
+is the verification level.  Only set for TLS connections.  Set prior
+to execution of
+.B \-\-tls-verify
+script.
+.\"*********************************************************
+.TP
+.B tls_serial_{n}
+The serial number of the certificate from the remote peer,
+where
+.B n
+is the verification level.  Only set for TLS connections.  Set prior
+to execution of
+.B \-\-tls-verify
+script. This is in the form of a hex string like "37AB46E0", which is
+suitable for doing serial-based OCSP queries (with OpenSSL, you have
+to prepend "0x" to the string). If something goes wrong while reading
+the value from the certificate it will be an empty string, so your
+code should check that.
+See the contrib/OCSP_check/OCSP_check.sh script for an example.
+.\"*********************************************************
+.TP
+.B tun_mtu
+The MTU of the TUN/TAP device.
+Set prior to
+.B \-\-up
+or
+.B \-\-down
+script execution.
+.\"*********************************************************
+.TP
+.B trusted_ip (or trusted_ip6)
+Actual IP address of connecting client or peer which has been authenticated.
+Set prior to execution of
+.B \-\-ipchange, \-\-client-connect,
+and
+.B \-\-client-disconnect
+scripts.
+If using ipv6 endpoints (udp6, tcp6),
+.B trusted_ip6
+will be set instead.
+.\"*********************************************************
+.TP
+.B trusted_port
+Actual port number of connecting client or peer which has been authenticated.
+Set prior to execution of
+.B \-\-ipchange, \-\-client-connect,
+and
+.B \-\-client-disconnect
+scripts.
+.\"*********************************************************
+.TP
+.B untrusted_ip (or untrusted_ip6)
+Actual IP address of connecting client or peer which has not been authenticated
+yet.  Sometimes used to
+.B nmap
+the connecting host in a
+.B \-\-tls-verify
+script to ensure it is firewalled properly.
+Set prior to execution of
+.B \-\-tls-verify
+and
+.B \-\-auth-user-pass-verify
+scripts.
+If using ipv6 endpoints (udp6, tcp6),
+.B untrusted_ip6
+will be set instead.
+.\"*********************************************************
+.TP
+.B untrusted_port
+Actual port number of connecting client or peer which has not been authenticated
+yet.
+Set prior to execution of
+.B \-\-tls-verify
+and
+.B \-\-auth-user-pass-verify
+scripts.
+.\"*********************************************************
+.TP
+.B username
+The username provided by a connecting client.
+Set prior to
+.B \-\-auth-user-pass-verify
+script execution only when the
+.B via-env
+modifier is specified.
+.\"*********************************************************
+.TP
+.B X509_{n}_{subject_field}
+An X509 subject field from the remote peer certificate,
+where
+.B n
+is the verification level.  Only set for TLS connections.  Set prior
+to execution of
+.B \-\-tls-verify
+script.  This variable is similar to
+.B tls_id_{n}
+except the component X509 subject fields are broken out, and
+no string remapping occurs on these field values (except for remapping
+of control characters to "_").
+For example, the following variables would be set on the
+OpenVPN server using the sample client certificate
+in sample-keys (client.crt).
+Note that the verification level is 0 for the client certificate
+and 1 for the CA certificate.
+
+.nf
+.ft 3
+.in +4
+X509_0_emailAddress=me@myhost.mydomain
+X509_0_CN=Test-Client
+X509_0_O=OpenVPN-TEST
+X509_0_ST=NA
+X509_0_C=KG
+X509_1_emailAddress=me@myhost.mydomain
+X509_1_O=OpenVPN-TEST
+X509_1_L=BISHKEK
+X509_1_ST=NA
+X509_1_C=KG
+.in -4
+.ft
+.fi
+.\"*********************************************************
+.SH INLINE FILE SUPPORT
+OpenVPN allows including files in the main configuration for the
+.B \-\-ca, \-\-cert, \-\-dh, \-\-extra-certs, \-\-key, \-\-pkcs12, \-\-secret
+and
+.B \-\-tls-auth
+options.
+
+Each inline file started by the line
+.B <option>
+and ended by the line
+.B </option>
+
+Here is an example of an inline file usage
+
+.nf
+.ft 3
+.in +4
+<cert>
+-----BEGIN CERTIFICATE-----
+[...]
+-----END CERTIFICATE-----
+</cert>
+.in -4
+.ft
+.fi
+
+When using the inline file feature with
+.B \-\-pkcs12
+the inline file has to be base64 encoded. Encoding of a .p12 file into base64 can be done for example with OpenSSL by running
+.B openssl base64 -in input.p12
+
+.SH SIGNALS
+.TP
+.B SIGHUP
+Cause OpenVPN to close all TUN/TAP and
+network connections,
+restart, re-read the configuration file (if any),
+and reopen TUN/TAP and network connections.
+.\"*********************************************************
+.TP
+.B SIGUSR1
+Like 
+.B SIGHUP,
+except don't re-read configuration file, and possibly don't close and reopen TUN/TAP
+device, re-read key files, preserve local IP address/port, or preserve most recently authenticated
+remote IP address/port based on
+.B \-\-persist-tun, \-\-persist-key, \-\-persist-local-ip,
+and
+.B \-\-persist-remote-ip
+options respectively (see above).
+
+This signal may also be internally generated by a timeout condition, governed
+by the
+.B \-\-ping-restart
+option.
+
+This signal, when combined with
+.B \-\-persist-remote-ip,
+may be
+sent when the underlying parameters of the host's network interface change
+such as when the host is a DHCP client and is assigned a new IP address.
+See
+.B \-\-ipchange
+above for more information.
+.\"*********************************************************
+.TP
+.B SIGUSR2
+Causes OpenVPN to display its current statistics (to the syslog
+file if
+.B \-\-daemon
+is used, or stdout otherwise).
+.\"*********************************************************
+.TP
+.B SIGINT, SIGTERM
+Causes OpenVPN to exit gracefully.
+.\"*********************************************************
+.SH TUN/TAP DRIVER SETUP
+If you are running Linux 2.4.7 or higher, you probably have the TUN/TAP driver
+already installed.  If so, there are still a few things you need to do:
+
+Make device:
+.B mknod /dev/net/tun c 10 200
+
+Load driver:
+.B modprobe tun
+.\"*********************************************************
+.SH EXAMPLES
+Prior to running these examples, you should have OpenVPN installed on two
+machines with network connectivity between them.  If you have not
+yet installed OpenVPN, consult the INSTALL file included in the OpenVPN
+distribution.
+.\"*********************************************************
+.SS TUN/TAP Setup:
+If you are using Linux 2.4 or higher,
+make the tun device node and load the tun module:
+.IP
+.B mknod /dev/net/tun c 10 200
+.LP
+.IP
+.B modprobe tun
+.LP
+If you installed from RPM, the
+.B mknod
+step may be omitted, because the RPM install does that for you.
+
+Only Linux 2.4 and newer are supported.
+
+For other platforms, consult the INSTALL file at
+.I http://openvpn.net/install.html
+for more information.
+.\"*********************************************************
+.SS Firewall Setup:
+If firewalls exist between
+the two machines, they should be set to forward UDP port 1194
+in both directions.  If you do not have control over the firewalls
+between the two machines, you may still be able to use OpenVPN by adding
+.B \-\-ping 15
+to each of the
+.B openvpn
+commands used below in the examples (this will cause each peer to send out
+a UDP ping to its remote peer once every 15 seconds which will cause many
+stateful firewalls to forward packets in both directions
+without an explicit firewall rule).
+
+If you are using a Linux iptables-based firewall, you may need to enter
+the following command to allow incoming packets on the TUN device:
+.IP
+.B iptables -A INPUT -i tun+ -j ACCEPT
+.LP
+See the firewalls section below for more information on configuring firewalls
+for use with OpenVPN.
+.\"*********************************************************
+.SS VPN Address Setup:
+For purposes
+of our example, our two machines will be called
+.B may.kg
+and
+.B june.kg.
+If you are constructing a VPN over the internet, then replace
+.B may.kg
+and
+.B june.kg
+with the internet hostname or IP address that each machine will use
+to contact the other over the internet.
+
+Now we will choose the tunnel endpoints.  Tunnel endpoints are
+private IP addresses that only have meaning in the context of
+the VPN.  Each machine will use the tunnel endpoint of the other
+machine to access it over the VPN.  In our example,
+the tunnel endpoint for may.kg
+will be 10.4.0.1 and for june.kg, 10.4.0.2.
+
+Once the VPN is established, you have essentially
+created a secure alternate path between the two hosts
+which is addressed by using the tunnel endpoints.  You can
+control which network
+traffic passes between the hosts 
+(a) over the VPN or (b) independently of the VPN, by choosing whether to use
+(a) the VPN endpoint address or (b) the public internet address,
+to access the remote host. For example if you are on may.kg and you wish to connect to june.kg
+via
+.B ssh
+without using the VPN (since
+.B ssh
+has its own built-in security) you would use the command
+.B ssh june.kg.
+However in the same scenario, you could also use the command
+.B telnet 10.4.0.2
+to create a telnet session with june.kg over the VPN, that would
+use the VPN to secure the session rather than
+.B ssh.
+
+You can use any address you wish for the
+tunnel endpoints
+but make sure that they are private addresses
+(such as those that begin with 10 or 192.168) and that they are
+not part of any existing subnet on the networks of
+either peer, unless you are bridging.  If you use an address that is part of
+your local subnet for either of the tunnel endpoints,
+you will get a weird feedback loop.
+.\"*********************************************************
+.SS Example 1: A simple tunnel without security
+.LP
+On may:
+.IP
+.B openvpn \-\-remote june.kg \-\-dev tun1 \-\-ifconfig 10.4.0.1 10.4.0.2 \-\-verb 9
+.LP
+On june:
+.IP
+.B openvpn \-\-remote may.kg \-\-dev tun1 \-\-ifconfig 10.4.0.2 10.4.0.1 \-\-verb 9
+.LP
+Now verify the tunnel is working by pinging across the tunnel.
+.LP
+On may:
+.IP
+.B ping 10.4.0.2
+.LP
+On june:
+.IP
+.B ping 10.4.0.1
+.LP
+The
+.B \-\-verb 9
+option will produce verbose output, similar to the
+.BR tcpdump (8)
+program.  Omit the
+.B \-\-verb 9
+option to have OpenVPN run quietly.
+.\"*********************************************************
+.SS Example 2: A tunnel with static-key security (i.e. using a pre-shared secret)
+First build a static key on may.
+.IP
+.B openvpn \-\-genkey \-\-secret key
+.LP
+This command will build a random key file called
+.B key
+(in ascii format).
+Now copy
+.B key
+to june over a secure medium such as by
+using the
+.BR scp (1)
+program.
+.LP
+On may:
+.IP
+.B openvpn \-\-remote june.kg \-\-dev tun1 \-\-ifconfig 10.4.0.1 10.4.0.2 \-\-verb 5 \-\-secret key
+.LP
+On june:
+.IP
+.B openvpn \-\-remote may.kg \-\-dev tun1 \-\-ifconfig 10.4.0.2 10.4.0.1 \-\-verb 5 \-\-secret key
+.LP
+Now verify the tunnel is working by pinging across the tunnel.
+.LP
+On may:
+.IP
+.B ping 10.4.0.2
+.LP
+On june:
+.IP
+.B ping 10.4.0.1
+.\"*********************************************************
+.SS Example 3: A tunnel with full TLS-based security
+For this test, we will designate
+.B may
+as the TLS client and
+.B june
+as the TLS server.
+.I Note that client or server designation only has meaning for the TLS subsystem.  It has no bearing on OpenVPN's peer-to-peer, UDP-based communication model.
+
+First, build a separate certificate/key pair
+for both may and june (see above where
+.B \-\-cert
+is discussed for more info).  Then construct
+Diffie Hellman parameters (see above where
+.B \-\-dh
+is discussed for more info).  You can also use the
+included test files client.crt, client.key,
+server.crt, server.key and ca.crt.
+The .crt files are certificates/public-keys, the .key
+files are private keys, and ca.crt is a certification
+authority who has signed both
+client.crt and server.crt.  For Diffie Hellman
+parameters you can use the included file dh1024.pem.
+.I Note that all client, server, and certificate authority certificates and keys included in the OpenVPN distribution are totally insecure and should be used for testing only.
+.LP
+On may:
+.IP
+.B openvpn \-\-remote june.kg \-\-dev tun1 \-\-ifconfig 10.4.0.1 10.4.0.2 \-\-tls-client \-\-ca ca.crt \-\-cert client.crt \-\-key client.key \-\-reneg-sec 60 \-\-verb 5
+.LP
+On june:
+.IP
+.B openvpn \-\-remote may.kg \-\-dev tun1 \-\-ifconfig 10.4.0.2 10.4.0.1 \-\-tls-server \-\-dh dh1024.pem \-\-ca ca.crt \-\-cert server.crt \-\-key server.key \-\-reneg-sec 60 \-\-verb 5
+.LP
+Now verify the tunnel is working by pinging across the tunnel.
+.LP
+On may:
+.IP
+.B ping 10.4.0.2
+.LP
+On june:
+.IP
+.B ping 10.4.0.1
+.LP
+Notice the
+.B \-\-reneg-sec 60
+option we used above.  That tells OpenVPN to renegotiate
+the data channel keys every minute.
+Since we used
+.B \-\-verb 5
+above, you will see status information on each new key negotiation.
+
+For production operations, a key renegotiation interval of 60 seconds
+is probably too frequent.  Omit the
+.B \-\-reneg-sec 60
+option to use OpenVPN's default key renegotiation interval of one hour.
+.\"*********************************************************
+.SS Routing:
+Assuming you can ping across the tunnel,
+the next step is to route a real subnet over
+the secure tunnel.  Suppose that may and june have two network
+interfaces each, one connected
+to the internet, and the other to a private
+network.  Our goal is to securely connect
+both private networks.  We will assume that may's private subnet
+is 10.0.0.0/24 and june's is 10.0.1.0/24.
+.LP
+First, ensure that IP forwarding is enabled on both peers.
+On Linux, enable routing:
+.IP
+.B echo 1 > /proc/sys/net/ipv4/ip_forward
+.LP
+and enable TUN packet forwarding through the firewall:
+.IP
+.B iptables -A FORWARD -i tun+ -j ACCEPT
+.LP
+On may:
+.IP
+.B route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2
+.LP
+On june:
+.IP
+.B route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1
+.LP
+Now any machine on the 10.0.0.0/24 subnet can
+access any machine on the 10.0.1.0/24 subnet
+over the secure tunnel (or vice versa).
+
+In a production environment, you could put the route command(s)
+in a script and execute with the
+.B \-\-up
+option.
+.\"*********************************************************
+.SH FIREWALLS
+OpenVPN's usage of a single UDP port makes it fairly firewall-friendly.
+You should add an entry to your firewall rules to allow incoming OpenVPN
+packets.  On Linux 2.4+:
+.IP
+.B iptables -A INPUT -p udp -s 1.2.3.4 \-\-dport 1194 -j ACCEPT
+.LP
+This will allow incoming packets on UDP port 1194 (OpenVPN's default UDP port)
+from an OpenVPN peer at 1.2.3.4.
+
+If you are using HMAC-based packet authentication (the default in any of
+OpenVPN's secure modes), having the firewall filter on source
+address can be considered optional, since HMAC packet authentication
+is a much more secure method of verifying the authenticity of
+a packet source.  In that case:
+.IP
+.B iptables -A INPUT -p udp \-\-dport 1194 -j ACCEPT
+.LP
+would be adequate and would not render the host inflexible with
+respect to its peer having a dynamic IP address.
+
+OpenVPN also works well on stateful firewalls.  In some cases, you may
+not need to add any static rules to the firewall list if you are
+using a stateful firewall that knows how to track UDP connections.
+If you specify
+.B \-\-ping n,
+OpenVPN will be guaranteed
+to send a packet to its peer at least once every
+.B n
+seconds.  If
+.B n
+is less than the stateful firewall connection timeout, you can
+maintain an OpenVPN connection indefinitely without explicit
+firewall rules.
+
+You should also add firewall rules to allow incoming IP traffic on
+TUN or TAP devices such as:
+.IP
+.B iptables -A INPUT -i tun+ -j ACCEPT
+.LP
+to allow input packets from tun devices,
+.IP
+.B iptables -A FORWARD -i tun+ -j ACCEPT
+.LP
+to allow input packets from tun devices to be forwarded to
+other hosts on the local network,
+.IP
+.B iptables -A INPUT -i tap+ -j ACCEPT
+.LP
+to allow input packets from tap devices, and
+.IP
+.B iptables -A FORWARD -i tap+ -j ACCEPT
+.LP
+to allow input packets from tap devices to be forwarded to
+other hosts on the local network.
+
+These rules are secure if you use packet authentication,
+since no incoming packets will arrive on a TUN or TAP
+virtual device
+unless they first pass an HMAC authentication test.
+.\"*********************************************************
+.SH FAQ
+.I http://openvpn.net/faq.html
+.\"*********************************************************
+.SH HOWTO
+For a more comprehensive guide to setting up OpenVPN
+in a production setting, see the OpenVPN HOWTO at
+.I http://openvpn.net/howto.html
+.\"*********************************************************
+.SH PROTOCOL
+For a description of OpenVPN's underlying protocol,
+see 
+.I http://openvpn.net/security.html
+.\"*********************************************************
+.SH WEB
+OpenVPN's web site is at
+.I http://openvpn.net/
+
+Go here to download the latest version of OpenVPN, subscribe
+to the mailing lists, read the mailing list
+archives, or browse the SVN repository.
+.\"*********************************************************
+.SH BUGS
+Report all bugs to the OpenVPN team <info@openvpn.net>.
+.\"*********************************************************
+.SH "SEE ALSO"
+.BR dhcpcd (8),
+.BR ifconfig (8),
+.BR openssl (1),
+.BR route (8),
+.BR scp (1)
+.BR ssh (1)
+.\"*********************************************************
+.SH NOTES 
+.LP
+This product includes software developed by the
+OpenSSL Project (
+.I http://www.openssl.org/
+)
+
+For more information on the TLS protocol, see
+.I http://www.ietf.org/rfc/rfc2246.txt
+
+For more information on the LZO real-time compression library see
+.I http://www.oberhumer.com/opensource/lzo/
+.\"*********************************************************
+.SH COPYRIGHT
+Copyright (C) 2002-2010 OpenVPN Technologies, Inc. This program is free software;
+you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2
+as published by the Free Software Foundation.
+.\"*********************************************************
+.SH AUTHORS
+James Yonan <jim@yonan.net>