wiki:Openvpn22ManPage
openvpn(8)                                                                            openvpn(8)



NAME
       openvpn - secure IP tunnel daemon.

SYNOPSIS
       openvpn [ options ... ]

INTRODUCTION
       OpenVPN  is an open source VPN daemon by James Yonan.  Because OpenVPN tries to be a uni‐
       versal 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 sec‐
       tion 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:
       http://openvpn.net/

       And if you would like to see a shorter version of this manual, see the openvpn usage mes‐
       sage which can be obtained by running openvpn without any parameters.

DESCRIPTION
       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 porta‐
       bility to most major OS platforms.

       OpenVPN is tightly bound to the OpenSSL library, and derives much of its crypto capabili‐
       ties from it.

       OpenVPN  supports conventional encryption using a pre-shared secret key (Static Key mode)
       or public key security (SSL/TLS mode) using client & server certificates.   OpenVPN  also
       supports non-encrypted TCP/UDP tunnels.

       OpenVPN  is designed to work with the 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.

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.

       --help Show options.

       --config file
              Load  additional  config options from file where each line corresponds to one com‐
              mand line option, but with the leading '--' removed.

              If --config file is the only option to the openvpn command, the  --config  can  be
              removed, and the command can be given as 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 char‐
              acters not in single quotations, so the following mappings should be observed:

                  \\       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.

              For example on Windows, use double backslashes to represent pathnames:

                  secret "c:\\OpenVPN\\secret.key"

              For examples of configuration files, see http://openvpn.net/examples.html

              Here is an example configuration file:

                  #
                  # 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

   Tunnel Options:
       --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.

       --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.

       --remote host [port] [proto]
              Remote  host  name or IP address.  On the client, multiple --remote options may be
              specified for redundancy, each referring to a different OpenVPN server.   Specify‐
              ing  multiple --remote options for this purpose is a special case of the more gen‐
              eral connection-profile feature.  See the <connection> documentation below.

              The OpenVPN client will try to connect to a server at host:port in the order spec‐
              ified by the list of --remote options.

              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 con‐
              nected to one server.

              Note that since UDP is connectionless, connection failure is defined by the --ping
              and --ping-restart options.

              Note the following corner case:  If you use multiple --remote options, AND you are
              dropping root privileges on the client with --user and/or --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 --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, --remote will act as a filter, rejecting  connections  from
              any host which does not match host.

              If  host  is  a DNS name which resolves to multiple IP addresses, one will be ran‐
              domly chosen, providing a sort of basic load-balancing and failover capability.

       --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".

       <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 <connection> and </connection>.

              An  OpenVPN client will try each connection profile sequentially until it achieves
              a successful connection.

              --remote-random can be used to initially "scramble" the connection list.

              Here is an example of connection profile usage:

                  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

              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 <connection> block:

              bind, connect-retry, connect-retry-max, connect-timeout, float, http-proxy,  http-
              proxy-option,  http-proxy-retry,  http-proxy-timeout,  local, lport, nobind, port,
              proto, remote, rport, socks-proxy, and socks-proxy-retry.

              A defaulting mechanism exists for specifying options to apply to all  <connection>
              profiles.  If any of the above options (with the exception of remote ) appear out‐
              side of a <connection> block, but in a configuration file which has  one  or  more
              <connection> blocks, the option setting will be used as a default for <connection>
              blocks which follow it in the configuration file.

              For example, suppose the nobind option were placed  in  the  sample  configuration
              file  above,  near  the top of the file, before the first <connection> block.  The
              effect would be as if nobind were declared in all <connection> blocks below it.

       --proto-force p
              When iterating through connection profiles, only consider profiles using  protocol
              p ('tcp'|'udp').

       --remote-random
              When  multiple --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-bal‐
              ancing measure.

       --proto p
              Use  protocol  p for communicating with remote host.  p can be udp, tcp-client, or
              tcp-server.

              The default protocol is udp when --proto is not specified.

              For UDP operation, --proto udp should be specified on both peers.

              For TCP operation, one peer must use --proto tcp-server and  the  other  must  use
              --proto  tcp-client.  A peer started with tcp-server will wait indefinitely for an
              incoming connection.  A peer started with tcp-client will attempt to connect,  and
              if  that  fails,  will  sleep  for  5  seconds (adjustable via the --connect-retry
              option) and try again infinite or up to N retries (adjustable via  the  --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:

              http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

              There are certain cases, however, where using TCP may be advantageous from a secu‐
              rity 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.

       --connect-retry n
              For --proto tcp-client, take n as the number of seconds to wait between connection
              retries (default=5).

       --connect-timeout n
              For --proto tcp-client, set connection timeout to n seconds (default=10).

       --connect-retry-max n
              For  --proto  tcp-client,  take  n  as the number of retries of connection attempt
              (default=infinite).

       --auto-proxy
              Try to sense HTTP or SOCKS proxy  settings  automatically.   If  no  settings  are
              present,  a  direct connection will be attempted.  If both HTTP and SOCKS settings
              are present, HTTP will be preferred.  If the HTTP proxy server  requires  a  pass‐
              word,  it will be queried from stdin or the management interface.  If the underly‐
              ing OS doesn't support an API for returning proxy settings,  a  direct  connection
              will  be  attempted.   Currently, only Windows clients support this option via the
              InternetQueryOption API.  This option exists in OpenVPN 2.1 or higher.

       --show-proxy-settings
              Show sensed HTTP or SOCKS proxy settings. Currently, only Windows clients  support
              this option.

       --http-proxy server port [authfile|'auto'|'auto-nct'] [auth-method]
              Connect  to remote host through an HTTP proxy at address server and port port.  If
              HTTP Proxy-Authenticate is required, authfile is a file containing a username  and
              password on 2 lines, or "stdin" to prompt from console.

              auth-method should be one of "none", "basic", or "ntlm".

              HTTP Digest authentication is supported as well, but only via the auto or auto-nct
              flags (below).

              The auto flag causes OpenVPN to automatically determine the 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 auto-nct flag (no clear-text auth) instructs OpenVPN to  automatically  deter‐
              mine  the  authentication method, but to reject weak authentication protocols such
              as HTTP Basic Authentication.

       --http-proxy-retry
              Retry indefinitely on HTTP proxy errors.  If an HTTP proxy error occurs,  simulate
              a SIGUSR1 reset.

       --http-proxy-timeout n
              Set proxy timeout to n seconds, default=5.

       --http-proxy-option type [parm]
              Set extended HTTP proxy options.  Repeat to set multiple options.

              VERSION version -- Set HTTP version number to version (default=1.0).

              AGENT user-agent -- Set HTTP "User-Agent" string to user-agent.

       --socks-proxy server [port]
              Connect  to  remote  host  through  a Socks5 proxy at address server and port port
              (default=1080).

       --socks-proxy-retry
              Retry indefinitely on Socks proxy errors.  If a Socks proxy error occurs, simulate
              a SIGUSR1 reset.

       --resolv-retry n
              If  hostname  resolve fails for --remote, retry resolve for n seconds before fail‐
              ing.

              Set n to "infinite" to retry indefinitely.

              By default, --resolv-retry infinite is enabled.  You can disable by setting n=0.

       --float
              Allow remote peer to change its IP address and/or port number, such as due to DHCP
              (this  is  the  default  if  --remote  is  not used).  --float when specified with
              --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, --float tells  OpenVPN  to  accept  authenticated  packets  from  any
              address, not only the address which was specified in the --remote option.

       --ipchange cmd
              Execute shell command cmd when our remote ip-address is initially authenticated or
              changes.

              Execute as:

              cmd ip_address port_number

              Don't use --ipchange  in  --mode  server  mode.   Use  a  --client-connect  script
              instead.

              See  the  "Environmental Variables" section below for additional parameters passed
              as environmental variables.

              Note that cmd can be a shell command with multiple arguments, in  which  case  all
              OpenVPN-generated  arguments will be appended to cmd to build a command line which
              will be passed to the script.

              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 /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  our  IP  address  changes  due  to DHCP, we should configure our IP
              address change script (see man page for dhcpcd(8) ) to deliver a SIGHUP or SIGUSR1
              signal  to  OpenVPN.   OpenVPN  will  then  reestablish a connection with its most
              recently authenticated peer on its new IP address.

       --port port
              TCP/UDP port number for both local and remote.  The current default of 1194 repre‐
              sents 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.

       --lport port
              TCP/UDP port number for bind.

       --rport port
              TCP/UDP port number for remote.

       --bind Bind to local address and port. This is the default unless  any  of  --proto  tcp-
              client , --http-proxy or --socks-proxy are used.

       --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 --remote option.

       --dev tunX | tapX | null
              TUN/TAP virtual network device ( 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.

              tun devices encapsulate IPv4 or IPv6 (OSI Layer 3) while tap  devices  encapsulate
              Ethernet 802.3 (OSI Layer 2).

       --dev-type device-type
              Which  device  type  are we using?  device-type should be tun (OSI Layer 3) or tap
              (OSI Layer 2).  Use this option only if the TUN/TAP device used  with  --dev  does
              not begin with tun or tap.

       --topology mode
              Configure virtual addressing topology when running in --dev tun mode.  This direc‐
              tive has no meaning in --dev tap mode, which always uses a subnet topology.

              If you set this directive on the server, the --server and  --server-bridge  direc‐
              tives  will  automatically  push  your chosen topology setting to clients as well.
              This directive can also be manually pushed to clients.  Like the --dev  directive,
              this directive must always be compatible between client and server.

              mode can be one of:

              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  con‐
              necting clients might be Windows systems.  This is the default on OpenVPN 2.0.

              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  --ifconfig-pool-linear directive which is available in OpenVPN 2.0 and is
              now deprecated.

              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 --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 man‐
              ually  patched with the --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 ifconfig(8) command which sets a subnet instead of a
              remote endpoint IP address.

              This option exists in OpenVPN 2.1 or higher.

       --tun-ipv6
              Build a tun link capable of forwarding IPv6 traffic.  Should be used  in  conjunc‐
              tion  with  --dev  tun  or --dev tunX.  A warning will be displayed if no specific
              IPv6 TUN support for your OS has been compiled into OpenVPN.

       --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 node is a TUN or TAP device based on
              the name, you should also specify --dev-type tun or --dev-type tap.

              On Windows systems, select the TAP-Win32 adapter which is named node in  the  Net‐
              work  Connections Control Panel or the raw GUID of the adapter enclosed by braces.
              The --show-adapters option under Windows can also be used to enumerate all  avail‐
              able  TAP-Win32  adapters and will show both the network connections control panel
              name and the GUID for each TAP-Win32 adapter.

       --lladdr address
              Specify the link layer address, more commonly known  as  the  MAC  address.   Only
              applied to TAP devices.

       --iproute cmd
              Set alternate command to execute instead of default iproute2 command.  May be used
              in order to execute OpenVPN in unprivileged environment.

       --ifconfig l rn
              Set TUN/TAP adapter parameters.  l is the IP address of the  local  VPN  endpoint.
              For  TUN  devices,  rn  is  the  IP  address  of the remote VPN endpoint.  For TAP
              devices, rn is the subnet mask of the virtual ethernet segment which is being cre‐
              ated or connected to.

              For  TUN  devices,  which  facilitate  virtual  point-to-point IP connections, the
              proper usage of --ifconfig is to use two private IP addresses which are not a mem‐
              ber  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  estab‐
              lished, by pinging rn, you will be pinging across the VPN.

              For  TAP  devices,  which provide the ability to create virtual ethernet segments,
              --ifconfig is used to set an IP address and subnet mask just as a physical  ether‐
              net  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 ifconfig(8) command, is  designed  to
              simplify  TUN/TAP  tunnel  configuration  by providing a standard interface to the
              different ifconfig implementations on different platforms.

              --ifconfig parameters which are IP addresses can also be specified  as  a  DNS  or
              /etc/hosts file resolvable name.

              For  TAP  devices, --ifconfig should not be used if the TAP interface will be get‐
              ting an IP address lease from a DHCP server.

       --ifconfig-noexec
              Don't actually execute ifconfig/netsh commands, instead pass --ifconfig parameters
              to scripts using environmental variables.

       --ifconfig-nowarn
              Don't output an options consistency check warning if the --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
              --disable-occ option) while only disabling the ifconfig component of the check.

              For example, if you have a configuration where the local host uses --ifconfig  but
              the remote host does not, use --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.

       --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  route(8)  shell  command,
              while  at  the  same  time  providing portable semantics across OpenVPN's platform
              space.

              netmask default -- 255.255.255.255

              gateway default -- taken from --route-gateway or the second parameter to  --ifcon‐
              fig when --dev tun is specified.

              metric default -- taken from --route-metric otherwise 0.

              The  default  can  be  specified  by  leaving  an  option  blank  or setting it to
              "default".

              The network and gateway parameters can also be specified as a  DNS  or  /etc/hosts
              file resolvable name, or as one of three special keywords:

              vpn_gateway  -- The remote VPN endpoint address (derived either from --route-gate‐
              way or the second parameter to --ifconfig when --dev tun is specified).

              net_gateway -- The pre-existing IP default gateway, read from  the  routing  table
              (not supported on all OSes).

              remote_host -- The --remote address if OpenVPN is being run in client mode, and is
              undefined in server mode.

       --max-routes n
              Allow a maximum number of n --route options to be specified, either in  the  local
              configuration file, or pulled from an OpenVPN server.  By default, n=100.

       --route-gateway gw|'dhcp'
              Specify a default gateway gw for use with --route.

              If  dhcp is specified as the parameter, the gateway address will be extracted from
              a DHCP negotiation with the OpenVPN server-side LAN.

       --route-metric m
              Specify a default metric m for use with --route.

       --route-delay [n] [w]
              Delay n seconds (default=0) after connection establishment, before adding  routes.
              If  n  is  0,  routes will be added immediately upon connection establishment.  If
              --route-delay is omitted, routes will be added immediately  after  TUN/TAP  device
              open  and  --up script execution, before any --user or --group privilege downgrade
              (or --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, --route-delay tries to be more intelligent by waiting w seconds  (w=30
              by default) for the TAP-Win32 adapter to come up before adding routes.

       --route-up cmd
              Execute shell command cmd after routes are added, subject to --route-delay.

              See  the  "Environmental Variables" section below for additional parameters passed
              as environmental variables.

              Note that cmd can be a shell command with multiple arguments.

       --route-noexec
              Don't add or remove routes  automatically.   Instead  pass  routes  to  --route-up
              script using environmental variables.

       --route-nopull
              When  used  with  --client  or  --pull, accept options pushed by server EXCEPT for
              routes.

              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.

       --allow-pull-fqdn
              Allow client to pull DNS names from  server  (rather  than  being  limited  to  IP
              address) for --ifconfig, --route, and --route-gateway.

       --redirect-gateway flags...
              (Experimental)  Automatically  execute  routing  commands to cause all outgoing IP
              traffic to be redirected over the VPN.

              This option performs three steps:

              (1) Create a static route for the --remote address  which  forwards  to  the  pre-
              existing  default  gateway.   This  is  done so that (3) will not create a routing
              loop.

              (2) Delete the default gateway route.

              (3) Set the new default gateway to be the VPN  endpoint  address  (derived  either
              from --route-gateway or the second parameter to --ifconfig when --dev tun is spec‐
              ified).

              When the tunnel is torn down, all of the above steps  are  reversed  so  that  the
              original default route is restored.

              Option flags:

              local  --  Add the local flag if both OpenVPN servers are directly connected via a
              common subnet, such as with wireless.  The local flag will cause step 1  above  to
              be omitted.

              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.

              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).

              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).

              Using the def1 flag is highly recommended.

       --redirect-private [flags]
              Like  --redirect-gateway,  but omit actually changing the default gateway.  Useful
              when pushing private subnets.

       --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.

       --tun-mtu n
              Take  the  TUN  device MTU to be 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 --fragment and/or --mssfix options to deal  with  MTU  sizing
              issues.

       --tun-mtu-extra n
              Assume  that  the  TUN/TAP  device  might  return as many as n bytes more than the
              --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 transmis‐
              sion overhead associated with using a larger value.

       --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.

              'no' -- Never send DF (Don't Fragment) frames
              'maybe' -- Use per-route hints
              'yes' -- Always DF (Don't Fragment)

       --mtu-test
              To  empirically  measure  MTU  on connection startup, add the --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 --mtu-
              test process normally takes about 3 minutes to complete.

       --fragment max
              Enable internal datagram fragmentation so that no UDP datagrams are sent which are
              larger than max bytes.

              The max parameter is interpreted in the same way as the --link-mtu parameter, i.e.
              the UDP packet size after encapsulation  overhead  has  been  added  in,  but  not
              including the UDP header itself.

              The  --fragment  option  only  makes  sense  when you are using the UDP protocol (
              --proto udp ).

              --fragment adds 4 bytes of overhead per datagram.

              See the --mssfix option below for an important related option to --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 fragmen‐
              tation capability may be your only option,  such  as  tunneling  a  UDP  multicast
              stream which requires fragmentation.

       --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 max bytes. The default
              value is 1450.

              The max parameter is interpreted in the same way as the --link-mtu parameter, i.e.
              the  UDP  packet  size  after  encapsulation  overhead  has been added in, but not
              including the UDP header itself.

              The --mssfix option only makes sense when you are using the UDP protocol for Open‐
              VPN peer-to-peer communication, i.e.  --proto udp.

              --mssfix  and  --fragment can be ideally used together, where --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), --fragment will internally
              fragment them.

              Both --fragment and --mssfix are designed to work around cases where Path MTU dis‐
              covery 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 --fragment and --mssfix are used together, --mssfix will take its  default  max
              parameter from the --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:

              --tun-mtu 1500 --fragment 1300 --mssfix

       --sndbuf size
              Set the TCP/UDP socket send buffer size.  Currently defaults to 65536 bytes.

       --rcvbuf size
              Set the TCP/UDP socket receive buffer size.  Currently defaults to 65536 bytes.

       --socket-flags flags...
              Apply the given flags to the OpenVPN transport socket.  Currently, only  TCP_NODE‐
              LAY is supported.

              The  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 improve‐
              ment in latency.

              This option is pushable from server to client, and should be used on  both  client
              and server for maximum effect.

       --txqueuelen n
              (Linux only) Set the TX queue length on the TUN/TAP interface.  Currently defaults
              to 100.

       --shaper n
              Limit bandwidth of outgoing tunnel data to 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  n  bytes  per second, after a datagram write of b bytes is queued on the
              TCP/UDP port, wait a minimum of (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 n to be between 100 bytes/sec and 100 Mbytes/sec.

       --inactive n [bytes]
              Causes OpenVPN to exit after 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 bytes parameter is included, exit if less than bytes  of  combined
              in/out traffic are produced on the tun/tap device in 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.

       --ping n
              Ping remote over the TCP/UDP control channel if no packets have been sent  for  at
              least  n seconds (specify --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 --secret, --tls-server, or
              --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
              --ping-exit option.

       --ping-exit n
              Causes OpenVPN to exit after n seconds pass without reception of a ping  or  other
              packet  from  remote.   This  option  can be combined with --inactive, --ping, and
              --ping-exit to create a two-tiered inactivity disconnect.

              For example,

              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.

       --ping-restart n
              Similar to --ping-exit, but trigger a SIGUSR1 restart after 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
              http://dyndns.org/ + a dynamic DNS client such as ddclient.

              If the peer cannot be reached, a restart will be triggered, causing  the  hostname
              used with --remote to be re-resolved (if --resolv-retry is also specified).

              In server mode, --ping-restart, --inactive, or any other type of internally gener‐
              ated signal will always be applied to individual client instance objects, never to
              whole  server itself.  Note also in server mode that any internally generated sig‐
              nal which would normally cause a restart, will cause the deletion  of  the  client
              instance object instead.

              In  client  mode,  the  --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 --keepalive setting in the server configuration.  To disable the 120
              second default, set --ping-restart 0 on the client.

              See the signals section below for more information on SIGUSR1.

              Note that the behavior of SIGUSR1 can be modified by the --persist-tun, --persist-
              key, --persist-local-ip, and --persist-remote-ip options.

              Also note that --ping-exit and --ping-restart are mutually exclusive and cannot be
              used together.

       --keepalive n m
              A helper directive designed to simplify  the  expression  of  --ping  and  --ping-
              restart in server mode configurations.

              For example, --keepalive 10 60 expands as follows:

                   if mode server:
                     ping 10
                     ping-restart 120
                     push "ping 10"
                     push "ping-restart 60"
                   else
                     ping 10
                     ping-restart 60

       --ping-timer-rem
              Run  the --ping-exit / --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  --remote  peer),  and  you don't want to start clocking timeouts until a
              remote peer connects.

       --persist-tun
              Don't close and reopen TUN/TAP device or run up/down  scripts  across  SIGUSR1  or
              --ping-restart restarts.

              SIGUSR1 is a restart signal similar to SIGHUP, but which offers finer-grained con‐
              trol over reset options.

       --persist-key
              Don't re-read key files across SIGUSR1 or --ping-restart.

              This option can be combined with --user nobody to allow restarts triggered by  the
              SIGUSR1  signal.  Normally if you drop root privileges in OpenVPN, the daemon can‐
              not be restarted since it will now be unable to re-read protected key files.

              This option solves the problem by persisting keys across SIGUSR1 resets,  so  they
              don't need to be re-read.

       --persist-local-ip
              Preserve  initially  resolved  local  IP address and port number across SIGUSR1 or
              --ping-restart restarts.

       --persist-remote-ip
              Preserve most recently authenticated remote IP  address  and  port  number  across
              SIGUSR1 or --ping-restart restarts.

       --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
              --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 operat‐
              ing  systems.   It ensures that even if an attacker was able to crack the box run‐
              ning OpenVPN, he would not be able to scan the system swap file to recover  previ‐
              ously  used  ephemeral  keys,  which are used for a period of time governed by the
              --reneg options (see below), then are discarded.

              The downside of using --mlock is that it will reduce the amount of physical memory
              available to other applications.

       --up cmd
              Shell command to run after successful TUN/TAP device open (pre --user UID change).
              The up script is useful for specifying route commands which route IP traffic  des‐
              tined  for private subnets which exist at the other end of the VPN connection into
              the tunnel.

              For --dev tun execute as:

              cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip [ init | restart
              ]

              For --dev tap execute as:

              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 cmd can be a shell command with multiple arguments, in  which  case  all
              OpenVPN-generated  arguments will be appended to cmd to build a command line which
              will be passed to the shell.

              Typically, 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 con‐
              text,  the  last command line parameter passed to the script will be init.  If the
              --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  --persist-tun  option  will  enable  such
              preservation).   A  restart can be generated by a SIGUSR1 signal, a --ping-restart
              timeout, or a connection reset when the TCP protocol is enabled with  the  --proto
              option.   If  a restart occurs, and --up-restart has been specified, the up script
              will be called with restart as the last parameter.

              The following standalone example shows how the --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).

              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 --ifconfig option  to  automatically  ifconfig
              the  TUN  device,  eliminating  the need to define an --up script, unless you also
              want to configure routes in the --up script.

              If --ifconfig is also specified, OpenVPN will pass the ifconfig local  and  remote
              endpoints  on the command line to the --up script so that they can be used to con‐
              figure routes such as:

              route add -net 10.0.0.0 netmask 255.255.255.0 gw $5

       --up-delay
              Delay TUN/TAP open and possible --up script execution until after TCP/UDP  connec‐
              tion establishment with peer.

              In --proto udp mode, this option normally requires the use of --ping to allow con‐
              nection 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  authen‐
              ticated packet from the peer.

       --down cmd
              Shell  command  to  run  after TUN/TAP device close (post --user UID change and/or
              --chroot ).  Called with the same parameters and environmental  variables  as  the
              --up option above.

              Note  that  if  you  reduce privileges by using --user and/or --group, your --down
              script will also run at reduced privilege.

       --down-pre
              Call --down cmd/script before, rather than after, TUN/TAP close.

       --up-restart
              Enable the --up and --down scripts to be called for restarts as  well  as  initial
              program start.  This option is described more fully above in the --up option docu‐
              mentation.

       --setenv name value
              Set a custom environmental variable name=value to pass to script.

       --setenv FORWARD_COMPATIBLE 1
              Relax config file syntax checking so that unknown directives will trigger a  warn‐
              ing  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.

       --setenv-safe name value
              Set a custom environmental variable OPENVPN_name=value to pass to script.

              This directive is designed to be pushed by the server to clients, and the prepend‐
              ing of "OPENVPN_" to the environmental variable is a safety precaution to  prevent
              a LD_PRELOAD style attack from a malicious or compromised server.

       --script-security level [method]
              This  directive  offers policy-level control over OpenVPN's usage of external pro‐
              grams and scripts.  Lower level values are more  restrictive,  higher  values  are
              more permissive.  Settings for level:

              0 -- Strictly no calling of external programs.
              1  --  (Default)  Only  call  built-in executables such as ifconfig, ip, route, or
              netsh.
              2 -- Allow calling of built-in executables and user-defined scripts.
              3 -- Allow passwords to be passed to scripts via environmental  variables  (poten‐
              tially unsafe).

              The  method  parameter  indicates  how  OpenVPN  should call external commands and
              scripts.  Settings for method:

              execve -- (default) Use execve() function on Unix family OSes and  CreateProcess()
              on Windows.
              system  -- Use system() function (deprecated and less safe since the external pro‐
              gram command line is subject to shell expansion).

              The --script-security option was introduced in OpenVPN 2.1_rc9.  For configuration
              file compatibility with previous OpenVPN versions, use: --script-security 3 system

       --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  --dev
              tun while the other peer uses --dev tap.

              Use  of  this  option is discouraged, but is provided as a temporary fix in situa‐
              tions where a recent version of OpenVPN must connect to an old version.

       --user user
              Change the user ID of the OpenVPN process to 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 user to 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  exam‐
              ple,  that if you want to reset an OpenVPN daemon with a SIGUSR1 signal (for exam‐
              ple in response to a DHCP reset), you should make use of one or more of the --per‐
              sist  options to ensure that OpenVPN doesn't need to execute any privileged opera‐
              tions in order to restart (such as re-reading key files or running ifconfig on the
              TUN device).

       --group group
              Similar  to  the  --user  option,  this option changes the group ID of the OpenVPN
              process to group after initialization.

       --cd dir
              Change directory to dir prior to reading any files such  as  configuration  files,
              key  files, scripts, etc.  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 --daemon mode, and you  want
              to consolidate all of your OpenVPN control files in one location.

       --chroot dir
              Chroot  to  dir after initialization.  --chroot essentially redefines 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 dir parameter can point to an empty directory, however  compli‐
              cations  can  result when scripts or restarts are executed after the chroot opera‐
              tion.

       --setcon context
              Apply SELinux 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 --user and --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  Poli‐
              cies) 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
              --persist-key and --persist-tun options.

       --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 shell scripts and ifconfig commands,
              which will go to /dev/null unless otherwise redirected.   The  syslog  redirection
              occurs  immediately  at the point that --daemon is parsed on the command line even
              though the daemonization point occurs later.  If  one  of  the  --log  options  is
              present, it will supercede syslog redirection.

              The  optional  progname parameter will cause OpenVPN to report its program name to
              the system logger as progname.  This can be useful in linking OpenVPN messages  in
              the  syslog  file  with  specific tunnels.  When unspecified, progname defaults to
              "openvpn".

              When OpenVPN is run with the --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.

       --syslog [progname]
              Direct log output to system logger, but do not  become  a  daemon.   See  --daemon
              directive above for description of progname parameter.

       --passtos
              Set the TOS field of the tunnel packet to what the payload's TOS is.

       --inetd [wait|nowait] [progname]
              Use this option when OpenVPN is being run from the inetd or xinetd(8) server.

              The  wait/nowait  option  must  match what is specified in the inetd/xinetd config
              file.  The nowait mode can only be used with --proto tcp-server.  The  default  is
              wait.   The 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:
              http://openvpn.net/faq.html#oneport

              This option precludes the use of --daemon, --local, or --remote.  Note  that  this
              option causes message and error output to be handled in the same way as the --dae‐
              mon option.  The optional progname parameter is also handled exactly as in  --dae‐
              mon.

              Also  note that in 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: http://openvpn.net/1xhowto.html

       --log file
              Output logging messages to file, including output to stdout/stderr which is gener‐
              ated by called scripts.  If 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 --daemon or --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 --ping-restart.

              Note that on Windows, when OpenVPN is started as  a  service,  logging  occurs  by
              default without the need to specify this option.

       --log-append file
              Append  logging  messages  to  file.   If file does not exist, it will be created.
              This option behaves exactly like --log except that it appends to rather than trun‐
              cating the log file.

       --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.

       --writepid file
              Write OpenVPN's main process ID to file.

       --nice n
              Change process priority after initialization ( n greater than 0 is lower priority,
              n less than zero is higher priority).

       --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 --proto  udp  is  speci‐
              fied, and when --shaper is NOT specified.

       --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 --multihome server should always use the --nobind
              option.

       --echo [parms...]
              Echo parms to log output.

              Designed to be used to send messages to a controlling application which is receiv‐
              ing the OpenVPN log output.

       --remap-usr1 signal
              Control whether internally or externally generated SIGUSR1 signals are remapped to
              SIGHUP (restart without persisting state) or SIGTERM (exit).

              signal can be set to "SIGHUP" or "SIGTERM".  By default, no remapping occurs.

       --verb n
              Set output verbosity to n (default=1).  Each level shows all info from the  previ‐
              ous levels.  Level 3 is recommended if you want a good summary of what's happening
              without being swamped by output.

              0 -- No output except fatal errors.
              1 to 4 -- Normal usage range.
              5 -- Output R and 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.
              6  to  11  -- Debug info range (see errlevel.h for additional information on debug
              levels).

       --status file [n]
              Write operational status to file every n seconds.

              Status can also be written to the syslog by sending a SIGUSR2 signal.

       --status-version [n]
              Choose the status file format version number.  Currently n can be 1, 2, or  3  and
              defaults to 1.

       --mute n
              Log  at most n consecutive messages in the same category.  This is useful to limit
              repetitive logging of similar message types.

       --comp-lzo [mode]
              Use fast LZO compression -- may add up to 1 byte  per  packet  for  incompressible
              data.  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 hav‐
              ing  at least one --comp-lzo directive, such as --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  --client-config-dir  file,  specify  the  compression setting for the
              client, for example:

                  comp-lzo yes
                  push "comp-lzo yes"

              The first line sets the comp-lzo setting for the server side of the link, the sec‐
              ond sets the client side.

       --comp-noadapt
              When used in conjunction with --comp-lzo, this option will disable OpenVPN's adap‐
              tive compression  algorithm.   Normally,  adaptive  compression  is  enabled  with
              --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  open‐
              vpn to disable compression for a period of time until the next re-sample test.

       --management IP port [pw-file]
              Enable a TCP server on IP:port to handle daemon management functions.  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  plat‐
              forms that support it.  To use a unix domain socket, specify the unix socket path‐
              name in place of IP and set port to 'unix'.  While the default behavior is to cre‐
              ate  a  unix  domain socket that may be connected to by any process, the --manage‐
              ment-client-user and --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 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 management folder of the OpenVPN source distribution.

              It  is  strongly  recommended  that IP be set to 127.0.0.1 (localhost) to restrict
              accessibility of the management server to local clients.

       --management-client
              Management interface will connect as a TCP client to IP:port specified  by  --man‐
              agement rather than listen as a TCP server.

       --management-query-passwords
              Query  management  channel  for  private  key  password and --auth-user-pass user‐
              name/password.  Only query the management  channel  for  inputs  which  ordinarily
              would have been queried from the console.

       --management-forget-disconnect
              Make OpenVPN forget passwords when management session disconnects.

              This  directive  does not affect the --http-proxy username/password.  It is always
              cached.

       --management-hold
              Start OpenVPN in a hibernating state, until a client of the  management  interface
              explicitly starts it with the hold release command.

       --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.

       --management-log-cache n
              Cache the most recent n lines of log file history  for  usage  by  the  management
              channel.

       --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.

       --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.

       --management-client-user u
              When the management interface is listening on a unix  domain  socket,  only  allow
              connections from user u.

       --management-client-group g
              When  the  management  interface  is listening on a unix domain socket, only allow
              connections from group g.

       --plugin module-pathname [init-string]
              Load plug-in module from the file module-pathname, passing init-string as an argu‐
              ment 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 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 doc and the actual plugin modules are in 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 mod‐
              ule/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.

   Server Mode
       Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode is supported,  and  can  be
       enabled  with  the --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.

       --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, --server 10.8.0.0 255.255.255.0 expands as follows:

                   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"

              Don't use --server if you are ethernet bridging.  Use --server-bridge instead.

       --server-bridge gateway netmask pool-start-IP pool-end-IP

       --server-bridge ['nogw']

              A  helper directive similar to --server which is designed to simplify the configu‐
              ration of OpenVPN's server mode in ethernet bridging configurations.

              If --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 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 brctl tool, and with Windows XP it is done in the Net‐
              work Connections Panel by selecting the ethernet and TAP adapters and right-click‐
              ing on "Bridge Connections".

              Next  you you must manually set the IP/netmask on the bridge interface.  The gate‐
              way and netmask parameters to --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 pool-start-IP  and
              pool-end-IP, for OpenVPN to allocate to connecting clients.

              For example, server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254 expands as
              follows:

                  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 another example, --server-bridge (without parameters) expands as follows:

                  mode server
                  tls-server

                  push "route-gateway dhcp"

              Or --server-bridge nogw expands as follows:

                  mode server
                  tls-server

       --push option
              Push a config file option back to the client  for  remote  execution.   Note  that
              option  must be enclosed in double quotes ("").  The client must specify --pull in
              its config file.  The set of options which can be pushed is limited by both feasi‐
              bility  and  security.  Some options such as those which would execute scripts are
              banned, since they would effectively allow a compromised server to  execute  arbi‐
              trary  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: --route, --route-
              gateway, --route-delay, --redirect-gateway, --ip-win32, --dhcp-option, --inactive,
              --ping,   --ping-exit,  --ping-restart,  --setenv,  --persist-key,  --persist-tun,
              --echo, --comp-lzo, --socket-flags, --sndbuf, --rcvbuf

       --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 --client-config-dir configura‐
              tion file.  This option will ignore --push  options  at  the  global  config  file
              level.

       --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 --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  --client-con‐
              fig-dir or dynamically generated using a --client-connect script.

       --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, indi‐
              vidual addresses will be allocated, and the optional netmask parameter  will  also
              be pushed to clients.


       --ifconfig-pool-persist file [seconds]
              Persist/unpersist  ifconfig-pool data to file, at 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 --persist-tun option.

              file is a comma-delimited ASCII file, formatted as <Common-Name>,<IP-address>.

              If  seconds  =  0, file will be treated as read-only.  This is useful if you would
              like to treat 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 --ifconfig-push

       --ifconfig-pool-linear
              Modifies  the  --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 --topology p2p which is
              functionally equivalent.

       --ifconfig-push local remote-netmask
              Push virtual IP  endpoints  for  client  tunnel,  overriding  the  --ifconfig-pool
              dynamic allocation.

              The parameters local and remote-netmask are set according to the --ifconfig direc‐
              tive which you want to execute on the client machine to configure the  remote  end
              of  the  tunnel.   Note  that the parameters local and 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.

              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 --client-con‐
              fig-dir or dynamically generated using a --client-connect script.

              Remember also to include a --route directive in the main OpenVPN config file which
              encloses  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:

              1 -- Use --client-connect script generated file for static IP (first choice).
              2 -- Use --client-config-dir file for static IP (next choice).
              3 -- Use --ifconfig-pool allocation for dynamic IP (last choice).

       --iroute network [netmask]
              Generate an internal route to a specific client. The netmask parameter,  if  omit‐
              ted, 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
              --route directive).  The reason why two routes are  needed  is  that  the  --route
              directive  routes  the  packet  from  the kernel to OpenVPN.  Once in OpenVPN, the
              --iroute directive routes to the specific client.

              This option must be specified either  in  a  client  instance  config  file  using
              --client-config-dir or dynamically generated using a --client-connect script.

              The  --iroute directive also has an important interaction with --push "route ...".
              --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 --push "route ..."  together with --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  accom‐
              plishes  this  by  not  not  pushing  a route to a client if it matches one of the
              client's iroutes.

       --client-to-client
              Because the OpenVPN server mode handles multiple clients through a single  tun  or
              tap  interface,  it  is  effectively  a router.  The --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 cur‐
              rently 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.

       --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.

       --client-connect script
              Run  script  on  client  connection.   The script is passed the common name and IP
              address of the just-authenticated client as environmental variables (see  environ‐
              mental  variable  section  below).   The  script  is also passed the pathname of a
              freshly created temporary file as $1 (i.e. the first command line argument), to be
              used  by  the  script 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 $1.

              See  the --client-config-dir option below for options which can be legally used in
              a dynamically generated config file.

              Note that the return value of script is significant.  If script returns a non-zero
              error status, it will cause the client to be disconnected.

       --client-disconnect
              Like  --client-connect but called on client instance shutdown.  Will not be called
              unless the --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 --client-disconnect script 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.

       --client-config-dir dir
              Specify a directory 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 priv‐
              ileges.

              This file can specify a fixed IP address for a given client using --ifconfig-push,
              as well as fixed subnets owned by the client using --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: --push, --push-
              reset, --iroute, --ifconfig-push, and --config.

       --ccd-exclusive
              Require, as a  condition  of  authentication,  that  a  connecting  client  has  a
              --client-config-dir file.

       --tmp-dir dir
              Specify a directory dir for temporary files.  This directory will be used by open‐
              vpn 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:

              * --client-connect scripts to dynamically generate  client-specific  configuration
              files.

              *  OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY  plugin hook to return success/failure via
              auth_control_file when using deferred auth method

              * OPENVPN_PLUGIN_ENABLE_PF plugin hook to pass filtering rules via pf_file

       --hash-size r v
              Set the size of the real address hash table to r and the virtual address table  to
              v.  By default, both tables are sized at 256 buckets.

       --bcast-buffers n
              Allocate n buffers for broadcast datagrams (default=256).

       --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 con‐
              nection, OpenVPN will start to drop outgoing packets directed at this client.

       --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:

                   if mode server:
                     socket-flags TCP_NODELAY
                     push "socket-flags TCP_NODELAY"

       --max-clients n
              Limit server to a maximum of n concurrent clients.

       --max-routes-per-client n
              Allow a maximum of 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 --client-config-dir file  or  auto-generated  by  a  --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.

       --connect-freq n sec
              Allow a maximum of n new connections  per  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 --proto udp and
              --tls-auth.

       --learn-address cmd
              Run script or shell command cmd to validate client virtual addresses or routes.

              cmd will be executed with 3 parameters:

              [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.
              [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 --dev tap is being used) such as "00:FF:01:02:03:04".
              [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 cmd script will use the information provided above to set  appropri‐
              ate  firewall  entries  on  the VPN TUN/TAP interface.  Since OpenVPN provides the
              association between virtual IP or MAC address and the client's authenticated  com‐
              mon  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.

       --auth-user-pass-verify script method
              Require  the  client  to  provide  a  username/password (possibly in addition to a
              client certificate) for authentication.

              OpenVPN will execute script as a shell command to validate  the  username/password
              provided by the client.

              If  method  is  set  to "via-env", OpenVPN will call script with the environmental
              variables username and 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 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 argu‐
              ment to script, and the file will be automatically deleted by  OpenVPN  after  the
              script returns.  The location of the temporary file is controlled by the --tmp-dir
              option, and will default to the current directory if unspecified.   For  security,
              consider  setting  --tmp-dir  to  a  volatile  storage medium such as /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  Open‐
              VPN'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 con‐
              sist 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 vul‐
              nerability 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 sample-scripts/auth-
              pam.pl in the OpenVPN source distribution.

       --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 --disable-occ NOT be used.

       --auth-user-pass-optional
              Allow  connections  by clients that do not specify a username/password.  Normally,
              when --auth-user-pass-verify  or  --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.

       --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  certifi‐
              cates from all clients.

              If  you  use this directive, the entire responsibility of authentication will rest
              on your --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 --auth-user-pass-verify
              script, then OpenVPN will perform double authentication.  The  client  certificate
              verification  AND the --auth-user-pass-verify script will need to succeed in order
              for a client to be authenticated and accepted onto the VPN.

       --username-as-common-name
              For --auth-user-pass-verify authentication, use the authenticated username as  the
              common name, rather than the common name from the client cert.

       --no-name-remapping
              Allow  Common  Name,  X509  Subject, and username strings to include any printable
              character including space, but excluding control characters such as tab,  newline,
              and carriage-return.

              By  default,  OpenVPN  will  remap any character other than alphanumeric, underbar
              ('_'), dash ('-'), dot ('.'), and slash ('/') to underbar ('_').  The X509 Subject
              string  as returned by the tls_id environmental variable, can additionally contain
              colon (':') or equal ('=').

              While name remapping is performed for security reasons to reduce  the  possibility
              of introducing string expansion security vulnerabilities in user-defined authenti‐
              cation scripts, this option is provided for those cases where it is  desirable  to
              disable the remapping feature.  Don't use this option unless you know what you are
              doing!

       --port-share host port
              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  host:port.
              Currently  only designed to work with HTTP/HTTPS, though it would be theoretically
              possible to extend to other protocols such as ssh.

              Not implemented on Windows.

   Client Mode
       Use client mode when connecting to an OpenVPN server which has --server, --server-bridge,
       or --mode server in it's configuration.

       --client
              A  helper  directive  designed  to  simplify the configuration of OpenVPN's client
              mode.  This directive is equivalent to:

                   pull
                   tls-client

       --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, pro‐
              vided they are part of the legal set of pushable options  (note  that  the  --pull
              option is implied by --client ).

              In  particular,  --pull  allows  the  server  to push routes to the client, so you
              should not use --pull or --client in situations where you don't trust  the  server
              to have control over the client's routing table.

       --auth-user-pass [up]
              Authenticate  with  server using username/password.  up is a file containing user‐
              name/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 up is omitted, username/password will be prompted from the console.

              The server configuration must specify an --auth-user-pass-verify script to  verify
              the username/password provided by the client.

       --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 --auth-user-
              pass  authentication,  or  if  the  server-side --client-connect script returns an
              error status when the client tries to connect.

              type can be one of:

              none -- Client will exit with a fatal error (this is the default).
              nointeract -- Client will retry the connection without requerying for  an  --auth-
              user-pass username/password.  Use this option for unattended clients.
              interact  --  Client will requery for an --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  man‐
              agement interface.

       --server-poll-timeout n
              when polling possible remote servers to connect to in a round-robin fashion, spend
              no more than n seconds waiting for a response before trying the next server.

       --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 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.

   Data Channel Encryption Options:
       These options are meaningful for both Static & TLS-negotiated key modes (must be compati‐
       ble between peers).

       --secret file [direction]
              Enable Static Key encryption mode (non-TLS).  Use pre-shared secret file which was
              generated with --genkey.

              The optional 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 secu‐
              rity  properties  including  eliminating  certain  kinds of DoS and message replay
              attacks.

              When the direction parameter is omitted, 2 keys are used bidirectionally, one  for
              HMAC and the other for encryption/decryption.

              The  direction parameter should always be complementary on either side of the con‐
              nection, i.e. one side should use "0" and the other should use "1", or both  sides
              should omit it altogether.

              The direction parameter requires that file contains a 2048 bit key.  While pre-1.5
              versions of OpenVPN generate 1024 bit key files, any version of OpenVPN which sup‐
              ports  the  direction  parameter,  will  also support 2048 bit key file generation
              using the --genkey option.

              Static key encryption mode has certain advantages, the primary being ease of  con‐
              figuration.

              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 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 hand‐
              shake-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.

       --auth alg
              Authenticate  packets  with HMAC using message digest algorithm alg.  (The default
              is 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 sig‐
              nature.

              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 --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 alg=none to disable authentication.

              For           more           information           on           HMAC           see
              http://www.cs.ucsd.edu/users/mihir/papers/hmac.html

       --cipher alg
              Encrypt packets with cipher algorithm alg.  The default is 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 http://www.counterpane.com/blowfish.html

              To  see  other  ciphers  that  are  available with OpenVPN, use the --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 alg=none to disable encryption.

       --keysize n
              Size  of  cipher  key in bits (optional).  If unspecified, defaults to cipher-spe‐
              cific default.  The --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  exten‐
              sively  cryptanalyzed with non-standard key lengths, and a larger key may offer no
              real guarantee of greater security, or may even reduce security.

       --prng alg [nsl]
              (Advanced) For PRNG (Pseudo-random number generator),  use  digest  algorithm  alg
              (default=sha1),  and set nsl (default=16) to the size in bytes of the nonce secret
              length (between 16 and 64).

              Set alg=none to disable the PRNG and use the OpenSSL RAND_bytes  function  instead
              for all of OpenVPN's pseudo-random number needs.

       --engine [engine-name]
              Enable OpenSSL hardware-based crypto engine functionality.

              If engine-name is specified, use a specific crypto engine.  Use the --show-engines
              standalone option to list the crypto engines which are supported by OpenSSL.

       --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  iden‐
              tifier  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 (iden‐
              tifying 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  unique‐
              ness  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 sliding window algorithm used by IPSec.

       --replay-window n [t]
              Use a replay protection sliding-window of size n and a time window of t seconds.

              By default n is 64 (the IPSec default) and t is 15 seconds.

              This option is only relevant in  UDP  mode,  i.e.   when  either  --proto  udp  is
              specifed, or no --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  emu‐
              lating 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.

              (a) The packet cannot be a replay (unless --no-replay is specified, which disables
              replay protection altogether).

              (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 n.

              (c) If a packet arrives out of order, it will only be accepted if  it  arrives  no
              later than 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 n.   Satel‐
              lite links in particular often require this.

              If  you run OpenVPN at --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 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 tun‐
              neling 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 mes‐
              sage deletion or reordering attack that falls within the normal operating  parame‐
              ters  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.

       --mute-replay-warnings
              Silence the output of replay warnings, which are a common false alarm on WiFi net‐
              works.   This  option preserves the security of the replay protection code without
              the verbosity associated with warnings about duplicate packets.

       --replay-persist file
              Persist replay-protection state across sessions using 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 --inetd)  when  OpenVPN  ses‐
              sions 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  --secret (shared-secret key mode) or TLS mode with --tls-
              auth.

       --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 mul‐
              tiple 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.

       --test-crypto
              Do a self-test of OpenVPN's crypto options by encrypting and decrypting test pack‐
              ets  using  the data channel encryption options specified above.  This option does
              not require a peer to function, and therefore can be specified  without  --dev  or
              --remote.

              The typical usage of --test-crypto would be something like this:

              openvpn --test-crypto --secret key

              or

              openvpn --test-crypto --secret key --verb 9

              This option is very useful to test OpenVPN after it has been ported to a new plat‐
              form, 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 authenti‐
              cation can be debugged independently of network and tunnel issues.

   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 medi‐
       ation.  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  authenti‐
       cation and Diffie Hellman forward secrecy.

       To  use  TLS  mode, each peer that runs OpenVPN should have its own local certificate/key
       pair ( --cert and --key ), signed by the root certificate which is specified in --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 --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 easy-rsa subdirectory.

       The easy-rsa package is also rendered in web form here: http://openvpn.net/easyrsa.html

       --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.

       --tls-client
              Enable TLS and assume client role during TLS handshake.

       --ca file
              Certificate authority (CA) file in .pem format, also referred to as the root  cer‐
              tificate.   This  file can have multiple certificates in .pem format, concatenated
              together.  You can construct your own certificate authority certificate  and  pri‐
              vate key by using a command such as:

              openssl req -nodes -new -x509 -keyout ca.key -out ca.crt

              Then edit your openssl.cnf file and edit the certificate variable to point to your
              new root certificate ca.crt.

              For testing purposes only, the OpenVPN distribution includes a sample CA  certifi‐
              cate (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.

       --capath dir
              Directory  containing trusted certificates (CAs and CRLs).  Available with OpenSSL
              version >= 0.9.7 dev.

       --dh file
              File containing Diffie Hellman parameters in  .pem  format  (required  for  --tls-
              server only). Use

              openssl dhparam -out dh1024.pem 1024

              to  generate your own, or use the existing dh1024.pem file included with the Open‐
              VPN distribution.  Diffie Hellman parameters may be considered public.

       --cert file
              Local peer's signed certificate in .pem format -- must be signed by a  certificate
              authority whose certificate is in --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 --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:

              openssl req -nodes -new -keyout mycert.key -out mycert.csr

              If your certificate authority private key lives on another machine, copy the  cer‐
              tificate 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:

              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 openssl  ca  com‐
              mand  reads  the  location of the certificate authority key from its configuration
              file such as /usr/share/ssl/openssl.cnf -- note also that for certificate  author‐
              ity functions, you must set up the files index.txt (may be empty) and serial (ini‐
              tialize to 01 ).

       --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 -cert file above).

       --pkcs12 file
              Specify  a PKCS #12 file containing local private key, local certificate, and root
              CA certificate.  This option can be used instead of --ca, --cert, and --key.

       --pkcs11-cert-private [0|1]...
              Set if access to certificate  object  should  be  performed  after  login.   Every
              provider has its own setting.

       --pkcs11-id name
              Specify  the  serialized  certificate  id  to be used. The id can be gotten by the
              standalone --show-pkcs11-ids option.

       --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.

       --pkcs11-pin-cache seconds
              Specify  how many seconds the PIN can be cached, the default is until the token is
              removed.

       --pkcs11-protected-authentication [0|1]...
              Use PKCS#11 protected authentication path, useful for biometric and external  key‐
              pad devices.  Every provider has its own setting.

       --pkcs11-providers provider...
              Specify  a  RSA  Security  Inc.  PKCS #11 Cryptographic Token Interface (Cryptoki)
              providers to load.  This  option  can  be  used  instead  of  --cert,  --key,  and
              --pkcs12.

       --pkcs11-private-mode mode...
              Specify which method to use in order to perform private key operations.  A differ‐
              ent mode can be specified for each provider.  Mode is encoded as hex  number,  and
              can be a mask one of the following:

              0 (default) -- Try to determind automatically.
              1 -- Use sign.
              2 -- Use sign recover.
              4 -- Use decrypt.
              8 -- Use unwrap.

       --cryptoapicert select-string
              Load  the  certificate  and  private key from the Windows Certificate System Store
              (Windows Only).

              Use this option instead of --cert and --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 pri‐
              vate 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:

              cryptoapicert "SUBJ:Peter Runestig"

              To select a certificate, based on certificate's thumbprint:

              cryptoapicert "THUMB:f6 49 24 41 01 b4 ..."

              The thumbprint hex string can easily be copy-and-pasted from the Windows  Certifi‐
              cate Store GUI.


       --key-method m
              Use  data  channel  key  negotiation  method 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  tun‐
              nel 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 --key-method parameter has  no  effect  on  this
              process.

              (2)  After  the  TLS  connection is established, the tunnel session keys are sepa‐
              rately negotiated over the existing secure TLS channel.  Here, --key-method deter‐
              mines the derivation of the tunnel session keys.

       --tls-cipher l
              A  list  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 --show-
              tls to see a list of supported TLS ciphers.

       --tls-timeout n
              Packet  retransmit timeout on TLS control channel if no acknowledgment from remote
              within n seconds (default=2).  When OpenVPN sends a control packet to its peer, it
              will  expect  to receive an acknowledgement within 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.

       --reneg-bytes n
              Renegotiate data channel key after 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 renegoti‐
              ation will be forced if any of these three criteria are met by either peer.

       --reneg-pkts n
              Renegotiate  data  channel  key  after  n  packets  sent and received (disabled by
              default).

       --reneg-sec n
              Renegotiate data channel key after 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 --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 sec‐
              onds.  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.

       --hand-window n
              Handshake Window -- the TLS-based key exchange must finalize within 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 --tran-
              window seconds to maintain continuity of transmission of tunnel data.

       --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.

       --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  recon‐
              nect.

              If  the  daemon is reset by a signal or --ping-restart, it will allow one new con‐
              nection.

              --single-session can be used with --ping-exit or --inactive  to  create  a  single
              dynamic session that will exit when finished.

       --tls-exit
              Exit on TLS negotiation failure.

       --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, --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.

              file (required) is a key file which can be in one of two formats:

              (1) An OpenVPN static key file generated by --genkey (required if direction param‐
              eter is used).

              (2) A freeform passphrase file.  In this case the HMAC key will be derived by tak‐
              ing a secure hash of this file, similar to the md5sum(1) or 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 --secret option for more information on the optional direction parameter.

              --tls-auth  is recommended when you are running OpenVPN in a mode where it is lis‐
              tening for packets from any IP address, such as when --remote is not specified, or
              --remote is specified with --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 authentica‐
              tion 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.

              --tls-auth does this by signing every TLS control channel packet with an HMAC sig‐
              nature, 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.  --tls-auth can
              be strengthened by adding the --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 --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.

       --askpass [file]
              Get certificate password from console or 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 --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
              -nodes option when you use the openssl command line tool  to  manage  certificates
              and private keys.

              If file is specified, read the password from the first line of 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 pass‐
              words 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).

       --auth-nocache
              Don't cache --askpass or --auth-user-pass username/passwords in virtual memory.

              If  specified,  this  directive  will  cause  OpenVPN  to immediately forget user‐
              name/password inputs after they are used.  As a result, when OpenVPN needs a user‐
              name/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 --http-proxy username/password.  It  is  always
              cached.

       --tls-verify cmd
              Execute shell command cmd to verify the X509 name of a pending TLS connection that
              has otherwise passed all other tests of certification (except for  revocation  via
              --crl-verify directive; the revocation test occurs after the --tls-verify test).

              cmd should return 0 to allow the TLS handshake to proceed, or 1 to fail.

              Note  that  cmd  is a command line and as such may (if enclosed in quotes) contain
              whitespace separated arguments.  The first word of cmd is  the  shell  command  to
              execute and the remaining words are its arguments.  When cmd is executed two argu‐
              ments are appended, as follows:

              cmd certificate_depth X509_NAME_oneline

              These arguments are, respectively, the current certificate depth and the X509 com‐
              mon 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 verify-cn in the OpenVPN distribution.

              See  the  "Environmental Variables" section below for additional parameters passed
              as environmental variables.

       --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.

       --x509-username-field fieldname
              Field  in x509 certificate subject to be used as username (default=CN).  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.

       --tls-remote name
              Accept  connections  only from a host with X509 name or common name equal to name.
              The remote host must also pass all other tests of verification.

              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  --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  certifi‐
              cates except for those associated with designated servers.

              --tls-remote  is  a  useful  replacement for the --tls-verify option to verify the
              remote host, because --tls-remote works in a --chroot environment too.

       --ns-cert-type client|server
              Require that peer certificate was signed with an explicit  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  cer‐
              tificate with the nsCertType field set to "server".

              If  the server certificate's nsCertType field is set to "server", then the clients
              can verify this with --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 imper‐
              sonating the server.  The attack is easily prevented by having clients verify  the
              server certificate using any one of --ns-cert-type, --tls-remote, or --tls-verify.

       --remote-cert-ku v...
              Require that peer certificate was signed with an explicit 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.

       --remote-cert-eku oid
              Require that peer certificate was signed with an explicit 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 rep‐
              resentation.

       --remote-cert-tls client|server
              Require that peer certificate was signed with an explicit key usage  and  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 --remote-cert-tls client option is equivalent to  --remote-cert-ku  80  08  88
              --remote-cert-eku "TLS Web Client Authentication"

              The key usage is digitalSignature and/or keyAgreement.

              The  --remote-cert-tls  server  option  is  equivalent  to  --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 imper‐
              sonating the server.  The attack is easily prevented by having clients verify  the
              server certificate using any one of --remote-cert-tls, --tls-remote, or --tls-ver‐
              ify.

       --crl-verify crl
              Check peer certificate against the file 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.

   SSL Library information:
       --show-ciphers
              (Standalone) Show all cipher algorithms to use with the --cipher option.

       --show-digests
              (Standalone) Show all message digest algorithms to use with the --auth option.

       --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.

       --show-engines
              (Standalone)  Show  currently available hardware-based crypto acceleration engines
              supported by the OpenSSL library.

   Generate a random key:
       Used only for non-TLS static key encryption mode.

       --genkey
              (Standalone) Generate a random key to be used as a shared secret, for use with the
              --secret  option.   This  file  must  be  shared with the peer over a pre-existing
              secure channel such as scp(1)

       --secret file
              Write key to file.

   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.

       --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  appli‐
              cation 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 --up and --down scripts to run the appropriate ifconfig(8)  and  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 uninter‐
              rupted connectivity through the tunnel in the event of a DHCP reset of the  peer's
              public IP address (see the --ipchange option above).

              One  disadvantage of persistent tunnels is that it is harder to automatically con‐
              figure their MTU value (see --link-mtu and --tun-mtu above).

              On some platforms such as Windows, TAP-Win32 tunnels are persistent by default.

       --rmtun
              (Standalone) Remove a persistent tunnel.

       --dev tunX | tapX
              TUN/TAP device

       --user user
              Optional user to be owner of this tunnel.

       --group group
              Optional group to be owner of this tunnel.

   Windows-Specific Options:
       --win-sys path|'env'
              Set the Windows system directory pathname to use when looking for system  executa‐
              bles such as route.exe and netsh.exe.  By default, if this directive is not speci‐
              fied, the pathname will be set to "C:\WINDOWS"

              The special string 'env' indicates that the pathname should be read from the  Sys‐
              temRoot environmental variable.

       --ip-win32 method
              When using --ifconfig on Windows, set the TAP-Win32 adapter IP address and netmask
              using method.  Don't use this option unless you are also using --ifconfig.

              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.

              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 --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 --dev tun mode, OpenVPN
              will cause the DHCP server to masquerade as if it were coming from the remote end‐
              point.   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  Win‐
              dows 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
              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.

              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.

              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."

              adaptive -- (Default) Try dynamic method initially and fail over to 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 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 adaptive mode to use  netsh  immediately,  rather  than  trying
              dynamic  first.   To  "unstick" the adaptive mode from using netsh, run OpenVPN at
              least once using the dynamic mode to restore the TAP-Win32 adapter TCP/IP  proper‐
              ties to a DHCP configuration.

       --route-method m
              Which method m to use for adding routes on Windows?

              adaptive  (default)  --  Try IP helper API first.  If that fails, fall back to the
              route.exe shell command.
              ipapi -- Use IP helper API.
              exe -- Call the route.exe shell command.

       --dhcp-option type [parm]
              Set extended TAP-Win32 TCP/IP properties, must be used with --ip-win32 dynamic  or
              --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.

              DOMAIN name -- Set Connection-specific DNS Suffix.

              DNS  addr  --  Set  primary domain name server address.  Repeat this option to set
              secondary DNS server addresses.

              WINS addr -- Set primary WINS server address (NetBIOS over  TCP/IP  Name  Server).
              Repeat this option to set secondary WINS server addresses.

              NBDD addr -- Set primary NBDD server address (NetBIOS over TCP/IP Datagram Distri‐
              bution Server) Repeat this option to set secondary NBDD server addresses.

              NTP addr -- Set primary NTP server address (Network Time Protocol).   Repeat  this
              option to set secondary NTP server addresses.

              NBT  type  --  Set  NetBIOS  over  TCP/IP Node type.  Possible options: 1 = b-node
              (broadcasts), 2 = p-node (point-to-point name queries to a WINS server),  4  =  m-
              node  (broadcast  then query name server), and 8 = h-node (query name server, then
              broadcast).

              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)

              DISABLE-NBT -- Disable Netbios-over-TCP/IP.

              Note that if --dhcp-option is pushed via  --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}".

       --tap-sleep n
              Cause OpenVPN to sleep for 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 --ifconfig
              and --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.

       --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.

       --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.

       --dhcp-release
              Ask Windows to release the TAP adapter lease on shutdown.   This  option  has  the
              same caveats as --dhcp-renew above.

       --register-dns
              Run net stop dnscache, net start dnscache, ipconfig /flushdns and ipconfig /regis‐
              terdns on connection initiation.  This is known to kick Windows  into  recognizing
              pushed DNS servers.

       --pause-exit
              Put  up a "press any key to continue" message on the console prior to OpenVPN pro‐
              gram exit.  This option is automatically used by the Windows explorer when OpenVPN
              is run on a configuration file using the right-click explorer menu.

       --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 possi‐
              ble.  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 config‐
              uration is being run as a service.

              exit-event is the name of a Windows global event object, and OpenVPN will continu‐
              ously monitor the state of this event object and exit when it becomes signaled.

              The second parameter indicates  the  initial  state  of  exit-event  and  normally
              defaults to 0.

              Multiple OpenVPN processes can be simultaneously executed with the same exit-event
              parameter.  In any case, the controlling process can  signal  exit-event,  causing
              all such OpenVPN processes to exit.

              When  executing  an  OpenVPN  process  using the --service directive, OpenVPN will
              probably not have a console window to output status/error messages,  therefore  it
              is useful to use --log or --log-append to write these messages to a file.

       --show-adapters
              (Standalone)  Show  available  TAP-Win32  adapters which can be selected using the
              --dev-node option.  On non-Windows systems, the ifconfig(8) command provides simi‐
              lar functionality.

       --allow-nonadmin [TAP-adapter]
              (Standalone) Set TAP-adapter to allow access from non-administrative accounts.  If
              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.

       --show-valid-subnets
              (Standalone) Show valid subnets for --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 mid‐
              dle two addresses of a /30 subnet (netmask 255.255.255.252).

       --show-net
              (Standalone) Show OpenVPN's view of the system routing table and  network  adapter
              list.

   PKCS#11 Standalone Options:
       --show-pkcs11-ids provider [cert_private]
              (Standalone) Show PKCS#11 token object list. Specify cert_private as 1 if certifi‐
              cates are stored as private objects.

              --verb option can be used BEFORE this option to produce debugging information.

SCRIPTING AND ENVIRONMENTAL VARIABLES
       OpenVPN exports a series of environmental variables for use by user-defined scripts.

   Script Order of Execution
       --up   Executed after TCP/UDP socket bind and TUN/TAP open.

       --tls-verify
              Executed when we have a still untrusted remote peer.

       --ipchange
              Executed after connection authentication, or remote IP address change.

       --client-connect
              Executed in --mode server mode immediately after client authentication.

       --route-up
              Executed after connection authentication, either immediately after, or some number
              of seconds after as defined by the --route-delay option.

       --client-disconnect
              Executed in --mode server mode on client instance shutdown.

       --down Executed after TCP/UDP and TUN/TAP close.

       --learn-address
              Executed  in  --mode  server mode whenever an IPv4 address/route or MAC address is
              added to OpenVPN's internal routing table.

       --auth-user-pass-verify
              Executed in --mode server mode on new client connections, when the client is still
              untrusted.

   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  con‐
       verted to underbar ('_').

       Q: Why is string remapping necessary?

       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.

       Q: Can string remapping be disabled?

       A:  Yes,  by  using  the --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:

       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.

       Common Names: Alphanumeric, underbar ('_'), dash ('-'), dot ('.'), and at ('@').

       --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.

       --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.

       --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.

       Environmental variable names: Alphanumeric or underbar ('_').

       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 ('_').

   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.

       bytes_received
              Total  number of bytes received from client during VPN session.  Set prior to exe‐
              cution of the --client-disconnect script.

       bytes_sent
              Total number of bytes sent to client during VPN session.  Set prior  to  execution
              of the --client-disconnect script.

       common_name
              The  X509  common  name  of  an  authenticated  client.  Set prior to execution of
              --client-connect, --client-disconnect, and --auth-user-pass-verify scripts.

       config Name of first --config file.  Set on program initiation and reset on SIGHUP.

       daemon Set to "1" if the --daemon directive is specified, or "0" otherwise.  Set on  pro‐
              gram initiation and reset on SIGHUP.

       daemon_log_redirect
              Set  to  "1"  if the --log or --log-append directives are specified, or "0" other‐
              wise.  Set on program initiation and reset on SIGHUP.

       dev    The actual name of the TUN/TAP device, including a unit number if it exists.   Set
              prior to --up or --down script execution.

       foreign_option_{n}
              An  option  pushed via --push to a client which does not natively support it, such
              as --dhcp-option on a non-Windows system, will be recorded to  this  environmental
              variable sequence prior to --up script execution.

       ifconfig_broadcast
              The  broadcast  address for the virtual ethernet segment which is derived from the
              --ifconfig option when --dev tap is used.  Set prior to OpenVPN calling the ifcon‐
              fig or netsh (windows version of ifconfig) commands which normally occurs prior to
              --up script execution.

       ifconfig_local
              The local VPN endpoint IP address specified in the --ifconfig option (first param‐
              eter).   Set  prior  to  OpenVPN calling the ifconfig or netsh (windows version of
              ifconfig) commands which normally occurs prior to --up script execution.

       ifconfig_remote
              The remote VPN endpoint IP address specified  in  the  --ifconfig  option  (second
              parameter)  when  --dev tun is used.  Set prior to OpenVPN calling the ifconfig or
              netsh (windows version of ifconfig) commands which normally occurs prior  to  --up
              script execution.

       ifconfig_netmask
              The  subnet  mask  of the virtual ethernet segment that is specified as the second
              parameter to --ifconfig when --dev tap is being used.  Set prior to OpenVPN  call‐
              ing  the  ifconfig  or netsh (windows version of ifconfig) commands which normally
              occurs prior to --up script execution.

       ifconfig_pool_local_ip
              The local virtual IP address for the TUN/TAP tunnel taken from an  --ifconfig-push
              directive  if  specified,  or  otherwise from the ifconfig pool (controlled by the
              --ifconfig-pool config file directive).  Only set for  --dev  tun  tunnels.   This
              option  is  set  on  the  server  prior  to  execution of the --client-connect and
              --client-disconnect scripts.

       ifconfig_pool_netmask
              The virtual IP netmask for the TUN/TAP tunnel taken from an --ifconfig-push direc‐
              tive if specified, or otherwise from the ifconfig pool (controlled by the --ifcon‐
              fig-pool config file directive).  Only set for --dev tap tunnels.  This option  is
              set  on the server prior to execution of the --client-connect and --client-discon‐
              nect scripts.

       ifconfig_pool_remote_ip
              The remote virtual IP address for the TUN/TAP tunnel taken from an --ifconfig-push
              directive  if  specified,  or  otherwise from the ifconfig pool (controlled by the
              --ifconfig-pool config file directive).  This option is set on the server prior to
              execution of the --client-connect and --client-disconnect scripts.

       link_mtu
              The maximum packet size (not including the IP header) of tunnel data in UDP tunnel
              transport mode.  Set prior to --up or --down script execution.

       local  The --local parameter.  Set on program initiation and reset on SIGHUP.

       local_port
              The local port number, specified by --port or --lport.  Set on program  initiation
              and reset on SIGHUP.

       password
              The  password provided by a connecting client.  Set prior to --auth-user-pass-ver‐
              ify script execution only when the via-env modifier is specified, and deleted from
              the environment after the script returns.

       proto  The --proto parameter.  Set on program initiation and reset on SIGHUP.

       remote_{n}
              The --remote parameter.  Set on program initiation and reset on SIGHUP.

       remote_port_{n}
              The remote port number, specified by --port or --rport.  Set on program initiation
              and reset on SIGHUP.

       route_net_gateway
              The pre-existing default IP gateway in the system routing  table.   Set  prior  to
              --up script execution.

       route_vpn_gateway
              The  default  gateway used by --route options, as specified in either the --route-
              gateway option or the second parameter to --ifconfig when --dev tun is  specified.
              Set prior to --up script execution.

       route_{parm}_{n}
              A  set of variables which define each route to be added, and are set prior to --up
              script execution.

              parm will be one of "network", "netmask", "gateway", or "metric".

              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 config‐
              uration file.

       peer_cert
              Temporary file name containing the client certificate upon connection.  Useful  in
              conjunction with --tls-verify

       script_context
              Set  to  "init" or "restart" prior to up/down script execution.  For more informa‐
              tion, see documentation for --up.

       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: up, down, ipchange, route-up, tls-verify,
              auth-user-pass-verify, client-connect, client-disconnect, or learn-address.

       signal The reason for exit or restart.  Can be one of sigusr1, sighup,  sigterm,  sigint,
              inactive  (controlled  by --inactive option), ping-exit (controlled by --ping-exit
              option), ping-restart  (controlled  by  --ping-restart  option),  connection-reset
              (triggered  on  TCP  connection  reset), error, or unknown (unknown signal).  This
              variable is set just prior to down script execution.

       time_ascii
              Client connection timestamp, formatted as a human-readable time string.  Set prior
              to execution of the --client-connect script.

       time_duration
              The  duration  (in seconds) of the client session which is now disconnecting.  Set
              prior to execution of the --client-disconnect script.

       time_unix
              Client connection timestamp, formatted as a unix  integer  date/time  value.   Set
              prior to execution of the --client-connect script.

       tls_id_{n}
              A  series  of certificate fields from the remote peer, where n is the verification
              level.  Only set for TLS connections.  Set  prior  to  execution  of  --tls-verify
              script.

       tls_serial_{n}
              The  serial number of the certificate from the remote peer, where n is the verifi‐
              cation level.  Only set for TLS connections.  Set prior to execution of --tls-ver‐
              ify 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  con‐
              trib/OCSP_check/OCSP_check.sh script for an example.

       tun_mtu
              The MTU of the TUN/TAP device.  Set prior to --up or --down script execution.

       trusted_ip
              Actual  IP address of connecting client or peer which has been authenticated.  Set
              prior  to  execution  of  --ipchange,  --client-connect,  and  --client-disconnect
              scripts.

       trusted_port
              Actual port number of connecting client or peer which has been authenticated.  Set
              prior  to  execution  of  --ipchange,  --client-connect,  and  --client-disconnect
              scripts.

       untrusted_ip
              Actual  IP  address  of connecting client or peer which has not been authenticated
              yet.  Sometimes used to nmap the connecting  host  in  a  --tls-verify  script  to
              ensure  it  is  firewalled  properly.   Set prior to execution of --tls-verify and
              --auth-user-pass-verify scripts.

       untrusted_port
              Actual port number of connecting client or peer which has not  been  authenticated
              yet.  Set prior to execution of --tls-verify and --auth-user-pass-verify scripts.

       username
              The  username provided by a connecting client.  Set prior to --auth-user-pass-ver‐
              ify script execution only when the via-env modifier is specified.

       X509_{n}_{subject_field}
              An X509 subject field from the remote peer certificate, where n is  the  verifica‐
              tion level.  Only set for TLS connections.  Set prior to execution of --tls-verify
              script.  This variable is similar to 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.

                  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

SIGNALS
       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.

       SIGUSR1
              Like 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 pre‐
              serve most recently authenticated remote IP address/port based  on  --persist-tun,
              --persist-key,  --persist-local-ip,  and  --persist-remote-ip options respectively
              (see above).

              This signal may also be internally generated by a timeout condition,  governed  by
              the --ping-restart option.

              This signal, when combined with --persist-remote-ip, may be sent when the underly‐
              ing 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 --ipchange above for more
              information.

       SIGUSR2
              Causes OpenVPN to display its current statistics (to the syslog file  if  --daemon
              is used, or stdout otherwise).

       SIGINT, SIGTERM
              Causes OpenVPN to exit gracefully.

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: mknod /dev/net/tun c 10 200

       Load driver: modprobe tun

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.

   TUN/TAP Setup:
       If you are using Linux 2.4 or higher, make the tun device node and load the tun module:

              mknod /dev/net/tun c 10 200

              modprobe tun

       If you installed from RPM, the 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 http://openvpn.net/install.html for more
       information.

   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 --ping 15 to each of the 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:

              iptables -A INPUT -i tun+ -j ACCEPT

       See the firewalls section below for more information on  configuring  firewalls  for  use
       with OpenVPN.

   VPN Address Setup:
       For  purposes of our example, our two machines will be called may.kg and june.kg.  If you
       are constructing a VPN over the internet, then replace may.kg and june.kg with the inter‐
       net  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 con‐
       nect to june.kg via ssh without using the VPN (since ssh has its own  built-in  security)
       you  would use the command ssh june.kg.  However in the same scenario, you could also use
       the command 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 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.

   Example 1: A simple tunnel without security
       On may:

              openvpn --remote june.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 9

       On june:

              openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --verb 9

       Now verify the tunnel is working by pinging across the tunnel.

       On may:

              ping 10.4.0.2

       On june:

              ping 10.4.0.1

       The --verb 9 option will produce verbose output, similar to the tcpdump(8) program.  Omit
       the --verb 9 option to have OpenVPN run quietly.

   Example 2: A tunnel with static-key security (i.e. using a pre-shared secret)
       First build a static key on may.

              openvpn --genkey --secret key

       This command will build a random key file called key (in ascii format).  Now copy key  to
       june over a secure medium such as by using the scp(1) program.

       On may:

              openvpn --remote june.kg --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --verb 5 --secret
              key

       On june:

              openvpn --remote may.kg --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --verb 5  --secret
              key

       Now verify the tunnel is working by pinging across the tunnel.

       On may:

              ping 10.4.0.2

       On june:

              ping 10.4.0.1

   Example 3: A tunnel with full TLS-based security
       For  this test, we will designate may as the TLS client and june as the TLS server.  Note
       that client or server designation only has meaning for the TLS subsystem. It has no bear‐
       ing 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
       --cert is discussed for more info).  Then construct Diffie Hellman parameters (see  above
       where  --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  certifi‐
       cates/public-keys, the .key files are private keys, and ca.crt is a certification author‐
       ity who has signed both client.crt and server.crt.  For Diffie Hellman parameters you can
       use  the included file dh1024.pem.  Note that all client, server, and certificate author‐
       ity certificates and keys included in the OpenVPN distribution are totally  insecure  and
       should be used for testing only.

       On may:

              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

       On june:

              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

       Now verify the tunnel is working by pinging across the tunnel.

       On may:

              ping 10.4.0.2

       On june:

              ping 10.4.0.1

       Notice  the  --reneg-sec  60 option we used above.  That tells OpenVPN to renegotiate the
       data channel keys every minute.  Since we used --verb 5 above, you will see status infor‐
       mation on each new key negotiation.

       For  production  operations,  a  key renegotiation interval of 60 seconds is probably too
       frequent.  Omit the --reneg-sec 60 option to  use  OpenVPN's  default  key  renegotiation
       interval of one hour.

   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.

       First, ensure that IP forwarding is enabled on both peers.  On Linux, enable routing:

              echo 1 > /proc/sys/net/ipv4/ip_forward

       and enable TUN packet forwarding through the firewall:

              iptables -A FORWARD -i tun+ -j ACCEPT

       On may:

              route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.4.0.2

       On june:

              route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.4.0.1

       Now  any machine on the 10.0.0.0/24 subnet can access any machine on the 10.0.1.0/24 sub‐
       net over the secure tunnel (or vice versa).

       In a production environment, you could put the route command(s) in  a  shell  script  and
       execute with the --up option.

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+:

              iptables -A INPUT -p udp -s 1.2.3.4 --dport 1194 -j ACCEPT

       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:

              iptables -A INPUT -p udp --dport 1194 -j ACCEPT

       would be adequate and would not render the host inflexible with respect to its peer  hav‐
       ing 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 --ping n, OpenVPN will be guaranteed to send a
       packet to its peer at least once every n seconds.  If n is less than the  stateful  fire‐
       wall  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:

              iptables -A INPUT -i tun+ -j ACCEPT

       to allow input packets from tun devices,

              iptables -A FORWARD -i tun+ -j ACCEPT

       to  allow input packets from tun devices to be forwarded to other hosts on the local net‐
       work,

              iptables -A INPUT -i tap+ -j ACCEPT

       to allow input packets from tap devices, and

              iptables -A FORWARD -i tap+ -j ACCEPT

       to allow input packets from tap devices to be forwarded to other hosts on the local  net‐
       work.

       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.

FAQ
       http://openvpn.net/faq.html

HOWTO
       For a more comprehensive guide to setting up OpenVPN in a  production  setting,  see  the
       OpenVPN HOWTO at http://openvpn.net/howto.html

PROTOCOL
       For a description of OpenVPN's underlying protocol, see http://openvpn.net/security.html

WEB
       OpenVPN's web site is at 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.

BUGS
       Report all bugs to the OpenVPN team <info@openvpn.net>.

SEE ALSO
       dhcpcd(8), ifconfig(8), openssl(1), route(8), scp(1) ssh(1)

NOTES
       This product includes software developed by the OpenSSL Project ( http://www.openssl.org/
       )

       For more information on the TLS protocol, see http://www.ietf.org/rfc/rfc2246.txt

       For  more  information  on  the  LZO  real-time  compression library see http://www.ober‐
       humer.com/opensource/lzo/

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 ver‐
       sion 2 as published by the Free Software Foundation.

AUTHORS
       James Yonan <jim@yonan.net>



                                        17 November 2008                              openvpn(8)
Last modified 5 years ago Last modified on 06/29/12 13:06:33