Differences

This shows you the differences between two versions of the page.

--- openvpn:options [2020/04/20 10:21] – peter
+++ openvpn:options [2020/07/15 09:30] (current) – external edit 127.0.0.1
@@ Line 58: / Line 58: @@
 |route network/IP [netmask] [gateway] [metric]|Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.|
 |:::|**netmask** default -- 255.255.255.255|
-|:::|**gateway** default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.|
+|:::|**gateway** default -- taken from **--route-gateway** or the second parameter to **--ifconfig** when **--dev tun** is specified.|
-|:::|**metric** default -- taken from --route-metric otherwise 0.|
+|:::|**metric** default -- taken from **--route-metric** otherwise 0.|
 |:::|The default can be specified by leaving an option blank or setting it to "default".|
 |:::|The **network** and **gateway** parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:|
@@ Line 91: / Line 91: @@
 |client|A helper directive designed to simplify the configuration of OpenVPN's client mode. This directive is equivalent to:|
-|:::|pull|
+|:::|**pull**|
-|:::|tls-client|
+|:::|**tls-client**|
-|pull|This option must be used on a client which is connecting to a multi-client server. It indicates to OpenVPN that it should accept options pushed by the server, provided they are part of the legal set of pushable options.|
+|pull|This option must be used on a client which is connecting to a multi-client server.  It indicates to OpenVPN that it should accept options pushed by the server, provided they are part of the legal set of pushable options.|
-|:::|In particular, --pull allows the server to push routes to the client, so you should not use --pull or --client in situations where you don't trust the server to have control over the client's routing table.|
+|:::|In particular, **--pull** allows the server to push routes to the client, so you should not use **--pull** or **--client** in situations where you don't trust the server to have control over the client's routing table.|
@@ Line 119: / Line 119: @@
 |:::|This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server.  The attack is easily prevented by having clients verify the server certificate using any one of **--remote-cert-tls**, **--verify-x509-name**, or **--tls-verify**.|
 |tls-client|Enable TLS and assume client role during TLS handshake.|
+|verify-x509-name Server name-prefix|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.|
+|:::|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'** and **--verify-x509-name Server-1 name** or you could use **--verify-x509-name Server- name-prefix** 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.|
 ----
@@ Line 128: / Line 136: @@
 |:::|**ipapi** -- Use IP helper API.|
 |:::|**exe** -- Call the route.exe shell command.|
-----
-|verify-x509-name Server name-prefix|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.|
-|:::|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'** and **--verify-x509-name Server-1 name** or you could use **--verify-x509-name Server- name-prefix** 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.|
 ----