neulab/tldr huggingface dataset:
It should be emphasized that this feature is optional and that the 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.
Use --tls-crypt instead if you want to use the key file to not only authenticate, but also encrypt the TLS control channel.
--tls-groups list A list of allowable groups/curves in order of preference.
Set the allowed elliptic curves/groups for the TLS session.  These groups are allowed to be used in signatures and key exchange.
mbedTLS currently allows all known curves per default.
OpenSSL 1.1+ restricts the list per default to
"X25519:secp256r1:X448:secp521r1:secp384r1".
If you use certificates that use non-standard curves, you might need to add them here. If you do not force the ecdh curve by using --ecdh-curve, the groups for ecdh will also be picked from this list.
OpenVPN maps the curve name secp256r1 to prime256v1 to allow specifying the same tls-groups option for mbedTLS and OpenSSL.
Warning: this option not only affects elliptic curve certificates but also the key exchange in TLS 1.3 and using this option improperly will disable TLS 1.3.
--tls-cert-profile profile Set the allowed cryptographic algorithms for certificates according to profile.
The following profiles are supported:
legacy (default) SHA1 and newer, RSA 2048-bit+, any elliptic curve.
preferred SHA2 and newer, RSA 2048-bit+, any elliptic curve.
suiteb SHA256/SHA384, ECDSA with P-256 or P-384.
This option is only fully supported for mbed TLS builds. OpenSSL builds use the following approximation:
legacy (default) sets "security level 1"
preferred sets "security level 2"
suiteb sets "security level 3" and --tls-cipher "SUITEB128".
OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.
WARNING: --tls-ciphers, --tls-ciphersuites and tls-groups These options are expert features, which - if used correctly - can improve the security of your VPN connection. But it is also easy to unwittingly use them to carefully align a gun with your foot, or just break your connection. Use with care!
--tls-cipher l A list l of allowable TLS ciphers delimited by a colon (":").
These setting can be used to ensure that certain cipher suites are used (or not used) for the TLS connection. OpenVPN uses TLS to secure the control channel, over which the keys that are used to protect the actual VPN traffic are exchanged.
The supplied list of ciphers is (after potential OpenSSL/IANA name translation) simply supplied to the crypto library. Please see the OpenSSL and/or mbed TLS documentation for details on the cipher list interpretation.
For OpenSSL, the --tls-cipher is used for TLS 1.2 and below.
Use --show-tls to see a list of TLS ciphers supported by your crypto library.
The default for --tls-cipher is to use mbed TLS's default cipher list when using mbed TLS or DEFAULT:!EXP:!LOW:!MEDIUM:!kDH:!kECDH:!DSS:!PSK:!SRP:!kRSA when using OpenSSL.
--tls-ciphersuites l Same as --tls-cipher but for TLS 1.3 and up. mbed TLS has no TLS 1.3 support yet and only the --tls-cipher setting is used.
The default for --tls-ciphersuites is to use the crypto library's default.
--tls-client Enable TLS and assume client role during TLS handshake.
--tls-crypt keyfile Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.)
Encrypting (and authenticating) control channel packets:
• provides more privacy by hiding the certificate used for the TLS connection,
• makes it harder to identify OpenVPN traffic as such,
• provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).
In contrast to --tls-auth, --tls-crypt does not require the user to set --key-direction.
Security Considerations
All peers use the same --tls-crypt pre-shared group key to authenticate and encrypt control channel messages. To ensure that IV collisions remain unlikely, this key should not be used to encrypt more than 2^48 client-to-server or 2^48 server-to-client control channel messages. A typical initial negotiation is about 10 packets in each direction. Assuming both initial negotiation and renegotiations are at most 2^16 (65536) packets (to be conservative), and (re)negotiations happen each minute for each user (24/7), this limits the tls-crypt key lifetime to 8171 years divided by the number of users. So a setup with 1000 users should rotate the key at least once each eight years. (And a setup with 8000 users each year.)
If IV collisions were to occur, this could result in the security of --tls-crypt degrading to the same security as using --tls-auth. That is, the control channel still benefits from the extra protection against active man-in-the-middle-attacks and DoS attacks, but may no longer offer extra privacy and post-quantum security on top of what TLS itself offers.
For large setups or setups where clients are not trusted, consider using --tls-crypt-v2 instead. That uses per-client unique keys, and thereby improves the bounds to 'rotate a client key at least once per 8000 years'.
--tls-crypt-v2 keyfile Use client-specific tls-crypt keys.
For clients, keyfile is a client-specific tls-crypt key. Such a key can be generated using the --genkey tls-crypt-v2-client option.
For servers, keyfile is used to unwrap client-specific keys supplied by the client during connection setup. This key must be the same as the key used to generate the client-specific key (see --genkey tls-crypt-v2-client).
On servers, this option can be used together with the --tls-auth or --tls-crypt option. In that case, the server will detect whether the client is using client-specific keys, and automatically select the right mode.
--tls-crypt-v2-verify cmd Run command cmd to verify the metadata of the client-specific tls-crypt-v2 key of a connecting client. This allows server administrators to reject client connections, before exposing the TLS stack (including the notoriously dangerous X.509 and ASN.1 stacks) to the connecting client.
OpenVPN supplies the following environment variables to the command:
• script_type is set to tls-crypt-v2-verify
• metadata_type is set to 0 if the metadata was user supplied, or 1 if it's a 64-bit unix timestamp representing the key creation time.
• metadata_file contains the filename of a temporary file that contains the client metadata.
The command can reject the connection by exiting with a non-zero exit code.
--tls-exit Exit on TLS negotiation failure.
--tls-export-cert directory Store the certificates the clients use 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.
--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-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.
--tls-version-min args Sets the minimum TLS version we will accept from the peer (default is "1.0").
tls-version-min version ['or-highest']
Examples for version include 1.0, 1.1, or 1.2. If or-highest is specified and version is not recognized, we will only accept the highest TLS version supported by the local SSL implementation.
--tls-version-max version Set the maximum TLS version we will use (default is the highest version supported). Examples for version include 1.0, 1.1, or 1.2.
--verify-hash args Specify SHA1 or SHA256 fingerprint for level-1 cert.
verify-hash hash [algo]
The level-1 cert is the CA (or intermediate cert) that signs the leaf certificate, and is one removed from the leaf certificate in the direction of the root. When accepting a connection from a peer, the level-1 cert fingerprint must match hash or certificate verification will fail. Hash is specified as XX:XX:... For example:
AD:B0:95:D8:09:C8:36:45:12:A9:89:C8:90:09:CB:13:72:A6:AD:16
The algo flag can be either SHA1 or SHA256. If not provided, it defaults to SHA1.
--verify-x509-name args Accept connections only if a host's X.509 name is equal to name. The remote host must also pass all other tests of verification.
verify-x509 name type
Which X.509 name is compared to name depends on the setting of type.  type can be subject to match the complete subject DN (default), name to match a subject RDN or name-prefix to match a subject RDN prefix. Which RDN is verified as name depends on the --x509-username-field option. But it defaults to the common name (CN), e.g. a certificate with a subject DN
C=KG, ST=NA, L=Bishkek, CN=Server-1
would be matched by:
verify-x509-name 'C=KG, ST=NA, L=Bishkek, CN=Server-1' verify-x509-name Server-1 name verify-x509-name Server- name-prefix
The last example is useful if you want a client to only accept connections to Server-1, Server-2, etc.
--verify-x509-name is a useful replacement for the --tls-verify option to verify the remote host, because --verify-x509-name works in a --chroot environment without any dependencies.
Using a name prefix is a useful alternative to managing a CRL (Certificate Revocation List) on the client, since it allows the client to refuse all certificates except for those associated with designated servers.
NOTE:  Test against a name prefix only when you are using OpenVPN with a custom CA certificate that is under your control. Never use this option with type name-prefix when your client certificates are signed by a third party, such as a commercial web CA.
--x509-track attribute Save peer X509 attribute value in environment for use by plugins and management interface. Prepend a + to attribute to save values from full cert chain. Values will be encoded as X509_<depth>_<attribute>=<value>. Multiple --x509-track options can be defined to track multiple attributes.
--x509-username-field args Field in the X.509 certificate subject to be used as the username (default CN).
x509-username-field [ext:]fieldname
Typically, this option is specified with fieldname as either of the following:
x509-username-field emailAddress x509-username-field ext:subjectAltName
The first example uses the value of the emailAddress attribute in the certificate's Subject field as the username. The second example uses the ext: prefix to signify that the X.509 extension fieldname subjectAltName be searched for an rfc822Name (email) field to be used as the username. In cases where there are multiple email addresses in ext:fieldname, the last occurrence is chosen.
When this option is used, the --verify-x509-name option will match against the chosen fieldname instead of the Common Name.
Only the subjectAltName and issuerAltName X.509 extensions are supported.
Please note: This option has a feature which will convert an all-lowercase fieldname to uppercase characters, e.g., ou -> OU. A mixed-case fieldname or one having the ext: prefix will be left as-is. This automatic upcasing feature is deprecated and will be removed in a future release.
PKCS#11 / SmartCard options --pkcs11-cert-private args Set if access to certificate object should be performed after login.  Every provider has its own setting.
pkcs11-cert-private 0 pkcs11-cert-private 1
--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-private-mode mode Specify which method to use in order to perform private key operations.  A different mode can be specified for each provider. Mode is encoded as hex number, and can be a mask one of the following:
0 (default)   Try to determine automatically.
1             Use sign.
2             Use sign recover.
4             Use decrypt.
8             Use unwrap.
--pkcs11-protected-authentication args Use PKCS#11 protected authentication path, useful for biometric and external keypad devices. Every provider has its own setting.
pkcs11-protected-authentication 0 pkcs11-protected-authentication 1
--pkcs11-providers provider Specify an RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) providers to load. This option can be used instead of --cert, --key and --pkcs12.
If p11-kit is present on the system, its p11-kit-proxy.so module will be loaded by default if either the --pkcs11-id or --pkcs11-id-management options are specified without --pkcs11-provider being given.
--show-pkcs11-ids args (Standalone) Show PKCS#11 token object list.
show-pkcs11 [provider] [cert_private]
Specify cert_private as 1 if certificates are stored as private objects.
If p11-kit is present on the system, the provider argument is optional; if omitted the default p11-kit-proxy.so module will be queried.
--verb option can be used BEFORE this option to produce debugging information.
OpenVPN 2.4 and higher have the capability to negotiate the data cipher that is used to encrypt data packets. This section describes the mechanism in more detail and the different backwards compatibility mechanism with older server and clients.
OpenVPN 2.5 and higher behaviour When both client and server are at least running OpenVPN 2.5, that the order of the ciphers of the server's --data-ciphers is used to pick the the data cipher.  That means that the first cipher in that list that is also in the client's --data-ciphers list is chosen. If no common cipher is found the client is rejected with a AUTH_FAILED message (as seen in client log): AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)
OpenVPN 2.5 will only allow the ciphers specified in --data-ciphers. To ensure backwards compatibility also if a cipher is specified using the --cipher option it is automatically added to this list. If both options are unset the default is AES-256-GCM:AES-128-GCM.
OpenVPN 2.4 clients The negotiation support in OpenVPN 2.4 was the first iteration of the implementation and still had some quirks. Its main goal was "upgrade to AES-256-GCM when possible".  An OpenVPN 2.4 client that is built against a crypto library that supports AES in GCM mode and does not have --ncp-disable will always announce support for AES-256-GCM and AES-128-GCM to a server by sending IV_NCP=2.
This only causes a problem if --ncp-ciphers option has been changed from the default of AES-256-GCM:AES-128-GCM to a value that does not include these two ciphers. When a OpenVPN servers try to use AES-256-GCM or AES-128-GCM the connection will then fail. It is therefore recommended to always have the AES-256-GCM and AES-128-GCM ciphers to the --ncp-ciphers options to avoid this behaviour.
OpenVPN 3 clients Clients based on the OpenVPN 3.x library (‐ https://github.com/openvpn/openvpn3/) do not have a configurable --ncp-ciphers or --data-ciphers option. Instead these clients will announce support for all their supported AEAD ciphers (AES-256-GCM, AES-128-GCM and in newer versions also Chacha20-Poly1305).
To support OpenVPN 3.x based clients at least one of these ciphers needs to be included in the server's --data-ciphers option.
OpenVPN 2.3 and older clients (and clients with --ncp-disable) When a client without cipher negotiation support connects to a server the cipher specified with the --cipher option in the client configuration must be included in the --data-ciphers option of the server to allow the client to connect. Otherwise the client will be sent the AUTH_FAILED message that indicates no shared cipher.
If the client is 2.3 or older and has been configured with the --enable-small  ./configure argument, using data-ciphers-fallback cipher in the server config file with the explicit cipher used by the client is necessary.
OpenVPN 2.4 server When a client indicates support for AES-128-GCM and AES-256-GCM (with IV_NCP=2) an OpenVPN 2.4 server will send the first cipher of the --ncp-ciphers to the OpenVPN client regardless of what the cipher is. To emulate the behaviour of an OpenVPN 2.4 client as close as possible and have compatibility to a setup that depends on this quirk, adding AES-128-GCM and AES-256-GCM to the client's --data-ciphers option is required. OpenVPN 2.5+ will only announce the IV_NCP=2 flag if those ciphers are present.
OpenVPN 2.3 and older servers (and servers with --ncp-disable) The cipher used by the server must be included in --data-ciphers to allow the client connecting to a server without cipher negotiation support. (For compatibility OpenVPN 2.5 will also accept the cipher set with --cipher)
If the server is 2.3 or older and  has been configured with the --enable-small ./configure argument, adding data-ciphers-fallback cipher to the client config with the explicit cipher used by the server is necessary.
Blowfish in CBC mode (BF-CBC) deprecation The --cipher option defaulted to BF-CBC in OpenVPN 2.4 and older version. The default was never changed to ensure backwards compatibility.  In OpenVPN 2.5 this behaviour has now been changed so that if the --cipher is not explicitly set it does not allow the weak BF-CBC cipher any more and needs to explicitly added as --cipher BFC-CBC or added to --data-ciphers.
We strongly recommend to switching away from BF-CBC to a more secure cipher as soon as possible instead.
OpenVPN consists of two sides of network configuration.  One side is the link between the local and remote side, the other side is the virtual network adapter (tun/tap device).
Link Options This link options section covers options related to the connection between the local and the remote host.
--bind keywords Bind to local address and port. This is the default unless any of --proto tcp-client , --http-proxy or --socks-proxy are used.
If the optional ipv6only keyword is present OpenVPN will bind only to IPv6 (as opposed to IPv6 and IPv4) when a IPv6 socket is opened.
--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.
--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 fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation.
--keepalive args A helper directive designed to simplify the expression of --ping and --ping-restart.
keepalive interval timeout
This option can be used on both client and server side, but it is enough to add this on the server side as it will push appropriate --ping and --ping-restart options to the client. If used on both server and client, the values pushed from server will override the client local values.
The timeout argument will be twice as long on the server side. This ensures that a timeout is detected on client side before the server side drops the connection.
For example, --keepalive 10 60 expands as follows:
if mode server: ping 10                    # Argument: interval ping-restart 120           # Argument: timeout*2 push "ping 10"             # Argument: interval push "ping-restart 60"     # Argument: timeout else ping 10                    # Argument: interval ping-restart 60            # Argument: timeout
--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.
--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.
--lport port Set local TCP/UDP port number or name. Cannot be used together with --nobind option.
--mark value Mark encrypted packets being sent with value. The mark value can be matched in policy routing and packetfilter rules. This option is only supported in Linux and does nothing on other operating systems.
--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.
--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. Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). Default value of 1450 allows IPv4 packets to be transmitted over a link with MTU 1473 or higher without IP level fragmentation.
The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN 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 discovery is broken on the network path between OpenVPN peers.
The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.
If --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
--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.
Valid types:
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.
--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.
--passtos Set the TOS field of the tunnel packet to what the payload's TOS is.
--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.
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 generated signal will always be applied to individual client instance objects, never to whole server itself. Note also in server mode that any internally generated signal which would normally cause a restart, will cause the deletion of the client instance object instead.
In client mode, the --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.
--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.
--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 security and robustness perspective, such as tunneling non-IP or application-level UDP protocols, or tunneling protocols which don't possess a built-in reliability layer.
--port port TCP/UDP port number or port name for both local and remote (sets both --lport and --rport options to given port). The current default of 1194 represents the official IANA port number assignment for OpenVPN and has been used since version 2.0-beta17. Previous versions used port 5000 as the default.
--rport port Set TCP/UDP port number or name used by the --remote option. The port can also be set directly using the --remote option.
--replay-window args Modify the replay protection sliding-window size and time window.
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 specified, 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 emulating the physical network layer, it will accept an out-of-order packet sequence, and will deliver such packets in the same order they were received to the TCP/IP protocol stack, provided they satisfy several constraints.
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. Satellite 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 tunneling non-IP or UDP application protocols which might be vulnerable to a message deletion or reordering attack which falls within the normal operational parameters of IP networks.
So I would make the statement that one should never tunnel a non-IP protocol or UDP application protocol over UDP, if the protocol might be vulnerable to a message deletion or reordering attack that falls within the normal operating parameters of what is to be expected from the physical IP layer. The problem is easily fixed by simply using TCP as the VPN transport layer.
--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 sessions are frequently started and stopped.
This option will keep a disk copy of the current replay protection state (i.e. the most recent packet timestamp and sequence number received from the remote peer), so that if an OpenVPN session is stopped and restarted, it will reject any replays of packets which were already received by the prior session.
This option only makes sense when replay protection is enabled (the default) and you are using either --secret (shared-secret key mode) or TLS mode with --tls-auth.
--socket-flags flags Apply the given flags to the OpenVPN transport socket. Currently, only TCP_NODELAY 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 improvement in latency.
This option is pushable from server to client, and should be used on both client and server for maximum effect.
--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"
Virtual Network Adapter (VPN interface) Options in this section relates to configuration of the virtual tun/tap network interface, including setting the VPN IP address and network routing.
--bind-dev device (Linux only) Set device to bind the server socket to a Virtual Routing and Forwarding device
--block-ipv6 On the client, instead of sending IPv6 packets over the VPN tunnel, all IPv6 packets are answered with an ICMPv6 no route host message. On the server, all IPv6 packets from clients are answered with an ICMPv6 no route to host message. This options is intended for cases when IPv6 should be blocked and other options are not available. --block-ipv6 will use the remote IPv6 as source address of the ICMPv6 packets if set, otherwise will use fe80::7 as source address.
For this option to make sense you actually have to route traffic to the tun interface. The following example config block would send all IPv6 traffic to OpenVPN and answer all requests with no route to host, effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked clients leaking around IPv4-only VPN services).
--ifconfig-ipv6 fd15:53b6:dead::2/64 fd15:53b6:dead::1 --redirect-gateway ipv6 --block-ipv6
Server config Push a "valid" ipv6 config to the client and block on the server
--push "ifconfig-ipv6 fd15:53b6:dead::2/64 fd15:53b6:dead::1" --push "redirect-gateway ipv6" --block-ipv6
Note: this option does not influence traffic sent from the server towards the client (neither on the server nor on the client side). This is not seen as necessary, as such traffic can be most easily avoided by not configuring IPv6 on the server tun, or setting up a server-side firewall rule.
--dev device TUN/TAP virtual network device which can be tunX, tapX, null or an arbitrary name string (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)
tap    devices encapsulate Ethernet 802.3 (OSI Layer 2).
dev tun2 dev tap4 dev ovpn
When the device name starts with tun or tap, the device type is extracted automatically.  Otherwise the --dev-type option needs to be added as well.
--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.
Under Mac OS X this option can be used to specify the default tun implementation. Using --dev-node utun forces usage of the native Darwin tun kernel support. Use --dev-node utunN to select a specific utun instance. To force using the tun.kext (/dev/tunX) use --dev-node tun. When not specifying a --dev-node option openvpn will first try to open utun, and fall back to tun.kext.
On Windows systems, select the TAP-Win32 adapter which is named node in the Network 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 available TAP-Win32 adapters and will show both the network connections control panel name and the GUID for each TAP-Win32 adapter.
--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.
--dhcp-option args Set additional network parameters on supported platforms. May be specified on the client or pushed from the server. On Windows these options are handled by the tap-windows6 driver by default or directly by OpenVPN if dhcp is disabled or the wintun driver is in use. The OpenVPN for Android client also handles them internally.
On all other platforms these options are only saved in the client's environment under the name foreign_options_{n} before the --up script is called. A plugin or an --up script must be used to pick up and interpret these as required. Many Linux distributions include such scripts and some third-party user interfaces such as tunnelblick also come with scripts that process these options.
dhcp-options type [parm]
DOMAIN name Set Connection-specific DNS Suffix to name.
ADAPTER_DOMAIN_SUFFIX name Alias to DOMAIN. This is a compatibility option, it should not be used in new deployments.
DOMAIN-SEARCH name Add name to the domain search list.  Repeat this option to add more entries. Up to 10 domains are supported.
DNS address Set primary domain name server IPv4 or IPv6 address. Repeat this option to set secondary DNS server addresses.
Note: DNS IPv6 servers are currently set using netsh (the existing DHCP code can only do IPv4 DHCP, and that protocol only permits IPv4 addresses anywhere). The option will be put into the environment, so an --up script could act upon it if needed.
WINS address Set primary WINS server address (NetBIOS over TCP/IP Name Server).  Repeat this option to set secondary WINS server addresses.
NBDD address Set primary NBDD server address (NetBIOS over TCP/IP Datagram Distribution Server). Repeat this option to set secondary NBDD server addresses.
NTP address 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)
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.
--ifconfig args Set TUN/TAP adapter parameters. It requires the IP address of the local VPN endpoint. For TUN devices in point-to-point mode, the next argument must be the VPN IP address of the remote VPN endpoint. For TAP devices, or TUN devices used with --topology subnet, the second argument is the subnet mask of the virtual network segment which is being created or connected to.
For TUN devices, which facilitate virtual point-to-point IP connections (when used in --topology net30 or p2p mode), the proper usage of --ifconfig is to use two private IP addresses which are not a member of any existing subnet which is in use. The IP addresses may be consecutive and should have their order reversed on the remote peer.  After the VPN is established, by pinging rn, you will be pinging across the VPN.
For TAP devices, which provide the ability to create virtual ethernet segments, or TUN devices in --topology subnet mode (which create virtual "multipoint networks"), --ifconfig is used to set an IP address and subnet mask just as a physical ethernet adapter would be similarly configured. If you are attempting to connect to a remote ethernet bridge, the IP address and subnet should be set to values which would be valid on the the bridged ethernet segment (note also that DHCP can be used for the same purpose).
This option, while primarily a proxy for the 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 getting an IP address lease from a DHCP server.
# tun device in net30/p2p mode ifconfig 10.8.0.2 10.8.0.1
# tun/tap device in subnet mode ifconfig 10.8.0.2 255.255.255.0
--ifconfig-ipv6 args Configure an IPv6 address on the tun device.
ifconfig-ipv6 ipv6addr/bits [ipv6remote]
The ipv6addr/bits argument is the IPv6 address to use. The second parameter is used as route target for --route-ipv6 if no gateway is specified.
The --topology option has no influence with --ifconfig-ipv6
--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.
--lladdr address Specify the link layer address, more commonly known as the MAC address.  Only applied to TAP devices.
--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 control over reset options.
--redirect-gateway flags Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.
This option performs three steps:
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 specified).
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 peers are directly connected via a common subnet, such as with wireless. The local flag will cause step (1) above to be omitted.
autolocal Try to automatically determine whether to enable local flag above.
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).
block-local Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN gateway address) into the tunnel.
ipv6   Redirect IPv6 routing into the tunnel. This works similar to the def1 flag, that is, more specific IPv6 routes are added (2000::/4, 3000::/4), covering the whole IPv6 unicast space.
!ipv4  Do not redirect IPv4 traffic - typically used in the flag pair ipv6 !ipv4 to redirect IPv6-only.
--redirect-private flags Like --redirect-gateway, but omit actually changing the default gateway.  Useful when pushing private subnets.
--route args 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.
route network/IP route network/IP netmask route network/IP netmask gateway route network/IP netmask gateway metric
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 defaults to 255.255.255.255 when not given
gateway default taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.
metric default taken from --route-metric if set, 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-gateway 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.
--route-delay args Valid syntaxes:
route-delay route-delay n route-delay n m
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 (default 30 by default) for the TAP-Win32 adapter to come up before adding routes.
--route-ipv6 args Setup IPv6 routing in the system to send the specified IPv6 network into OpenVPN's tun.
route-ipv6 ipv6addr/bits [gateway] [metric]
The gateway parameter is only used for IPv6 routes across tap devices, and if missing, the ipv6remote field from --ifconfig-ipv6 or --route-ipv6-gateway is used.
--route-gateway arg Specify a default gateway 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-gateway gateway route-gateway dhcp