DOC: Proofread openvpn-examples.rst (#1779)

* DOC: Proofread openvpn-examples.rst

* Apply suggestions from code review

Co-authored-by: Daniil Baturin <daniil@baturin.org>

---------

Co-authored-by: Daniil Baturin <daniil@baturin.org>

1 files changed, 184 insertions, 173 deletions

diff --git a/docs/configuration/interfaces/openvpn-examples.rst b/docs/configuration/interfaces/openvpn-examples.rst
index c380e7a8..46409975 100644
--- a/docs/configuration/interfaces/openvpn-examples.rst
+++ b/docs/configuration/interfaces/openvpn-examples.rst
@@ -1,54 +1,55 @@
 
-Site-to-Site
+Site-to-site
 ============
 
-OpenVPN is popular for client-server setups, but its site-to-site mode
-remains a relatively obscure feature, and many router appliances
-still don't support it. However, it's very useful for quickly setting up
-tunnels between routers.
+OpenVPN is popular for client-server setups, but its site-to-site mode is less 
+common and often not supported by router appliances. Despite limited support, 
+it is effective for quickly establishing tunnels between routers.
 
-As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or
+As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or 
 x.509 certificates.
 
-The pre-shared key mode is deprecated and will be removed from future OpenVPN
-versions, so VyOS will have to remove support for that option as well. The
-reason is that using pre-shared keys is significantly less secure than using TLS.
+Pre-shared key mode is now deprecated and will be removed from future OpenVPN 
+versions. VyOS will also discontinue support for this option because pre-shared 
+keys are significantly less secure than TLS.
 
-We'll configure OpenVPN using self-signed certificates, and then discuss the
+We will configure OpenVPN with self-signed certificates, and then discuss the 
 legacy pre-shared key mode.
 
 In both cases, we will use the following settings:
 
-* The public IP address of the local side of the VPN will be 198.51.100.10.
-* The public IP address of the remote side of the VPN will be 203.0.113.11.
-* The tunnel will use 10.255.1.1 for the local IP and 10.255.1.2 for the remote.
-* The local site will have a subnet of 10.0.0.0/16.
-* The remote site will have a subnet of 10.1.0.0/16.
-* The official port for OpenVPN is 1194, which we reserve for client VPN; we
-  will use 1195 for site-to-site VPN.
-* The ``persistent-tunnel`` directive will allow us to configure tunnel-related
-  attributes, such as firewall policy as we would on any normal network
+* The public IP address of the local VPN endpoint is 198.51.100.10.
+* The public IP address of the remote VPN endpoint is 203.0.113.11.
+* The tunnel uses 10.255.1.1 for the local IP address and 10.255.1.2 for the 
+  remote IP address.
+* The local site has a subnet of 10.0.0.0/16.
+* The remote site has a subnet of 10.1.0.0/16.
+* The official OpenVPN port 1194 is reserved for client VPN. For site-to-site 
+  VPN, port 1195 is used.
+* The ``persistent-tunnel`` directive allows us to configure tunnel-related 
+  attributes, such as firewall policy, as we would on any standard network 
   interface.
-* If known, the IP of the remote router can be configured using the
-  ``remote-host`` directive; if unknown, it can be omitted. We will assume a
-  dynamic IP for our remote router.
+* If known, the remote router's IP address can be configured using the 
+  ``remote-host`` directive. If unknown, it can be omitted. We assume the remote 
+  router has a dynamic IP address.
 
-.. figure:: /_static/images/openvpn_site2site_diagram.jpg
 
-Setting up certificates
------------------------
+.. figure:: /_static/images/openvpn_site2site_diagram.jpg
 
-Setting up a full-blown PKI with a CA certificate would arguably defeat the purpose
-of site-to-site OpenVPN, since its main goal is supposed to be configuration simplicity,
-compared to server setups that need to support multiple clients.
+Set up site-to-site certificates
+--------------------------------
 
-However, since VyOS 1.4, it is possible to verify self-signed certificates using
-certificate fingerprints.
+Deploying a complete Public Key Infrastructure (PKI) with a Certificate 
+Authority (CA) would overcomplicate site-to-site OpenVPN setups, which are 
+primarily designed for simplicity. To keep their configuration simple without 
+compromising security, VyOS 1.4 and later lets you verify self-signed 
+certificates using certificate fingerprints.
 
-On both sides, you need to generate a self-signed certificate, preferrably using the "ec" (elliptic curve) type.
-You can generate them by executing command ``run generate pki certificate self-signed install <name>`` in the configuration mode.
-Once the command is complete, it will add the certificate to the configuration session, to the ``pki`` subtree.
-You can then review the proposed changes and commit them.
+Generate a self-signed certificate on each router, preferably using the 
+Elliptic Curve (EC) type. In configuration mode, run the following command: 
+``run generate pki certificate self-signed install <name>``. This adds the 
+certificate to the configuration session's ``pki`` subtree. Review and commit 
+the changes.
 
 .. code-block:: none
 
@@ -81,22 +82,25 @@ You can then review the proposed changes and commit them.
 
   vyos@vyos# commit
 
-You do **not** need to copy the certificate to the other router. Instead, you need to retrieve its SHA-256 fingerprint.
-OpenVPN only supports SHA-256 fingerprints at the moment, so you need to use the following command:
+
+You do **not** need to copy the certificate to the other router. Instead, 
+retrieve its SHA-256 fingerprint. Since OpenVPN currently supports only SHA-256 
+fingerprints, use the following command:
 
 .. code-block:: none
 
   vyos@vyos# run show pki certificate openvpn-local fingerprint sha256
   5C:B8:09:64:8B:59:51:DC:F4:DF:2C:12:5C:B7:03:D1:68:94:D7:5B:62:C2:E1:83:79:F1:F0:68:B2:81:26:79
 
-Note: certificate names don't matter, we use 'openvpn-local' and 'openvpn-remote' but they can be arbitrary.
+.. note:: Certificate names are arbitrary. While ``openvpn-local`` and 
+   ``openvpn-remote`` are used here, you may choose any names.
 
 Repeat the procedure on the other router.
 
-Setting up OpenVPN
-------------------
+Set up site-to-site OpenVPN
+---------------------------
 
-Local Configuration:
+Local configuration:
 
 .. code-block:: none
 
@@ -111,10 +115,10 @@ Local Configuration:
   set interfaces openvpn vtun1 local-address '10.255.1.1'                         # Local IP of vtun interface
   set interfaces openvpn vtun1 remote-address '10.255.1.2'                        # Remote IP of vtun interface
   set interfaces openvpn vtun1 tls certificate 'openvpn-local'                    # The self-signed certificate
-  set interfaces openvpn vtun1 tls peer-fingerprint <remote cert fingerprint>     # The output of 'run show pki certificate <name> fingerprint sha256 on the remote router
+  set interfaces openvpn vtun1 tls peer-fingerprint <remote cert fingerprint>     # The output of 'run show pki certificate <name> fingerprint sha256' on the remote router
   set interfaces openvpn vtun1 tls role active
 
-Remote Configuration:
+Remote configuration:
 
 .. code-block:: none
 
@@ -130,17 +134,17 @@ Remote Configuration:
   set interfaces openvpn vtun1 tls peer-fingerprint <local cert fingerprint>       # The output of 'run show pki certificate <name> fingerprint sha256 on the local router
   set interfaces openvpn vtun1 tls role passive
 
-Pre-shared keys
----------------
+Set up pre-shared keys
+----------------------
 
-Until VyOS 1.4, the only option for site-to-site OpenVPN without PKI was to use
-pre-shared keys. That option is still available but it is deprecated and will
-be removed in the future. However, if you need to set up a tunnel to an older
-VyOS version or a system with older OpenVPN, you need to still need to know how
-to use it.
+Before VyOS 1.4, site-to-site OpenVPN without PKI required pre-shared keys. 
+This option is still available but is deprecated and will be removed in future 
+releases. If you need to set up a tunnel to an older VyOS version or a system 
+with older OpenVPN, you still need to use pre-shared keys.
 
-First, you need to generate a key by running ``run generate pki openvpn shared-secret install <name>`` from configuration mode.
-You can use any name, we will use ``s2s``.
+First, generate a key by running ``run generate pki openvpn shared-secret 
+install <name>`` in configuration mode. You can use any name; in this example, 
+we use ``s2s``.
 
 .. code-block:: none
 
@@ -159,23 +163,23 @@ You can use any name, we will use ``s2s``.
   vyos@local# commit
   [edit]
 
-Then you need to install the key on the remote router:
+Next, install the key on the remote router:
 
 .. code-block:: none
 
   vyos@remote# set pki openvpn shared-secret s2s key <generated key string>
 
-Then you need to set the key in your OpenVPN interface settings:
+Finally, configure the key in your OpenVPN interface settings:
 
 .. code-block:: none
 
   set interfaces openvpn vtun1 shared-secret-key s2s
 
-Firewall Exceptions
--------------------
+Set up firewall exceptions
+--------------------------
 
-For the OpenVPN traffic to pass through the WAN interface, you must create a
-firewall exception.
+To allow OpenVPN traffic to pass through the WAN interface, create a firewall 
+exception:
 
 .. code-block:: none
 
@@ -189,8 +193,8 @@ firewall exception.
    set firewall ipv4 name OUTSIDE_LOCAL rule 20 log
    set firewall ipv4 name OUTSIDE_LOCAL rule 20 protocol 'udp'
 
-You should also ensure that the OUTISDE_LOCAL firewall group is applied to the
-WAN interface and applied to input filter where traffic destined for the router itself
+Apply the OUTSIDE_LOCAL firewall group to the WAN interface and to the input 
+filter for traffic destined for the router itself:
 
 .. code-block:: none
 
@@ -198,30 +202,32 @@ WAN interface and applied to input filter where traffic destined for the router
     set firewall ipv4 input filter rule 10 inbound-interface name eth0
     set firewall ipv4 input filter rule 10 jump-target OUTSIDE_LOCAL
 
-Static Routing:
+Static routing:
 
-Static routes can be configured referencing the tunnel interface; for example,
-the local router will use a network of 10.0.0.0/16, while the remote has a
-network of 10.1.0.0/16:
+Configure static routes by referencing the tunnel interface. For example, if 
+the local router's network is ``10.0.0.0/16`` and the remote router's network 
+is ``10.1.0.0/16``, define the routes as follows:
 
-Local Configuration:
+Local configuration:
 
 .. code-block:: none
 
   set protocols static route 10.1.0.0/16 interface vtun1
 
-Remote Configuration:
+Remote configuration:
 
 .. code-block:: none
 
   set protocols static route 10.0.0.0/16 interface vtun1
 
-Firewall policy can also be applied to the tunnel interface for input, output and forward directions and functions identically to ethernet interfaces.
+As with standard Ethernet interfaces, you can apply firewall policies to the 
+tunnel interface for input, output, and forward directions.
 
-If you are making use of multiple tunnels, OpenVPN must have a way to distinguish between different tunnels aside from the pre-shared-key. This is done either by referencing IP addresses or port numbers. 
-One option is to dedicate a public IP to each tunnel. Another option is to dedicate a port number to each tunnel (e.g. 1195,1196,1197…).
+If you use multiple tunnels, OpenVPN must distinguish between them beyond just 
+the pre-shared key. To achieve this, assign either unique IP addresses or 
+unique ports to each tunnel.
 
-OpenVPN status can be verified using the show openvpn operational commands.
+Verify OpenVPN status using the show openvpn operational commands.
 
 .. code-block:: none
 
@@ -234,28 +240,27 @@ OpenVPN status can be verified using the show openvpn operational commands.
   N/A          10.110.12.54:1195  N/A          N/A           504.0 B     656.0 B     N/A
 
 
-Server-Client
+Server-client
 =============
 
-OpenVPN’s server-client mode is a configuration setup where server device acts
-as a central hub that multiple other machines (the clients) connect to securely 
-route their traffic or access a private network.
-Multi-client server is the most popular OpenVPN mode on routers. 
+In OpenVPN’s server-client mode, the server acts as a central hub, allowing 
+multiple clients to connect and securely route their traffic or access a 
+private network. Multi-client server is the most popular OpenVPN mode for 
+routers.
 
+Set up server-client certificates
+---------------------------------
 
-Setting up certificates
------------------------
+Server-client mode always uses x.509 authentication and therefore requires a 
+PKI setup. The PKI utility now simplifies the creation of Certificate 
+Authorities (CAs), server and client certificates, and Diffie-Hellman keys 
+directly in VyOS using configuration or operational mode commands.
 
-Client-Server always uses x.509 authentication and therefore requires a PKI setup.
-The PKI utility now simplifies the creation of Certificate Authorities (CAs), 
-server and client certificates, and Diffie-Hellman keys directly from the VyOS 
-using configuration or operational mode commands. 
+On the server, generate all certificates by running the following commands in 
+configuration mode. The certificates will be added to the configuration 
+session's PKI subtree.
 
-Usually on server side, you can generate all certificates by executing these 
-commands in the configuration mode. Once the command is complete, it will add 
-the certificate to the configuration session, to the ``pki`` subtree. 
-
-Certificate Authority (CA)
+Certificate Authority (CA):
 
 .. code-block:: none
 
@@ -285,7 +290,7 @@ Certificate Authority (CA)
   vyos@vyos# commit
 
 
-Server Certificate
+Server certificate:
 
 .. code-block:: none
 
@@ -318,7 +323,7 @@ Server Certificate
   vyos@vyos# commit
 
 
-DH Key
+Diffie-Hellman key:
 
 .. code-block:: none
 
@@ -336,7 +341,7 @@ DH Key
   [edit]
   vyos@vyos# commit
 
-Client Certificate
+Client certificate:
 
 .. code-block:: none
 
@@ -358,23 +363,23 @@ Client Certificate
   set pki certificate client1 certificate 'MIIDrjCCApagAwIBAgIUPvtffeYTdoOiHxu++wdrjHwwVX4wDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCR0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzENMAsGA1UEAwwEY2EtMTAeFw0yNTA2MTExMTQxMDlaFw0yNjA2MTExMTQxMDlaMFcxCzAJBgNVBAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5T1MxEDAOBgNVBAMMB2NsaWVudDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9H6E6gm0PfXO1n/WoA9xlg89/bnScLmfztVDn1uyNn8epE6zAi2GWBhtj4ixLllIwLdkJ7L2mF3yUZtA1Q0oYbGIqTbnaZ37JydCygVGnlLT7UX9zfRfS3KebCIvIte7OyCmnUfVfFzdIsp+4LI3S2wX/9Vyn4UBAR8QQNbezRB3XPMk9gzULnuLhmEDP6GVcPq7RzGXoXUMqsCxfEOJBjej0y4ANKH07HGVVrfVRiY+zlGkM4TFjVuZKnEA0BO6dhOA0E+7gsIXsC06UzzatkjsyWHpb2/DOECIifBoYej9DITu8VxyyZmgaINHEn2gGb0LRHO7rvQapc+XZ2z9DAgMBAAGjdTBzMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQnUyqEzG+AqZzsdSud5MDqsOxiXTAfBgNVHSMEGDAWgBQAb2W+vsDMn/Li9j9eVbFeu77qbTANBgkqhkiG9w0BAQsFAAOCAQEAplItvZpoX/joG3QREu9tHVKwDTmXB2lwUM5G8iKPgd6D6oOILZMe2KuvWt12dcdEzUCGfJwJJ8M8R2WD0OmcLdFqvM/8UM1hYzUP2BCnFCLtElVD+b4wMlQNpdHqNbdckw8J4MLQlhUgu9rZAZ0XjWCprr+U50bX++vYRw7Un3Ds6ETEvjflm5WAPb2e0V1hhISPl8K+VXO7RAwxy0DHcDuR+YaD+hnNgMsJV3/QwA17Iy8x86RpOgqmesbt0U7e9Rmo81aVgiy/V4OCV7u6bPX03fmZNS8UwwJuRUlxkjO+epHNYB2cnOcjSkUxaIJ9Hv3tMWHQEtbVZsNYSOZozw=='
   set pki certificate client1 private key 'MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQC9H6E6gm0PfXO1n/WoA9xlg89/bnScLmfztVDn1uyNn8epE6zAi2GWBhtj4ixLllIwLdkJ7L2mF3yUZtA1Q0oYbGIqTbnaZ37JydCygVGnlLT7UX9zfRfS3KebCIvIte7OyCmnUfVfFzdIsp+4LI3S2wX/9Vyn4UBAR8QQNbezRB3XPMk9gzULnuLhmEDP6GVcPq7RzGXoXUMqsCxfEOJBjej0y4ANKH07HGVVrfVRiY+zlGkM4TFjVuZKnEA0BO6dhOA0E+7gsIXsC06UzzatkjsyWHpb2/DOECIifBoYej9DITu8VxyyZmgaINHEn2gGb0LRHO7rvQapc+XZ2z9DAgMBAAECggEAPS/Fhtt5k2BgFivZW3FcVc+OS0keGwV8hkFsGoXTZIKEIzSFWIn/mX0CUY90C0Rn9MRwiqB4PwssOAsHY6QQjdRK8irRbVK8l2ZeydHC7DfVUdXtKR0YnxTaePML3nTV/TqPF14Rx6EINtHrkLeBbu2DhGsKfhoHIoTVbvUiKLHa2TkGJOkhvjsyMSPKzUXa1AzLmu+UBIhRYpEPHj0SQUUJJnKgIb7mTR2fhJScHcKwsrPq6S8OpChvsYZ6zatgrTFz9tuhD4IjL7NBiYP45BwGaLIaQjph8yAJwwHWoOP+TTj5WYflkW6Uu8F9gC0ve6dPGPNEi2TUdirvAe4LYQKBgQD0UfAPm6tQg8pdkvfMBvYc21fk8zqmgcA4OtvDi60aXuv5jI5+faISvOG2JLuFhKIDOb5ZerzGvkN+LvWgzr9H7YdGZNNtwKgpS/MGqcuuHncTxWBAwYgKhf26a/tqFZRNurJ6GowxDiAcQEc1mWnmdngRa+dvvCwNbXvGVqfVEQKBgQDGKi447TqD76QfvRPn/fRSjM+QE1duk+XorEJ0HHIha5HV9kCrZdV/olGRjDLwPJO6JW7iE2FUsS9SsIrccFE/9P2ZUqfYP2wL5vNO5kAmoLLUl0gwqg1WnBTPJfXeKReTj2uGmOdEuuMPXpL/49hDuPViiE2Q4MGe2Z+oEYN/EwKBgHfQMuTEl2e9qaDn8OM6SrluC5V4fjunh6dLnfgwaCx1fk1702lOnQuJWzsiml9o4raoO6PP4AGqzphz2PsKSJ2ya1NnIJRDFXRjDYQoAn2Z7RViBsja36chfINObxXgDUFtHBdrK3LnFXIlR4aOfHOLh2grvWx7IDNZjIiAeH+xAoGAJlmFZnjqiRv4bDgAQTZRcSRVCvHjSsAOj0++8I+MutEBgSHN9B2aCsBT/tHeDcX7ZNvXsKLFhElh+iO2S+DkqHb2GRT47I2hkFAaqBtBMPiKgz/ftaNDP46nLEuRYHQdXu4zhfHTV+a/CHtqAWGLuddyjaYJNM96SQ6eqjzxcMcCgYAzdxOF2e27hIgo2ttjsROMGqW0/0r/HsKGKPnao7xHQNCAswTnBT+QGugPCe0NXjuxbySP7V1GeWMWF+WV5khtteWerT1/ELAC48NSDpaMxVa4GP8Q/0w6+ZyJty3UGbCYQzZZue81dU+42LUIaVJ4NAc2tYj3jD780udasawS6w=='
 
-Remember to copy the CA and client certificate/key manually to the client side 
-and commit before using under the openvpn interface configuration 
+Manually copy the CA, client certificate, and Diffie-Hellman key to the client 
+device, then commit them before configuring the OpenVPN interface. 
 
-Refer this topic :ref:`configuration/pki/index:pki` for more options.
+For more options, refer to :ref:`configuration/pki/index:pki`.
 
-Setting up OpenVPN
-------------------
+Set up server-client OpenVPN
+----------------------------
 
-In this example we will use the most complicated case: a setup where each client
-is a router that has its own subnet (think HQ and branch offices), since simpler
-setups are subsets of it.
+The following example demonstrates the most complicated scenario: each client 
+acts as a router with its own subnet (e.g., an HQ and multiple branch offices). 
+Simpler setups are subsets of it.
 
-Suppose you want to use 10.23.1.0/24 network for client tunnel endpoints and all 
-client subnets belong to 10.23.0.0/20. All clients need access to the 
+In this scenario, the 10.23.1.0/24 network is used for client tunnel endpoints, 
+and all client subnets belong to 10.23.0.0/20. Each client needs access to the 
 192.168.0.0/16 network.
 
-Server Configuration:
+Server configuration:
 
 .. code-block:: none
 
@@ -392,38 +397,39 @@ Server Configuration:
   set interfaces openvpn vtun10 server name-server '172.16.254.30'
   set interfaces openvpn vtun10 server subnet '10.23.1.0/24'
   set interfaces openvpn vtun10 server topology 'subnet'
-  set interfaces openvpn vtun10 tls ca-cert ca-1
+  set interfaces openvpn vtun10 tls ca-certificate ca-1
   set interfaces openvpn vtun10 tls certificate srv-1
   set interfaces openvpn vtun10 tls dh-params dh-1
 
-The configurations above uses 1194/UDP default port, 256-bit AES for 
-encryption, SHA-512 for HMAC authentication and the persistent-tunnel option 
-which is recommended, as it prevents the TUN/TAP device from closing on connection resets or daemon reloads.
-Remember, clients are identified using their CN attribute in the SSL certificate.
+The configuration above uses the default 1194/UDP port, 256-bit AES encryption, 
+SHA-512 for HMAC authentication, and the persistent-tunnel option. 
+Persistent-tunnel is recommended as it keeps the TUN/TAP device active during 
+connection resets or daemon reloads. Clients are identified by the CN attribute 
+in their SSL certificates.
 
-To allow clients to access a specific network behind the router, we'll use the 
-push-route option to automatically install the appropriate route on each client.
+To grant clients access to a specific network behind the router, use the 
+push-route option to automatically install the appropriate route on each client. 
 
 .. code-block:: none
 
   set interfaces openvpn vtun10 server push-route 192.168.0.0/16
 
-OpenVPN will not automatically create routes in the kernel for client subnets 
-when they connect and will only use client-subnet association internally, so we 
-need to create a route to the 10.23.0.0/20 network ourselves:
+OpenVPN does not automatically create kernel routes for client subnets when 
+clients connect; it only uses client-subnet association internally. Therefore, 
+you must manually create a route to the 10.23.0.0/20 network:
 
 .. code-block:: none
 
   set protocols static route 10.23.0.0/20 interface vtun10
 
-Client
-------
+Set up OpenVPN client
+---------------------
 
-VyOS can not only act as an OpenVPN site-to-site or server for multiple clients
-but you can also configure any VyOS OpenVPN interface as an OpenVPN client that
-connects to a VyOS OpenVPN server or any other OpenVPN server.
+VyOS can operate not only as an OpenVPN site-to-site peer or a server for 
+multiple clients, but also as an OpenVPN client. Any VyOS OpenVPN interface 
+can be configured to connect to another VyOS or third-party OpenVPN server.
 
-Client Configuration:
+Client configuration:
 
 .. code-block:: none
 
@@ -434,11 +440,11 @@ Client Configuration:
   set interfaces openvpn vtun10 protocol 'udp'
   set interfaces openvpn vtun10 remote-host '172.18.201.10'
   set interfaces openvpn vtun10 remote-port '1194'
-  set interfaces openvpn vtun10 tls ca-cert ca-1
+  set interfaces openvpn vtun10 tls ca-certificate ca-1
   set interfaces openvpn vtun10 tls certificate client1
 
-Output
-------
+Verification
+------------
 
 Check the tunnel status:
 
@@ -454,17 +460,18 @@ Check the tunnel status:
 
 
 
-Server Bridge
+Server bridge
 =============
 
-In Ethernet bridging configurations, OpenVPN's server mode can be set as a
-'bridge' where the VPN tunnel encapsulates entire Ethernet frames
-(up to 1514 bytes) instead of just IP packets (up to 1500 bytes). This setup
-allows clients to transmit Layer 2 frames through the OpenVPN tunnel. Below,
-we outline a basic configuration to achieve this:
+In Ethernet bridging configurations, an OpenVPN interface operating in server 
+mode with the device type set to TAP can be added to a bridge. By encapsulating 
+entire Ethernet frames (up to 1514 bytes) rather than just IP packets (up to 
+1500 bytes), this setup enables clients to transmit Layer 2 frames through the 
+OpenVPN tunnel. 
 
+The following is a basic configuration example:
 
-Server Side:
+Server side:
 
 .. code-block:: none
 
@@ -472,7 +479,7 @@ Server Side:
   set interfaces bridge br10 member interface vtun10
   set interfaces openvpn vtun10 device-type 'tap'
   set interfaces openvpn vtun10 encryption data-ciphers 'aes192'
-  set interfaces openvpn vtun10 hash 'sha256''
+  set interfaces openvpn vtun10 hash 'sha256'
   set interfaces openvpn vtun10 local-host '172.18.201.10'
   set interfaces openvpn vtun10 local-port '1194'
   set interfaces openvpn vtun10 mode 'server'
@@ -483,15 +490,15 @@ Server Side:
   set interfaces openvpn vtun10 server topology 'subnet'
   set interfaces openvpn vtun10 tls ca-certificate 'ca-1'
   set interfaces openvpn vtun10 tls certificate 'srv-1'
-  set interfaces openvpn vtun10 tls dh-params 'srv-1'
+  set interfaces openvpn vtun10 tls dh-params 'dh-1'
 
-Client Side :
+Client side:
 
 .. code-block:: none
 
   set interfaces openvpn vtun10 device-type 'tap'
   set interfaces openvpn vtun10 encryption data-ciphers 'aes192'
-  set interfaces openvpn vtun10 hash 'sha256''
+  set interfaces openvpn vtun10 hash 'sha256'
   set interfaces openvpn vtun10 mode 'client'
   set interfaces openvpn vtun10 protocol 'udp'
   set interfaces openvpn vtun10 remote-host '172.18.201.10'
@@ -501,26 +508,28 @@ Client Side :
 
 
 
-Server LDAP Authentication
+Server LDAP authentication
 ==========================
 
 LDAP
 ----
 
-Enterprise installations usually ship a kind of directory service which is used
-to have a single password store for all employees. VyOS and OpenVPN support
-using LDAP/AD as single user backend.
+Enterprise installations usually include a directory service to centralize 
+employee password management. VyOS and OpenVPN support using LDAP and Active 
+Directory as a single user backend.
+
+Authentication is performed by the ``openvpn-auth-ldap.so`` plugin, included 
+with every VyOS installation. To use it, you must create a dedicated 
+configuration file.
 
-Authentication is done by using the ``openvpn-auth-ldap.so`` plugin which is
-shipped with every VyOS installation. A dedicated configuration file is
-required. It is best practise to store it in ``/config`` to survive image
-updates
+**Best practice:** Store the configuration file in the ``/config`` directory 
+to ensure it is preserved after image updates.
 
 .. code-block:: none
 
   set interfaces openvpn vtun0 openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"
 
-The required config file may look like this:
+A sample configuration file is shown below:
 
 .. code-block:: none
 
@@ -547,7 +556,7 @@ The required config file may look like this:
 Active Directory
 ^^^^^^^^^^^^^^^^
 
-Despite the fact that AD is a superset of LDAP
+A sample configuration file is shown below:
 
 .. code-block:: none
 
@@ -580,8 +589,8 @@ Despite the fact that AD is a superset of LDAP
     </Group>
   </Authorization>
 
-If you only want to check if the user account is enabled and can authenticate
-(against the primary group) the following snipped is sufficient:
+If you only want to check that the user account is enabled and can authenticate 
+(against the primary group), the following snippet is sufficient:
 
 .. code-block:: none
 
@@ -600,8 +609,8 @@ If you only want to check if the user account is enabled and can authenticate
     RequireGroup    false
   </Authorization>
 
-A complete LDAP auth OpenVPN configuration could look like the following
-example:
+A complete example of an LDAP authentication configuration for OpenVPN is shown 
+below:
 
 .. code-block:: none
 
@@ -630,14 +639,14 @@ example:
        }
    }
 
-For detailed example, refer this topic :doc:`OpenVPN with LDAP</configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP>`
+For a detailed example, refer to :doc:`OpenVPN with LDAP</configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP>`.
 
-Multi-factor Authentication
+Multi-factor authentication
 ===========================
 
-VyOS supports multi-factor authentication (MFA) or two-factor authentication
-using Time-based One-Time Password (TOTP). Compatible with Google Authenticator
-software token, other software tokens.
+VyOS supports multi-factor authentication (MFA) or two-factor authentication 
+using Time-based One-Time Passwords (TOTP). It is compatible with Google 
+Authenticator and other software tokens.
 
 Server side
 -----------
@@ -656,10 +665,11 @@ Server side
   set interfaces openvpn vtun20 tls certificate 'openvpn_vtun20'
   set interfaces openvpn vtun20 tls dh-params 'dh-pem'
 
-For every client in the openvpn server configuration a totp secret is created.
-To display the authentication information, use the command ``show interfaces openvpn vtun20 user user1 mfa qrcode``
+A TOTP secret is created for each client in the OpenVPN server configuration. 
+To display authentication information, use the following command: 
+``show interfaces openvpn vtun20 user user1 mfa qrcode``.
 
-An example:
+Example:
 
 .. code-block:: none
 
@@ -684,24 +694,25 @@ An example:
    █████████████████████████████████████
    █████████████████████████████████████
 
-Use the QR code to add the user account in Google authenticator application and
-on client side, use the OTP number as password.
+Scan the QR code to add the user account to Google Authenticator. On the client 
+side, use the generated OTP as the password.
 
-Authentication with Username/Password
+Authentication with username/password
 =====================================
 
-OpenVPN server allows to securely obtain a username and password from a connecting 
-client, and to use that information as a basis for authenticating the client.
+An OpenVPN server can securely obtain a username and password from a connecting 
+client and use this information for authentication. 
 
-First, configure the server to use an authentication plugin, which may be a 
-script. The OpenVPN server will call the plugin every time a client tries to 
-connect, passing it the username/password entered on the client
+First, configure the server to use an authentication plugin or script. The 
+server calls this plugin every time a client tries to connect, passing it the 
+client's credentials.
 
-In this exammple, the ``--auth-user-pass-verify`` directive is used with the 
-via-env method and a specified script path to validate the username and password provided by the client.
+In the following example, the ``--auth-user-pass-verify`` directive is used 
+with the via-env method and a specified script path to validate the client's 
+username and password.
 
-Server
-------
+Server configuration
+--------------------
 
 .. code-block:: none
 
@@ -719,7 +730,7 @@ Server
   set interfaces openvpn vtun10 tls certificate 'srv-1'
   set interfaces openvpn vtun10 tls dh-params 'dh-1'
 
-Example of /config/auth/check_user.sh, includes two testing users:
+The /config/auth/check_user.sh example includes two test users:
 
 .. code-block:: none
 
@@ -736,20 +747,20 @@ Example of /config/auth/check_user.sh, includes two testing users:
       exit 1
   fi
 
-Client
-------
+Client configuration
+--------------------
 
-One advantage of having the client certificate stored locally is the ability to create the client configuration.
-Use this command:
+Storing the client certificate locally lets you generate the OpenVPN client 
+configuration file. Use the following command:
 
 .. code-block:: none
 
   vyos@vyos:~$ generate openvpn client-config interface vtun10 ca ca-1 certificate client1
 
-Save the output to a file, and add the ``auth-user-pass`` directive to the client 
-configuration. It will direct the OpenVPN client to query the user for a 
-username/password, passing it on to the server over the secure TLS channel.
-You can use this file to import to any clients.
+Copy the output and save it as a .ovpn file. Add the ``auth-user-pass`` 
+directive to the file. This instructs the OpenVPN client to prompt the user 
+for a username and password, which are then sent to the server over the TLS 
+channel. You can now import this file into any OpenVPN client application.
 
 .. code-block:: none
 
@@ -852,4 +863,4 @@ You can use this file to import to any clients.
   
   </key>
 
-Login using the username and password, once prompted in the dialog.
+When prompted, log in with the username and password.