Сети‎ > ‎VPN‎ > ‎Параметры OpenVPN‎ > ‎


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 expands as follows:

mode server tls-server push "topology [topology]" if dev tun AND (topology == net30 OR topology == p2p): ifconfig if !nopool: ifconfig-pool route if client-to-client: push "route" else if topology == net30: push "route" if dev tap OR (dev tun AND topology == subnet): ifconfig if !nopool: ifconfig-pool push "route-gateway"

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 configuration 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 Network Connections Panel by selecting the ethernet and TAP adapters and right-clicking on "Bridge Connections".

Next you you must manually set the IP/netmask on the bridge interface. The gateway 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 expands as follows:

mode server tls-server ifconfig-pool push "route-gateway"

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 feasibility and security. Some options such as those which would execute scripts are banned, since they would effectively allow a compromised server to execute arbitrary code on the client. Other options such as TLS or MTU parameters cannot be pushed because the client needs to know them before the connection to the server can be initiated.

This is a partial list of options which can currently be pushed: --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

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 configuration file. This option will ignore --push options at the global config file level.
Push additional information about the client to server. The additional information consists of the following data:

IV_VER=<version> -- the client OpenVPN version

IV_PLAT=[linux|solaris|openbsd|mac|netbsd|freebsd|win] -- the client OS platform

IV_HWADDR=<mac address> -- the MAC address of clients default gateway

IV_LZO_STUB=1 -- if client was built with LZO stub capability

UV_<name>=<value> -- client environment variables whose names start with "UV_"

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-config-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, individual 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

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 [alias]
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 directive 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.

The optional alias parameter may be used in cases where NAT causes the client view of its local endpoint to differ from the server view. In this case local/remote-netmask will refer to the server view while alias/remote-netmask will refer to the client view.

This option must be associated with a specific client instance, which means that it must be specified either in a client instance config file using --client-config-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 omitted, defaults to

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 accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes.

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 currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.

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 cmd
Run command cmd on client connection.

cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces.

The command is passed the common name and IP address of the just-authenticated client as environmental variables (see environmental variable section below). The command is also passed the pathname of a freshly created temporary file as the last argument (after any arguments specified in cmd ), to be used by the command to pass dynamically generated config file directives back to OpenVPN.

If the script wants to generate a dynamic config file to be applied on the server when the client connects, it should write it to the file named by the last argument.

See the --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 cmd
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 command or plugins are cascaded, and at least one client-connect function succeeded, then ALL of the client-disconnect functions for scripts and plugins will be called on client instance object deletion, even in cases where some of the related client-connect functions returned an error status.

The --client-disconnect command is passed the same pathname as the corresponding --client-connect command as its last argument. (after any arguments specified in cmd ).

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

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.

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 openvpn processes and script to communicate temporary data with openvpn main process. Note that the directory must be writable by the OpenVPN process after it has dropped it's root privileges.

This directory will be used by in the following cases:

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

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.

--stale-routes-check n [t]
Remove routes haven't had activity for n seconds (i.e. the ageing time).

This check is ran every t seconds (i.e. check interval).

If t is not present it defaults to n

This option helps to keep the dynamic routing table small. See also --max-routes-per-client

--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 command cmd to validate client virtual addresses or routes.

cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces.

Three arguments will be appended to any arguments in cmd as follows:

[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 "", an IPv4 subnet such as "", 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 appropriate firewall entries on the VPN TUN/TAP interface. Since OpenVPN provides the association between virtual IP or MAC address and the client's authenticated common name, it allows a user-defined script to configure firewall access policies with regard to the client's high-level common name, rather than the low level client virtual addresses.

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

OpenVPN will run command cmd to validate the username/password provided by the client.

cmd consists of a path to script (or executable program), optionally followed by arguments. The path and arguments may be single- or double-quoted and/or escaped using a backslash, and should be separated by one or more spaces.

If 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 argument 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 OpenVPN's authentication capabilities.

To protect against a client passing a maliciously formed username or password string, the username string must consist only of these characters: alphanumeric, underbar ('_'), dash ('-'), dot ('.'), or at ('@'). The password string can consist of any printable characters except for CR or LF. Any illegal characters in either the username or password string will be converted to underbar ('_').

Care must be taken by any user-defined scripts to avoid creating a security vulnerability in the way that these strings are handled. Never use these strings in such a way that they might be escaped or evaluated by a shell interpreter.

For a sample script that performs PAM authentication, see sample-scripts/auth-pam.pl in the OpenVPN source distribution.

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.

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.
Don't require client certificate, client will authenticate using username/password only. Be aware that using this directive is less secure than requiring certificates from all clients.

If you use this directive, the entire responsibility of authentication will rest on your --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.

For --auth-user-pass-verify authentication, use the authenticated username as the common name, rather than the common name from the client cert.
--compat-names [no-remapping] (DEPRECATED)
Until OpenVPN v2.3 the format of the X.509 Subject fields was formatted like this:
/C=US/L=Somewhere/CN=John Doe/emailAddress=john@example.com
In addition the old behaviour was to remap any character other than alphanumeric, underscore ('_'), dash ('-'), dot ('.'), and slash ('/') to underscore ('_'). The X.509 Subject string as returned by the tls_id environmental variable, could additionally contain colon (':') or equal ('=').
When using the --compat-names option, this old formatting and remapping will be re-enabled again. This is purely implemented for compatibility reasons when using older plug-ins or scripts which does not handle the new formatting or UTF-8 characters.
In OpenVPN v2.3 the formatting of these fields changed into a more standardised format. It now looks like:
C=US, L=Somewhere, CN=John Doe, emailAddress=john@example.com
The new default format in OpenVPN v2.3 also does not do the character remapping which happened earlier. This new format enables proper support for UTF-8 characters in the usernames, X.509 Subject fields and Common Name variables and it complies to the RFC 2253, UTF-8 String Representation of Distinguished Names.

The no-remapping mode flag can be used with the --compat-names option to be compatible with the now deprecated --no-name-remapping option. It is only available at the server. When this mode flag is used, the Common Name, Subject, and username strings are allowed to include any printable character including space, but excluding control characters such as tab, newline, and carriage-return. no-remapping is only available on the server side.

Please note: This option is immediately deprecated. It is only implemented to make the transition to the new formatting less intrusive. It will be removed either in OpenVPN v2.4 or v2.5. So please make sure you use the --verify-x509-name option instead of --tls-remote as soon as possible and update your scripts where necessary.

--no-name-remapping (DEPRECATED)
The --no-name-remapping option is an alias for --compat-names no-remapping. It ensures compatibility with server configurations using the --no-name-remapping option.

Please note: This option is now deprecated. It will be removed either in OpenVPN v2.4 or v2.5. So please make sure you support the new X.509 name formatting described with the --compat-names option as soon as possible.

--port-share host port [dir]
When run in TCP server mode, share the OpenVPN port with another application, such as an HTTPS server. If OpenVPN senses a connection to its port which is using a non-OpenVPN protocol, it will proxy the connection to the server at host:port. Currently only designed to work with HTTP/HTTPS, though it would be theoretically possible to extend to other protocols such as ssh.

dir specifies an optional directory where a temporary file with name N containing content C will be dynamically generated for each proxy connection, where N is the source IP:port of the client connection and C is the source IP:port of the connection to the proxy receiver. This directory can be used as a dictionary by the proxy receiver to determine the origin of the connection. Each generated file will be automatically deleted when the proxied connection is torn down.

Not implemented on Windows.