summaryrefslogtreecommitdiff
path: root/app/openvpn/doc/management-notes.txt
diff options
context:
space:
mode:
authorParménides GV <parmegv@sdf.org>2014-04-08 12:04:17 +0200
committerParménides GV <parmegv@sdf.org>2014-04-08 12:04:17 +0200
commit3c3421afd8f74a3aa8d1011de07a8c18f9549210 (patch)
tree49d52344661c23d7268b8ea69466a1cfef04bf8b /app/openvpn/doc/management-notes.txt
parent5fc5d37330d3535a0f421632694d1e7918fc22d7 (diff)
Rename app->bitmask_android
This way, gradle commands generate apks correctly named.
Diffstat (limited to 'app/openvpn/doc/management-notes.txt')
-rw-r--r--app/openvpn/doc/management-notes.txt1039
1 files changed, 0 insertions, 1039 deletions
diff --git a/app/openvpn/doc/management-notes.txt b/app/openvpn/doc/management-notes.txt
deleted file mode 100644
index ef39b855..00000000
--- a/app/openvpn/doc/management-notes.txt
+++ /dev/null
@@ -1,1039 +0,0 @@
-OpenVPN Management Interface Notes
-----------------------------------
-
-The OpenVPN Management interface allows OpenVPN to
-be administratively controlled from an external program via
-a TCP or unix domain socket.
-
-The interface has been specifically designed for developers
-who would like to programmatically or remotely control
-an OpenVPN daemon, and can be used when OpenVPN is running
-as a client or server.
-
-The management interface is implemented using a client/server TCP
-connection or unix domain socket where OpenVPN will listen on a
-provided IP address and port for incoming management client connections.
-
-The management protocol is currently cleartext without an explicit
-security layer. For this reason, it is recommended that the
-management interface either listen on a unix domain socket,
-localhost (127.0.0.1), or on the local VPN address. It's possible
-to remotely connect to the management interface over the VPN itself,
-though some capabilities will be limited in this mode, such as the
-ability to provide private key passwords.
-
-The management interface is enabled in the OpenVPN
-configuration file using the following directive:
-
---management
-
-See the man page for documentation on this and related
-directives.
-
-Once OpenVPN has started with the management layer enabled,
-you can telnet to the management port (make sure to use
-a telnet client which understands "raw" mode).
-
-Once connected to the management port, you can use
-the "help" command to list all commands.
-
-COMMAND -- bytecount
---------------------
-
-The bytecount command is used to request real-time notification
-of OpenVPN bandwidth usage.
-
-Command syntax:
-
- bytecount n (where n > 0) -- set up automatic notification of
- bandwidth usage once every n seconds
- bytecount 0 -- turn off bytecount notifications
-
-If OpenVPN is running as a client, the bytecount notification
-will look like this:
-
- >BYTECOUNT:{BYTES_IN},{BYTES_OUT}
-
-BYTES_IN is the number of bytes that have been received from
-the server and BYTES_OUT is the number of bytes that have been
-sent to the server.
-
-If OpenVPN is running as a server, the bytecount notification
-will look like this:
-
- >BYTECOUNT_CLI:{CID},{BYTES_IN},{BYTES_OUT}
-
-CID is the Client ID, BYTES_IN is the number of bytes that have
-been received from the client and BYTES_OUT is the number of
-bytes that have been sent to the client.
-
-Note that when the bytecount command is used on the server, every
-connected client will report its bandwidth numbers once every n
-seconds.
-
-When the client disconnects, the final bandwidth numbers will be
-placed in the 'bytes_received' and 'bytes_sent' environmental variables
-as included in the >CLIENT:DISCONNECT notification.
-
-COMMAND -- echo
----------------
-
-The echo capability is used to allow GUI-specific
-parameters to be either embedded in the OpenVPN config file
-or pushed to an OpenVPN client from a server.
-
-Command examples:
-
- echo on -- turn on real-time notification of echo messages
- echo all -- print the current echo history list
- echo off -- turn off real-time notification of echo messages
- echo on all -- atomically enable real-time notification,
- plus show any messages in history buffer
-
-For example, suppose you are developing a OpenVPN GUI and
-you want to give the OpenVPN server the ability to ask
-the GUI to forget any saved passwords.
-
-In the OpenVPN server config file, add:
-
- push "echo forget-passwords"
-
-When the OpenVPN client receives its pulled list of directives
-from the server, the "echo forget-passwords" directive will
-be in the list, and it will cause the management interface
-to save the "forget-passwords" string in its list of echo
-parameters.
-
-The management client can use "echo all" to output the full
-list of echoed parameters, "echo on" to turn on real-time
-notification of echoed parameters via the ">ECHO:" prefix,
-or "echo off" to turn off real-time notification.
-
-When the GUI connects to the OpenVPN management socket, it
-can issue an "echo all" command, which would produce output
-like this:
-
- 1101519562,forget-passwords
- END
-
-Essentially the echo command allowed us to pass parameters from
-the OpenVPN server to the OpenVPN client, and then to the
-management client (such as a GUI). The large integer is the
-unix date/time when the echo parameter was received.
-
-If the management client had issued the command "echo on",
-it would have enabled real-time notifications of echo
-parameters. In this case, our "forget-passwords" message
-would be output like this:
-
- >ECHO:1101519562,forget-passwords
-
-Like the log command, the echo command can atomically show
-history while simultaneously activating real-time updates:
-
- echo on all
-
-The size of the echo buffer is currently hardcoded to 100
-messages.
-
-COMMAND -- exit, quit
----------------------
-
-Close the managment session, and resume listening on the
-management port for connections from other clients. Currently,
-the OpenVPN daemon can at most support a single management client
-any one time.
-
-COMMAND -- help
----------------
-
-Print a summary of commands.
-
-COMMAND -- hold
----------------
-
-The hold command can be used to manipulate the hold flag,
-or release OpenVPN from a hold state.
-
-If the hold flag is set on initial startup or
-restart, OpenVPN will hibernate prior to initializing
-the tunnel until the management interface receives
-a "hold release" command.
-
-The --management-hold directive of OpenVPN can be used
-to start OpenVPN with the hold flag set.
-
-The hold flag setting is persistent and will not
-be reset by restarts.
-
-OpenVPN will indicate that it is in a hold state by
-sending a real-time notification to the management
-client:
-
- >HOLD:Waiting for hold release
-
-Command examples:
-
- hold -- show current hold flag, 0=off, 1=on.
- hold on -- turn on hold flag so that future restarts
- will hold.
- hold off -- turn off hold flag so that future restarts will
- not hold.
- hold release -- leave hold state and start OpenVPN, but
- do not alter the current hold flag setting.
-
-COMMAND -- kill
----------------
-
-In server mode, kill a particlar client instance.
-
-Command examples:
-
- kill Test-Client -- kill the client instance having a
- common name of "Test-Client".
- kill 1.2.3.4:4000 -- kill the client instance having a
- source address and port of 1.2.3.4:4000
-
-Use the "status" command to see which clients are connected.
-
-COMMAND -- log
---------------
-
-Show the OpenVPN log file. Only the most recent n lines
-of the log file are cached by the management interface, where
-n is controlled by the OpenVPN --management-log-cache directive.
-
-Command examples:
-
- log on -- Enable real-time output of log messages.
- log all -- Show currently cached log file history.
- log on all -- Atomically show all currently cached log file
- history then enable real-time notification of
- new log file messages.
- log off -- Turn off real-time notification of log messages.
- log 20 -- Show the most recent 20 lines of log file history.
-
-Real-time notification format:
-
-Real-time log messages begin with the ">LOG:" prefix followed
-by the following comma-separated fields:
-
- (a) unix integer date/time,
- (b) zero or more message flags in a single string:
- I -- informational
- F -- fatal error
- N -- non-fatal error
- W -- warning
- D -- debug, and
- (c) message text.
-
-COMMAND -- mute
----------------
-
-Change the OpenVPN --mute parameter. The mute parameter is
-used to silence repeating messages of the same message
-category.
-
-Command examples:
-
- mute 40 -- change the mute parameter to 40
- mute -- show the current mute setting
-
-COMMAND -- net
---------------
-
-(Windows Only) Produce output equivalent to the OpenVPN
---show-net directive. The output includes OpenVPN's view
-of the system network adapter list and routing table based
-on information returned by the Windows IP helper API.
-
-COMMAND -- pid
---------------
-
-Shows the process ID of the current OpenVPN process.
-
-COMMAND -- password and username
---------------------------------
-
- The password command is used to pass passwords to OpenVPN.
-
- If OpenVPN is run with the --management-query-passwords
- directive, it will query the management interface for RSA
- private key passwords and the --auth-user-pass
- username/password.
-
- When OpenVPN needs a password from the management interface,
- it will produce a real-time ">PASSWORD:" message.
-
- Example 1:
-
- >PASSWORD:Need 'Private Key' password
-
- OpenVPN is indicating that it needs a password of type
- "Private Key".
-
- The management client should respond to this query as follows:
-
- password "Private Key" foo
-
- Example 2:
-
- >PASSWORD:Need 'Auth' username/password
-
- OpenVPN needs a --auth-user-pass password. The management
- client should respond:
-
- username "Auth" foo
- password "Auth" bar
-
- The username/password itself can be in quotes, and special
- characters such as double quote or backslash must be escaped,
- for example,
-
- password "Private Key" "foo\"bar"
-
- The escaping rules are the same as for the config file.
- See the "Command Parsing" section below for more info.
-
- The PASSWORD real-time message type can also be used to
- indicate password or other types of authentication failure:
-
- Example 3: The private key password is incorrect and OpenVPN
- is exiting:
-
- >PASSWORD:Verification Failed: 'Private Key'
-
- Example 4: The --auth-user-pass username/password failed,
- and OpenVPN is exiting:
-
- >PASSWORD:Verification Failed: 'Auth'
-
- Example 5: The --auth-user-pass username/password failed,
- and the server provided a custom client-reason-text string
- using the client-deny server-side management interface command.
-
- >PASSWORD:Verification Failed: 'custom server-generated string'
-
-COMMAND -- forget-passwords
----------------------------
-
-The forget-passwords command will cause the daemon to forget passwords
-entered during the session.
-
-Command example:
-
- forget-passwords -- forget passwords entered so far.
-
-COMMAND -- signal
------------------
-
-The signal command will send a signal to the OpenVPN daemon.
-The signal can be one of SIGHUP, SIGTERM, SIGUSR1, or SIGUSR2.
-
-Command example:
-
- signal SIGUSR1 -- send a SIGUSR1 signal to daemon
-
-COMMAND -- state
-----------------
-
-Show the current OpenVPN state, show state history, or
-enable real-time notification of state changes.
-
-These are the OpenVPN states:
-
-CONNECTING -- OpenVPN's initial state.
-WAIT -- (Client only) Waiting for initial response
- from server.
-AUTH -- (Client only) Authenticating with server.
-GET_CONFIG -- (Client only) Downloading configuration options
- from server.
-ASSIGN_IP -- Assigning IP address to virtual network
- interface.
-ADD_ROUTES -- Adding routes to system.
-CONNECTED -- Initialization Sequence Completed.
-RECONNECTING -- A restart has occurred.
-EXITING -- A graceful exit is in progress.
-
-Command examples:
-
- state -- Print current OpenVPN state.
- state on -- Enable real-time notification of state changes.
- state off -- Disable real-time notification of state changes.
- state all -- Print current state history.
- state 3 -- Print the 3 most recent state transitions.
- state on all -- Atomically show state history while at the
- same time enable real-time state notification
- of future state transitions.
-
-The output format consists of 4 comma-separated parameters:
- (a) the integer unix date/time,
- (b) the state name,
- (c) optional descriptive string (used mostly on RECONNECTING
- and EXITING to show the reason for the disconnect),
- (d) optional TUN/TAP local IP address (shown for ASSIGN_IP
- and CONNECTED), and
- (e) optional address of remote server (OpenVPN 2.1 or higher).
-
-Real-time state notifications will have a ">STATE:" prefix
-prepended to them.
-
-COMMAND -- status
------------------
-
-Show current daemon status information, in the same format as
-that produced by the OpenVPN --status directive.
-
-Command examples:
-
-status -- Show status information using the default status
- format version.
-
-status 3 -- Show status information using the format of
- --status-version 3.
-
-COMMAND -- username
--------------------
-
-See the "password" section above.
-
-COMMAND -- verb
----------------
-
-Change the OpenVPN --verb parameter. The verb parameter
-controls the output verbosity, and may range from 0 (no output)
-to 15 (maximum output). See the OpenVPN man page for additional
-info on verbosity levels.
-
-Command examples:
-
- verb 4 -- change the verb parameter to 4
- mute -- show the current verb setting
-
-COMMAND -- version
-------------------
-
-Show the current OpenVPN and Management Interface versions.
-
-
-COMMAND -- auth-retry
----------------------
-
-Set the --auth-retry setting to control how OpenVPN responds to
-username/password authentication errors. See the manual page
-for more info.
-
-Command examples:
-
- auth-retry interact -- Don't exit when bad username/passwords are entered.
- Query for new input and retry.
-
-COMMAND -- needok (OpenVPN 2.1 or higher)
-------------------------------------------
-
-Confirm a ">NEED-OK" real-time notification, normally used by
-OpenVPN to block while waiting for a specific user action.
-
-Example:
-
- OpenVPN needs the user to insert a cryptographic token,
- so it sends a real-time notification:
-
- >NEED-OK:Need 'token-insertion-request' confirmation MSG:Please insert your cryptographic token
-
- The management client, if it is a GUI, can flash a dialog
- box containing the text after the "MSG:" marker to the user.
- When the user acknowledges the dialog box,
- the management client can issue this command:
-
- needok token-insertion-request ok
- or
- needok token-insertion-request cancel
-
-COMMAND -- needstr (OpenVPN 2.1 or higher)
--------------------------------------------
-
-Confirm a ">NEED-STR" real-time notification, normally used by
-OpenVPN to block while waiting for a specific user input.
-
-Example:
-
- OpenVPN needs the user to specify some input, so it sends a
- real-time notification:
-
- >NEED-STR:Need 'name' input MSG:Please specify your name
-
- The management client, if it is a GUI, can flash a dialog
- box containing the text after the "MSG:" marker to the user.
- When the user acknowledges the dialog box,
- the management client can issue this command:
-
- needstr name "John"
-
-COMMAND -- pkcs11-id-count (OpenVPN 2.1 or higher)
----------------------------------------------------
-
-Retrieve available number of certificates.
-
-Example:
-
- pkcs11-id-count
- >PKCS11ID-COUNT:5
-
-COMMAND -- pkcs11-id-get (OpenVPN 2.1 or higher)
--------------------------------------------------
-
-Retrieve certificate by index, the ID string should be provided
-as PKCS#11 identity, the blob is BASE64 encoded certificate.
-
-Example:
-
- pkcs11-id-get 1
- PKCS11ID-ENTRY:'1', ID:'<snip>', BLOB:'<snip>'
-
-COMMAND -- client-auth (OpenVPN 2.1 or higher)
------------------------------------------------
-
-Authorize a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request and specify
-"client-connect" configuration directives in a subsequent text block.
-
-The OpenVPN server should have been started with the
---management-client-auth directive so that it will ask the management
-interface to approve client connections.
-
-
- client-auth {CID} {KID}
- line_1
- line_2
- ...
- line_n
- END
-
-CID,KID -- client ID and Key ID. See documentation for ">CLIENT:"
-notification for more info.
-
-line_1 to line_n -- client-connect configuration text block, as would be
-returned by a --client-connect script. The text block may be null, with
-"END" immediately following the "client-auth" line (using a null text
-block is equivalent to using the client-auth-nt command).
-
-A client-connect configuration text block contains OpenVPN directives
-that will be applied to the client instance object representing a newly
-connected client.
-
-COMMAND -- client-auth-nt (OpenVPN 2.1 or higher)
---------------------------------------------------
-
-Authorize a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request without specifying
-client-connect configuration text.
-
-The OpenVPN server should have been started with the
---management-client-auth directive so that it will ask the management
-interface to approve client connections.
-
- client-auth-nt {CID} {KID}
-
-CID,KID -- client ID and Key ID. See documentation for ">CLIENT:"
-notification for more info.
-
-COMMAND -- client-deny (OpenVPN 2.1 or higher)
------------------------------------------------
-
-Deny a ">CLIENT:CONNECT" or ">CLIENT:REAUTH" request.
-
- client-deny {CID} {KID} "reason-text" ["client-reason-text"]
-
-CID,KID -- client ID and Key ID. See documentation for ">CLIENT:"
-notification for more info.
-
-reason-text: a human-readable message explaining why the authentication
-request was denied. This message will be output to the OpenVPN log
-file or syslog.
-
-client-reason-text: a message that will be sent to the client as
-part of the AUTH_FAILED message.
-
-Note that client-deny denies a specific Key ID (pertaining to a
-TLS renegotiation). A client-deny command issued in response to
-an initial TLS key negotiation (notified by ">CLIENT:CONNECT") will
-terminate the client session after returning "AUTH-FAILED" to the client.
-On the other hand, a client-deny command issued in response to
-a TLS renegotiation (">CLIENT:REAUTH") will invalidate the renegotiated
-key, however the TLS session associated with the currently active
-key will continue to live for up to --tran-window seconds before
-expiration.
-
-To immediately kill a client session, use "client-kill".
-
-COMMAND -- client-kill (OpenVPN 2.1 or higher)
------------------------------------------------
-
-Immediately kill a client instance by CID.
-
- client-kill {CID}
-
-CID -- client ID. See documentation for ">CLIENT:" notification for more
-info.
-
-COMMAND -- client-pf (OpenVPN 2.1 or higher)
----------------------------------------------
-
-Push a packet filter file to a specific client.
-
-The OpenVPN server should have been started with the
---management-client-pf directive so that it will require that
-VPN tunnel packets sent or received by client instances must
-conform to that client's packet filter configuration.
-
- client-pf {CID}
- line_1
- line_2
- ...
- line_n
- END
-
-CID -- client ID. See documentation for ">CLIENT:" notification for
-more info.
-
-line_1 to line_n -- the packet filter configuration file for this
-client.
-
-Packet filter file grammar:
-
- [CLIENTS DROP|ACCEPT]
- {+|-}common_name1
- {+|-}common_name2
- . . .
- [SUBNETS DROP|ACCEPT]
- {+|-}subnet1
- {+|-}subnet2
- . . .
- [END]
-
- Subnet: IP-ADDRESS | IP-ADDRESS/NUM_NETWORK_BITS | "unknown"
-
- CLIENTS refers to the set of clients (by their common-name) which
- this instance is allowed ('+') to connect to, or is excluded ('-')
- from connecting to. Note that in the case of client-to-client
- connections, such communication must be allowed by the packet filter
- configuration files of both clients AND the --client-to-client
- directive must have been specified in the OpenVPN server config.
-
- SUBNETS refers to IP addresses or IP address subnets which this
- client instance may connect to ('+') or is excluded ('-') from
- connecting to, and applies to IPv4 and ARP packets. The special
- "unknown" tag refers to packets of unknown type, i.e. a packet that
- is not IPv4 or ARP.
-
- DROP or ACCEPT defines default policy when there is no explicit match
- for a common-name or subnet. The [END] tag must exist.
-
- Notes:
-
- * The SUBNETS section currently only supports IPv4 addresses and
- subnets.
-
- * A given client or subnet rule applies to both incoming and
- outgoing packets.
-
- * The CLIENTS list is order-invariant. Because the list is stored
- as a hash-table, the order of the list does not affect its function.
-
- * The SUBNETS table is scanned sequentially, and the first item to
- match is chosen. Therefore the SUBNETS table is NOT order-invariant.
-
- * No client-to-client communication is allowed unless the
- --client-to-client configuration directive is enabled AND
- the CLIENTS list of BOTH clients allows the communication.
-
-Example packet filter spec, as transmitted to the management interface:
-
- client-pf 42
- [CLIENTS ACCEPT]
- -accounting
- -enigma
- [SUBNETS DROP]
- -10.46.79.9
- +10.0.0.0/8
- [END]
- END
-
-The above example sets the packet filter policy for the client
-identified by CID=42. This client may connect to all other clients
-except those having a common name of "accounting" or "enigma".
-The client may only interact with external IP addresses in the
-10.0.0.0/8 subnet, however access to 10.46.79.9 is specifically
-excluded.
-
-Another example packet filter spec, as transmitted to the
-management interface:
-
- client-pf 99
- [CLIENTS DENY]
- +public
- [SUBNETS ACCEPT]
- +10.10.0.1
- -10.0.0.0/8
- -unknown
- [END]
- END
-
-The above example sets the packet filter policy for the client
-identified by CID=99. This client may not connect to any other
-clients except those having a common name of "public". It may
-interact with any external IP address except those in the
-10.0.0.0/8 netblock. However interaction with one address in
-the 10.0.0.0/8 netblock is allowed: 10.10.0.1. Also, the client
-may not interact with external IP addresses using an "unknown"
-protocol (i.e. one that is not IPv4 or ARP).
-
-COMMAND -- remote (OpenVPN AS 2.1.5/OpenVPN 2.3 or higher)
---------------------------------------------
-
-Provide remote host/port in response to a >REMOTE notification
-(client only). Requires that the --management-query-remote
-directive is used.
-
- remote ACTION [HOST PORT]
-
-The "remote" command should only be given in response to a >REMOTE
-notification. For example, the following >REMOTE notification
-indicates that the client config file would ordinarily connect
-to vpn.example.com port 1194 (UDP):
-
- >REMOTE:vpn.example.com,1194,udp
-
-Now, suppose we want to override the host and port, connecting
-instead to vpn.otherexample.com port 1234. After receiving
-the above notification, use this command:
-
- remote MOD vpn.otherexample.com 1234
-
-To accept the same host and port as the client would ordinarily
-have connected to, use this command:
-
- remote ACCEPT
-
-To skip the current connection entry and advance to the next one,
-use this command:
-
- remote SKIP
-
-COMMAND -- proxy (OpenVPN 2.3 or higher)
---------------------------------------------
-
-Provide proxy server host/port and flags in response to a >PROXY
-notification (client only). Requires that the --management-query-proxy
-directive is used.
-
- proxy TYPE HOST PORT ["nct"]
-
-The "proxy" command must only be given in response to a >PROXY
-notification. Use the "nct" flag if you only want to allow
-non-cleartext auth with the proxy server. The following >PROXY
-notification indicates that the client config file would ordinarily
-connect to the first --remote configured, vpn.example.com using TCP:
-
- >PROXY:1,TCP,vpn.example.com
-
-Now, suppose we want to connect to the remote host using the proxy server
-proxy.intranet port 8080 with secure authentication only, if required.
-After receiving the above notification, use this command:
-
- proxy HTTP proxy.intranet 8080 nct
-
-You can also use the SOCKS keyword to pass a SOCKS server address, like:
-
- proxy SOCKS fe00::1 1080
-
-To accept connecting to the host and port directly, use this command:
-
- proxy NONE
-
-COMMAND -- rsa-sig (OpenVPN 2.3 or higher)
-------------------------------------------
-Provides support for external storage of the private key. Requires the
---management-external-key option. This option can be used instead of "key"
-in client mode, and allows the client to run without the need to load the
-actual private key. When the SSL protocol needs to perform an RSA sign
-operation, the data to be signed will be sent to the management interface
-via a notification as follows:
-
->RSA_SIGN:[BASE64_DATA]
-
-The management interface client should then sign BASE64_DATA
-using the private key and return the SSL signature as follows:
-
-rsa-sig
-[BASE64_SIG_LINE]
-.
-.
-.
-END
-
-Base64 encoded output of RSA_sign(NID_md5_sha1,... will provide a
-correct signature.
-
-This capability is intended to allow the use of arbitrary cryptographic
-service providers with OpenVPN via the management interface.
-
-
-OUTPUT FORMAT
--------------
-
-(1) Command success/failure indicated by "SUCCESS: [text]" or
- "ERROR: [text]".
-
-(2) For commands which print multiple lines of output,
- the last line will be "END".
-
-(3) Real-time messages will be in the form ">[source]:[text]",
- where source is "CLIENT", "ECHO", "FATAL", "HOLD", "INFO", "LOG",
- "NEED-OK", "PASSWORD", or "STATE".
-
-REAL-TIME MESSAGE FORMAT
-------------------------
-
-The OpenVPN management interface produces two kinds of
-output: (a) output from a command, or (b) asynchronous,
-real-time output which can be generated at any time.
-
-Real-time messages start with a '>' character in the first
-column and are immediately followed by a type keyword
-indicating the type of real-time message. The following
-types are currently defined:
-
-BYTECOUNT -- Real-time bandwidth usage notification, as enabled
- by "bytecount" command when OpenVPN is running as
- a client.
-
-BYTECOUNT_CLI -- Real-time bandwidth usage notification per-client,
- as enabled by "bytecount" command when OpenVPN is
- running as a server.
-
-CLIENT -- Notification of client connections and disconnections
- on an OpenVPN server. Enabled when OpenVPN is started
- with the --management-client-auth option. CLIENT
- notifications may be multi-line. See "The CLIENT
- notification" section below for detailed info.
-
-ECHO -- Echo messages as controlled by the "echo" command.
-
-FATAL -- A fatal error which is output to the log file just
- prior to OpenVPN exiting.
-
-HOLD -- Used to indicate that OpenVPN is in a holding state
- and will not start until it receives a
- "hold release" command.
-
-INFO -- Informational messages such as the welcome message.
-
-LOG -- Log message output as controlled by the "log" command.
-
-NEED-OK -- OpenVPN needs the end user to do something, such as
- insert a cryptographic token. The "needok" command can
- be used to tell OpenVPN to continue.
-
-NEED-STR -- OpenVPN needs information from end, such as
- a certificate to use. The "needstr" command can
- be used to tell OpenVPN to continue.
-
-PASSWORD -- Used to tell the management client that OpenVPN
- needs a password, also to indicate password
- verification failure.
-
-STATE -- Shows the current OpenVPN state, as controlled
- by the "state" command.
-
-The CLIENT notification
------------------------
-
-The ">CLIENT:" notification is enabled by the --management-client-auth
-OpenVPN configuration directive that gives the management interface client
-the responsibility to authenticate OpenVPN clients after their client
-certificate has been verified. CLIENT notifications may be multi-line, and
-the sequentiality of a given CLIENT notification, its associated environmental
-variables, and the terminating ">CLIENT:ENV,END" line are guaranteed to be
-atomic.
-
-CLIENT notification types:
-
-(1) Notify new client connection ("CONNECT") or existing client TLS session
- renegotiation ("REAUTH"). Information about the client is provided
- by a list of environmental variables which are documented in the OpenVPN
- man page. The environmental variables passed are equivalent to those
- that would be passed to an --auth-user-pass-verify script.
-
- >CLIENT:CONNECT|REAUTH,{CID},{KID}
- >CLIENT:ENV,name1=val1
- >CLIENT:ENV,name2=val2
- >CLIENT:ENV,...
- >CLIENT:ENV,END
-
-(2) Notify successful client authentication and session initiation.
- Called after CONNECT.
-
- >CLIENT:ESTABLISHED,{CID}
- >CLIENT:ENV,name1=val1
- >CLIENT:ENV,name2=val2
- >CLIENT:ENV,...
- >CLIENT:ENV,END
-
-(3) Notify existing client disconnection. The environmental variables passed
- are equivalent to those that would be passed to a --client-disconnect
- script.
-
- >CLIENT:DISCONNECT,{CID}
- >CLIENT:ENV,name1=val1
- >CLIENT:ENV,name2=val2
- >CLIENT:ENV,...
- >CLIENT:ENV,END
-
-(4) Notify that a particular virtual address or subnet
- is now associated with a specific client.
-
- >CLIENT:ADDRESS,{CID},{ADDR},{PRI}
-
-Variables:
-
-CID -- Client ID, numerical ID for each connecting client, sequence = 0,1,2,...
-KID -- Key ID, numerical ID for the key associated with a given client TLS session,
- sequence = 0,1,2,...
-PRI -- Primary (1) or Secondary (0) VPN address/subnet. All clients have at least
- one primary IP address. Secondary address/subnets are associated with
- client-specific "iroute" directives.
-ADDR -- IPv4 address/subnet in the form 1.2.3.4 or 1.2.3.0/255.255.255.0
-
-In the unlikely scenario of an extremely long-running OpenVPN server,
-CID and KID should be assumed to recycle to 0 after (2^32)-1, however this
-recycling behavior is guaranteed to be collision-free.
-
-Command Parsing
----------------
-
-The management interface uses the same command line lexical analyzer
-as is used by the OpenVPN config file parser.
-
-Whitespace is a parameter separator.
-
-Double quotation or single quotation characters ("", '') can be used
-to enclose parameters containing whitespace.
-
-Backslash-based shell escaping is performed, using the following
-mappings, when not in single quotations:
-
-\\ Maps to a single backslash character (\).
-\" Pass a literal doublequote character ("), don't
- interpret it as enclosing a parameter.
-\[SPACE] Pass a literal space or tab character, don't
- interpret it as a parameter delimiter.
-
-Challenge/Response Protocol
----------------------------
-
-The OpenVPN Challenge/Response Protocol allows an OpenVPN server to
-generate challenge questions that are shown to the user, and to see
-the user's responses to those challenges. Based on the responses, the
-server can allow or deny access.
-
-In this way, the OpenVPN Challenge/Response Protocol can be used
-to implement multi-factor authentication. Two different
-variations on the challenge/response protocol are supported: the
-"Dynamic" and "Static" protocols.
-
-The basic idea of Challenge/Response is that the user must enter an
-additional piece of information, in addition to the username and
-password, to successfully authenticate. Normally, this information
-is used to prove that the user posesses a certain key-like device
-such as cryptographic token or a particular mobile phone.
-
-Dynamic protocol:
-
-The OpenVPN dynamic challenge/response protocol works by returning
-a specially formatted error message after initial successful
-authentication. This error message contains the challenge question,
-and is formatted as such:
-
- CRV1:<flags>:<state_id>:<username_base64>:<challenge_text>
-
-flags: a series of optional, comma-separated flags:
- E : echo the response when the user types it
- R : a response is required
-
-state_id: an opaque string that should be returned to the server
- along with the response.
-
-username_base64 : the username formatted as base64
-
-challenge_text : the challenge text to be shown to the user
-
-Example challenge:
-
- CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN
-
-After showing the challenge_text and getting a response from the user
-(if R flag is specified), the client should submit the following
-auth creds back to the OpenVPN server:
-
-Username: [username decoded from username_base64]
-Password: CRV1::<state_id>::<response_text>
-
-Where state_id is taken from the challenge request and response_text
-is what the user entered in response to the challenge_text.
-If the R flag is not present, response_text may be the empty
-string.
-
-Example response (suppose the user enters "8675309" for the token PIN):
-
- Username: cr1 ("Y3Ix" base64 decoded)
- Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
-
-Static protocol:
-
-The static protocol differs from the dynamic protocol in that the
-challenge question and response field is given to the user in the
-initial username/password dialog, and the username, password, and
-response are delivered back to the server in a single transaction.
-
-The "static-challenge" directive is used to give the challenge text
-to OpenVPN and indicate whether or not the response should be echoed.
-
-When the "static-challenge" directive is used, the management
-interface will respond as such when credentials are needed:
-
- >PASSWORD:Need 'Auth' username/password SC:<ECHO>,<TEXT>
-
- ECHO: "1" if response should be echoed, "0" to not echo
- TEXT: challenge text that should be shown to the user to
- facilitate their response
-
-For example:
-
- >PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN
-
-The above notification indicates that OpenVPN needs a --auth-user-pass
-password plus a response to a static challenge ("Please enter token PIN").
-The "1" after the "SC:" indicates that the response should be echoed.
-
-The management interface client in this case should add the static
-challenge text to the auth dialog followed by a field for the user to
-enter a response. Then the client should pack the password and response
-together into an encoded password:
-
- username "Auth" foo
- password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>"
-
-For example, if the user entered "bar" as the password and 8675309
-as the PIN, the following management interface commands should be
-issued:
-
- username "Auth" foo
- password "Auth" "SCRV1:Zm9v:ODY3NTMwOQ=="
-
-Client-side support for challenge/response protocol:
-
-Currently, the Access Server client and standalone OpenVPN
-client support both static and dynamic challenge/response
-protocols. However, any OpenVPN client UI that drives OpenVPN
-via the management interface needs to add explicit support
-for the challenge/response protocol.