merge: resolve CLAUDE.md conflict, keep current branch version

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

38 files changed, 1663 insertions, 1067 deletions

diff --git a/docs/configuration/firewall/bridge.rst b/docs/configuration/firewall/bridge.rst
index fdf1179f..832bdf67 100644
--- a/docs/configuration/firewall/bridge.rst
+++ b/docs/configuration/firewall/bridge.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2024-08-05
+:lastproofread: 2026-03-28
 
 .. _firewall-configuration:
 
@@ -10,13 +10,15 @@ Bridge Firewall Configuration
 Overview
 ********
 
-In this section there's useful information on all firewall configuration that
-can be done regarding bridges, and appropriate op-mode commands.
-Configuration commands covered in this section:
+Learn more about bridge firewall configuration
+and related op-mode commands.
 
-.. cfgcmd:: set firewall bridge ...
+The following commands are covered in this section:
 
-From the main structure defined in :doc:`Firewall Overview</configuration/firewall/index>`
+.. cfgcmd:: set firewall bridge <options>
+
+From the main structure defined in
+:doc:`Firewall Overview</configuration/firewall/index>`
 in this section you can find detailed information only for the next part
 of the general structure:
 
@@ -35,7 +37,7 @@ of the general structure:
             - name
                + custom_name
 
-Traffic which is received by the router on an interface which is member of a
+Traffic that is received by the router on an interface that is a member of a
 bridge is processed on the **Bridge Layer**. Before the bridge decision is
 made, all packets are analyzed at **Prerouting**. First filters can be applied
 here, and also rules for ignoring connection tracking system can be configured.
@@ -43,15 +45,16 @@ The relevant configuration that acts in **prerouting** is:
 
   * ``set firewall bridge prerouting filter ...``.
 
-For traffic that needs to be switched internally by the bridge, base chain is
-**forward**, and it's base command for filtering is ``set firewall bridge
-forward filter ...``, which happens in stage 4, highlighted with red color.
+For traffic that needs to be switched internally by the bridge, the base
+chain is **forward**, and its base command for filtering is ``set firewall
+bridge forward filter ...``, which happens in stage 4, highlighted with red
+color.
 
 .. figure:: /_static/images/firewall-bridge-forward.*
 
-For traffic destined to the router itself, or that needs to be routed (assuming
-a layer3 bridge is configured), the base chain is **input**, the base command
-is ``set firewall bridge input filter ...`` and the path is:
+For traffic destined to the router itself or that needs to be routed
+(assuming a layer3 bridge is configured), the base chain is **input**, and the
+base command is ``set firewall bridge input filter ...`` and the path is:
 
 .. figure:: /_static/images/firewall-bridge-input.*
 
@@ -60,15 +63,15 @@ processed by the **IP Layer** firewall: IPv4 or IPv6 ruleset. Check once again
 the :doc:`general packet flow diagram</configuration/firewall/index>` if
 needed.
 
-And for traffic that originates from the bridge itself, the base chain is
-**output**, base command is ``set firewall bridge output filter ...``, and
-the path is:
+For traffic that originates from the bridge itself, the base chain is
+**output**, and the base command is ``set firewall bridge output filter
+...``, and the path is:
 
 .. figure:: /_static/images/firewall-bridge-output.*
 
-Custom bridge firewall chains can be created with the command ``set firewall bridge
-name <name> ...``. In order to use such custom chain, a rule with action jump,
-and the appropriate target should be defined in a base chain.
+Custom bridge firewall chains can be created with the command ``set firewall
+bridge name <name> ...``. To use such a custom chain, a rule with action jump
+and the appropriate target must be defined in a base chain.
 
 ************
 Bridge Rules
@@ -83,8 +86,8 @@ rule will be executed.
 Actions
 =======
 
-If a rule is defined, then an action must be defined for it. This tells the
-firewall what to do if all matching criterea in the rule are met.
+If a rule is defined, an action must also be defined for it. This tells the
+firewall what to do if all matching criteria in the rule are met.
 
 In firewall bridge rules, the action can be:
 
@@ -169,7 +172,7 @@ In firewall bridge rules, the action can be:
    queue-options fanout
 
 Also, **default-action** is an action that takes place whenever a packet does
-not match any rule in its' chain. For base chains, possible options for
+not match any rule in its chain. For base chains, possible options for
 **default-action** are **accept** or **drop**.
 
 .. cfgcmd:: set firewall bridge forward filter default-action
@@ -202,8 +205,8 @@ not match any rule in its' chain. For base chains, possible options for
 Firewall Logs
 =============
 
-Logging can be enable for every single firewall rule. If enabled, other
-log options can be defined.
+You can enable logging for every firewall rule. If enabled, other log options
+can be configured.
 
 .. cfgcmd:: set firewall bridge forward filter rule <1-999999> log
 .. cfgcmd:: set firewall bridge input filter rule <1-999999> log
@@ -287,7 +290,7 @@ log options can be defined.
 Firewall Description
 ====================
 
-For reference, a description can be defined for every defined custom chain.
+You can define a description for reference for every custom chain.
 
 .. cfgcmd:: set firewall bridge name <name> description <text>
 
@@ -309,8 +312,8 @@ For reference, a description can be defined for every defined custom chain.
 Rule Status
 ===========
 
-When defining a rule, it is enabled by default. In some cases, it is useful to
-just disable the rule, rather than removing it.
+By default, when you define a rule, it is enabled. In some cases, it is
+useful to disable the rule instead of removing it.
 
 .. cfgcmd:: set firewall bridge forward filter rule <1-999999> disable
 .. cfgcmd:: set firewall bridge input filter rule <1-999999> disable
@@ -323,11 +326,11 @@ just disable the rule, rather than removing it.
 Matching criteria
 =================
 
-There are a lot of matching criteria against which the packet can be tested.
-Please refer to :doc:`IPv4</configuration/firewall/ipv4>` and
+There are many matching criteria against which a packet can be tested. Refer
+to :doc:`IPv4</configuration/firewall/ipv4>` and
 :doc:`IPv6</configuration/firewall/ipv6>` matching criteria for more details.
 
-Since bridges operats at layer 2, both matchers for IPv4 and IPv6 are
+Since bridges operate at layer 2, both matchers for IPv4 and IPv6 are
 supported in bridge firewall configuration. Same applies to firewall groups.
 
 Same specific matching criteria that can be used in bridge firewall are
@@ -434,15 +437,15 @@ are:
 
 .. cfgcmd:: set firewall global-options apply-to-bridged-traffic ipv4
 
-   This command enables the IPv4 firewall for bridged traffic. If this
-   options is used, then packet will also be parsed by rules defined in ``set
-   firewall ipv4 ...`` 
+   This command enables the IPv4 firewall for bridged traffic. If this option
+   is used, packets are also parsed by rules defined in ``set firewall ipv4
+   ...`` 
 
 .. cfgcmd:: set firewall global-options apply-to-bridged-traffic ipv6
 
-   This command enables the IPv6 firewall for bridged traffic. If this
-   options is used, then packet will also be parsed by rules defined in ``set
-   firewall ipv6 ...`` 
+   This command enables the IPv6 firewall for bridged traffic. If this option
+   is used, packets are also parsed by rules defined in ``set firewall ipv6
+   ...`` 
 
 ***********************
 Operation-mode Firewall
diff --git a/docs/configuration/firewall/flowtables.rst b/docs/configuration/firewall/flowtables.rst
index 35fb0add..f996a59e 100644
--- a/docs/configuration/firewall/flowtables.rst
+++ b/docs/configuration/firewall/flowtables.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2024-07-02
+:lastproofread: 2026-03-30
 
 .. _firewall-flowtables-configuration:
 
@@ -6,21 +6,18 @@
 Flowtables Firewall Configuration
 #################################
 
-.. note:: **Documentation under development**
+.. include:: /_include/need_improvement.txt
 
 ********
 Overview
 ********
 
-In this section there's useful information on all firewall configuration that
-can be done regarding flowtables.
+This section provides information on firewall configuration for flowtables.
 
-.. cfgcmd:: set firewall flowtables ...
+.. cfgcmd:: set firewall flowtable ...
 
-From the main structure defined in
-:doc:`Firewall Overview</configuration/firewall/index>`
-in this section you can find detailed information only for the next part
-of the general structure:
+To learn about the general traffic flow in VyOS firewalls,
+see :doc:`Firewall </configuration/firewall/index>`.
 
 .. code-block:: none
 
@@ -30,24 +27,23 @@ of the general structure:
                + ...
 
 
-Flowtables allow you to define a fastpath through the flowtable datapath.
-The flowtable supports for the layer 3 IPv4 and IPv6 and the layer 4 TCP
-and UDP protocols.
+Flowtables let you define a fastpath through the flowtable datapath.
+Flowtables support layer 3 (IPv4 and IPv6) and layer 4 (TCP and UDP)
+protocols.
 
 .. figure:: /_static/images/firewall-flowtable-packet-flow.*
 
-Once the first packet of the flow successfully goes through the IP forwarding
-path (black circles path), from the second packet on, you might decide to
-offload the flow to the flowtable through your ruleset. The flowtable
-infrastructure provides a rule action that allows you to specify when to add
-a flow to the flowtable (On forward filtering, red circle number 6)
+After the first packet successfully traverses the IP forwarding path (black
+circles path), you can offload subsequent packets to the flowtable through your
+ruleset. You specify when to add a flow to the flowtable during forward
+filtering (red circle number 6).
 
-A packet that finds a matching entry in the flowtable (flowtable hit) is
-transmitted to the output netdevice, hence, packets bypass the classic IP
-forwarding path and uses the **Fast Path** (orange circles path). The visible
-effect is that you do not see these packets from any of the Netfilter
-hooks coming after ingress. In case that there is no matching entry in the
-flowtable (flowtable miss), the packet follows the classic IP forwarding path.
+When a packet finds a matching entry in the flowtable (flowtable hit), the
+system transmits it to the output netdevice. This means packets bypass the
+classic IP forwarding path and use the **Fast Path** (orange circles path).
+As a result, you do not see these packets from any Netfilter hooks after
+ingress. If no matching entry exists in the flowtable (flowtable miss), the
+packet traverses the classic IP forwarding path.
 
 .. note:: **Flowtable Reference:**
    https://docs.kernel.org/networking/nf_flowtable.html
@@ -57,64 +53,68 @@ flowtable (flowtable miss), the packet follows the classic IP forwarding path.
 Flowtable Configuration
 ***********************
 
-In order to use flowtables, the minimal configuration needed includes:
+To use flowtables, you need to configure the following:
 
-   * Create flowtable: create flowtable, which includes the interfaces
+   * Create a flowtable that includes the interfaces
      that are going to be used by the flowtable.
 
-   * Create firewall rule: create a firewall rule, setting action to
-     ``offload`` and using desired flowtable for ``offload-target``.
+   * Create a firewall rule. Set the action to
+     ``offload`` and use your desired flowtable for ``offload-target``.
 
 Creating a flow table:
 
 .. cfgcmd:: set firewall flowtable <flow_table_name> interface <iface>
 
-   Define interfaces to be used in the flowtable.
+   Specify interfaces to use in the flowtable.
 
 .. cfgcmd:: set firewall flowtable <flow_table_name> description <text>
 
-Provide a description to the flow table.
+Provide a description for the flow table.
 
 .. cfgcmd:: set firewall flowtable <flow_table_name> offload
    <hardware | software>
 
-   Define type of offload to be used by the flowtable: ``hardware`` or
-   ``software``. By default, ``software`` offload is used.
+   Specify the offload type the flowtable uses: ``hardware`` or
+   ``software``. The default is ``software`` offload.
 
-.. note:: **Hardware offload:** should be supported by the NICs used.
+.. note:: **Hardware offload**: Make sure your network interface controller
+   (NIC) supports hardware offloading and that you have the necessary drivers
+    installed before enabling this option.
 
 Creating rules for using flow tables:
 
 .. cfgcmd:: set firewall [ipv4 | ipv6] forward filter rule <1-999999>
    action offload
 
-   Create firewall rule in forward chain, and set action to ``offload``.
+   Create a firewall rule in the forward chain with the action set to
+   ``offload``.
 
 .. cfgcmd:: set firewall [ipv4 | ipv6] forward filter rule <1-999999>
    offload-target <flowtable>
 
-   Create firewall rule in forward chain, and define which flowtbale
-   should be used. Only applicable if action is ``offload``.
+   Create a firewall rule in the forward chain and specify which flowtable
+   to use. Only applicable if the action is ``offload``.
 
 *********************
 Configuration Example
 *********************
 
-Things to be considered in this setup:
+Consider the following in this setup:
 
-   * Two interfaces are going to be used in the flowtables: eth0 and eth1
+   * This example uses two interfaces in the flowtables: ``eth0`` and ``eth1``.
 
-   * Minimum firewall ruleset is provided, which includes some filtering rules,
-     and appropriate rules for using flowtable offload capabilities.
+   * The example provides a minimal firewall ruleset with filtering rules
+     and rules for using flowtable offload capabilities.
 
-As described, the first packet will be evaluated by the firewall path, so a
-desired connection should be explicitly accepted. Same thing should be taken
-into account for traffic in reverse order. In most cases state policies are
-used in order to accept a connection in the reverse path.
+The first packet is evaluated by the firewall path, so a
+desired connection should be explicitly accepted.
+The same should occur for traffic in reverse order.
+In most cases, state policies are
+used to accept a connection in the reverse path.
 
-We will only accept traffic coming from interface eth0, protocol tcp and
-destination port 1122. All other traffic trespassing the router should be
-blocked.
+In the following example only traffic coming from interface ``eth0``,
+TCP protocol, and destination port 1122 is accepted.
+All other traffic to the router is dropped.
 
 Commands
 --------
@@ -140,33 +140,32 @@ Commands
 Explanation
 -----------
 
-Analysis on what happens for desired connection:
+Here's what happens for a desired connection:
 
-   1. Firstly, a packet is received on eth0, with destination address 192.0.2.100,
-   protocol tcp and destination port 1122. Assume such destination address is
-   reachable through interface eth1.
+   1. A packet arrives on ``eth0`` with destination address ``192.0.2.100``, TCP
+      protocol, and destination port 1122. Assume this address is reachable
+      through interface ``eth1``.
 
-   2. Since this is the first packet, connection status of this connection,
-   so far is **new**. So neither rule 10 nor 20 are valid.
+   2. For this first packet, the connection state is **new**. Neither rule 10
+      nor rule 20 applies.
 
-   3. Rule 110 is hit, so connection is accepted.
+   3. Rule 110 matches, so the connection is accepted.
 
-   4. Once an answer from server 192.0.2.100 is seen in opposite direction,
-   connection state will be triggered to **established**, so this reply is
-   accepted in rule 20.
+   4. When the server 192.0.2.100 replies, the connection state becomes
+      **established**, and rule 20 accepts the reply.
 
-   5. The second packet for this connection is received by the router. Since
-   connection state is **established**, then rule 10 is hit, and a new entry
-   in the flowtable FT01 is added for this connection.
+   5. The router receives the second packet for this connection. Because the
+      connection state is **established**, rule 10 matches and adds a new
+      entry in the flowtable FT01 for this connection.
 
-   6. All the following packets will skip the traditional path, will be
-   offloaded and use the **Fast Path**.
+   6. Subsequent packets skip the traditional path and use the **Fast Path**
+      for offloading.
 
 Checks
 ------
 
-It's time to check the conntrack table, to see if any connections were accepted,
-and if it was properly offloaded
+Check the conntrack table to verify that the system accepted and properly
+offloaded connections.
 
 .. code-block:: none
 
diff --git a/docs/configuration/firewall/global-options.rst b/docs/configuration/firewall/global-options.rst
index 60addbe9..8eec5c3f 100644
--- a/docs/configuration/firewall/global-options.rst
+++ b/docs/configuration/firewall/global-options.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2024-07-03
+:lastproofread: 2026-03-30
 
 .. _firewall-global-options-configuration:
 
@@ -10,9 +10,9 @@ Global Options Firewall Configuration
 Overview
 ********
 
-Some firewall settings are global and have an affect on the whole system.
-In this section there's useful information about these global-options that can
-be configured using vyos cli.
+Some firewall settings are global and affect the entire system. This section
+provides information about these global options that you can configure using
+the VyOS CLI.
 
 Configuration commands covered in this section:
 
@@ -25,51 +25,50 @@ Configuration
 .. cfgcmd:: set firewall global-options all-ping [enable | disable]
 
    By default, when VyOS receives an ICMP echo request packet destined for
-   itself, it will answer with an ICMP echo reply, unless you prevent it
-   through its firewall.
+   itself, it answers with an ICMP echo reply, unless your firewall prevents
+   it.
 
-   With the firewall you can set rules to accept, drop or reject ICMP in,
-   out or local traffic. You can also use the general **firewall all-ping**
-   command. This command affects only to LOCAL (packets destined for your
-   VyOS system), not to IN or OUT traffic.
+   You can set firewall rules to accept, drop, or reject ICMP in, out, or
+   local traffic. You can also use the **firewall global-options all-ping**
+   command. This command affects only LOCAL traffic (packets destined for your
+   VyOS system), not IN or OUT traffic.
 
-   .. note:: **firewall global-options all-ping** affects only to LOCAL
-      and it always behaves in the most restrictive way
+   .. note:: **firewall global-options all-ping** affects only LOCAL traffic
+      and always behaves in the most restrictive way
 
    .. code-block:: none
 
       set firewall global-options all-ping enable
 
-   When the command above is set, VyOS will answer every ICMP echo request
-   addressed to itself, but that will only happen if no other rule is
-   applied dropping or rejecting local echo requests. In case of conflict,
-   VyOS will not answer ICMP echo requests.
+   When you set this command, VyOS answers every ICMP echo request addressed
+   to itself, but that response occurs only if no other rule drops or rejects
+   local echo requests. In case of conflict, VyOS does not answer ICMP echo
+   requests.
 
    .. code-block:: none
 
       set firewall global-options all-ping disable
 
-   When the command above is set, VyOS will answer no ICMP echo request
-   addressed to itself at all, no matter where it comes from or whether
-   more specific rules are being applied to accept them.
+   When you set this command, VyOS answers no ICMP echo requests addressed to
+   itself, regardless of where they come from or what specific rules accept
+   them.
 
 .. cfgcmd:: set firewall global-options apply-to-bridged-traffic [ipv4 | ipv6]
 
-   Use these commands to also use IPv4, or IPv6 firewall rules for bridged
-   traffic
+   Apply IPv4 or IPv6 firewall rules to bridged traffic.
 
 .. cfgcmd:: set firewall global-options broadcast-ping [enable | disable]
 
-   This setting enables or disables the response to icmp broadcast
-   messages. The following system parameter will be altered:
+   Enable or disable the response to ICMP broadcast messages. The system
+   alters the following parameter:
 
    * ``net.ipv4.icmp_echo_ignore_broadcasts``
 
 .. cfgcmd:: set firewall global-options ip-src-route [enable | disable]
 .. cfgcmd:: set firewall global-options ipv6-src-route [enable | disable]
 
-   This setting handles if VyOS accepts packets with a source route
-   option. The following system parameters will be altered:
+   Set whether VyOS accepts packets with a source route option.
+   The following sysctl parameters will be changed:
 
    * ``net.ipv4.conf.all.accept_source_route``
    * ``net.ipv6.conf.all.accept_source_route``
@@ -78,23 +77,23 @@ Configuration
 .. cfgcmd:: set firewall global-options ipv6-receive-redirects
    [enable | disable]
 
-   Enable or disable ICMPv4 or ICMPv6 redirect messages being accepted by
-   VyOS. The following system parameters will be altered:
+   Allow VyOS to accept ICMPv4 and ICMPv6 redirect messages.
+   The following sysctl parameters will be changed:
 
    * ``net.ipv4.conf.all.accept_redirects``
    * ``net.ipv6.conf.all.accept_redirects``
 
 .. cfgcmd:: set firewall global-options send-redirects [enable | disable]
 
-   Enable or disable ICMPv4 redirect messages being sent by VyOS
-   The following system parameter will be altered:
+   Allow VyOS to send ICMPv4 redirect messages.
+   The following sysctl parameter will be changed:
 
    * ``net.ipv4.conf.all.send_redirects``
 
 .. cfgcmd:: set firewall global-options log-martians [enable | disable]
 
-   Enable or disable the logging of martian IPv4 packets.
-   The following system parameter will be altered:
+   Allow VyOS to log martian IPv4 packets.
+   The following sysctl parameter will be changed:
 
    * ``net.ipv4.conf.all.log_martians``
 
@@ -102,22 +101,22 @@ Configuration
    [strict | loose | disable]
 
    Set the IPv4 source validation mode.
-   The following system parameter will be altered:
+   The following sysctl parameter will be changed:
 
    * ``net.ipv4.conf.all.rp_filter``
 
 .. cfgcmd:: set firewall global-options syn-cookies [enable | disable]
 
-   Enable or disable if VyOS uses IPv4 TCP SYN Cookies.
-   The following system parameter will be altered:
+   Allow VyOS to use IPv4 TCP SYN Cookies.
+   The following sysctl parameter will be changed:
 
    * ``net.ipv4.tcp_syncookies``
 
 .. cfgcmd:: set firewall global-options twa-hazards-protection
    [enable | disable]
 
-   Enable or Disable VyOS to be :rfc:`1337` conformant.
-   The following system parameter will be altered:
+   Enable or disable VyOS :rfc:`1337` conformance.
+   The following sysctl parameter will be changed:
 
    * ``net.ipv4.tcp_rfc1337``
 
@@ -151,10 +150,9 @@ Configuration
 
    Set the global setting for related connections.
 
-VyOS supports setting timeouts for connections according to the
-connection type. You can set timeout values for generic connections, for ICMP
-connections, UDP connections, or for TCP connections in a number of different
-states.
+VyOS supports setting timeouts for connections by connection type. You can
+set timeout values for generic connections, ICMP connections, UDP
+connections, or TCP connections in various states.
 
 .. cfgcmd:: set firewall global-options timeout icmp <1-21474836>
     :defaultvalue:
diff --git a/docs/configuration/firewall/groups.rst b/docs/configuration/firewall/groups.rst
index b1accca5..9d29866e 100644
--- a/docs/configuration/firewall/groups.rst
+++ b/docs/configuration/firewall/groups.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2024-07-03
+:lastproofread: 2026-03-30
 
 .. _firewall-groups-configuration:
 
@@ -11,20 +11,20 @@ Configuration
 *************
 
 Firewall groups represent collections of IP addresses, networks, ports,
-mac addresses, domains or interfaces. Once created, a group can be referenced
-by firewall, nat and policy route rules as either a source or destination
-matcher, and/or as inbound/outbound in the case of interface group.
+MAC addresses, domains, or interfaces. You can reference a group in firewall,
+NAT, and policy route rules as either a source or destination matcher, and/or
+as inbound or outbound in the case of interface groups.
 
 Address Groups
 ==============
 
-In an **address group** a single IP address or IP address range is defined.
+An **address group** contains a single IP address or IP address range.
 
 .. cfgcmd:: set firewall group address-group <name> address [address |
    address range]
 .. cfgcmd:: set firewall group ipv6-address-group <name> address <address>
 
-   Define a IPv4 or a IPv6 address group
+   Define an IPv4 or IPv6 address group.
 
    .. code-block:: none
 
@@ -35,30 +35,31 @@ In an **address group** a single IP address or IP address range is defined.
 .. cfgcmd:: set firewall group address-group <name> description <text>
 .. cfgcmd:: set firewall group ipv6-address-group <name> description <text>
 
-   Provide a IPv4 or IPv6 address group description
+   Provide an IPv4 or IPv6 address group description.
 
 Remote Groups
 ==============
 
-A **remote-group** takes an argument of a URL hosting a linebreak-deliminated
-list of IPv4 and/or IPv6 addresses, CIDRs and ranges. VyOS will pull this list periodicity
-according to the frequency defined in the firewall **resolver-interval** and load
-matching entries into the group for use in rules. The list will be cached in
-persistent storage, so in cases of update failure rules will still function.
+A **remote-group** uses a URL that hosts a newline-delimited list of IPv4
+and/or IPv6 addresses, CIDRs, and ranges. VyOS pulls this list periodically
+according to the frequency you define in the firewall **resolver-interval**
+and loads matching entries into the group for use in rules. The list is cached
+in persistent storage, so rules continue to function if updates fail.
 
 .. cfgcmd:: set firewall group remote-group <name> url <http(s) url>
 
-   Define remote list of IPv4 and/or IPv6 addresses/ranges/CIDRs to fetch
+   Specify a remote list of IPv4 and/or IPv6 addresses, ranges, and CIDRs
+   to fetch.
 
 .. cfgcmd:: set firewall group remote-group <name> description <text>
 
-   Set a description for a remote group
+   Set a description for a remote group.
 
-The format of the remote list is very flexible. VyOS will attempt to parse the
-first word of each line as an entry, and will skip if it cannot find a valid
-match. Lines that begin with an alphanumeric character but do not match valid IPv4
-or IPv6 addresses, ranges, or CIDRs will be logged to the system log. Below is a
-list of acceptable matches that would be parsed correctly:
+The remote list format is flexible. VyOS attempts to parse the first word of
+each line as an entry and skips lines it cannot match. Lines that begin with
+an alphanumeric character but do not match valid IPv4 or IPv6 addresses,
+ranges, or CIDRs are logged to the system log. The following examples show
+acceptable formats that VyOS parses correctly:
 
 .. code-block:: none
 
@@ -72,15 +73,14 @@ list of acceptable matches that would be parsed correctly:
 Network Groups
 ==============
 
-While **network groups** accept IP networks in CIDR notation, specific
-IP addresses can be added as a 32-bit prefix. If you foresee the need
-to add a mix of addresses and networks, then a network group is
-recommended.
+**Network groups** accept IP networks in CIDR notation. You can add specific
+IP addresses as a 32-bit prefix. If you need to add a mix of addresses and
+networks, use a network group.
 
 .. cfgcmd:: set firewall group network-group <name> network <CIDR>
 .. cfgcmd:: set firewall group ipv6-network-group <name> network <CIDR>
 
-   Define a IPv4 or IPv6 Network group.
+   Define an IPv4 or IPv6 network group.
 
    .. code-block:: none
 
@@ -100,7 +100,9 @@ An **interface group** represents a collection of interfaces.
 
 .. cfgcmd:: set firewall group interface-group <name> interface <text>
 
-   Define an interface group. Wildcard are accepted too.
+   Define an interface group.
+   Wildcard ``*`` is supported. For example: ``eth3*``.
+   Prepend the character ``!`` to invert the criteria. For example: ``!eth2``.
 
 .. code-block:: none
 
@@ -109,22 +111,21 @@ An **interface group** represents a collection of interfaces.
 
 .. cfgcmd:: set firewall group interface-group <name> description <text>
 
-   Provide an interface group description
+   Provide an interface group description.
 
 Port Groups
 ===========
 
-A **port group** represents only port numbers, not the protocol. Port
-groups can be referenced for either TCP or UDP. It is recommended that
-TCP and UDP groups are created separately to avoid accidentally
-filtering unnecessary ports. Ranges of ports can be specified by using
-`-`.
+A **port group** represents only port numbers, not the protocol. You can
+reference port groups for either TCP or UDP. Create TCP and UDP groups
+separately to avoid accidentally filtering unnecessary ports. Specify port
+ranges by using `-`.
 
 .. cfgcmd:: set firewall group port-group <name> port
    [portname | portnumber | startport-endport]
 
    Define a port group. A port name can be any name defined in
-   /etc/services. e.g.: http
+   /etc/services. For example, ``http``.
 
    .. code-block:: none
 
@@ -152,7 +153,7 @@ A **mac group** represents a collection of mac addresses.
 
 .. cfgcmd:: set firewall group mac-group <name> description <text>
 
-   Provide a mac group description.
+      Provide a MAC group description.
 
 Domain Groups
 =============
@@ -169,24 +170,21 @@ A **domain group** represents a collection of domains.
 
 .. cfgcmd:: set firewall group domain-group <name> description <text>
 
-   Provide a domain group description.
+      Provide a domain group description.
 
 Dynamic Groups
 ==============
 
-Firewall dynamic groups are different from all the groups defined previously
-because, not only they can be used as source/destination in firewall rules,
-but members of these groups are not defined statically using vyos
-configuration.
-
-Instead, members of these groups are added dynamically using firewall
-rules.
+Firewall dynamic groups differ from other groups because you can use them as
+source/destination in firewall rules, and members are not defined statically
+in VyOS configuration. Instead, firewall rules dynamically add members to
+these groups.
 
 Defining Dynamic Address Groups
 -------------------------------
 
-Dynamic address group is supported by both IPv4 and IPv6 families.
-Commands used to define dynamic IPv4|IPv6 address groups are:
+Dynamic address groups support both IPv4 and IPv6 families. Use these
+commands to define dynamic IPv4 and IPv6 address groups:
 
 .. cfgcmd:: set firewall group dynamic-group address-group <name>
 .. cfgcmd:: set firewall group dynamic-group ipv6-address-group <name>
@@ -201,8 +199,8 @@ Add description to firewall groups:
 Adding elements to Dynamic Firewall Groups
 ------------------------------------------
 
-Once dynamic firewall groups are defined, they should be used in firewall
-rules in order to dynamically add elements to it.
+After you define dynamic firewall groups, use them in firewall rules to
+dynamically add elements to them.
 
 Commands used for this task are:
 
@@ -228,11 +226,11 @@ Commands used for this task are:
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999> add-address-to-group
    source-address address-group <name>
 
-Also, specific timeouts can be defined per rule. In case rule gets a hit,
-a source or destinatination address will be added to the group, and this
-element will remain in the group until the timeout expires. If no timeout
-is defined, then the element will remain in the group until next reboot,
-or until a new commit that changes firewall configuration is done.
+You can define specific timeouts per rule. When a rule matches, the source or
+destination address is added to the group, and the element remains in the group
+until the timeout expires. If you do not define a timeout, the element remains
+in the group until the next reboot or until you commit firewall configuration
+changes.
 
 .. cfgcmd:: set firewall ipv4 [forward | input | output] filter rule
    <1-999999> add-address-to-group [destination-address | source-address]
@@ -259,7 +257,7 @@ Timeout can be defined using seconds, minutes, hours or days:
 Using Dynamic Firewall Groups
 -----------------------------
 
-As any other firewall group, dynamic firewall groups can be used in firewall
+Like other firewall groups, you can use dynamic firewall groups in firewall
 rules as matching options. For example:
 
 .. code-block:: none
@@ -274,10 +272,9 @@ Examples
 General example
 ===============
 
-As said before, once firewall groups are created, they can be referenced
-either in firewall, nat, nat66 and/or policy-route rules.
-
-Here is an example were multiple groups are created:
+After you create firewall groups, you can reference them in firewall, NAT,
+NAT66, and/or policy-route rules. The following example creates multiple
+groups:
 
    .. code-block:: none
 
@@ -314,10 +311,9 @@ And next, some configuration example where groups are used:
 Port knocking example
 =====================
 
-Using dynamic firewall groups, we can secure access to the router, or any other
-device if needed, by using the technique of port knocking.
-
-A 4 step port knocking example is shown next:
+You can use dynamic firewall groups with port knocking to secure access to
+the router or any other device. The following example shows a 4-step port
+knocking configuration:
 
    .. code-block:: none
 
@@ -371,11 +367,10 @@ Before testing, we can check the members of firewall groups:
       [edit]
       vyos@vyos#
 
-With this configuration, in order to get ssh access to the router, the user
-needs to:
+With this configuration, to gain SSH access to the router, the user must:
 
-1. Generate a new TCP connection with destination port 9990. As shown next,
-a new entry was added to dynamic firewall group **PN_01**
+1. Create a new TCP connection to destination port 9990. A new entry is added
+   to dynamic firewall group ``PN_01``.
 
    .. code-block:: none
 
@@ -390,8 +385,8 @@ a new entry was added to dynamic firewall group **PN_01**
       [edit]
       vyos@vyos#
 
-2. Generate a new TCP connection with destination port 9991. As shown next,
-a new entry was added to dynamic firewall group **PN_02**
+2. Create a new TCP connection to destination port 9991. A new entry is added
+   to dynamic firewall group ``PN_02``.
 
    .. code-block:: none
 
@@ -406,8 +401,8 @@ a new entry was added to dynamic firewall group **PN_02**
       [edit]
       vyos@vyos#
 
-3. Generate a new TCP connection with destination port 9992. As shown next,
-a new entry was added to dynamic firewall group **ALLOWED**
+3. Create a new TCP connection to destination port 9992. A new entry is added
+   to dynamic firewall group ``ALLOWED``.
 
    .. code-block:: none
 
@@ -422,7 +417,8 @@ a new entry was added to dynamic firewall group **ALLOWED**
       [edit]
       vyos@vyos#
 
-4. Now the user can connect through ssh to the router (assuming ssh is configured).
+4. Now you can connect via SSH to the router (assuming SSH is
+   configured).
 
 **************
 Operation-mode
@@ -431,9 +427,9 @@ Operation-mode
 .. opcmd:: show firewall group
 .. opcmd:: show firewall group <name>
 
-   Overview of defined groups. You see the firewall group name, type,
-   references (where the group is used), members, timeout and expiration (last
-   two only present in dynamic firewall groups).
+   Display an overview of defined groups, including the firewall group name,
+   type, references (where the group is used), members, timeout, and
+   expiration (the last two only apply to dynamic firewall groups).
 
 Here is an example of such command:
 
diff --git a/docs/configuration/firewall/index.rst b/docs/configuration/firewall/index.rst
index 4fd9b208..c4b3c808 100644
--- a/docs/configuration/firewall/index.rst
+++ b/docs/configuration/firewall/index.rst
@@ -1,128 +1,122 @@
-:lastproofread: 2024-08-05
+:lastproofread: 2026-03-30
 
 ########
 Firewall
 ########
 
-.. warning:: Due to a race condition that can lead to a failure during boot
-   process, all interfaces are initialized before firewall is configured. This
-   leads to a situation where the system is open to all traffic, and can be
-   considered as a security risk.
+.. warning:: Due to a boot-time race condition, all interfaces initialize
+   before the firewall. This temporarily leaves the system open to all traffic
+   and poses a security risk.
 
-As VyOS is based on Linux it leverages its firewall. The Netfilter project
-created iptables and its successor nftables for the Linux kernel to
-work directly on packet data flows. This now extends the concept of 
-zone-based security to allow for manipulating the data at multiple stages once 
-accepted by the network interface and the driver before being handed off to 
-the destination (e.g., a web server OR another device).
+VyOS uses Netfilter. The Netfilter
+project developed ``iptables`` and its successor ``nftables`` for the Linux
+kernel to process packet data flows directly. This extends the concept of
+zone-based security to let you manipulate data at multiple stages after the
+network interface and driver accept it, and before sending it to its
+destination (for example, a web server or another device).
 
-A simplified traffic flow diagram, based on Netfilter packet flow, is shown 
-next, in order to have a full view and understanding of how packets are 
-processed, and what possible paths traffic can take.
+The following is a simplified traffic flow diagram based on Netfilter
+packet flow.
+This diagram provides an overview of how packets are processed and the
+possible paths traffic can take.
 
 .. figure:: /_static/images/firewall-gral-packet-flow.*
 
-The main points regarding this packet flow and terminology used in VyOS 
-firewall are covered below:
+The main points regarding packet flow and terminology in VyOS firewall
+are:
 
-   * **Bridge Port?**: choose appropriate path based on whether interface 
-     where the packet was received is part of a bridge, or not.
+   * **Bridge Port?**: Choose the appropriate path based on whether the
+     interface where the packet was received is part of a bridge.
 
-If the interface where the packet was received isn't part of a bridge, then 
+If the interface where the packet was received is not part of a bridge, the
 packet is processed at the **IP Layer**:
 
-   * **Prerouting**: All packets that are received by the router
-     are processed in this stage, regardless of the destination of the packet.
-     Starting from vyos-1.5-rolling-202406120020, a new section was added to 
-     the firewall configuration. There are several actions that can be done in
-     this stage, and currently these actions are also defined in different
-     parts of the VyOS configuration. Order is important, and the relevant 
-     configuration that acts in this stage are:
+   * **Prerouting**: The router processes all packets in this stage,
+     regardless of the destination. You can perform several actions in
+     this stage, and these actions are also defined in different parts of the
+     VyOS configuration. Order is important. The relevant configuration that
+     applies in this stage includes:
 
-      * **Firewall prerouting**: rules defined under ``set firewall [ipv4 |
-        ipv6] prerouting raw...``. All rules defined in this section are
-        processed before connection tracking subsystem.
+      * **Firewall prerouting**: Rules you define under ``set firewall
+        [ipv4 | ipv6] prerouting raw...``. The system processes all rules in
+        this section before the connection tracking subsystem.
 
-      * **Conntrack Ignore**: rules defined under ``set system conntrack ignore
-        [ipv4 | ipv6] ...``. Starting from vyos-1.5-rolling-202406120020,
-        configuration done in this section can be done in ``firewall [ipv4 |
-        ipv6] prerouting ...``. For compatibility reasons, this feature is
-        still present, but it will be removed in the future.
+      * **Conntrack Ignore**: Rules you define under ``set system conntrack
+        ignore [ipv4 | ipv6] ...``. You can configure this section with
+        ``firewall [ipv4 | ipv6] prerouting ...``. For compatibility reasons,
+        this feature is supported, but will be deprecated in the future.
 
-      * **Policy Route**: rules defined under ``set policy [route | route6]
-        ...``.
+      * **Policy Route**: Rules you define under ``set policy [route |
+        route6] ...``.
 
-      * **Destination NAT**: rules defined under ``set [nat | nat66]
+      * **Destination NAT**: Rules you define under ``set [nat | nat66]
         destination...``.
 
-   * **Destination is the router?**: choose an appropriate path based on
-     destination IP address. Transit forward continues to **forward**,
-     while traffic where the destination IP address is configured on the router
-     continues to **input**.
+   * **Destination is the router?**: Choose the appropriate path based on the
+     destination IP address. Transit traffic continues to **forward**, while
+     traffic destined for the router continues to **input**.
 
-   * **Input**: stage where traffic destined for the router itself can be
-     filtered and controlled. This is where all rules for securing the router
-     should take place. This includes ipv4 and ipv6 filtering rules, defined
-     in:
+   * **Input**: The stage where you filter and control traffic destined for
+     the router itself. This is where you enforce all rules for securing the
+     router. This includes IPv4 and IPv6 filtering rules, defined in:
 
      * ``set firewall ipv4 input filter ...``.
 
      * ``set firewall ipv6 input filter ...``.
 
-   * **Forward**: stage where transit traffic can be filtered and controlled.
-     This includes ipv4 and ipv6 filtering rules, defined in:
+   * **Forward**: The stage where you filter and control transit traffic.
+     This includes IPv4 and IPv6 filtering rules, defined in:
 
      * ``set firewall ipv4 forward filter ...``.
 
      * ``set firewall ipv6 forward filter ...``.
 
-   * **Output**: stage where traffic that originates from the router itself
-     can be filtered and controlled. Bear in mind that this traffic can be a
-     new connection originated by a internal process running on the VyOS router
-     such as NTP, or a response to traffic received externally through
-     **input** (for example response to an ssh login attempt to the router).
-     This includes ipv4 and ipv6 rules, and two different sections are present:
+   * **Output**: The stage where you filter and control traffic that the
+     router originates. Note that this traffic comes from either a new
+     connection that an internal process on the VyOS router (such as NTP)
+     originates or a response to traffic the router receives externally through
+     **input** (for example, a response to an SSH login attempt). This includes
+     IPv4 and IPv6 rules, and two different sections apply:
 
-     * **Output Prerouting**: ``set firewall [ipv4 | ipv6] output filter ...``.
-       As described in **Prerouting**, rules defined in this section are
-       processed before connection tracking subsystem.
+     * **Output Prerouting**: ``set firewall [ipv4 | ipv6] output
+       filter ...``. As described in **Prerouting**, the system processes
+       rules in this section before the connection tracking subsystem.
 
      * **Output Filter**: ``set firewall [ipv4 | ipv6] output filter ...``.
 
-   * **Postrouting**: as in **Prerouting**, several actions defined in
-     different parts of VyOS configuration are performed in this
-     stage. This includes:
+   * **Postrouting**: As in **Prerouting**, you can perform several actions
+     defined in different parts of VyOS configuration in this stage. This
+     includes:
 
-     * **Source NAT**: rules defined under ``set [nat | nat66]
+     * **Source NAT**: Rules you define under ``set [nat | nat66]
        destination...``.
 
-If the interface where the packet was received is part of a bridge, then 
-the packet is processed at the **Bridge Layer**:
+If the interface where the packet was received is part of a bridge, the
+packet is processed at the **Bridge Layer**:
 
-   * **Prerouting (Bridge)**: all packets that are received by the bridge are
-     processed in this stage, regardless of the destination of the packet.
-     First filters can be applied here, and/or also configure rules for
-     ignoring connection tracking system. The relevant configuration that
-     acts in:
+   * **Prerouting (Bridge)**: The bridge processes all packets it receives in
+     this stage, regardless of the destination. First, you can apply filters
+     here, or you can configure rules that ignore the connection tracking
+     system. The relevant configuration that applies:
 
      * ``set firewall bridge prerouting filter ...``.
 
-   * **Forward (Bridge)**: stage where traffic that is trespassing through the
-     bridge is filtered and controlled:
+   * **Forward (Bridge)**: The stage where you filter and control traffic
+     that passes through the bridge:
 
      * ``set firewall bridge forward filter ...``.
 
-   * **Input (Bridge)**: stage where traffic destined for the bridge itself can
-     be filtered and controlled:
+   * **Input (Bridge)**: The stage where you filter and control traffic
+     destined for the bridge itself:
 
      * ``set firewall bridge input filter ...``.
 
-   * **Output (Bridge)**: stage where traffic that originates from the bridge
-     itself can be filtered and controlled:
+   * **Output (Bridge)**: The stage where you filter and control traffic that
+     the bridge originates:
 
      * ``set firewall bridge output filter ...``.
 
-The main structure of the VyOS firewall CLI is shown next:
+The following is the overall structure of the VyOS firewall CLI:
 
 .. code-block:: none
 
@@ -182,8 +176,53 @@ The main structure of the VyOS firewall CLI is shown next:
             - custom_zone_name
                + ...
 
-Please, refer to appropriate section for more information about firewall
-configuration:
+Here is a list of VyOS firewall CLI subcommands and their
+corresponding pages in the documentation:
+
+.. cfgcmd:: set firewall bridge ...
+
+   Configure bridge firewall rules for traffic at the bridge layer. For detailed
+   information, see 
+   :doc:`Bridge Firewall Configuration</configuration/firewall/bridge>`.
+
+.. cfgcmd:: set firewall flowtable ...
+
+   Configure firewall flowtables for stateful connection tracking and rules.
+   For detailed information, see
+   :doc:`Flowtables Firewall Configuration </configuration/firewall/flowtables>`
+   .
+
+.. cfgcmd:: set firewall global-options ...
+
+   Configure global firewall options such as ``all-ping``, ``broadcast-ping``,
+   ``syn-cookies``, and other system-wide firewall settings. For detailed
+   information, see
+   :doc:`Global Firewall Options</configuration/firewall/global-options>`.
+
+.. cfgcmd:: set firewall group ...
+
+   Organize firewall rules by creating reusable address, network, interface,
+   MAC, port, and domain groups. Use groups in multiple rules to simplify
+   configuration and maintenance. For detailed information, see
+   :doc:`Firewall Groups</configuration/firewall/groups>`.
+
+.. cfgcmd:: set firewall ipv4 ...
+
+   Configure IPv4-specific firewall rules. For detailed information, see
+   :doc:`IPv4 Firewall Configuration</configuration/firewall/ipv4>`.
+
+.. cfgcmd:: set firewall ipv6 ...
+
+   Configure IPv6-specific firewall rules. For detailed information, see
+   :doc:`IPv6 Firewall Configuration</configuration/firewall/ipv6>`.
+
+.. cfgcmd:: set firewall zone ...
+
+   Configure zone-based firewall policies for controlling traffic between
+   different network zones. For detailed information, see
+   :doc:`Zone-Based Firewall Configuration</configuration/firewall/zone>`.
+
+For more information on firewall configuration, see the following pages:
 
 .. toctree::
    :maxdepth: 1
@@ -196,31 +235,32 @@ configuration:
    ipv6
    flowtables
 
-.. note:: **For more information**
-   of Netfilter hooks and Linux networking packet flows can be
-   found in `Netfilter-Hooks
+.. note::
+   For more information on Netfilter hooks and Linux networking packet flows,
+   see the `Netfilter-Hooks
    <https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks>`_
+   documentation.
 
 
-Zone-based firewall
+Zone-Based firewall
 ^^^^^^^^^^^^^^^^^^^
+
 .. toctree::
    :maxdepth: 1
    :includehidden:
 
    zone
 
-With zone-based firewalls a new concept was implemented, in addition to the
-standard in and out traffic flows, a local flow was added. This local flow was
-for traffic originating and destined to the router itself. Which means that 
-additional rules were required to secure the firewall itself from the network,
-in addition to the existing inbound and outbound rules from the traditional
-concept above.
+With zone-based firewalls, a new concept applies. In addition to the standard
+in and out traffic flows, a local flow enables traffic originating from and
+destined to the router itself. This means you must configure additional rules to
+secure the firewall from the network, in addition to the existing inbound and
+outbound rules.
 
-To configure VyOS with the
-:doc:`zone-based firewall configuration </configuration/firewall/zone>`
+To configure VyOS with zone-based firewall, see
+:doc:`Zone-Based Firewall Configuration </configuration/firewall/zone>`.
 
-As the example image below shows, the device now needs rules to allow/block
+As the following example image shows, you must configure rules to allow or block
 traffic to or from the services running on the device that have open
 connections on that interface.
 
diff --git a/docs/configuration/firewall/ipv4.rst b/docs/configuration/firewall/ipv4.rst
index 4d54a68f..efd0fe18 100644
--- a/docs/configuration/firewall/ipv4.rst
+++ b/docs/configuration/firewall/ipv4.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2025-02-14
+:lastproofread: 2026-03-30
 
 .. _firewall-ipv4-configuration:
 
@@ -10,16 +10,14 @@ IPv4 Firewall Configuration
 Overview
 ********
 
-In this section there's useful information on all firewall configuration that
-can be done regarding IPv4, and appropriate op-mode commands.
-Configuration commands covered in this section:
+This section provides information on IPv4 firewall configuration and
+appropriate operation-mode commands. This section covers the following
+configuration commands:
 
 .. cfgcmd:: set firewall ipv4 ...
 
-From the main structure defined in
-:doc:`Firewall Overview</configuration/firewall/index>`
-in this section you can find detailed information only for the next part
-of the general structure:
+To learn about the general traffic flow in VyOS firewalls,
+see :doc:`Firewall </configuration/firewall/index>`.
 
 .. code-block:: none
 
@@ -37,8 +35,8 @@ of the general structure:
             - name
                + custom_name
 
-First, all traffic is received by the router, and it is processed in the
-**prerouting** section.
+First, the router receives all traffic and processes it in the **prerouting**
+stage.
 
 This stage includes:
 
@@ -52,79 +50,78 @@ This stage includes:
      ``set nat destination ...``
 
 For transit traffic, which is received by the router and forwarded, the base
-chain is **forward**. A simplified packet flow diagram for transit traffic is
-shown next:
+chain is **forward**. The following is a simplified packet flow diagram for
+transit traffic:
 
 .. figure:: /_static/images/firewall-fwd-packet-flow.*
 
-The base firewall chain to configure filtering rules for transit traffic
-is ``set firewall ipv4 forward filter ...``, which happens in stage 5,
-highlighted in the color red.
+The base firewall chain for configuring filtering rules for transit traffic is
+``set firewall ipv4 forward filter ...``, which occurs in stage 5, highlighted
+in red.
 
-For traffic towards the router itself, the base chain is **input**, while
-traffic originated by the router has the base chain **output**.
-A new simplified packet flow diagram is shown next, which shows the path
-for traffic destined to the router itself, and traffic generated by the
-router (starting from circle number 6):
+For traffic to the router itself, the base chain is **input**. For traffic
+the router originates, the base chain is **output**. A simplified packet flow
+diagram is shown next, which shows the path for traffic destined to the router
+itself and traffic the router generates (starting from circle number 6):
 
 .. figure:: /_static/images/firewall-input-packet-flow.*
 
-The base chain for traffic towards the router is ``set firewall ipv4 input
-filter ...``
+The base chain for traffic towards the router is
+``set firewall ipv4 input filter ...``
 
-And the base chain for traffic generated by the router is ``set firewall ipv4
+The base chain for traffic the router generates is ``set firewall ipv4
 output ...``, where two sub-chains are available: **filter** and **raw**:
 
-* **Output Prerouting**: ``set firewall ipv4 output raw ...``.
-  As described in **Prerouting**, rules defined in this section are
-  processed before connection tracking subsystem.
-* **Output Filter**: ``set firewall ipv4 output filter ...``. Rules defined
-  in this section are processed after connection tracking subsystem.
+* **Output Prerouting**: ``set firewall ipv4 output raw ...``. As described
+  in **Prerouting**, the system processes rules in this section before the
+  connection tracking subsystem.
+* **Output Filter**: ``set firewall ipv4 output filter ...``. The system
+  processes rules in this section after the connection tracking subsystem.
 
 .. note:: **Important note about default-actions:**
-   If a default action for any base chain is not defined, then the default
-   action is set to **accept** for that chain. For custom chains, if the 
-   default action is not defined, then the default-action is set to **drop**
+   If you do not define a default action for a base chain, the system sets
+   the default action to **accept** for that chain. For custom chains, if you
+   do not define a default action, the system sets the default-action to
+   **drop**.
 
-Custom firewall chains can be created, with commands
-``set firewall ipv4 name <name> ...``. In order to use
-such custom chain, a rule with **action jump**, and the appropriate **target**
-should be defined in a base chain.
+You can create custom firewall chains using the following commands:
+``set firewall ipv4 name <name> ...``. To use a custom chain, you must define
+a rule with the **action jump** and the appropriate **target** in a base
+chain.
 
 *********************
 Firewall - IPv4 Rules
 *********************
 
-For firewall filtering, firewall rules need to be created. Each rule is
-numbered, has an action to apply if the rule is matched, and the ability
-to specify multiple matching criteria. Data packets go through the rules
-from 1 - 999999, so order is crucial. At the first match the action of the
-rule will be executed.
+Each firewall rule has a
+number, an action to apply if the rule matches, and the ability to specify
+multiple matching criteria. Packets traverse rules numbered 1-999999, so order
+is crucial. The system executes the rule action at the first match.
 
 Actions
 =======
 
-If a rule is defined, then an action must be defined for it. This tells the
-firewall what to do if all of the criteria defined for that rule match.
+If you define a rule, you must define an action for it. The action tells the
+firewall what to do if all the criteria you define for that rule are met.
 
-The action can be :
+The action can be:
 
-   * ``accept``: accept the packet.
+   * ``accept``: Accept the packet.
 
-   * ``continue``: continue parsing next rule.
+   * ``continue``: Continue parsing the next rule.
 
-   * ``drop``: drop the packet.
+   * ``drop``: Drop the packet.
 
-   * ``reject``: reject the packet.
+   * ``reject``: Reject the packet.
 
-   * ``jump``: jump to another custom chain.
+   * ``jump``: Jump to another custom chain.
 
    * ``return``: Return from the current chain and continue at the next rule
      of the last chain.
 
    * ``queue``: Enqueue packet to userspace.
 
-   * ``synproxy``: synproxy the packet.
+   * ``synproxy``: Synproxy the packet.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999> action
    [accept | continue | drop | jump | queue | reject | return | synproxy]
@@ -135,8 +132,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999> action
    [accept | continue | drop | jump | queue | reject | return]
 
-   This required setting defines the action of the current rule. If the action
-   is set to jump, then a jump-target is also needed.
+   This required setting defines the action of the current rule. If you set
+   the action to jump, you must also specify a jump-target.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    jump-target <text>
@@ -147,8 +144,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    jump-target <text>
 
-   To be used only when action is set to ``jump``. Use this command to specify
-   the jump target.
+   Use this command only when the action is set to ``jump``. Specify the
+   jump target.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    queue <0-65535>
@@ -159,8 +156,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    queue <0-65535>
 
-   To be used only when action is set to ``queue``. Use this command to specify
-   the queue target to use. Queue range is also supported.
+   Use this command only when the action is set to ``queue``. Specify the
+   queue target to use. Queue range is also supported.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    queue-options bypass
@@ -171,8 +168,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    queue-options bypass
 
-   To be used only when action is set to ``queue``. Use this command to let the
-   packet go through firewall when no userspace software is connected to the
+   Use this command only when the action is set to ``queue``. Allow the packet
+   to pass through the firewall when no userspace software is connected to the
    queue.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
@@ -184,11 +181,11 @@ The action can be :
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    queue-options fanout
 
-   To be used only when action is set to ``queue``. Use this command to
-   distribute packets between several queues.
+   Use this command only when the action is set to ``queue``. Distribute
+   packets between several queues.
 
-Also, **default-action** is an action that takes place whenever a packet does
-not match any rule in its chain. For base chains, possible options for
+Also, **default-action** is an action that applies when a packet does not
+match any rule in its chain. For base chains, possible options for
 **default-action** are **accept** or **drop**. 
 
 .. cfgcmd:: set firewall ipv4 forward filter default-action
@@ -200,43 +197,44 @@ not match any rule in its chain. For base chains, possible options for
 .. cfgcmd:: set firewall ipv4 name <name> default-action
    [accept | drop | jump | queue | reject | return]
 
-   This sets the default action of the rule-set if a packet does not match the
-   criteria of any rule. If default-action is set to ``jump``, then
-   ``default-jump-target`` is also needed. Note that for base chains, the
-   default action can only be set to ``accept`` or ``drop``, while on custom 
-   chains, more actions are available.
+   This command sets the default action of the rule-set if a packet does not
+   match the criteria of any rule. If you set the default-action to ``jump``,
+   you must also specify ``default-jump-target``. Note that for base chains,
+   you can set the default action only to ``accept`` or ``drop``, while on
+   custom chains, more actions are available.
 
 .. cfgcmd:: set firewall ipv4 name <name> default-jump-target <text>
 
-   To be used only when ``default-action`` is set to ``jump``. Use this
-   command to specify the jump target for the default rule.
+   Use this command only when you set ``default-action`` to ``jump``. Specify
+   the jump target for the default rule.
 
 .. note:: **Important note about default-actions:**
-   If the default action for any base chain is not defined, then the default
-   action is set to **accept** for that chain. For custom chains if a default
-   action is not defined then the default-action is set to **drop**.
+   If you do not define a default action for a base chain, the system sets
+   the default action to **accept** for that chain. For custom chains, if you
+   do not define a default action, the system sets the default-action to
+   **drop**.
 
 Firewall Logs
 =============
 
-Logging can be enabled for every single firewall rule. If enabled, other
-log options can be defined. 
+You can enable logging for every single firewall rule. If you enable logging,
+you can define other log options. 
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv4 input filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv4 output filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999> log
 
-   Enable logging for the matched packet. If this configuration command is not
-   present, then the log is not enabled.
+   Enable logging for the matched packet. If this command is not present, then
+   logging is not enabled.
 
 .. cfgcmd:: set firewall ipv4 forward filter default-log
 .. cfgcmd:: set firewall ipv4 input filter default-log
 .. cfgcmd:: set firewall ipv4 output filter default-log
 .. cfgcmd:: set firewall ipv4 name <name> default-log
 
-   Use this command to enable the logging of the default action on
-   the specified chain.
+   Use this command to enable logging of the default action on the specified
+   chain.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    log-options level [emerg | alert | crit | err | warn | notice
@@ -251,7 +249,7 @@ log options can be defined.
    log-options level [emerg | alert | crit | err | warn | notice
    | info | debug]
 
-   Define log-level. Only applicable if rule log is enabled.
+   Define the log level. Only applicable if you enable rule logging.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    log-options group <0-65535>
@@ -262,8 +260,8 @@ log options can be defined.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    log-options group <0-65535>
 
-   Define the log group to send messages to. Only applicable if rule log is
-   enabled.
+   Define the log group to send messages to. Only applicable if you enable rule
+   logging.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    log-options snapshot-length <0-9000>
@@ -275,7 +273,7 @@ log options can be defined.
    log-options snapshot-length <0-9000>
 
    Define the length of packet payload to include in a netlink message. Only
-   applicable if rule log is enabled and log group is defined.
+   applicable if you enable rule logging and define the log group.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    log-options queue-threshold <0-65535>
@@ -287,17 +285,18 @@ log options can be defined.
    log-options queue-threshold <0-65535>
 
    Define the number of packets to queue inside the kernel before sending them
-   to userspace. Only applicable if rule log is enabled and log group is defined.
+   to userspace. Only applicable if you enable rule logging and define the log
+   group.
 
 Firewall Description
 ====================
 
-For reference, a description can be defined for every single rule, and for
-every defined custom chain.
+You can add a description for reference for every single rule and for every
+defined custom chain.
 
 .. cfgcmd:: set firewall ipv4 name <name> description <text>
 
-   Provide a rule-set description to a custom firewall chain.
+   Provide a rule-set description for a custom firewall chain.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    description <text>
@@ -312,15 +311,15 @@ every defined custom chain.
 Rule Status
 ===========
 
-When defining a rule, it is enabled by default. In some cases, it is useful to
-just disable the rule, rather than removing it.
+When you define a rule, it is enabled by default. In some cases, it is useful
+to disable the rule rather than removing it.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999> disable
 .. cfgcmd:: set firewall ipv4 input filter rule <1-999999> disable
 .. cfgcmd:: set firewall ipv4 output filter rule <1-999999> disable
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999> disable
 
-   Command for disabling a rule but keep it in the configuration.
+   Command for disabling a rule but keeping it in the configuration.
 
 Matching criteria
 =================
@@ -727,9 +726,9 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    inbound-interface name <iface>
 
-   Match based on inbound interface. Wildcard ``*`` can be used.
-   For example: ``eth2*``. Prepending the character ``!`` to invert the
-   criteria to match is also supported. For example ``!eth2``
+   Match based on inbound interface. Wildcard ``*`` is supported. For example:
+   ``eth2*``. Prepend the character ``!`` to invert the criteria. For example:
+   ``!eth2``
 
 .. note:: If an interface is attached to a non-default vrf, when using
    **inbound-interface**, the vrf name must be used. For example ``set firewall
@@ -742,8 +741,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    inbound-interface group <iface_group>
 
-   Match based on the inbound interface group. Prepending the character ``!`` 
-   to invert the criteria to match is also supported. For example ``!IFACE_GROUP``
+   Match based on the inbound interface group. Prepend the character ``!`` to
+   invert the criteria. For example, ``!IFACE_GROUP``
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    outbound-interface name <iface>
@@ -752,9 +751,9 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    outbound-interface name <iface>
 
-   Match based on outbound interface. Wildcard ``*`` can be used.
-   For example: ``eth2*``. Prepending the character ``!`` to invert the
-   criteria to match is also supported. For example ``!eth2``
+   Match based on outbound interface. Wildcard ``*`` is supported. For example:
+   ``eth2*``. Prepend the character ``!`` to invert the criteria. For example:
+   ``!eth2``
 
 .. note:: If an interface is attached to a non-default vrf, when using
    **outbound-interface**, the real interface name must be used. For example
@@ -767,8 +766,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    outbound-interface group <iface_group>
 
-   Match based on outbound interface group. Prepending the character ``!`` to
-   invert the criteria to match is also supported. For example ``!IFACE_GROUP``
+   Match based on outbound interface group. Prepend the character ``!`` to
+   invert the criteria. For example: ``!IFACE_GROUP``
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    ipsec [match-ipsec-in | match-ipsec-out | match-none-in | match-none-out]
@@ -801,8 +800,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    limit rate <text>
 
-   Match based on the maximum average rate, specified as **integer/unit**.
-   For example **5/minutes**
+   Specify the maximum average rate as **integer/unit**. For example:
+   **5/minutes**
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    packet-length <text>
@@ -822,8 +821,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    packet-length-exclude <text>
 
-   Match based on the packet length. Multiple values from 1 to 65535
-   and ranges are supported.
+   Match based on packet length. Specify multiple values from 1 to 65535 and
+   ranges.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    packet-type [broadcast | host | multicast | other]
@@ -846,13 +845,13 @@ geoip) to keep database and rules updated.
    protocol [<text> | <0-255> | all | tcp_udp]
 
    Match based on protocol number or name as defined in ``/etc/protocols``.
-   Special names are ``all`` for all protocols and ``tcp_udp`` for tcp and udp
-   based packets. The ``!`` negates the selected protocol.
+   Special names are ``all`` for all protocols and ``tcp_udp`` for TCP and UDP
+   based packets. The ``!`` character negates the selected protocol.
 
    .. code-block:: none
 
-      set firewall ipv4 forward fitler rule 10 protocol tcp_udp
-      set firewall ipv4 forward fitler rule 11 protocol !tcp_udp
+      set firewall ipv4 forward filter rule 10 protocol tcp_udp
+      set firewall ipv4 forward filter rule 11 protocol !tcp_udp
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    recent count <1-255>
@@ -883,9 +882,9 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    tcp flags [not] <text>
 
-   Allowed values fpr TCP flags: ``ack``, ``cwr``, ``ecn``, ``fin``, ``psh``,
-   ``rst``, ``syn`` and ``urg``. Multiple values are supported, and for
-   inverted selection use ``not``, as shown in the example.
+   Specify TCP flags. Allowed values are ``ack``, ``cwr``, ``ecn``, ``fin``,
+   ``psh``, ``rst``, ``syn``, and ``urg``. Specify multiple values, and use
+   ``not`` for inverted selection, as shown in the example.
 
    .. code-block:: none
 
@@ -956,8 +955,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    ttl <eq | gt | lt> <0-255>
 
-   Match the time to live parameter, where 'eq' stands for 'equal'; 'gt' stands
-   for 'greater than', and 'lt' stands for 'less than'.
+   Match the time to live parameter, where 'eq' means 'equal', 'gt' means
+   'greater than', and 'lt' means 'less than'.
 
 .. cfgcmd:: set firewall ipv4 forward filter rule <1-999999>
    recent count <1-255>
@@ -977,14 +976,14 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv4 name <name> rule <1-999999>
    recent time <second | minute | hour>
 
-   Match when 'count' amount of connections are seen within 'time'. These
-   matching criteria can be used to block brute-force attempts.
+   Match when 'count' amount of connections appear within 'time'. Use these
+   matching criteria to block brute-force attempts.
 
 Packet Modifications
 ====================
 
 Starting from **VyOS-1.5-rolling-202410060007**, the firewall can modify
-packets before they are sent out. This feaure provides more flexibility in
+packets before sending them out. This feature provides more flexibility in
 packet handling.
 
 .. cfgcmd:: set firewall ipv4 prerouting raw rule <1-999999>
@@ -1053,9 +1052,9 @@ Example synproxy
 ================
 Requirements to enable synproxy:
 
-  * Traffic must be symmetric
-  * Synproxy relies on syncookies and TCP timestamps, ensure these are enabled
-  * Disable conntrack loose track option
+  * Traffic must be symmetric.
+  * Synproxy relies on syncookies and TCP timestamps, ensure these are enabled.
+  * Disable conntrack loose track option.
 
 .. code-block:: none
 
@@ -1085,8 +1084,8 @@ Rule-set overview
 
 .. opcmd:: show firewall
 
-   This will show you a basic firewall overview, for all rule-sets, and not
-   only for ipv4
+   This will show you a basic firewall overview, for all rule-sets, not
+   only for IPv4.
 
    .. code-block:: none
 
@@ -1140,7 +1139,7 @@ Rule-set overview
 
 .. opcmd:: show firewall summary
 
-   This will show you a summary of rule-sets and groups
+   This shows you a summary of rule-sets and groups.
 
    .. code-block:: none
 
@@ -1215,7 +1214,7 @@ Rule-set overview
    filter rule <1-999999>
 .. opcmd:: show firewall ipv4 name <name> rule <1-999999>
 
-   This command will give an overview of a rule in a single rule-set, plus
+   This command gives an overview of a rule in a single rule-set, plus
    information for default action.
 
 .. code-block:: none
@@ -1249,9 +1248,9 @@ Show Firewall log
 .. opcmd:: show log firewall ipv4 [forward | input | output] filter rule <rule>
 .. opcmd:: show log firewall ipv4 name <name> rule <rule>
 
-   Show the logs of all firewall; show all ipv4 firewall logs; show all logs
+   Show the logs of all firewall; show all IPv4 firewall logs; show all logs
    for particular hook; show all logs for particular hook and priority;
-   show all logs for particular custom chain; show logs for specific Rule-Set.
+   show all logs for particular custom chain; show logs for specific rule-set.
 
 Example Partial Config
 ======================
@@ -1303,4 +1302,4 @@ Update geoip database
 
 .. opcmd:: update geoip
 
-   Command used to update GeoIP database and firewall sets.
+   Command to update GeoIP database and firewall sets.
diff --git a/docs/configuration/firewall/ipv6.rst b/docs/configuration/firewall/ipv6.rst
index 905d0d20..d31ceb6f 100644
--- a/docs/configuration/firewall/ipv6.rst
+++ b/docs/configuration/firewall/ipv6.rst
@@ -1,4 +1,4 @@
-:lastproofread: 2025-02-14
+:lastproofread: 2026-04-01
 
 .. _firewall-ipv6-configuration:
 
@@ -10,16 +10,15 @@ IPv6 Firewall Configuration
 Overview
 ********
 
-In this section there's useful information on all firewall configuration that
-can be done regarding IPv6, and appropriate op-mode commands.
-Configuration commands covered in this section:
+This section covers useful information about IPv6 firewall configuration and
+appropriate operation-mode commands.
+
+This section describes the following configuration commands:
 
 .. cfgcmd:: set firewall ipv6 ...
 
-From the main structure defined in
-:doc:`Firewall Overview</configuration/firewall/index>`
-in this section you can find detailed information only for the next part
-of the general structure:
+To learn about the general traffic flow in VyOS firewalls,
+see :doc:`Firewall </configuration/firewall/index>`.
 
 .. code-block:: none
 
@@ -37,8 +36,8 @@ of the general structure:
             - name
                + custom_name
 
-First, all traffic is received by the router, and it is processed in the
-**prerouting** section.
+The router first receives all traffic and processes it in the **prerouting**
+section.
 
 This stage includes:
 
@@ -51,61 +50,59 @@ This stage includes:
    * :doc:`Destination NAT</configuration/nat/nat44>`: commands found under
      ``set nat66 destination ...``
 
-For transit traffic, which is received by the router and forwarded, the base
-chain is **forward**. A simplified packet flow diagram for transit traffic is
-shown next:
+For transit traffic that the router receives and forwards, the base chain is
+**forward**. The following diagram shows a simplified packet flow for transit
+traffic:
 
 .. figure:: /_static/images/firewall-fwd-packet-flow.*
 
-The base firewall chain to configure filtering rules for transit traffic
-is ``set firewall ipv6 forward filter ...``, which happens in stage 5,
-highlighted in the color red.
+Use ``set firewall ipv6 forward filter ...`` to configure filtering rules for
+transit traffic. This command corresponds to stage 5 and is highlighted in red
+in the diagram.
 
-For traffic towards the router itself, the base chain is **input**, while
-traffic originated by the router has the base chain **output**.
-A new simplified packet flow diagram is shown next, which shows the path
-for traffic destined to the router itself, and traffic generated by the
+For traffic destined to the router, use the **input** chain. For traffic the
+router generates, use the **output** chain. The following diagram shows the
+packet flow for traffic destined to the router and traffic generated by the
 router (starting from circle number 6):
 
 .. figure:: /_static/images/firewall-input-packet-flow.*
 
-The base chain for traffic towards the router is ``set firewall ipv6 input
-filter ...``
+Use ``set firewall ipv6 input filter ...`` to configure traffic destined to
+the router.
 
-And the base chain for traffic generated by the router is ``set firewall ipv6
-output ...``, where two sub-chains are available: **filter** and **raw**:
+Use ``set firewall ipv6 output ...`` to configure traffic the router generates.
+Two sub-chains are available: **filter** and **raw**:
 
 * **Output Prerouting**: ``set firewall ipv6 output raw ...``.
-  As described in **Prerouting**, rules defined in this section are
-  processed before connection tracking subsystem.
-* **Output Filter**: ``set firewall ipv6 output filter ...``. Rules defined
-  in this section are processed after connection tracking subsystem.
+  As described in **Prerouting**, the firewall processes rules in this
+  section before the connection tracking subsystem.
+* **Output Filter**: ``set firewall ipv6 output filter ...``. The firewall
+  processes rules in this section after the connection tracking subsystem.
 
 .. note:: **Important note about default-actions:**
-   If a default action for any base chain is not defined, then the default
-   action is set to **accept** for that chain. For custom chains, if the
-   default action is not defined, then the default-action is set to **drop**
+   If you do not define a default action for a base chain, the system sets
+   the default action to **accept** for that chain. For custom chains, if you
+   do not define a default action, the system sets the default-action to
+   **drop**
 
-Custom firewall chains can be created, with commands
-``set firewall ipv6 name <name> ...``. In order to use
-such custom chain, a rule with **action jump**, and the appropriate **target**
-should be defined in a base chain.
+Create custom firewall chains using the commands
+``set firewall ipv6 name <name> ...``. To use the custom chain, define a
+rule with **action jump** and the appropriate **target** in a base chain.
 
 ******************************
 Firewall - IPv6 Rules
 ******************************
 
-For firewall filtering, firewall rules need to be created. Each rule is
-numbered, has an action to apply if the rule is matched, and the ability
-to specify multiple matching criteria. Data packets go through the rules
-from 1 - 999999, so order is crucial. At the first match the action of the
-rule will be executed.
+Create firewall rules for firewall filtering. Each rule is numbered and has
+an action to apply when the rule is matched. You can specify multiple matching
+criteria. Packets go through rules from 1 - 999999, so order is crucial. The
+firewall executes the action of the first matching rule.
 
 Actions
 =======
 
-If a rule is defined, then an action must be defined for it. This tells the
-firewall what to do if all of the criteria defined for that rule match.
+If you define a rule, you must define an action for it. The action tells the
+firewall what to do when all criteria for that rule are met.
 
 The action can be :
 
@@ -135,8 +132,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999> action
    [accept | continue | drop | jump | queue | reject | return]
 
-   This required setting defines the action of the current rule. If the action
-   is set to jump, then a jump-target is also needed.
+   This required setting defines the action of the current rule. If you set
+   the action to jump, you must also define a jump-target.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    jump-target <text>
@@ -147,8 +144,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    jump-target <text>
 
-   To be used only when action is set to ``jump``. Use this command to specify
-   the jump target.
+   Use this command only when action is set to ``jump``. Specify the jump
+   target.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    queue <0-65535>
@@ -159,8 +156,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    queue <0-65535>
 
-   To be used only when action is set to ``queue``. Use this command to specify
-   the queue target to use. Queue range is also supported.
+   Use this command only when action is set to ``queue``. Specify the queue
+   target. Queue ranges are also supported.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    queue-options bypass
@@ -171,9 +168,9 @@ The action can be :
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    queue-options bypass
 
-   To be used only when action is set to ``queue``. Use this command to let the
-   packet go through firewall when no userspace software is connected to the
-   queue.
+   Use this command only when action is set to ``queue``. This command allows
+   the packet to go through the firewall when no userspace software is connected
+   to the queue.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    queue-options fanout
@@ -184,8 +181,8 @@ The action can be :
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    queue-options fanout
 
-   To be used only when action is set to ``queue``. Use this command to
-   distribute packets between several queues.
+   Use this command only when action is set to ``queue``. This command
+   distributes packets among multiple queues.
 
 Also, **default-action** is an action that takes place whenever a packet does
 not match any rule in its chain. For base chains, possible options for
@@ -200,11 +197,11 @@ not match any rule in its chain. For base chains, possible options for
 .. cfgcmd:: set firewall ipv6 name <name> default-action
    [accept | drop | jump | queue | reject | return]
 
-   This sets the default action of the rule-set if a packet does not match the
-   criteria of any rule. If default-action is set to ``jump``, then
-   ``default-jump-target`` is also needed. Note that for base chains, the
-   default action can only be set to ``accept`` or ``drop``, while on custom 
-   chains, more actions are available.
+   Set the default action of the rule-set if a packet does not match any rule
+   criteria. If you set default-action to ``jump``, you must also define
+   ``default-jump-target``. For base chains, you can only set the default
+   action to ``accept`` or ``drop``. For custom chains, more actions are
+   available.
 
 .. cfgcmd:: set firewall ipv6 name <name> default-jump-target <text>
 
@@ -212,23 +209,24 @@ not match any rule in its chain. For base chains, possible options for
    command to specify the jump target for the default rule.
 
 .. note:: **Important note about default-actions:**
-   If the default action for any base chain is not defined, then the default
-   action is set to **accept** for that chain. For custom chains if a default
-   action is not defined then the default-action is set to **drop**.
+   If you do not define the default action for a base chain, the system sets
+   the default action to **accept** for that chain. For custom chains, if you
+   do not define a default action, the system sets the default-action to
+   **drop**.
 
 Firewall Logs
 =============
 
-Logging can be enabled for every single firewall rule. If enabled, other
-log options can be defined. 
+You can enable logging for each firewall rule. When enabled, you can also
+define other log options. 
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv6 input filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv6 output filter rule <1-999999> log
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999> log
 
-   Enable logging for the matched packet. If this configuration command is not
-   present, then the log is not enabled.
+   Enable logging for matched packets. If this configuration command is not
+   present, logging is disabled.
 
 .. cfgcmd:: set firewall ipv6 forward filter default-log
 .. cfgcmd:: set firewall ipv6 input filter default-log
@@ -275,7 +273,7 @@ log options can be defined.
    log-options snapshot-length <0-9000>
 
    Define the length of packet payload to include in a netlink message. Only
-   applicable if rule log is enabled and log group is defined.
+   applicable when rule logging is enabled and log group is defined.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    log-options queue-threshold <0-65535>
@@ -287,13 +285,13 @@ log options can be defined.
    log-options queue-threshold <0-65535>
 
    Define the number of packets to queue inside the kernel before sending them
-   to userspace. Only applicable if rule log is enabled and log group is defined.
+   to userspace. Only applicable when rule logging is enabled and log group is
+   defined.
 
 Firewall Description
 ====================
 
-For reference, a description can be defined for every single rule, and for
-every defined custom chain.
+For reference, you can define descriptions on every rule and custom chain.
 
 .. cfgcmd:: set firewall ipv6 name <name> description <text>
 
@@ -312,8 +310,8 @@ every defined custom chain.
 Rule Status
 ===========
 
-When defining a rule, it is enabled by default. In some cases, it is useful to
-just disable the rule, rather than removing it.
+New rules are enabled by default. In some cases, you may want to disable a
+rule rather than remove it.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999> disable
 .. cfgcmd:: set firewall ipv6 input filter rule <1-999999> disable
@@ -336,7 +334,7 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    connection-status nat [destination | source]
 
-   Match based on nat connection status.
+   Match packets based on NAT connection status.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    connection-mark <1-2147483647>
@@ -347,7 +345,7 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    connection-mark <1-2147483647>
 
-   Match based on connection mark.
+   Match packets based on connection mark.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source address [address | addressrange | CIDR]
@@ -367,8 +365,8 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination address [address | addressrange | CIDR]
 
-   Match based on source and/or destination address. This is similar to the
-   network groups part, but here you are able to negate the matching addresses.
+   Match based on source or destination address. This is similar to network
+   groups, but you can negate the matching addresses here.
 
    .. code-block:: none
 
@@ -392,15 +390,14 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination address-mask [address]
 
-   An arbitrary netmask can be applied to mask addresses to only match against
-   a specific portion. This is particularly useful with IPv6 as rules will
-   remain valid if the IPv6 prefix changes and the host
-   portion of systems IPv6 address is static (for example, with SLAAC or
-   `tokenised IPv6 addresses
-   <https://datatracker.ietf.org
-   /doc/id/draft-chown-6man-tokenised-ipv6-identifiers-02.txt>`_)
+   Apply an arbitrary netmask to mask addresses and match only a specific
+   portion. This is useful for IPv6 because rules remain valid when the IPv6
+   prefix changes if the host portion of the system's IPv6 address is static.
+   Examples include SLAAC and `tokenised IPv6 addresses
+   <https://datatracker.ietf.org/doc/id/draft-chown-6man-tokenised-ipv6-
+   identifiers-02.txt>`_
    
-   This functions for both individual addresses and address groups.
+   This function works for both individual addresses and address groups.
 
    .. stop_vyoslinter
    .. code-block:: none
@@ -433,8 +430,8 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination fqdn <fqdn>
 
-   Specify a Fully Qualified Domain Name as source/destination to match. Ensure
-   that the router is able to resolve this dns query.
+   Specify a Fully Qualified Domain Name as source or destination to match.
+   Ensure that the router can resolve the DNS query.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source geoip country-code <country>
@@ -472,14 +469,16 @@ There are a lot of matching criteria against which the packet can be tested.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination geoip inverse-match
 
-   Match IP addresses based on its geolocation. More info: `geoip matching
-   <https://wiki.nftables.org/wiki-nftables/index.php/GeoIP_matching>`_.
-   Use inverse-match to match anything except the given country-codes.
+   Match IP addresses based on their geolocation. For more information, see
+   `GeoIP matching <https://wiki.nftables.org/wiki-nftables/index.php/GeoIP_
+   matching>`_. Use inverse-match to match anything except the specified
+   country codes.
 
-Data is provided by DB-IP.com under CC-BY-4.0 license. Attribution required,
-permits redistribution so we can include a database in images(~3MB
-compressed). Includes cron script (manually callable by op-mode update
-geoip) to keep database and rules updated.
+DB-IP.com provides data under CC-BY-4.0 license. Attribution is required and
+redistribution is permitted, allowing VyOS to include a database in images
+(approximately 3 MB compressed). The package includes a cron script that you
+can manually call through op-mode update geoip to keep the database and rules
+updated.
 
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
@@ -491,7 +490,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    source mac-address <mac-address>
 
-   You can only specify a source mac-address to match.
+   You can specify only a source MAC address to match.
 
    .. code-block:: none
 
@@ -516,7 +515,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination port [1-65535 | portname | start-end]
 
-   A port can be set by number or name as defined in ``/etc/services``.
+   Specify a port by number or by name as defined in ``/etc/services``.
 
    .. code-block:: none
 
@@ -549,8 +548,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group address-group <name | !name>
 
-   Use a specific address-group. Prepending the character ``!`` to invert the
-   criteria to match is also supported.
+   Specify an address group. You can prepend the character ``!`` to invert the
+   matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source group dynamic-address-group <name | !name>
@@ -570,8 +569,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group dynamic-address-group <name | !name>
 
-   Use a specific dynamic-address-group. Prepending the character ``!`` to
-   invert the criteria to match is also supported.
+   Specify a dynamic address group. You can prepend the character ``!`` to
+   invert the matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source group network-group <name | !name>
@@ -591,8 +590,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group network-group <name | !name>
 
-   Use a specific network-group. Prepending the character ``!`` to invert the
-   criteria to match is also supported.
+   Specify a network group. You can prepend the character ``!`` to invert the
+   matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source group port-group <name | !name>
@@ -612,8 +611,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group port-group <name | !name>
 
-   Use a specific port-group. Prepending the character ``!`` to invert the
-   criteria to match is also supported.
+   Specify a port group. You can prepend the character ``!`` to invert the
+   matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source group domain-group <name | !name>
@@ -633,8 +632,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group domain-group <name | !name>
 
-   Use a specific domain-group. Prepending the character ``!`` to invert the
-   criteria to match is also supported.
+   Specify a domain group. You can prepend the character ``!`` to invert the
+   matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    source group mac-group <name | !name>
@@ -654,8 +653,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    destination group mac-group <name | !name>
 
-   Use a specific mac-group. Prepending the character ``!`` to invert the
-   criteria to match is also supported.
+   Specify a MAC group. You can prepend the character ``!`` to invert the
+   matching criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    dscp [0-63 | start-end]
@@ -686,7 +685,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    fragment [match-frag | match-non-frag]
 
-   Match based on fragmentation.
+   Match packets based on fragmentation.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    icmpv6 [code | type] <0-255>
@@ -697,7 +696,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    icmpv6 [code | type] <0-255>
 
-   Match based on icmp|icmpv6 code and type.
+   Match packets based on ICMP or ICMPv6 code and type.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    icmpv6 type-name <text>
@@ -708,8 +707,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    icmpv6 type-name <text>
 
-   Match based on icmpv6 type-name. Use tab for information
-   about what **type-name** criteria are supported.
+   Match based on ICMPv6 type-name. Press **Tab** for information about
+   supported **type-name** criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    inbound-interface name <iface>
@@ -718,13 +717,13 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    inbound-interface name <iface>
 
-   Match based on inbound interface. Wildcard ``*`` can be used.
-   For example: ``eth2*``. Prepending the character ``!`` to invert the
-   criteria to match is also supported. For example ``!eth2``
+   Match based on inbound interface. You can use the wildcard ``*``. For
+   example: ``eth2*``. You can prepend the character ``!`` to invert the
+   matching criteria. For example ``!eth2``
 
-.. note:: If an interface is attached to a non-default vrf, when using
-   **inbound-interface**, the vrf name must be used. For example ``set firewall
-   ipv6 forward filter rule 10 inbound-interface name MGMT``
+.. note:: If an interface is attached to a non-default VRF, when using
+   **inbound-interface**, use the VRF name. For example:
+   ``set firewall ipv6 forward filter rule 10 inbound-interface name MGMT``
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    inbound-interface group <iface_group>
@@ -733,8 +732,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    inbound-interface group <iface_group>
 
-   Match based on the inbound interface group. Prepending the character ``!`` 
-   to invert the criteria to match is also supported. For example ``!IFACE_GROUP``
+   Match based on the inbound interface group. You can prepend the character
+   ``!`` to invert the matching criteria. For example ``!IFACE_GROUP``
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    outbound-interface name <iface>
@@ -743,12 +742,12 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    outbound-interface name <iface>
 
-   Match based on outbound interface. Wildcard ``*`` can be used.
-   For example: ``eth2*``. Prepending the character ``!`` to invert the
-   criteria to match is also supported. For example ``!eth2``
+   Match based on outbound interface. You can use the wildcard ``*``. For
+   example: ``eth2*``. You can prepend the character ``!`` to invert the
+   matching criteria. For example ``!eth2``
 
-.. note:: If an interface is attached to a non-default vrf, when using
-   **outbound-interface**, the real interface name must be used. For example
+.. note:: If an interface is attached to a non-default VRF, when using
+   **outbound-interface**, use the physical interface name. For example:
    ``set firewall ipv6 forward filter rule 10 outbound-interface name eth0``
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
@@ -758,8 +757,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    outbound-interface group <iface_group>
 
-   Match based on outbound interface group. Prepending the character ``!`` to
-   invert the criteria to match is also supported. For example ``!IFACE_GROUP``
+   Match based on outbound interface group. You can prepend the character ``!``
+   to invert the matching criteria. For example ``!IFACE_GROUP``
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    ipsec [match-ipsec-in | match-ipsec-out | match-none-in | match-none-out]
@@ -770,7 +769,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    ipsec [match-ipsec-in | match-ipsec-out | match-none-in | match-none-out]
 
-   Match based on ipsec.
+   Match packets based on IPsec.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    limit burst <0-4294967295>
@@ -781,7 +780,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    limit burst <0-4294967295>
 
-   Match based on the maximum number of packets to allow in excess of rate.
+   Match based on the maximum number of packets allowed to exceed the rate
+   limit.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    limit rate <text>
@@ -792,8 +792,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    limit rate <text>
 
-   Match based on the maximum average rate, specified as **integer/unit**.
-   For example **5/minutes**
+   Match based on the maximum average rate, specified as ``integer/unit``.
+   For example, specify ``5/minutes``.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    packet-length <text>
@@ -813,8 +813,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    packet-length-exclude <text>
 
-   Match based on the packet length. Multiple values from 1 to 65535
-   and ranges are supported.
+   Match based on packet length. You can specify multiple values from 1 to
+   65535 and ranges.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    packet-type [broadcast | host | multicast | other]
@@ -825,7 +825,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    packet-type [broadcast | host | multicast | other]
 
-   Match based on the packet type.
+   Match based on packet type.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    protocol [<text> | <0-255> | all | tcp_udp]
@@ -837,8 +837,8 @@ geoip) to keep database and rules updated.
    protocol [<text> | <0-255> | all | tcp_udp]
 
    Match based on protocol number or name as defined in ``/etc/protocols``.
-   Special names are ``all`` for all protocols and ``tcp_udp`` for tcp and udp
-   based packets. The ``!`` negates the selected protocol.
+   Specify ``all`` for all protocols and ``tcp_udp`` for TCP and UDP packets.
+   Prepend ``!`` to negate the protocol selection.
 
    .. code-block:: none
 
@@ -862,7 +862,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    recent time [second | minute | hour]
 
-   Match bases on recently seen sources.
+   Match packets based on recently seen sources.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    tcp flags [not] <text>
@@ -873,9 +873,9 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    tcp flags [not] <text>
 
-   Allowed values fpr TCP flags: ``ack``, ``cwr``, ``ecn``, ``fin``, ``psh``,
-   ``rst``, ``syn`` and ``urg``. Multiple values are supported, and for
-   inverted selection use ``not``, as shown in the example.
+   Allowed values for TCP flags: ``ack``, ``cwr``, ``ecn``, ``fin``, ``psh``,
+   ``rst``, ``syn``, and ``urg``. You can specify multiple values. To invert
+   the selection, use ``not``, as shown in the following example.
 
    .. code-block:: none
 
@@ -892,7 +892,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    state [established | invalid | new | related]
 
-   Match against the state of a packet.
+   Match based on packet state.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    time startdate <text>
@@ -935,7 +935,7 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    time weekdays <text>
 
-   Time to match the defined rule.
+   Match packets based on time criteria.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    hop-limit <eq | gt | lt> <0-255>
@@ -946,8 +946,8 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    hop-limit <eq | gt | lt> <0-255>
 
-   Match the hop-limit parameter, where 'eq' stands for 'equal'; 'gt' stands for
-   'greater than', and 'lt' stands for 'less than'.
+   Match the hop-limit parameter. Use ``eq`` for equal, ``gt`` for greater than,
+   and ``lt`` for less than.
 
 .. cfgcmd:: set firewall ipv6 forward filter rule <1-999999>
    recent count <1-255>
@@ -967,15 +967,14 @@ geoip) to keep database and rules updated.
 .. cfgcmd:: set firewall ipv6 name <name> rule <1-999999>
    recent time <second | minute | hour>
 
-   Match when 'count' amount of connections are seen within 'time'. These
-   matching criteria can be used to block brute-force attempts.
+   Match when the specified number of connections occur within the specified
+   time period. Use these criteria to block brute-force attempts.
 
 Packet Modifications
 ====================
 
-Starting from **VyOS-1.5-rolling-202410060007**, the firewall can modify
-packets before they are sent out. This feaure provides more flexibility in
-packet handling.
+The firewall can modify packets before sending them.
+This feature provides more flexibility for packet handling.
 
 .. cfgcmd:: set firewall ipv6 prerouting raw rule <1-999999>
    set dscp <0-63>
@@ -1032,12 +1031,12 @@ Synproxy connections
 .. cfgcmd:: set firewall ipv6 [input | forward] filter rule <1-999999>
    synproxy tcp mss <501-65535>
 
-    Set the TCP-MSS (maximum segment size) for the connection
+    Set the TCP MSS (maximum segment size) for the connection.
 
 .. cfgcmd:: set firewall ipv6 [input | forward] filter rule <1-999999>
    synproxy tcp window-scale <1-14>
 
-    Set the window scale factor for TCP window scaling
+    Set the window scale factor for TCP window scaling.
 
 Example synproxy
 ================
@@ -1075,8 +1074,7 @@ Rule-set overview
 
 .. opcmd:: show firewall
 
-   This will show you a basic firewall overview, for all rule-sets, and not
-   only for ipv6
+   Show a basic firewall overview for all rule-sets, not only for IPv6:
 
    .. code-block:: none
 
@@ -1224,8 +1222,8 @@ Rule-set overview
 
 .. opcmd:: show firewall group <name>
 
-   Overview of defined groups. You see the type, the members, and where the
-   group is used.
+   Show an overview of defined groups, including the type, members, and where
+   the group is used.
 
    .. code-block:: none
 
@@ -1242,7 +1240,7 @@ Rule-set overview
 
 .. opcmd:: show firewall statistics
 
-   This will show you statistics of all rule-sets since the last boot.
+   Show statistics of all rule-sets since the last boot.
 
 Show Firewall log
 =================
@@ -1255,9 +1253,8 @@ Show Firewall log
 .. opcmd:: show log firewall ipv6 [forward | input | output] filter rule <rule>
 .. opcmd:: show log firewall ipv6 name <name> rule <rule>
 
-   Show the logs of all firewall; show all ipv6 firewall logs; show all logs
-   for particular hook; show all logs for particular hook and priority;
-   show all logs for particular custom chain; show logs for specific Rule-Set.
+   Show firewall logs for all firewalls, all IPv6 firewalls, specific hooks,
+   specific priorities, specific custom chains, or specific rule-sets.
 
 Example Partial Config
 ======================
diff --git a/docs/configuration/firewall/zone.rst b/docs/configuration/firewall/zone.rst
index fde6c162..f3b12473 100644
--- a/docs/configuration/firewall/zone.rst
+++ b/docs/configuration/firewall/zone.rst
@@ -1,34 +1,27 @@
-:lastproofread: 2024-07-03
+:lastproofread: 2026-03-30
 
 .. _firewall-zone:
 
 ###################
-Zone Based Firewall
+Zone-Based Firewall
 ###################
 
 ********
 Overview
 ********
 
-.. note:: Starting from VyOS 1.4-rolling-202308040557, a new firewall
-   structure can be found on all VyOS installations. The Zone based firewall
-   was removed in that version, but re introduced in VyOS 1.4 and 1.5. All
-   versions built after 2023-10-22 have this feature.
-   Documentation for most of the new firewall CLI can be
-   found in the `firewall
-   <https://docs.vyos.io/en/latest/configuration/firewall/general.html>`_
-   chapter.
+.. note::
+    All VyOS versions built after 2023-10-22 (VyOS 1.4 and 1.5) support
+    this feature.
 
-In this section there's useful information on all firewall configuration that
-is needed for the zone-based firewall.
-Configuration commands covered in this section:
+This section provides information on firewall configuration for the
+zone-based firewall. This section covers the following configuration
+commands:
 
 .. cfgcmd:: set firewall zone ...
 
-From the main structure defined in
-:doc:`Firewall Overview</configuration/firewall/index>`
-in this section you can find detailed information only for the next part
-of the general structure:
+To learn about the general traffic flow in VyOS firewalls,
+see :doc:`Firewall </configuration/firewall/index>`.
 
 .. code-block:: none
 
@@ -37,22 +30,23 @@ of the general structure:
             - custom_zone_name
                + ...
 
-In zone-based policy, interfaces are assigned to zones, and inspection policy
-is applied to traffic moving between the zones and acted on according to
-firewall rules. A zone is a group of interfaces that have similar functions or
-features. It establishes the security borders of a network. A zone defines a
-boundary where traffic is subjected to policy restrictions as it crosses to
-another region of a network.
+In zone-based policy, you assign interfaces to zones and apply inspection
+policy to traffic moving between zones. The firewall acts on traffic
+according to rules. A zone is a group of interfaces that have similar
+functions or features. It establishes the security borders of a network.
+A zone defines a boundary where the system subjects traffic to policy
+restrictions as it crosses to another region of a network.
 
 Key Points:
 
-* A zone must be configured before an interface is assigned to it and an
-  interface can be assigned to only a single zone.
-* All traffic to and from an interface within a zone is permitted.
-* All traffic between zones is affected by existing policies
-* Traffic cannot flow between a zone member interface and any interface that is
-  not a zone member.
-* You need 2 separate firewalls to define traffic: one for each direction.
+* A zone must be configured before you assign an interface to it, and you
+  can assign an interface to only a single zone.
+* All traffic to and from an interface within a zone flows freely.
+* Existing policies affect all traffic between zones.
+* Traffic cannot flow between a zone member interface and any interface that
+  is not a zone member.
+* You must define 2 separate firewalls to define traffic: one for each
+  direction.
 
 .. note:: In :vytask:`T2199` the syntax of the zone configuration was changed.
    The zone configuration moved from ``zone-policy zone <name>`` to ``firewall
@@ -62,12 +56,13 @@ Key Points:
 Configuration
 *************
 
-As an alternative to applying policy to an interface directly, a zone-based
-firewall can be created to simplify configuration when multiple interfaces
-belong to the same security zone. Instead of applying rule-sets to interfaces,
-they are applied to source-destination zone pairs.
+As an alternative to applying policy to an interface directly, you can
+create a zone-based firewall to simplify configuration when multiple
+interfaces belong to the same security zone. Instead of applying rule-sets
+to interfaces, you apply them to source-destination zone pairs.
 
-A basic introduction to zone-based firewalls can be found `here
+You can find a basic introduction to zone-based firewalls in the
+`VyOS Knowledge Base
 <https://support.vyos.io/en/kb/articles/a-primer-to-zone-based-firewall>`_,
 and an example at :ref:`examples-zone-policy`.
 
@@ -80,7 +75,7 @@ The following steps are required to create a zone-based firewall:
 Define a Zone
 =============
 
-To define a zone setup either one with interfaces or the local zone.
+To define a zone, set up either one with interfaces or as the local zone.
 
 .. cfgcmd:: set firewall zone <name> interface <interface>
 
@@ -89,41 +84,41 @@ To define a zone setup either one with interfaces or the local zone.
    .. note::
 
       * An interface can only be a member of one zone.
-      * A zone can have multiple interfaces, with traffic between interfaces in
-        the same zone subject to the intra-zone-filtering policy (allowed by
-        default).
+      * You can have multiple interfaces in a zone. Traffic between
+        interfaces in the same zone follows the intra-zone-filtering
+        policy (allowed by default).
 
 .. cfgcmd:: set firewall zone <name> local-zone
 
-   Define the zone as the local zone, for traffic originating from and destined
-   to the router itself.
+   Define the zone as the local zone for traffic that originates from or is
+   destined to the router itself.
 
    .. note::
 
       * A local zone cannot have any member interfaces
-      * There cannot be multiple local zones
+      * You cannot have multiple local zones
 
 .. cfgcmd:: set firewall zone <name> default-action [drop | reject]
 
-   Change the zone default-action, which applies to traffic destined to this
-   zone that doesn't match any of the source zone rulesets applied.
+   Modify the zone default-action, which applies to traffic destined to this
+   zone that does not match any of the source zone rulesets applied.
 
 .. cfgcmd:: set firewall zone <name> default-log
 
-   Enable logging of packets that hit this zone's default-action (disabled by
-   default).
+   Enable logging of packets that match this zone's default-action (disabled
+   by default).
 
 .. cfgcmd:: set firewall zone <name> description
 
-   Set a meaningful description.
+   Add a meaningful description.
 
 Defining a Rule-Set
 =============================
 
-Zone-based firewall rule-sets are for traffic from a *Source Zone* to a
+Zone-based firewall rule-sets define traffic from a *Source Zone* to a
 *Destination Zone*.
 
-The rule-sets are created as a custom firewall chain using the commands below
+You create rule-sets as a custom firewall chain using the commands below
 (refer to the firewall IPv4/IPv6 sections for the full syntax):
 
 * For :ref:`IPv4<configuration/firewall/ipv4:Firewall - IPv4 Rules>`:
@@ -131,15 +126,16 @@ The rule-sets are created as a custom firewall chain using the commands below
 * For :ref:`IPv6<configuration/firewall/ipv6:Firewall - IPv6 Rules>`:
   ``set firewall ipv6 name <name> ...``
 
-It can be helpful to name the rule-sets in the format
-``<Sourze Zone>-<Destination Zone>-<v4 | v6>`` to make them easily identifiable.
+It is helpful to name the rule-sets in the format
+``<Source Zone>-<Destination Zone>-<v4 | v6>`` to make them easily
+identifiable.
 
 Applying a Rule-Set to a Zone
 =============================
 
-Once a rule-set has been defined, it can then be applied to the source and
-destination zones. The configuration syntax is anchored on the destination
-zone, with each of the source zone rule-sets listed against the destination.
+After you define a rule-set, apply it to the source and destination zones.
+The configuration syntax anchors to the destination zone, with each of the
+source zone rule-sets listed against the destination.
 
 .. cfgcmd::  set firewall zone <Destination Zone> from <Source Zone>
    firewall name <ipv4-rule-set-name>
@@ -147,7 +143,8 @@ zone, with each of the source zone rule-sets listed against the destination.
 .. cfgcmd::  set firewall zone <Destination Zone> from <Source Zone>
    firewall ipv6-name <ipv6-rule-set-name>
 
-It is recommended to create two rule-sets for each source-destination zone pair.
+You should create two rule-sets for each source-destination zone
+pair.
 
 .. code-block:: none
 
@@ -157,10 +154,10 @@ It is recommended to create two rule-sets for each source-destination zone pair.
 Applying a Default Rule-Set to a Zone
 =====================================
 
-When a destination zone shares a common rule-set for multiple source zones or
-a complex set of default policies are required, an optional default rule-set
-can be applied. The default rule-set applies to all zones that do not have a
-rule-set configured as defined in
+When a destination zone shares a common rule-set for multiple source zones,
+or when you require a complex set of default policies, you can apply an
+optional default rule-set. The default rule-set applies to all zones that do
+not have a rule-set configured as defined in
 :ref:`IPv4<configuration/firewall/zone:Applying a Rule-Set to a Zone>`
 
 .. cfgcmd:: set firewall zone <Destination Zone> default-firewall name
@@ -175,7 +172,7 @@ Operation-mode
 
 .. opcmd:: show firewall zone-policy
 
-   This will show you a basic summary of the zone configuration.
+   Display a basic summary of the zone configuration.
 
    .. code-block:: none
 
@@ -191,7 +188,7 @@ Operation-mode
 
 .. opcmd:: show firewall zone-policy zone <zone>
 
-   This will show you a basic summary of a particular zone.
+   Display a basic summary of a particular zone.
 
    .. code-block:: none
 
diff --git a/docs/configuration/highavailability/index.rst b/docs/configuration/highavailability/index.rst
index 40465c30..c82391c7 100644
--- a/docs/configuration/highavailability/index.rst
+++ b/docs/configuration/highavailability/index.rst
@@ -2,8 +2,9 @@
 
 .. _high-availability:
 
+#################
 High availability
-=================
+#################
 
 VRRP (Virtual Router Redundancy Protocol) provides active/backup redundancy for
 routers. Every VRRP router has a physical IP/IPv6 address, and a virtual
@@ -252,8 +253,12 @@ need to configure it. But if necessary, Gratuitous ARP can be configured in
 
    0 if not defined.
 
+.. stop_vyoslinter
+
 .. cfgcmd:: set high-availability vrrp global-parameters garp master-delay <1-255>
 
+.. start_vyoslinter
+
 .. cfgcmd:: set high-availability vrrp group <name> garp master-delay <1-255>
 
    Set delay for second set of gratuitous ARPs after transition to MASTER.
@@ -316,37 +321,46 @@ vice versa and can be used to enable or disable certain services, for example.
 
      chmod +x /config/scripts/script-name.sh
 
-.. warning:: It is not recommended to change VRRP configuration inside health-check
-   and transition scripts.
+.. warning:: It is not recommended to change VRRP configuration
+   inside health-check and transition scripts.
 
 Health check scripts
 ^^^^^^^^^^^^^^^^^^^^
 
-There is the ability to run an arbitrary script at regular intervals according to health-check
-parameters. If a script returns 0, it indicates success. If a script returns anything
-else, it will indicate that the VRRP instance should enter the FAULT state.
+There is the ability to run an arbitrary script at regular intervals
+according to health-check parameters. If a script returns 0, it
+indicates success. If a script returns anything else, it will indicate
+that the VRRP instance should enter the FAULT state.
 
 This setup will make the VRRP process execute the
 ``/config/scripts/vrrp-check.sh script`` every 60 seconds, and transition the
 group to the fault state if it fails (i.e. exits with non-zero status) three
 times:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set high-availability vrrp group Foo health-check script /config/scripts/vrrp-check.sh
   set high-availability vrrp group Foo health-check interval 60
   set high-availability vrrp group Foo health-check failure-count 3
 
+.. start_vyoslinter
+
 When the vrrp group is a member of the sync group will use only
 the sync group health check script.
 This example shows how to configure it for the sync group:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set high-availability vrrp sync-group Bar health-check script /config/scripts/vrrp-check.sh
   set high-availability vrrp sync-group Bar health-check interval 60
   set high-availability vrrp sync-group Bar health-check failure-count 3
 
+.. start_vyoslinter
+
 Transition scripts
 ^^^^^^^^^^^^^^^^^^
 
@@ -356,12 +370,16 @@ This setup will make the VRRP process execute the
 ``/config/scripts/vrrp-fail.sh`` with argument ``Foo`` when VRRP fails,
 and the ``/config/scripts/vrrp-master.sh`` when the router becomes the master:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set high-availability vrrp group Foo transition-script backup "/config/scripts/vrrp-fail.sh Foo"
   set high-availability vrrp group Foo transition-script fault "/config/scripts/vrrp-fail.sh Foo"
   set high-availability vrrp group Foo transition-script master "/config/scripts/vrrp-master.sh Foo"
 
+.. start_vyoslinter
+
 To know more about scripting, check the :ref:`command-scripting` section.
 
 Virtual-server
@@ -401,10 +419,14 @@ Health-check
 ^^^^^^^^^^^^
 Custom health-check script allows checking real-server availability
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set high-availability virtual-server 203.0.113.1 real-server 192.0.2.11 health-check script <path-to-script>
 
+.. start_vyoslinter
+
 Fwmark
 ^^^^^^
 Firewall mark. It possible to loadbalancing traffic based on ``fwmark`` value
@@ -417,10 +439,14 @@ Real server
 ^^^^^^^^^^^
 Real server IP address and port
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set high-availability virtual-server 203.0.113.1 real-server 192.0.2.11 port '80'
 
+.. start_vyoslinter
+
 
 Example
 ^^^^^^^
@@ -432,6 +458,8 @@ protocol TCP is balanced between 2 real servers ``192.0.2.11`` and
 
 Real server is auto-excluded if port check with this server fail.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set interfaces ethernet eth0 address '203.0.113.11/24'
@@ -451,6 +479,7 @@ Real server is auto-excluded if port check with this server fail.
   set high-availability virtual-server 203.0.113.1 real-server 192.0.2.11 port '80'
   set high-availability virtual-server 203.0.113.1 real-server 192.0.2.12 port '80'
 
+.. start_vyoslinter
 
 A firewall mark ``fwmark`` allows using multiple ports for high-availability
 virtual-server.
@@ -460,6 +489,8 @@ In this example all traffic destined to ports "80, 2222, 8888" protocol TCP
 marks to fwmark "111" and balanced between 2 real servers.
 Port "0" is required if multiple ports are used.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set interfaces ethernet eth0 address 'dhcp'
@@ -483,6 +514,8 @@ Port "0" is required if multiple ports are used.
   set nat source rule 100 source address '192.0.2.0/24'
   set nat source rule 100 translation address 'masquerade'
 
+.. start_vyoslinter
+
 Op-mode check virtual-server status
 
 .. code-block:: none
diff --git a/docs/configuration/index.rst b/docs/configuration/index.rst
index f607d4d7..f86365a9 100644
--- a/docs/configuration/index.rst
+++ b/docs/configuration/index.rst
@@ -2,7 +2,7 @@
 Configuration Guide
 ###################
 
-The following structure respresent the cli structure.
+The following structure represents the CLI structure.
 
 .. toctree::
    :maxdepth: 1
diff --git a/docs/configuration/interfaces/openvpn-examples.rst b/docs/configuration/interfaces/openvpn-examples.rst
index bba04d9c..6e746e46 100644
--- a/docs/configuration/interfaces/openvpn-examples.rst
+++ b/docs/configuration/interfaces/openvpn-examples.rst
@@ -1,6 +1,10 @@
 
+############
 Site-to-site
-============
+############
+
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
 
 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, 
@@ -29,9 +33,9 @@ In both cases, we will use the following settings:
 * 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 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.
+* 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.*
@@ -51,6 +55,8 @@ Elliptic Curve (EC) type. In configuration mode, run the following command:
 certificate to the configuration session's ``pki`` subtree. Review and commit 
 the changes.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos# run generate pki certificate self-signed install openvpn-local
@@ -82,16 +88,21 @@ the changes.
 
   vyos@vyos# commit
 
+.. start_vyoslinter
 
 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:
 
+.. stop_vyoslinter
+
 .. 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
 
+.. start_vyoslinter
+
 .. note:: Certificate names are arbitrary. While ``openvpn-local`` and 
    ``openvpn-remote`` are used here, you may choose any names.
 
@@ -102,6 +113,8 @@ Set up site-to-site OpenVPN
 
 Local configuration:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   Configure the tunnel:
@@ -134,6 +147,8 @@ 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
 
+.. start_vyoslinter
+
 Set up pre-shared keys
 ----------------------
 
@@ -146,6 +161,8 @@ 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``.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@local# run generate pki openvpn shared-secret install s2s
@@ -163,6 +180,8 @@ we use ``s2s``.
   vyos@local# commit
   [edit]
 
+.. start_vyoslinter
+
 Next, install the key on the remote router:
 
 .. code-block:: none
@@ -181,6 +200,8 @@ Set up firewall exceptions
 To allow OpenVPN traffic to pass through the WAN interface, create a firewall 
 exception:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
    set firewall ipv4 name OUTSIDE_LOCAL rule 10 action 'accept'
@@ -193,6 +214,8 @@ exception:
    set firewall ipv4 name OUTSIDE_LOCAL rule 20 log
    set firewall ipv4 name OUTSIDE_LOCAL rule 20 protocol 'udp'
 
+.. start_vyoslinter
+
 Apply the OUTSIDE_LOCAL firewall group to the WAN interface and to the input 
 filter for traffic destined for the router itself:
 
@@ -229,6 +252,8 @@ unique ports to each tunnel.
 
 Verify OpenVPN status using the show openvpn operational commands.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos:~$ show openvpn site-to-site
@@ -239,6 +264,7 @@ Verify OpenVPN status 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
 
+.. start_vyoslinter
 
 Server-client
 =============
@@ -262,6 +288,8 @@ session's PKI subtree.
 
 Certificate Authority (CA):
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos# run generate pki ca install ca-1
@@ -363,6 +391,8 @@ 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=='
 
+.. start_vyoslinter
+
 Manually copy the CA, client certificate, and Diffie-Hellman key to the client 
 device, then commit them before configuring the OpenVPN interface. 
 
@@ -408,7 +438,8 @@ connection resets or daemon reloads. Clients are identified by the CN attribute
 in their SSL certificates.
 
 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. 
+push-route option to automatically install the appropriate route on
+each client.
 
 .. code-block:: none
 
@@ -448,6 +479,8 @@ Verification
 
 Check the tunnel status:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos:~$ show openvpn server
@@ -456,9 +489,9 @@ Check the tunnel status:
 
   Client CN    Remote Host         Tunnel IP    Local Host        TX bytes    RX bytes    Connected Since
   -----------  ------------------  -----------  ----------------  ----------  ----------  -------------------
-  client1      172.110.12.54:33166  10.23.1.10   172.18.201.10:1194  3.4 KB      3.4 KB      2024-06-11 12:07:25
-
+  client1      172.16.12.54:33166  10.23.1.10   172.18.201.10:1194  3.4 KB      3.4 KB      2024-06-11 12:07:25
 
+.. start_vyoslinter
 
 Server bridge
 =============
@@ -525,10 +558,14 @@ configuration file.
 **Best practice:** Store the configuration file in the ``/config`` directory 
 to ensure it is preserved after image updates.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set interfaces openvpn vtun0 openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"
 
+.. start_vyoslinter
+
 A sample configuration file is shown below:
 
 .. code-block:: none
@@ -558,6 +595,8 @@ Active Directory
 
 A sample configuration file is shown below:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   <LDAP>
@@ -589,8 +628,11 @@ A sample configuration file is shown below:
     </Group>
   </Authorization>
 
-If you only want to check that the user account is enabled and can authenticate 
-(against the primary group), the following snippet is sufficient:
+.. start_vyoslinter
+
+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
 
@@ -609,8 +651,10 @@ If you only want to check that the user account is enabled and can authenticate
     RequireGroup    false
   </Authorization>
 
-A complete example of an LDAP authentication configuration for OpenVPN is shown 
-below:
+A complete example of an LDAP authentication configuration for OpenVPN
+is shown below:
+
+.. stop_vyoslinter
 
 .. code-block:: none
 
@@ -639,7 +683,14 @@ below:
        }
    }
 
-For a detailed example, refer to :doc:`OpenVPN with LDAP</configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP>`.
+.. start_vyoslinter
+
+.. stop_vyoslinter
+
+For a detailed example, refer to
+:doc:`OpenVPN with LDAP</configexamples/autotest/OpenVPN_with_LDAP/OpenVPN_with_LDAP>`.
+
+.. start_vyoslinter
 
 Multi-factor authentication
 ===========================
@@ -671,6 +722,8 @@ To display authentication information, use the following command:
 
 Example:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
    vyos@vyos:~$ sh interfaces openvpn vtun20 user user1 mfa qrcode
@@ -694,6 +747,8 @@ Example:
    █████████████████████████████████████
    █████████████████████████████████████
 
+.. start_vyoslinter
+
 Scan the QR code to add the user account to Google Authenticator. On the client 
 side, use the generated OTP as the password.
 
@@ -714,6 +769,8 @@ username and password.
 Server configuration
 --------------------
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set interfaces openvpn vtun10 local-port '1194'
@@ -730,6 +787,8 @@ Server configuration
   set interfaces openvpn vtun10 tls certificate 'srv-1'
   set interfaces openvpn vtun10 tls dh-params 'dh-1'
 
+.. start_vyoslinter
+
 The /config/auth/check_user.sh example includes two test users:
 
 .. code-block:: none
@@ -753,10 +812,14 @@ Client configuration
 Storing the client certificate locally lets you generate the OpenVPN client 
 configuration file. Use the following command:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos:~$ generate openvpn client-config interface vtun10 ca ca-1 certificate client1
 
+.. start_vyoslinter
+
 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 
diff --git a/docs/configuration/interfaces/tunnel.rst b/docs/configuration/interfaces/tunnel.rst
index 27c47a91..f1376cdf 100644
--- a/docs/configuration/interfaces/tunnel.rst
+++ b/docs/configuration/interfaces/tunnel.rst
@@ -2,8 +2,9 @@
 
 .. _tunnel-interface:
 
+######
 Tunnel
-======
+######
 
 Tunnel interfaces are virtual links that transmit encapsulated traffic between 
 private networks or hosts across public infrastructure, such as the Internet. 
diff --git a/docs/configuration/interfaces/vti.rst b/docs/configuration/interfaces/vti.rst
index 1704b9d1..e45c17d9 100644
--- a/docs/configuration/interfaces/vti.rst
+++ b/docs/configuration/interfaces/vti.rst
@@ -1,17 +1,92 @@
 .. _vti-interface:
 
 ##############################
-VTI - Virtual Tunnel Interface
+VTI (virtual tunnel interface)
 ##############################
 
-Set Virtual Tunnel Interface
+:abbr:`VTIs (virtual tunnel interfaces)` let you create secure, encrypted 
+tunnels between private networks or hosts across public infrastructure, such as 
+the Internet. They operate alongside an underlying IPsec tunnel, which handles 
+encapsulation and encryption, while VTIs function exclusively as routing 
+interfaces.
+
+*************
+Configuration
+*************
+
+Common interface configuration
+==============================
+
+.. cmdinclude:: /_include/interface-address.txt
+   :var0: vti
+   :var1: vti0
+
+.. cmdinclude:: /_include/interface-description.txt
+   :var0: vti
+   :var1: vti0
+
+.. cmdinclude:: /_include/interface-disable.txt
+  :var0: vti
+  :var1: vti0
+
+.. cmdinclude:: /_include/interface-ip.txt
+  :var0: vti
+  :var1: vti0
+
+.. cmdinclude:: /_include/interface-ipv6.txt
+  :var0: vti
+  :var1: vti0
+
+.. cmdinclude:: /_include/interface-mtu.txt
+  :var0: vti
+  :var1: vti0
+
+.. cfgcmd:: set interfaces vti <interface> mirror egress <monitor-interface>
+
+   Configure mirroring of outgoing traffic from the specified VTI to the 
+   designated monitor interface.
+
+.. cfgcmd:: set interfaces vti <interface> mirror ingress <monitor-interface>
+   
+   Configure mirroring of incoming traffic from the specified VTI to the 
+   designated monitor interface.
+
+.. cfgcmd:: set interfaces vti <interface> redirect <interface>
+
+   Enable redirection of incoming packets to the specified interface.
+
+.. cmdinclude:: /_include/interface-vrf.txt
+  :var0: vti
+  :var1: vti0
+
+*********
+Operation
+*********
+
+.. opcmd:: show interfaces vti <vtiX>
+
+   Show the operational status and traffic statistics for the specified VTI.
+
+.. opcmd:: show interfaces vti <vtiX> brief
+
+   Show a brief operational status summary for the specified VTI. 
+
+
+*******
+Example
+*******
+
+**Configure a VTI**
+
+Assign IPv4 and IPv6 addresses to the VTI, along with a brief description:
 
 .. code-block:: none
 
   set interfaces vti vti0 address 192.168.2.249/30
   set interfaces vti vti0 address 2001:db8:2::249/64
+  set interfaces vti vti0 description "Description"
 
-Results in:
+Resulting configuration:
 
 .. code-block:: none
 
@@ -22,19 +97,19 @@ Results in:
       description "Description"
   }
 
-.. warning:: When using site-to-site IPsec with VTI interfaces,
-   be sure to disable route autoinstall
+.. warning:: When configuring site-to-site IPsec with VTIs, ensure that route 
+   autoinstall is disabled.
 
 .. code-block:: none
   
   set vpn ipsec options disable-route-autoinstall
 
-More details about the IPsec and VTI issue and option disable-route-autoinstall
-https://blog.vyos.io/vyos-1-dot-2-0-development-news-in-july
+For more information about the IPsec and VTI issue, as well as the 
+``disable-route-autoinstall`` option, see:
+https://blog.vyos.io/vyos-1-dot-2-0-development-news-in-july.
 
-The root cause of the problem is that for VTI tunnels to work, their traffic 
-selectors have to be set to 0.0.0.0/0 for traffic to match the tunnel, even 
-though actual routing decision is made according to netfilter marks. Unless 
-route insertion is disabled entirely, StrongSWAN thus mistakenly inserts a 
-default route through the VTI peer address, which makes all traffic routed 
-to nowhere.
\ No newline at end of file
+The root cause of the problem is that VTI tunnels require their traffic 
+selectors to be set to ``0.0.0.0/0`` for traffic to match the tunnel, even 
+though routing decisions are based on netfilter marks. Unless route insertion 
+is explicitly disabled, strongSWAN incorrectly inserts a default route through 
+the VTI peer address, causing all traffic to be misrouted.
diff --git a/docs/configuration/interfaces/wireless.rst b/docs/configuration/interfaces/wireless.rst
index e6a29f9a..728783b2 100644
--- a/docs/configuration/interfaces/wireless.rst
+++ b/docs/configuration/interfaces/wireless.rst
@@ -1,17 +1,14 @@
-:lastproofread: 2024-07-04
+:lastproofread: 2026-03-23
 
 .. _wireless-interface:
 
-########################
-WLAN/WIFI - Wireless LAN
-########################
+####################
+Wireless LAN / Wi-Fi
+####################
 
-The :abbr:`WLAN (Wireless LAN)` interface provides 802.11 (a/b/g/n/ac) wireless
-support (commonly referred to as Wi-Fi) by means of compatible hardware. If
-your hardware supports it, VyOS supports multiple logical wireless interfaces
-per physical device.
-
-There are three modes of operation for a wireless interface:
+:abbr:`WLAN (Wireless LAN)` interfaces provide 802.11 (a/b/g/n/ac) wireless
+connectivity, referred to as Wi-Fi, and operate in one of the following
+modes:
 
 * :abbr:`WAP (Wireless Access-Point)` mode provides network access to connecting
   stations if the physical hardware supports acting as a WAP
@@ -22,7 +19,7 @@ There are three modes of operation for a wireless interface:
 * Monitor mode lets the system passively monitor wireless traffic
 
 If the system detects an unconfigured wireless device, it will be automatically
-added the configuration tree, specifying any detected settings (for example,
+added to the configuration tree, specifying any detected settings (for example,
 its MAC address) and configured to run in monitor mode.
 
 *************
@@ -36,7 +33,7 @@ Common interface configuration
    :var0: wireless
    :var1: wlan0
 
-System Wide configuration
+System-wide configuration
 =========================
 
 .. cfgcmd:: set system wireless country-code <cc>
@@ -45,24 +42,20 @@ System Wide configuration
   to indicate country in which device is operating. This can limit available
   channels and transmit power.
 
-  .. note:: This option is mandatory in Access-Point mode.
+  .. note:: This option is mandatory in ``access-point`` mode.
 
 Wireless options
 ================
 
-.. cfgcmd:: set system wireless country-code <cc>
-
-  Country code (ISO/IEC 3166-1). Used to set regulatory domain. Set as needed
-  to indicate country in which the box is operating. This can limit available
-  channels and transmit power.
-
-  .. note:: This option is mandatory in Access-Point mode.
-
 .. cfgcmd:: set interfaces wireless <interface> channel <number>
 
-  Channel number (IEEE 802.11), for 2.4Ghz (802.11 b/g/n/ax) channels range from
-  1-14. On 5Ghz (802.11 a/h/j/n/ac) channels available are 0, 34 to 177. 
-  On 6GHz (802.11 ax) channels range from 1 to 233.
+  Configure the IEEE 802.11 wireless radio channel for the interface.
+  Channel allocation depends on the frequency band:
+
+  * **2.4 GHz** (802.11b/g/n/ax): Channels range from 1 to 14.
+  * **5 GHz** (802.11a/h/j/n/ac/ax): Channels range from 34 to 177.
+  * **6 GHz** (802.11ax): Channels range from 1 to 233.
+  * **Automatic channel selection:** 0.
 
 .. cfgcmd:: set interfaces wireless <interface> disable-broadcast-ssid
 
@@ -84,7 +77,7 @@ Wireless options
 
   By default, this bridging is allowed.
 
-.. cfgcmd:: set interfaces wireless <interface> max-stations
+.. cfgcmd:: set interfaces wireless <interface> max-stations <count>
 
   Maximum number of stations allowed in station table. New stations will be
   rejected after the station table is full. IEEE 802.11 has a limit of 2007
@@ -144,9 +137,9 @@ Wireless options
 
   Wireless device type for this interface
 
-  * ``access-point`` - Access-point forwards packets between other nodes
-  * ``station`` - Connects to another access point
-  * ``monitor`` - Passively monitor all packets on the frequency/channel
+  * ``access-point``: Forwards packets between other nodes.
+  * ``station``: Connects to another :abbr:`AP (Access Point)`.
+  * ``monitor``: Passively monitors all packets on the frequency/channel.
 
 .. cmdinclude:: /_include/interface-per-client-thread.txt
    :var0: wireless
@@ -164,7 +157,8 @@ PPDU
 HT (High Throughput) capabilities (802.11n)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-  Configuring HT mode options is required when using 802.11n or 802.11ax at 2.4GHz.
+  Configuring HT mode options is required when using 802.11n or
+  802.11ax at 2.4GHz.
 
 .. cfgcmd:: set interfaces wireless <interface> capabilities ht 40mhz-incapable
 
@@ -185,12 +179,9 @@ HT (High Throughput) capabilities (802.11n)
   * ``ht40+`` - Both 20 MHz and 40 MHz with secondary channel above the primary
     channel
 
-  .. note:: There are limits on which channels can be used with HT40- and HT40+.
-    Following table shows the channels that may be available for HT40- and HT40+
-    use per IEEE 802.11n Annex J:
-
-    Depending on the location, not all of these channels may be available for
-    use!
+  .. note:: Channel availability for HT40- and HT40+ is limited. The following
+     table lists channels permitted for HT40- and HT40+ according to IEEE
+     802.11n Annex J. Channel availability may vary by location.
 
     .. code-block:: none
 
@@ -199,7 +190,7 @@ HT (High Throughput) capabilities (802.11n)
       5 GHz		40,48,56,64	36,44,52,60
 
   .. note:: 40 MHz channels may switch their primary and secondary channels if
-    needed or creation of 40 MHz channel maybe rejected based on overlapping
+    needed or creation of 40 MHz channel may be rejected based on overlapping
     BSSes. These changes are done automatically when hostapd is setting up the
     40 MHz channel.
 
@@ -250,7 +241,11 @@ HT (High Throughput) capabilities (802.11n)
 VHT (Very High Throughput) capabilities (802.11ac)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. cfgcmd:: set interfaces wireless <interface> capabilities vht antenna-count
+.. stop_vyoslinter
+
+.. cfgcmd:: set interfaces wireless <interface> capabilities vht antenna-count <count>
+
+.. start_vyoslinter
 
   Number of antennas on this card
 
@@ -352,7 +347,7 @@ HE (High Efficiency) capabilities (802.11ax)
     single user beamformer
   * ``single-user-beamformee`` - Support for operation as 
     single user beamformee
-  * ``multi-user-beamformer`` - Support for operation as single 
+  * ``multi-user-beamformer`` - Support for operation as multi
     user beamformer
 
 .. cfgcmd:: set interfaces wireless <interface> 
@@ -394,7 +389,7 @@ HE (High Efficiency) capabilities (802.11ax)
 .. cfgcmd:: set interfaces wireless <interface> 
   capabilities he coding-scheme <number>
 
-  This setting configures Spacial Stream and Modulation Coding Scheme 
+  This setting configures Spatial Stream and Modulation Coding Scheme 
   settings for HE mode (HE-MCS). It is usually not needed to set this 
   explicitly, but it might help with some WiFi adapters.
 
@@ -417,10 +412,10 @@ default physical device (``phy0``) is used.
   set system wireless country-code de
   set interfaces wireless wlan0 type station
   set interfaces wireless wlan0 address dhcp
-  set interfaces wireless wlan0 ssid Test
+  set interfaces wireless wlan0 ssid 'TEST'
   set interfaces wireless wlan0 security wpa passphrase '12345678'
 
-Resulting in
+Resulting configuration:
 
 .. code-block:: none
 
@@ -445,7 +440,7 @@ Security
 ========
 
 :abbr:`WPA (Wi-Fi Protected Access)`, WPA2 Enterprise and WPA3 Enterprise in 
-combination with 802.1x based authentication can be used to authenticate 
+combination with 802.1X based authentication can be used to authenticate 
 users or computers in a domain.
 
 The wireless client (supplicant) authenticates against the RADIUS server
@@ -472,7 +467,7 @@ The WAP in this example has the following characteristics:
   set interfaces wireless wlan0 type access-point
   set interfaces wireless wlan0 channel 1
   set interfaces wireless wlan0 mode n
-  set interfaces wireless wlan0 ssid 'TEST'
+  set interfaces wireless wlan0 ssid 'Enterprise-TEST'
   set interfaces wireless wlan0 security wpa mode wpa2
   set interfaces wireless wlan0 security wpa cipher CCMP
   set interfaces wireless wlan0 security wpa radius server 192.168.3.10 key 'VyOSPassword'
@@ -480,7 +475,7 @@ The WAP in this example has the following characteristics:
 
 .. start_vyoslinter
 
-Resulting in
+Resulting configuration:
 
 .. code-block:: none
 
@@ -546,7 +541,7 @@ about all wireless interfaces.
 
 .. opcmd:: show interfaces wireless detail
 
-Use this command to view operational status and details wireless-specific
+Show the operational status and detailed wireless-specific
 information about all wireless interfaces.
 
 .. stop_vyoslinter
@@ -688,7 +683,7 @@ The WAP in this example has the following characteristics:
   set interfaces wireless wlan0 security wpa cipher CCMP
   set interfaces wireless wlan0 security wpa passphrase '12345678'
 
-Resulting in
+Resulting configuration:
 
 .. code-block:: none
 
@@ -715,28 +710,29 @@ Resulting in
       }
   }
 
-To get it to work as an access point with this configuration you will need
-to set up a DHCP server to work with that network. You can - of course - also
-bridge the Wireless interface with any configured bridge
-(:ref:`bridge-interface`) on the system.
+To enable access point functionality, configure a DHCP server for this
+interface's network, or add the interface to an existing local bridge
+(see :ref:`bridge-interface` for details).
 
-WiFi-6(e) - 802.11ax
-====================
+Wi-Fi 6/6E (802.11ax)
+=====================
 
-The following examples will show valid configurations for WiFi-6 (2.4GHz) 
-and WiFi-6e (6GHz) Access-Points with the following characteristics:
+The following examples configure Wi-Fi 6 (2.4 GHz) and Wi-Fi 6E (6 GHz)
+:abbr:`APs (Access Points)` with the following parameters:
 
-* Network ID (SSID) ``test.ax``
-* WPA passphrase ``super-dooper-secure-passphrase``
-* Use 802.11ax protocol
-* Wireless channel ``11`` for 2.4GHz
-* Wireless channel ``5`` for 6GHz 
+* Network ID (SSID): ``test.ax``
+* WPA passphrase: ``super-dooper-secure-passphrase``
+* Protocol: 802.11ax
+* Wireless channel for 2.4 GHz: ``11``
+* Wireless channel for 6 GHz: ``5``
 
 
-Example Configuration: WiFi-6 at 2.4GHz
----------------------------------------
+Example configuration: Wi-Fi 6 at 2.4 GHz
+------------------------------------------
 
-You may expect real throughputs around 10MBytes/s or higher in crowded areas.
+You may expect real throughput around 10 MB/s or higher in crowded areas.
+
+.. stop_vyoslinter
 
 .. code-block:: none
 
@@ -768,7 +764,9 @@ You may expect real throughputs around 10MBytes/s or higher in crowded areas.
   set interfaces wireless wlan0 type access-point
   commit
 
-Resulting in
+.. start_vyoslinter
+
+Resulting configuration:
 
 .. code-block:: none
 
@@ -824,14 +822,16 @@ Resulting in
       }
   }
 
-Example Configuration: WiFi-6e at 6GHz
---------------------------------------
+Example configuration: Wi-Fi 6E at 6 GHz
+-----------------------------------------
 
-You may expect real throughputs around 50MBytes/s to 150MBytes/s, 
-depending on obstructions by walls, water, metal or other materials
-with high electro-magnetic dampening at 6GHz. Best results are achieved 
+You may expect real throughput between 50 MB/s and 150 MB/s, depending on
+obstructions from walls, water, metal, or other materials
+with high electromagnetic damping at 6 GHz. Best results are achieved
 with the AP being in the same room and in line-of-sight.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set system wireless country-code de
@@ -841,7 +841,7 @@ with the AP being in the same room and in line-of-sight.
   set interfaces wireless wlan0 capabilities he beamform single-user-beamformer
   set interfaces wireless wlan0 capabilities he bss-color 13
   set interfaces wireless wlan0 capabilities he channel-set-width 134
-  set interfaces wireless wlan0 capabilities he capabilities he center-channel-freq freq-1 15
+  set interfaces wireless wlan0 capabilities he center-channel-freq freq-1 15
   set interfaces wireless wlan0 channel 5
   set interfaces wireless wlan0 description "802.11ax 6GHz"
   set interfaces wireless wlan0 mode ax
@@ -858,7 +858,9 @@ with the AP being in the same room and in line-of-sight.
   set interfaces wireless wlan0 stationary-ap
   commit
 
-Resulting in
+.. start_vyoslinter
+
+Resulting configuration:
 
 .. code-block:: none
 
@@ -913,8 +915,7 @@ Resulting in
 Intel AX200
 ===========
 
-The Intel AX200 card does not work out of the box in AP mode, see
-https://unix.stackexchange.com/questions/598275/intel-ax200-ap-mode. You can
+The Intel AX200 card does not work out of the box in AP mode. You can
 still put this card into AP mode using the following configuration:
 
 .. stop_vyoslinter
diff --git a/docs/configuration/interfaces/wwan.rst b/docs/configuration/interfaces/wwan.rst
index b4b6a9ce..7ab3ac74 100644
--- a/docs/configuration/interfaces/wwan.rst
+++ b/docs/configuration/interfaces/wwan.rst
@@ -1,15 +1,15 @@
-:lastproofread: 2024-07-04
+:lastproofread: 2026-03-30
 
 .. _wwan-interface:
 
-#################################
-WWAN - Wireless Wide-Area-Network
-#################################
+####
+WWAN
+####
 
-The Wireless Wide-Area-Network interface provides access (through a wireless
-modem/wwan) to wireless networks provided by various cellular providers.
+:abbr:`WWAN (Wireless Wide Area Network)` interfaces provide access to cellular 
+networks via a cellular modem or card. 
 
-VyOS uses the `interfaces wwan` subsystem for configuration.
+Configure these interfaces under the ``interfaces wwan`` node.
 
 *************
 Configuration
@@ -64,14 +64,18 @@ Common interface configuration
    :var0: wwan
    :var1: wwan0
 
-WirelessModem (WWAN) options
-============================
+WWAN options
+============
 
 .. cfgcmd:: set interfaces wwan <interface> apn <apn>
 
-  Every WWAN connection requires an :abbr:`APN (Access Point Name)` which is
-  used by the client to dial into the ISPs network. This is a mandatory
-  parameter. Contact your Service Provider for correct APN.
+  **Configure the** :abbr:`APN (Access Point Name)` **for the WWAN connection.** 
+
+  Every WWAN connection requires an :abbr:`APN (Access Point Name)` to connect to 
+  the cellular network.
+
+  This parameter is mandatory. Contact your service provider for the correct 
+  :abbr:`APN (Access Point Name)`.
 
 
 *********
@@ -80,7 +84,8 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface>
 
-  Show detailed information on given `<interface>`
+  Show the operational status and traffic statistics for the specified WWAN 
+  interface. 
 
   .. code-block:: none
 
@@ -99,7 +104,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> summary
 
-  Show detailed information summary on given `<interface>`
+  Show WWAN module hardware characteristics and connection information.
 
   .. code-block:: none
 
@@ -166,7 +171,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> capabilities
 
-  Show WWAN module hardware capabilities.
+  Show WWAN module radio capabilities.
 
   .. code-block:: none
 
@@ -181,7 +186,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> firmware
 
-  Show WWAN module firmware.
+  Show WWAN module firmware information.
 
   .. code-block:: none
 
@@ -208,7 +213,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> imsi
 
-  Show WWAN module IMSI.
+  Show the IMSI of the associated SIM card.
 
   .. code-block:: none
 
@@ -226,7 +231,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> msisdn
 
-  Show WWAN module MSISDN.
+  Show the MSISDN of the associated SIM card.
 
   .. code-block:: none
 
@@ -244,7 +249,7 @@ Operation
 
 .. opcmd:: show interfaces wwan <interface> signal
 
-  Show WWAN module signal strength.
+  Show signal information for the cellular connection.
 
   .. code-block:: none
 
@@ -293,20 +298,20 @@ Operation
 Example
 *******
 
-The following example is based on a Sierra Wireless MC7710 miniPCIe card (only
-the form factor in reality it runs UBS) and Deutsche Telekom as ISP. The card
-is assembled into a :ref:`pc-engines-apu4`.
+The following example shows how to configure a cellular connection using a 
+Sierra Wireless MC7710 miniPCIe card that operates over USB despite its form 
+factor. The card is installed in a :ref:`pc-engines-apu4`.
 
 .. code-block:: none
 
   set interfaces wwan wwan0 apn 'internet.telekom'
   set interfaces wwan wwan0 address 'dhcp'
 
-*****************
-Supported Modules
-*****************
+******************
+Supported hardware
+******************
 
-The following hardware modules have been tested successfully in an
+The following WWAN modules have been successfully tested with a 
 :ref:`pc-engines-apu4` board:
 
 * Sierra Wireless AirPrime MC7304 miniPCIe card (LTE)
@@ -318,19 +323,18 @@ The following hardware modules have been tested successfully in an
 * HP LT4120 Snapdragon X5 LTE
 
 ***************
-Firmware Update
+Firmware update
 ***************
 
-All available WWAN cards have a built-in, reprogrammable firmware. Most vendors
-provide regular updates to firmware used in the baseband chip.
+WWAN modules include reprogrammable firmware, and most vendors regularly 
+provide updates for it.
 
-As VyOS makes use of the QMI interface to connect to the WWAN modem cards, the
-firmware can be reprogrammed.
+Since VyOS communicates with these devices via the QMI interface, you can 
+update firmware directly within the system using the ``qmi-firmware-update`` 
+utility.
 
-To update the firmware, VyOS also ships the `qmi-firmware-update` binary. To
-upgrade the firmware of an e.g. Sierra Wireless MC7710 module to the firmware
-provided in the file ``9999999_9999999_9200_03.05.14.00_00_generic_000.000_001_SPKG_MC.cwe``
-use the following command:
+The following example shows how to update the firmware for a Sierra Wireless 
+MC7710 module using the provided .cwe file.
 
 .. code-block:: bash
 
diff --git a/docs/configuration/loadbalancing/haproxy.rst b/docs/configuration/loadbalancing/haproxy.rst
index 667ebb95..d742ec18 100644
--- a/docs/configuration/loadbalancing/haproxy.rst
+++ b/docs/configuration/loadbalancing/haproxy.rst
@@ -1,21 +1,22 @@
+:lastproofread: 2026-04-06
 
 #############
-Haproxy
+HAproxy
 #############
 
 .. include:: /_include/need_improvement.txt
 
-Haproxy is a balancer and proxy server that provides
-high-availability, load balancing and proxying for TCP (level 4)
-and HTTP-based (level 7) applications.
+HAProxy is a load balancer and proxy server that provides
+high-availability, load balancing, and proxying for TCP (level 4) and
+HTTP-based (level 7) applications.
 
 Configuration
 =============
 
 
-Service configuration is responsible for binding to a specific port,
-while the backend configuration determines the type of load balancing
-to be applied and specifies the real servers to be utilized.
+Service configuration specifies the port to bind to. Backend
+configuration defines the load balancing method and specifies the backend
+servers.
 
 Service
 -------
@@ -23,7 +24,8 @@ Service
 .. cfgcmd:: set load-balancing haproxy service <name> listen-address
    <address>
 
-  Set service to bind on IP address, by default listen on any IPv4 and IPv6
+  Set the IP address for the service to bind to. By default, the service
+  listens on all IPv4 and IPv6 addresses.
 
 .. cfgcmd:: set load-balancing haproxy service <name> port
    <port>
@@ -43,19 +45,21 @@ Service
 .. cfgcmd:: set load-balancing haproxy service <name> ssl
    certificate <name>
 
-  Set SSL certificate <name> for service <name>. Multiple certificates could be defined.
+  Set the SSL certificate <name> for service <name>. You can define
+  multiple certificates.
 
 .. cfgcmd:: set load-balancing haproxy service <name>
   http-response-headers <header-name> value <header-value>
 
-  Set custom HTTP headers to be included in all responses
+  Set custom HTTP headers to include in all responses.
 
 .. cfgcmd:: set load-balancing haproxy service <name> logging facility
   <facility> level <level>
 
   Specify facility and level for logging.
-  For an explanation on :ref:`syslog_facilities` and :ref:`syslog_severity_level`
-  see tables in syslog configuration section.
+  For an explanation on :ref:`syslog_facilities` and
+  :ref:`syslog_severity_level`,
+  see tables in the syslog configuration section.
 
 .. cfgcmd:: set load-balancing haproxy service <name> timeout client
   <seconds>
@@ -76,9 +80,9 @@ Service
 
 Rules
 ^^^^^
-Rules allow to control and route incoming traffic to specific backend based
-on predefined conditions. Rules allow to define matching criteria and
-perform action accordingly.
+Rules control and route incoming traffic to specific backends based on
+predefined conditions. Rules define matching criteria and specify actions
+to perform.
 
 .. cfgcmd:: set load-balancing haproxy service <name> rule <rule>
    domain-name <name>
@@ -98,15 +102,13 @@ perform action accordingly.
 .. cfgcmd:: set load-balancing haproxy service <name> rule <rule>
    url-path <match> <url>
 
-  Allows to define URL path matching rules for a specific service.
-
-  With this command, you can specify how the URL path should be matched 
-  against incoming requests.
+  Define URL path matching rules for a specific service. Use this command
+  to specify how to match the URL path against incoming requests.
 
   The available options for <match> are:
    * ``begin`` Matches the beginning of the URL path
    * ``end`` Matches the end of the URL path.
-   * ``exact`` Requires an exactly match of the URL path
+   * ``exact`` Matches the URL path exactly.
 
 .. cfgcmd:: set load-balancing haproxy service <name> rule <rule>
    set backend <name>
@@ -116,7 +118,7 @@ perform action accordingly.
 .. cfgcmd:: set load-balancing haproxy service <name> rule <rule>
    redirect-location <url>
 
-  Redirect URL to a new location
+  Redirect URL to a new location.
 
 
 Backend
@@ -125,37 +127,36 @@ Backend
 .. cfgcmd:: set load-balancing haproxy backend <name> balance
    <balance>
 
-  Load-balancing algorithms to be used for distributed requests among the
-  available servers
+  Specify the load balancing algorithm for distributing requests among
+  available servers.
 
   Balance algorithms:
    * ``source-address`` Distributes requests based on the source IP address
-     of the client
+     of the client.
    * ``round-robin`` Distributes requests in a circular manner,
-     sequentially sending each request to the next server in line
+     sequentially sending each request to the next server in line.
    * ``least-connection`` Distributes requests to the server with the fewest
-     active connections
+     active connections.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> mode
    <mode>
 
-  Configure backend `<name>` mode TCP or HTTP
+  Configure backend `<name>` mode TCP or HTTP.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> address <x.x.x.x>
 
-  Set the address of the backend server to which the incoming traffic will
-  be forwarded
+  Set the address of the backend server that receives incoming traffic.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> port <port>
 
-  Set the address of the backend port
+  Set the address of the backend port.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> check
 
-  Active health check backend server
+  Active health check backend server.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> check port <port>
@@ -166,35 +167,36 @@ Backend
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> send-proxy
 
-  Send a Proxy Protocol version 1 header (text format)
+  Send a Proxy Protocol version 1 header (text format).
 
 .. cfgcmd:: set load-balancing haproxy backend <name> server
    <name> send-proxy-v2
 
-  Send a Proxy Protocol version 2 header (binary format)
+  Send a Proxy Protocol version 2 header (binary format).
 
 .. cfgcmd:: set load-balancing haproxy backend <name> ssl
    ca-certificate <ca-certificate>
 
-  Configure requests to the backend server to use SSL encryption and
-  authenticate backend against <ca-certificate>
+  Use SSL encryption for backend requests and authenticate the backend
+  against ``<ca-certificate>``.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> ssl no-verify
 
-  Configure requests to the backend server to use SSL encryption without
-  validating server certificate
+  Use SSL encryption for backend requests without validating the server
+  certificate.
 
 .. cfgcmd:: set load-balancing haproxy backend <name>
   http-response-headers <header-name> value <header-value>
 
-  Set custom HTTP headers to be included in all responses using the backend
+  Set custom HTTP headers to include in all responses from the backend.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> logging facility
   <facility> level <level>
 
   Specify facility and level for logging.
-  For an explanation on :ref:`syslog_facilities` and :ref:`syslog_severity_level`
-  see tables in syslog configuration section.
+  For an explanation on :ref:`syslog_facilities` and
+  :ref:`syslog_severity_level`,
+  see tables in the :ref:`syslog` configuration section.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> timeout check
   <seconds>
@@ -220,7 +222,7 @@ Backend
 Global
 -------
 
-Global parameters
+Global configuration parameters:
 
 .. cfgcmd:: set load-balancing haproxy global-parameters max-connections
    <num>
@@ -230,7 +232,7 @@ Global parameters
 .. cfgcmd:: set load-balancing haproxy global-parameters ssl-bind-ciphers
    <ciphers>
 
-  Limit allowed cipher algorithms used during SSL/TLS handshake
+  Limit the cipher algorithms allowed during SSL/TLS handshake.
 
 .. cfgcmd:: set load-balancing haproxy global-parameters tls-version-min
    <version>
@@ -241,7 +243,8 @@ Global parameters
   facility <facility> level <level>
 
   Specify facility and level for logging.
-  For an explanation on :ref:`syslog_facilities` and :ref:`syslog_severity_level`
+  For an explanation on :ref:`syslog_facilities` and
+  :ref:`syslog_severity_level`
   see tables in syslog configuration section.
 
 .. cfgcmd:: set load-balancing haproxy timeout check <seconds>
@@ -271,8 +274,8 @@ Health checks
 HTTP checks
 -----------
 
-For web application providing information about their state HTTP health
-checks can be used to determine their availability.
+Use HTTP health checks to monitor web applications that provide health status
+information and determine their availability.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> http-check
 
@@ -282,17 +285,17 @@ checks can be used to determine their availability.
 .. cfgcmd:: set load-balancing haproxy backend <name> http-check
    method <method>
 
-  Sets the HTTP method to be used, can be either: option, get, post, put
+  Set the HTTP method: ``OPTION``, ``GET``, ``POST``, or ``PUT``.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> http-check
    uri <path>
 
-  Sets the endpoint to be used for health checks
+  Set the endpoint to use for health checks.
 
 .. cfgcmd:: set load-balancing haproxy backend <name> http-check
    expect <condition>
 
-  Sets the expected result condition for considering a server healthy.
+  Set the expected result condition for a server to be considered healthy.
 
   Some possible examples are:
    * ``status 200`` Expecting a 200 response code
@@ -303,8 +306,8 @@ checks can be used to determine their availability.
 TCP checks
 ----------
 
-Health checks can also be configured for TCP mode backends. You can configure
-protocol aware checks for a range of Layer 7 protocols:
+Configure health checks for TCP mode backends. You can configure protocol-aware
+checks for a range of Layer 7 protocols:
 
 .. cfgcmd:: set load-balancing haproxy backend <name> health-check <protocol>
 
@@ -315,25 +318,23 @@ protocol aware checks for a range of Layer 7 protocols:
    * ``pgsql`` PostgreSQL protocol check.
    * ``smtp`` SMTP protocol check.
 
-.. note:: If you specify a server to be checked but do not configure a
-   protocol, a basic TCP health check will be attempted. A server shall be
-   deemed online if it responses to a connection attempt with a valid
-   ``SYN/ACK`` packet.
+.. note:: If you specify a server to check but do not configure a
+   protocol, HAProxy performs a basic TCP health check. A server is online if
+   it responds to a connection attempt with a valid ``SYN/ACK`` packet.
 
 
 Redirect HTTP to HTTPS
 ======================
-Configure the load-balancing haproxy service for HTTP.
 
-This configuration listen on port 80 and redirect incoming
-requests to HTTPS:
+Configure a HAProxy service for HTTP that listens on port 80 and redirects
+incoming requests to HTTPS:
 
 .. code-block:: none
 
     set load-balancing haproxy service http port '80'
     set load-balancing haproxy service http redirect-http-to-https
 
-The name of the service can be different, in this example it is only for 
+You can use a different service name; in this example, ``http`` is just for
 convenience.
 
 
@@ -343,9 +344,10 @@ Examples
 Level 4 balancing
 -----------------
 
-This configuration enables the TCP reverse proxy for the "my-tcp-api" service.
-Incoming TCP connections on port 8888 will be load balanced across the backend
-servers (srv01 and srv02) using the round-robin load-balancing algorithm.
+This configuration enables the TCP reverse proxy for the ``my-tcp-api``
+service. Incoming TCP connections on port 8888 are load balanced across the
+backend servers (srv01 and srv02) using the round-robin load balancing
+algorithm.
 
 .. code-block:: none
 
@@ -365,15 +367,15 @@ servers (srv01 and srv02) using the round-robin load-balancing algorithm.
 Balancing based on domain name
 ------------------------------
 The following configuration demonstrates how to use VyOS
-to achieve load balancing based on the domain name.
+to achieve load balancing based on the domain name:
 
-The HTTP service listen on TCP port 80.
+The HTTP service listens on TCP port 80.
 
-Rule 10 matches requests with the domain name ``node1.example.com`` forwards
-to the backend ``bk-api-01``
+Rule 10 matches requests with the domain name ``node1.example.com`` and
+forwards them to the backend ``bk-api-01``.
 
-Rule 20 matches requests with the domain name ``node2.example.com`` forwards
-to the backend ``bk-api-02``
+Rule 20 matches requests with the domain name ``node2.example.com`` and
+forwards them to the backend ``bk-api-02``.
 
 .. code-block:: none
 
@@ -398,23 +400,25 @@ to the backend ``bk-api-02``
 
 Terminate SSL
 -------------
+
 The following configuration terminates SSL on the router.
 
-The ``http`` service is listens on port 80 and force redirects from HTTP to
+The ``http`` service listens on port 80 and redirects HTTP requests to
 HTTPS.
 
-The ``https`` service listens on port 443 with backend ``bk-default`` to
-handle HTTPS traffic. It uses certificate named ``cert`` for SSL termination.
-HSTS header is set with a 1-year expiry, to tell browsers to always use SSL for site.
+The ``https`` service listens on port 443 with the ``bk-default`` backend
+and handles HTTPS traffic using the ``cert`` certificate for SSL termination.
+The HSTS header is set with a 1-year expiry to tell browsers to always use
+SSL for the site.
 
-Rule 10 matches requests with the exact URL path ``/.well-known/xxx``
-and redirects to location ``/certs/``.
+Rule 10 matches requests with the exact URL path ``/.well-known/xxx`` and
+redirects them to ``/certs/``.
 
-Rule 20 matches requests with URL paths ending in ``/mail`` or exact
-path ``/email/bar`` redirect to location ``/postfix/``.
+Rule 20 matches requests with URL paths ending in ``/mail`` or the exact
+path ``/email/bar`` and redirects them to ``/postfix/``.
 
-Additional global parameters are set, including the maximum number
-connection limit of 4000 and a minimum TLS version of 1.3.
+Global parameters include a maximum connection limit of 4000 and a minimum
+TLS version of 1.3.
 
 
 .. code-block:: none
@@ -447,9 +451,10 @@ connection limit of 4000 and a minimum TLS version of 1.3.
 
 SSL Bridging
 -------------
+
 The following configuration terminates incoming HTTPS traffic on the router,
-then re-encrypts the traffic and sends to the backend server via HTTPS.
-This is useful if encryption is required for both legs, but you do not want to
+then re-encrypts the traffic and sends it to the backend server via HTTPS.
+Use this when encryption is required for both paths but you do not want to
 install publicly trusted certificates on each backend server.
 
 Backend service certificates are checked against the certificate authority
@@ -458,7 +463,7 @@ specified in the configuration, which could be an internal CA.
 The ``https`` service listens on port 443 with backend ``bk-bridge-ssl`` to
 handle HTTPS traffic. It uses certificate named ``cert`` for SSL termination.
 
-The ``bk-bridge-ssl`` backend connects to sr01 server on port 443 via HTTPS
+The ``bk-bridge-ssl`` backend connects to ``sr01`` server on port 443 via HTTPS
 and checks backend server has a valid certificate trusted by CA ``cacert``
 
 
@@ -480,7 +485,7 @@ and checks backend server has a valid certificate trusted by CA ``cacert``
 Balancing with HTTP health checks
 ---------------------------------
 
-This configuration enables HTTP health checks on backend servers.
+This configuration enables HTTP health checks for backend servers.
 
 .. code-block:: none
 
diff --git a/docs/configuration/loadbalancing/index.rst b/docs/configuration/loadbalancing/index.rst
index 92dcc622..b87faed2 100644
--- a/docs/configuration/loadbalancing/index.rst
+++ b/docs/configuration/loadbalancing/index.rst
@@ -1,3 +1,5 @@
+:lastproofread: 2026-04-06
+
 .. _load-balancing:
 
 ##############
diff --git a/docs/configuration/loadbalancing/wan.rst b/docs/configuration/loadbalancing/wan.rst
index b376f4fb..56fdb02c 100644
--- a/docs/configuration/loadbalancing/wan.rst
+++ b/docs/configuration/loadbalancing/wan.rst
@@ -1,22 +1,25 @@
-:lastproofread: 2023-01-27
+:lastproofread: 2026-04-06
 
+##################
 WAN load balancing
-==================
+##################
 
-Outbound traffic can be balanced between two or more outbound interfaces.
-If a path fails, traffic is balanced across the remaining healthy paths,
-a recovered path is automatically added back to the routing table and used by 
-the load balancer. The load balancer automatically adds routes for each path to
-the routing table and balances traffic across the configured interfaces,
-determined by interface health and weight.
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
+
+The load balancer distributes outbound traffic across two or more
+interfaces. If a path fails, the load balancer balances traffic across the
+remaining healthy paths. When a path recovers, it is automatically added back
+to the routing table. The load balancer adds routes for each path and
+distributes traffic based on interface health and weight.
 
 
 In a minimal configuration, the following must be provided:
 
- * an interface with a nexthop
- * one rule with a LAN (inbound-interface) and the WAN (interface).
+ * An interface with a ``nexthop``.
+ * One rule with a LAN (inbound-interface) and the WAN (interface).
 
-Let's assume we have two DHCP WAN interfaces and one LAN (eth2):
+The following examples uses two DHCP WAN interfaces and one LAN (``eth2``):
 
 .. code-block:: none
 
@@ -28,18 +31,18 @@ Let's assume we have two DHCP WAN interfaces and one LAN (eth2):
 
 .. note::
 
-    WAN Load Balacing should not be used when dynamic routing protocol is
-    used/needed. This feature creates customized routing tables and firewall
-    rules, that makes it incompatible to use with routing protocols.
+    Do not use WAN load balancing with dynamic routing protocols. This
+    feature creates customized routing tables and firewall rules that are
+    incompatible with routing protocols.
 
-Balancing Rules
----------------
+Load balancing rules
+--------------------
 
-Interfaces, their weight and the type of traffic to be balanced are defined in
-numbered balancing rule sets. The rule sets are executed in numerical order
-against outgoing packets. In case of a match the packet is sent through an
-interface specified in the matching rule. If a packet doesn't match any rule
-it is sent by using the system routing table. Rule numbers can't be changed.
+You define interfaces, their weight, and the traffic type to balance in
+numbered rule sets. The load balancer executes rules in numerical order
+against outgoing packets. When a packet matches a rule, it is sent through the
+specified interface. Packets that do not match any rule use the system routing
+table. You cannot change rule numbers.
 
 Create a load balancing rule, it can be a number between 1 and 9999:
 
@@ -61,23 +64,25 @@ Create a load balancing rule, it can be a number between 1 and 9999:
 Interface weight
 ****************
 
-Let's expand the example from above and add weight to the interfaces.
-The bandwidth from eth0 is larger than eth1. Per default, outbound traffic is
-distributed randomly across available interfaces. Weights can be assigned to
-interfaces to influence the balancing.
+By default, the load balancer distributes outbound
+traffic randomly across available interfaces. You can assign weights to
+interfaces to influence the distribution. If ``eth0`` has more bandwidth
+than ``eth1``, you can assign a higher weight to ``eth0`` to send more
+traffic through it:
 
 .. code-block:: none
 
     set load-balancing wan rule 1 interface eth0 weight 2
     set load-balancing wan rule 1 interface eth1 weight 1
 
-66% of traffic is routed to eth0, eth1 gets 33% of traffic.
+In this example,``eth0`` receives 66% of traffic, and ``eth1`` receives
+33% of traffic.
 
 Rate limit
 **********
 
-A packet rate limit can be set for a rule to apply the rule to traffic above or
-below a specified threshold. To configure the rate limiting use:
+Set a packet rate limit for a rule to apply it to traffic above or below a
+specified threshold. To configure rate limiting, use:
 
 .. code-block:: none
 
@@ -88,22 +93,20 @@ below a specified threshold. To configure the rate limiting use:
 * ``period``: Time window for rate calculation. Possible values:
   ``second`` (one second), ``minute`` (one minute), ``hour`` (one hour).
   Default is ``second``.
-* ``rate``: Number of packets. Default 5.
+* ``rate``: Number of packets. Default: ``5``.
 * ``threshold``: ``below`` or ``above`` the specified rate limit.
 
 Flow and packet-based balancing
 *******************************
 
-Outgoing traffic is balanced in a flow-based manner.
-A connection tracking table is used to track flows by their source address,
-destination address and port. Each flow is assigned to an interface according
-to the defined balancing rules and subsequent packets are sent through the
-same interface. This has the advantage that packets always arrive in order if
-links with different speeds are in use.
+The load balancer balances outgoing traffic by flow. A connection tracking
+table tracks flows by source address, destination address, and port. Each
+flow is assigned to an interface based on the balancing rules, and subsequent
+packets use the same interface. This ensures packets arrive in order when links
+have different speeds.
 
-Packet-based balancing can lead to a better balance across interfaces when out
-of order packets are no issue. Per-packet-based balancing can be set for a
-balancing rule with:
+Packet-based balancing can improve balance across interfaces when packet
+order is not critical. Enable per-packet balancing for a rule with:
 
 .. code-block:: none
 
@@ -112,8 +115,8 @@ balancing rule with:
 Exclude traffic
 ***************
 
-To exclude traffic from load balancing, traffic matching an exclude rule is not
-balanced but routed through the system routing table instead:
+To exclude traffic from load balancing, traffic matching an exclude rule
+bypasses load balancing and uses the system routing table instead:
 
 .. code-block:: none
 
@@ -123,10 +126,10 @@ balanced but routed through the system routing table instead:
 Health checks
 -------------
 
-The health of interfaces and paths assigned to the load balancer is
-periodically checked by sending ICMP packets (ping) to remote destinations,
-a TTL test or the execution of a user defined script. If an interface fails the
-health check it is removed from the load balancer's pool of interfaces.
+The load balancer periodically checks the health of interfaces and paths by
+sending ICMP packets (ping) to remote destinations, performing TTL tests, or
+executing a user-defined script. If an interface fails the health check, the
+load balancer removes it from its interface pool.
 To enable health checking for an interface:
 
 .. code-block:: none
@@ -138,26 +141,26 @@ To enable health checking for an interface:
     success-count    Success count
     +> test          Rule number
 
-Specify nexthop on the path to the destination, ``ipv4-address`` can be set to
-``dhcp``
+Specify the nexthop on the path to the destination. You can set
+``ipv4-address`` to ``dhcp``.
 
 .. code-block:: none
 
     set load-balancing wan interface-health <interface> nexthop <ipv4-address>
 
-Set the number of health check failures before an interface is marked as
-unavailable, range for number is 1 to 10, default 1. Or set the number of
-successful health checks before an interface is added back to the interface
-pool, range for number is 1 to 10, default 1.
+Set the number of health check failures before the load balancer marks an
+interface as unavailable (range 1-10, default 1). Or set the number of
+successful health checks before adding an interface back to the pool
+(range 1-10, default 1).
 
 .. code-block:: none
 
     set load-balancing wan interface-health <interface> failure-count <number>
     set load-balancing wan interface-health <interface> success-count <number>
 
-Each health check is configured in its own test, tests are numbered and
-processed in numeric order. For multi target health checking multiple tests
-can be defined:
+Configure each health check in its own test. Tests are numbered and processed
+in numeric order. You can define multiple tests for multi-target health
+checking:
 
 .. code-block:: none
 
@@ -169,46 +172,45 @@ can be defined:
     ttl-limit    Ttl limit (hop count)
     type         WLB test type
 
-* ``resp-time``: the maximum response time for ping in seconds.
-  Range 1...30, default 5
-* ``target``: the target to be sent ICMP packets to, address can be an IPv4
-  address or hostname
-* ``test-script``: A user defined script must return 0 to be considered
-  successful and non-zero to fail. Scripts are located in /config/scripts,
-  for different locations the full path needs to be provided
-* ``ttl-limit``: For the UDP TTL limit test the hop count limit must be
-  specified. The limit must be shorter than the path length, an ICMP time
-  expired message is needed to be returned for a successful test. default 1
-* ``type``: Specify the type of test. type can be ping, ttl or a user defined
-  script
+* ``resp-time``: The maximum response time for ping in seconds. Range
+  1-30, default ``5``.
+* ``target``: The target to receive ICMP packets. The address can be an IPv4
+  address or hostname.
+* ``test-script``: A user-defined script must return 0 to succeed and
+  non-zero to fail. Scripts reside in ``/config/scripts``. For other locations,
+  provide the full path.
+* ``ttl-limit``: For the UDP TTL limit test, specify the hop count limit.
+  The limit must be shorter than the path length. The test succeeds when an
+  ICMP time-expired message is returned. Default ``1``.
+* ``type``: Specify the test type: ``ping``, ``ttl``, or a user-defined
+  script.
 
 Source NAT rules
 ----------------
 
-Per default, interfaces used in a load balancing pool replace the source IP
-of each outgoing packet with its own address to ensure that replies arrive on
-the same interface. This works through automatically generated source NAT (SNAT)
-rules, these rules are only applied to balanced traffic. In cases where this
-behaviour is not desired, the automatic generation of SNAT rules can be
-disabled:
+By default, interfaces in a load balancing pool replace the source IP of
+each outgoing packet with their own address to ensure replies arrive on the
+same interface. The load balancer handles this through automatically generated
+Source NAT (SNAT) rules applied only to balanced traffic. To disable the
+automatic generation of SNAT rules when this behavior is not desired, use:
 
 .. code-block:: none
 
     set load-balancing wan disable-source-nat
 
-Sticky Connections
+Sticky connections
 ------------------
-Inbound connections to a WAN interface can be improperly handled when the reply
-is sent back to the client.
+Inbound connections to a WAN interface can be improperly handled when
+replies are sent back to the client.
 
 .. image:: /_static/images/sticky-connections.*
    :width: 80%
    :align: center
 
 
-Upon reception of an incoming packet, when a response is sent, it might be
-desired to ensure that it leaves from the same interface as the inbound one.
-This can be achieved by enabling sticky connections in the load balancing:
+When responding to an incoming packet, you may want to ensure the response
+leaves from the same interface as the incoming packet. Enable sticky
+connections in the load balancer to do this:
 
 .. code-block:: none
 
@@ -217,23 +219,21 @@ This can be achieved by enabling sticky connections in the load balancing:
 Failover
 --------
 
-In failover mode, one interface is set to be the primary interface and other
-interfaces are secondary or spare. Instead of balancing traffic across all
-healthy interfaces, only the primary interface is used and in case of failure,
-a secondary interface selected from the pool of available interfaces takes over.
-The primary interface is selected based on its weight and health, others become
-secondary interfaces. Secondary interfaces to take over a failed primary
-interface are chosen from the load balancer's interface pool, depending
-on their weight and health. Interface roles can also be selected based on rule
-order by including interfaces in balancing rules and ordering those rules
-accordingly. To put the load balancer in failover mode, create a failover rule:
+In failover mode, one interface is primary and other interfaces are
+secondary or spare. The load balancer uses only the primary interface. If it
+fails, a secondary interface from the available pool takes over. The load
+balancer selects the primary interface based on its weight and health. Other
+interfaces become secondary. Secondary interfaces are chosen based on their
+weight and health. You can also select interface roles based on rule order by
+including interfaces in balancing rules and ordering those rules accordingly.
+To enable failover mode, create a failover rule:
 
 .. code-block:: none
 
     set load-balancing wan rule <number> failover
 
-Because existing sessions do not automatically fail over to a new path,
-the session table can be flushed on each connection state change:
+Existing sessions do not automatically fail over to a new path. Flush the
+session table on each connection state change to enable failover:
 
 .. code-block:: none
 
@@ -241,14 +241,15 @@ the session table can be flushed on each connection state change:
 
 .. warning::
 
-    Flushing the session table will cause other connections to fall back from
+    Flushing the session table causes other connections to revert from
     flow-based to packet-based balancing until each flow is reestablished.
 
 Script execution
 ----------------
 
-A script can be run when an interface state change occurs. Scripts are run
-from /config/scripts, for a different location specify the full path:
+Run a script when an interface state changes. Scripts run from the
+``/config/scripts`` directory. To use a script in another location,
+specify the full path:
 
 .. code-block:: none
 
@@ -261,19 +262,20 @@ Two environment variables are available:
 
 .. warning::
 
-    Blocking call with no timeout. System will become unresponsive if script
-    does not return!
+    Blocking call with no timeout: VyOS becomes unresponsive if the
+    script does not return. 
 
 Handling and monitoring
 -----------------------
 
 
-Show WAN load balancer information including test types and targets.
-A character at the start of each line depicts the state of the test
+The following command shows WAN load balancer information including test
+types and targets. The character at the start of each line indicates the test
+state:
 
-* ``+`` successful
-* ``-`` failed
-* a blank indicates that no test has been carried out
+* ``+`` successful.
+* ``-`` failed.
+* A blank indicates that no test has been carried out.
 
 .. code-block:: none
 
diff --git a/docs/configuration/nat/nat64.rst b/docs/configuration/nat/nat64.rst
index e8a3a0e6..04ba56f4 100644
--- a/docs/configuration/nat/nat64.rst
+++ b/docs/configuration/nat/nat64.rst
@@ -69,6 +69,8 @@ NAT64 client configuration:
 
 Test from the IPv6 only client:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@r1:~$ ping 64:ff9b::192.0.2.1 count 2
@@ -79,3 +81,5 @@ Test from the IPv6 only client:
   --- 64:ff9b::192.0.2.1 ping statistics ---
   2 packets transmitted, 2 received, 0% packet loss, time 1023ms
   rtt min/avg/max/mdev = 0.351/0.362/0.373/0.011 ms
+
+.. start_vyoslinter
diff --git a/docs/configuration/nat/nat66.rst b/docs/configuration/nat/nat66.rst
index 31f6c002..aecce524 100644
--- a/docs/configuration/nat/nat66.rst
+++ b/docs/configuration/nat/nat66.rst
@@ -4,6 +4,9 @@
 NAT66(NPTv6)
 ############
 
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
+
 :abbr:`NPTv6 (IPv6-to-IPv6 Network Prefix Translation)` is an address 
 translation technology based on IPv6 networks, used to convert an IPv6 
 address prefix in an IPv6 message into another IPv6 address prefix. 
@@ -151,14 +154,17 @@ R2:
   set service router-advert interface br1 prefix ::/0
 
 
-Use the following topology to translate internal user local addresses (``fc::/7``)
-to DHCPv6-PD provided prefixes from an ISP connected to a VyOS HA pair.
+Use the following topology to translate internal user local addresses
+(``fc::/7``) to DHCPv6-PD provided prefixes from an ISP connected to
+a VyOS HA pair.
 
 .. figure:: /_static/images/vyos_1_5_nat66_dhcpv6_wdummy.*
    :alt: VyOS NAT66 DHCPv6 using a dummy interface
 
 Configure both routers (a and b) for DHCPv6-PD via dummy interface:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set interfaces dummy dum1 description 'DHCPv6-PD NPT dummy'
@@ -169,6 +175,8 @@ Configure both routers (a and b) for DHCPv6-PD via dummy interface:
   set interfaces bonding bond0 vif 20 dhcpv6-options rapid-commit
   commit
 
+.. start_vyoslinter
+
 Get the DHCPv6-PD prefixes from both routers:
 
 .. code-block:: none
diff --git a/docs/configuration/policy/index.rst b/docs/configuration/policy/index.rst
index 51f60479..0394eb21 100644
--- a/docs/configuration/policy/index.rst
+++ b/docs/configuration/policy/index.rst
@@ -1,4 +1,4 @@
-:lastproofread:2021-07-12
+:lastproofread: 2021-07-12
 
 .. include:: /_include/need_improvement.txt
 
diff --git a/docs/configuration/protocols/index.rst b/docs/configuration/protocols/index.rst
index f95c1cf6..d40a4b12 100644
--- a/docs/configuration/protocols/index.rst
+++ b/docs/configuration/protocols/index.rst
@@ -16,6 +16,7 @@ Protocols
    mpls
    multicast
    segment-routing
+   traffic-engineering
    openfabric
    ospf
    pim
diff --git a/docs/configuration/protocols/isis.rst b/docs/configuration/protocols/isis.rst
index 0fb0e9e0..75634800 100644
--- a/docs/configuration/protocols/isis.rst
+++ b/docs/configuration/protocols/isis.rst
@@ -355,6 +355,69 @@ Loop Free Alternate (LFA)
   This command will limit LFA backup computation up to the specified
   prefix priority. 
 
+Segment Routing over IPv6 (SRv6)
+-------------------------
+
+.. cfgcmd:: set protocols isis segment-routing srv6 interface <interface>
+
+  The :ref:`dummy interface<configuration/interfaces/dummy:dummy>` used
+  to install SRv6 SIDs into the Linux data plane. The interface must exist and
+  must be present when configuring IS-IS with
+  SRv6.
+
+.. cfgcmd:: set protocols isis segment-routing srv6 locator <locator>
+  
+  Specifies the SRv6 locator to use for IS-IS. IS-IS automatically allocates
+  prefix and adjacency SIDs, creates local SID entries and advertises them
+  into the IGP domain.
+
+.. cfgcmd:: set protocols isis segment-routing srv6 node-msd max-end-d <0-255>
+
+  The Maximum End D MSD Type specifies the maximum number of SIDs present in an
+  SRH when performing decapsulation. As specified in :rfc:`8986`, the permitted
+  SID types include, but are not limited to, End.DX6, End.DT4, End.DT46, End
+  with USD, and End.X with USD.
+
+  If the advertised value is zero or no value is advertised, then the router
+  cannot apply any behavior that results in decapsulation and forwarding of the
+  inner packet if the outer IPv6 header contains an SRH.
+
+  Reference: :rfc:`9352`
+
+.. cfgcmd:: set protocols isis segment-routing srv6 node-msd max-end-pop <0-255>
+
+  The Maximum End Pop MSD Type signals the maximum number of SIDs in the SRH to
+  which the router can apply "Penultimate Segment Pop (PSP) of the SRH" or
+  "Ultimate Segment Pop (USP) of the SRH" behavior, as defined in "Flavors"
+  (Section 4.16 of :rfc:`8986`).
+
+  If the advertised value is zero or no value is advertised, then the router
+  cannot apply PSP or USP flavors.
+
+  Reference: :rfc:`9352`
+
+.. cfgcmd:: set protocols isis segment-routing srv6 node-msd max-h-encaps <0-255>
+
+  The Maximum H.Encaps MSD Type signals the maximum number of SIDs that can be
+  added to the segment list of an SRH as part of the "H.Encaps" behavior, as
+  defined in :rfc:`8986`.
+
+  If the advertised value is zero or no value is advertised, then the headend
+  can apply an SR Policy that only contains one segment without inserting any
+  SRH header. A non-zero SRH Max H.encaps MSD indicates that the headend can
+  insert an SRH up to the advertised number of SIDs.
+
+  Reference: :rfc:`9352`
+
+.. cfgcmd:: set protocols isis segment-routing srv6 node-msd max-segs-left <0-255>
+
+  The Maximum Segments Left MSD Type signals the maximum value of the
+  "Segments Left" field (:rfc:`8754`) in the SRH of a received packet before
+  applying the Endpoint behavior associated with a SID.
+
+  If no value is advertised, the supported value is 0.
+
+  Reference: :rfc:`9352`
 
 ********
 Examples
@@ -598,3 +661,87 @@ Here is the routing tables showing the MPLS segment routing label operations:
 
   I   192.0.2.0/24 [115/20] via 192.0.2.1, eth1 inactive, weight 1, 00:07:46
   I>* 192.168.255.255/32 [115/20] via 192.0.2.1, eth1, label IPv4 Explicit Null, weight 1, 00:03:43
+
+Enable IS-IS with Segment Routing over IPv6 (Experimental)
+==========================================================
+
+**Node 1:**
+
+.. code-block:: none
+
+  set interfaces dummy dum6 description "SRv6 IS-IS"
+  set interfaces ethernet eth1 address '192.0.2.1/24'
+  set interfaces loopback lo address '192.168.255.255/32'
+
+  set protocols segment-routing srv6 locator MAIN prefix 2001:db8:1::/64
+  set protocols segment-routing interface eth1
+
+  set protocols isis interface eth1
+  set protocols isis interface lo
+  set protocols isis net '49.0001.1921.6825.5255.00'
+  set protocols isis segment-routing srv6 locator MAIN
+  set protocols isis segment-routing srv6 interface dum6
+
+**Node 2:**
+
+.. code-block:: none
+
+  set interfaces dummy dum6 description "SRv6 IS-IS"
+  set interfaces ethernet eth1 address '192.0.2.2/24'
+  set interfaces loopback lo address '192.168.255.254/32'
+
+  set protocols segment-routing srv6 locator MAIN prefix 2001:db8:2::/64
+  set protocols segment-routing interface eth1
+
+  set protocols isis interface eth1
+  set protocols isis interface lo
+  set protocols isis net '49.0001.1921.6825.5254.00'
+  set protocols isis segment-routing srv6 locator MAIN
+  set protocols isis segment-routing srv6 interface dum6
+
+Enable IS-IS with Segment Routing over IPv6 (uSID) (Experimental)
+=================================================================
+
+**Node 1:**
+
+.. code-block:: none
+
+  set interfaces dummy dum6 description "SRv6 IS-IS"
+  set interfaces ethernet eth1 address '192.0.2.1/24'
+  set interfaces loopback lo address '192.168.255.255/32'
+
+  set protocols segment-routing interface eth1
+  set protocols segment-routing srv6 locator MAIN prefix 2001:db8:1::/48
+  set protocols segment-routing srv6 locator MAIN behavior-usid
+  set protocols segment-routing srv6 locator MAIN block-len 32
+  set protocols segment-routing srv6 locator MAIN format usid-f3216
+  set protocols segment-routing srv6 locator MAIN func-bits 16
+  set protocols segment-routing srv6 locator MAIN node-len 16
+
+  set protocols isis interface eth1
+  set protocols isis interface lo
+  set protocols isis net '49.0001.1921.6825.5255.00'
+  set protocols isis segment-routing srv6 interface dum6
+  set protocols isis segment-routing srv6 locator MAIN
+
+**Node 2:**
+
+.. code-block:: none
+
+  set interfaces dummy dum6 description "SRv6 IS-IS"
+  set interfaces ethernet eth1 address '192.0.2.2/24'
+  set interfaces loopback lo address '192.168.255.254/32'
+
+  set protocols segment-routing interface eth1
+  set protocols segment-routing srv6 locator MAIN prefix 2001:db8:2::/48
+  set protocols segment-routing srv6 locator MAIN behavior-usid
+  set protocols segment-routing srv6 locator MAIN block-len 32
+  set protocols segment-routing srv6 locator MAIN format usid-f3216
+  set protocols segment-routing srv6 locator MAIN func-bits 16
+  set protocols segment-routing srv6 locator MAIN node-len 16
+
+  set protocols isis interface eth1
+  set protocols isis interface lo
+  set protocols isis net '49.0001.1921.6825.5254.00'
+  set protocols isis segment-routing srv6 interface dum6
+  set protocols isis segment-routing srv6 locator MAIN
diff --git a/docs/configuration/protocols/static.rst b/docs/configuration/protocols/static.rst
index 3e3eb47b..eb5a439c 100644
--- a/docs/configuration/protocols/static.rst
+++ b/docs/configuration/protocols/static.rst
@@ -70,8 +70,12 @@ IPv4 BFD
    Configure a static route for `<subnet>` using gateway `<address>` and use the
    gateway address as BFD peer destination address.
 
+.. stop_vyoslinter
+
 .. cfgcmd:: set protocols static route <subnet> next-hop <address> bfd profile <profile>
 
+.. start_vyoslinter
+
    Configure a static route for `<subnet>` using gateway `<address>` and use the
    gateway address as BFD peer destination address with BFD profile `<profile>`.
 
@@ -153,13 +157,20 @@ IPv6 Unicast Routes
    .. note:: Routes with a distance of 255 are effectively disabled and not
       installed into the kernel.
 
+.. stop_vyoslinter
+
 .. cfgcmd:: set protocols static route6 <subnet> next-hop <address> segments <segments>
 
-   It is possible to specify a static route for ipv6 prefixes using an SRv6 segments
-   instruction. The `/` separator can be used to specify multiple segment instructions.
+.. start_vyoslinter
+
+   It is possible to specify a static route for ipv6 prefixes using an
+   SRv6 segments instruction. The ``/`` separator can be used to specify
+   multiple segment instructions.
 
    Example:
 
+.. stop_vyoslinter
+
    .. code-block:: none
 
      set protocols static route6 2001:db8:1000::/36 next-hop 2001:db8:201::ffff segments '2001:db8:aaaa::7/2002::4/2002::3/2002::2'
@@ -176,6 +187,8 @@ IPv6 Unicast Routes
      C>* 2001:db8:201::/64 is directly connected, eth0.201, 00:00:46
      S>* 2001:db8:1000::/36 [1/0] via 2001:db8:201::ffff, eth0.201, seg6 2001:db8:aaaa::7,2002::4,2002::3,2002::2, weight 1, 00:00:08
 
+.. start_vyoslinter
+
 IPv6 Interface Routes
 =====================
 
@@ -202,15 +215,20 @@ IPv6 Interface Routes
 .. cfgcmd:: set protocols static route6 <subnet> interface
    <interface> segments <segments>
 
-   It is possible to specify a static route for ipv6 prefixes using an SRv6 segments
-   instruction. The `/` separator can be used to specify multiple segment instructions.
+   It is possible to specify a static route for ipv6 prefixes using an
+   SRv6 segments instruction. The ``/`` separator can be used to specify
+   multiple segment instructions.
 
    Example:
 
+.. stop_vyoslinter
+
    .. code-block:: none
 
      set protocols static route6 2001:db8:1000::/36 interface eth0 segments '2001:db8:aaaa::7/2002::4/2002::3/2002::2'
 
+.. start_vyoslinter
+
 IPv6 BFD
 ========
 
@@ -219,14 +237,22 @@ IPv6 BFD
    Configure a static route for `<subnet>` using gateway `<address>` and use the
    gateway address as BFD peer destination address.
 
+.. stop_vyoslinter
+
 .. cfgcmd:: set protocols static route6 <subnet> next-hop <address> bfd profile <profile>
 
+.. start_vyoslinter
+
    Configure a static route for `<subnet>` using gateway `<address>` and use the
    gateway address as BFD peer destination address with BFD profile `<profile>`.
 
+.. stop_vyoslinter
+
 .. cfgcmd:: set protocols static route6 <subnet> next-hop <address> bfd multi-hop
    source-address <source>
 
+.. start_vyoslinter
+
    Configure a static route for `<subnet>` using gateway `<address>` and use the
    gateway address as BFD peer destination address with source address
    `<source>` but initiate a multi-hop session.
@@ -271,7 +297,5 @@ IPv6 Blackhole Routes
 Alternate Routing Tables
 ************************
 
-TBD
-
 Alternate routing tables are used with policy based routing by utilizing
 :ref:`vrf`.
diff --git a/docs/configuration/protocols/traffic-engineering.rst b/docs/configuration/protocols/traffic-engineering.rst
new file mode 100644
index 00000000..977a5e5c
--- /dev/null
+++ b/docs/configuration/protocols/traffic-engineering.rst
@@ -0,0 +1,51 @@
+.. _traffic-engineering:
+
+###################
+Traffic Engineering
+###################
+
+Traffic Engineering (TE) is possibility to send traffic from node to node using
+alternative path.
+
+Common link parameters
+----------------------
+
+Traffic Engineering parameters are used for both IS-IS and OSPF (not supported yet).
+
+.. cfgcmd::  set protocols traffic-engineering admin-group <admin-group-name> bit-position <bit-position-value>
+
+  Create Administrative group and assosiate bit position with it. These groups can be
+  used in the following commands.
+
+  <bit-position-value> can have value 0-31. There cannot be two groups with same bit position.
+
+.. cfgcmd::  set protocols traffic-engineering interface <ifname> admin-group <admin-group-name>
+
+  Set administrative group for interface <ifname>. Multiple values can be provided.
+
+.. cfgcmd::  set protocols traffic-engineering interface <ifname> max-bandwidth <max-bandwidth-value-mbps>
+
+  Set maximum bandwidth for interface <ifname>. Value given in Mbits per second.
+
+.. cfgcmd::  set protocols traffic-engineering interface <ifname> max-reservable-bandwidth <max-reservable-bandwidth-value-mbps>
+
+  Set maximum reservable bandwidth for interface <ifname>. Value given in Mbits per second.
+
+
+IS-IS TE Configuration
+----------------------
+
+Traffic Engineering (TE) can be enabled and exported for IS-IS
+using the following commands:
+
+.. cfgcmd:: set protocols isis traffic-engineering enable
+
+  Enable Traffic Engineering for IS-IS.
+
+.. cfgcmd:: set protocols isis traffic-engineering export
+
+  Export Traffic Engineering data to neighbors.
+
+.. cfgcmd:: set protocols isis traffic-engineering address <ipv4-address>
+
+  Configure IPv4 address for MPLS-TE.
diff --git a/docs/configuration/service/conntrack-sync.rst b/docs/configuration/service/conntrack-sync.rst
index 08b71eed..62e96e0e 100644
--- a/docs/configuration/service/conntrack-sync.rst
+++ b/docs/configuration/service/conntrack-sync.rst
@@ -98,6 +98,20 @@ Configuration
    This diable the external cache and directly injects the flow-states into the
    in-kernel Connection Tracking System of the backup firewall.
 
+.. cfgcmd:: set service conntrack-sync purge-timeout <timeout>
+
+   Timeout (in seconds) for purging synchronized entries on handover events.
+
+   On handover, ``conntrackd -t`` is invoked, which schedules a conntrack table
+   flush after ``<timeout>`` seconds to purge stale (“zombie”) entries and
+   reduce clashes when multiple handovers occur in a short period.
+   The default is 60 seconds.
+
+.. note:: In VRRP stateful firewall deployments, align VRRP timing with this
+   behavior: because synchronized conntrack state is purged after the purge
+   timeout, set **VRRP preempt-delay** to ≥ **purge-timeout** so mastership
+   can be restored before conntrack state is purged.
+
 .. cfgcmd:: set service conntrack-sync disable-syslog
 
    Disable connection logging via Syslog.
diff --git a/docs/configuration/service/eventhandler.rst b/docs/configuration/service/eventhandler.rst
index 15f08239..9f4ebb04 100644
--- a/docs/configuration/service/eventhandler.rst
+++ b/docs/configuration/service/eventhandler.rst
@@ -8,8 +8,9 @@ Event Handler
 Event Handler Technology Overview
 *********************************
 
-Event handler allows you to execute scripts when a string that matches a regex or a regex with 
-a service name appears in journald logs. You can pass variables, arguments, and a full matching string to the script.
+Event handler allows you to execute scripts when a string that matches
+a regex or a regex with a service name appears in journald logs. You
+can pass variables, arguments, and a full matching string to the script.
 
 
 ******************************
@@ -33,49 +34,76 @@ Event Handler Configuration Steps
 
     .. cfgcmd:: set service event-handler event <event-handler name>
 
-    This is an optional command because the event handler will be automatically created after any of the next commands.
+    This is an optional command because the event handler will be
+    automatically created after any of the next commands.
 
 
 2. Add regex to the script
 ===========================================
 
-    .. cfgcmd:: set service event-handler event <event-handler name> filter pattern <regex>   
+.. stop_vyoslinter
 
-    This is a mandatory command. Sets regular expression to match against log string message.
-    
-    .. note:: The regular expression matches if and only if the entire string matches the pattern.
+    .. cfgcmd:: set service event-handler event <event-handler name> filter pattern <regex>
+
+.. start_vyoslinter
+
+    This is a mandatory command. Sets regular expression to match
+    against log string message.
+
+    .. note:: The regular expression matches if and only if the entire
+       string matches the pattern.
 
 
 
 3. Add a full path to the script
 ================================
 
+.. stop_vyoslinter
+
     .. cfgcmd:: set service event-handler event <event-handler name> script path <path to script>
-   
-    This is a mandatory command. Sets the full path to the script. The script file must be executable.
+
+.. start_vyoslinter
+
+    This is a mandatory command. Sets the full path to the script.
+    The script file must be executable.
 
 
    
 4. Add optional parameters
 ==========================
 
-    .. cfgcmd:: set service event-handler event <event-handler name> filter syslog-identifier <sylogid name>
+.. stop_vyoslinter
+
+    .. cfgcmd:: set service event-handler event <event-handler name> filter syslog-identifier <syslogid name>
+
+.. start_vyoslinter
 
     This is an optional command. Filters log messages by syslog-identifier.
 
+.. stop_vyoslinter
+
     .. cfgcmd:: set service event-handler event <event-handler name> script environment <env name> value <env value>
 
-    This is an optional command. Adds environment and its value to the script. Use separate commands for each environment.
+.. start_vyoslinter
+
+    This is an optional command. Adds environment and its value to the
+    script. Use separate commands for each environment.
     
     One implicit environment exists.
     
     * ``message``: Full message that has triggered the script.
 
+.. stop_vyoslinter
+
     .. cfgcmd:: set service event-handler event <event-handler name> script arguments <arguments>
 
-    This is an optional command. Adds arguments to the script. Arguments must be separated by spaces.
+.. start_vyoslinter
+
+    This is an optional command. Adds arguments to the script.
+    Arguments must be separated by spaces.
 
-    .. note:: We don't recomend to use arguments. Using environments is more preffereble.
+    .. note:: We don't recommend to use arguments. Using environments
+       is more preferable.
     
 
 *******
@@ -84,44 +112,48 @@ Example
 
     Event handler that monitors the state of interface eth0.
 
+.. stop_vyoslinter
+
     .. code-block:: none
 
-	set service event-handler event INTERFACE_STATE_DOWN filter pattern '.*eth0.*,RUNNING,.*->.*'
-	set service event-handler event INTERFACE_STATE_DOWN filter syslog-identifier 'netplugd'
-	set service event-handler event INTERFACE_STATE_DOWN script environment interface_action value 'down'
-	set service event-handler event INTERFACE_STATE_DOWN script environment interface_name value 'eth2'
-	set service event-handler event INTERFACE_STATE_DOWN script path '/config/scripts/eventhandler.py'
+      set service event-handler event INTERFACE_STATE_DOWN filter pattern '.*eth0.*,RUNNING,.*->.*'
+      set service event-handler event INTERFACE_STATE_DOWN filter syslog-identifier 'netplugd'
+      set service event-handler event INTERFACE_STATE_DOWN script environment interface_action value 'down'
+      set service event-handler event INTERFACE_STATE_DOWN script environment interface_name value 'eth0'
+      set service event-handler event INTERFACE_STATE_DOWN script path '/config/scripts/eventhandler.py'
 
     Event handler script
 
     .. code-block:: none
 
-	#!/usr/bin/env python3
-	#
-	# VyOS event-handler script example
-	from os import environ
-	import subprocess
-	from sys import exit
-
-	# Perform actions according to requirements
-	def process_event() -> None:
-    	    # Get variables
-    	    message_text = environ.get('message')
-    	    interface_name = environ.get('interface_name')
-    	    interface_action = environ.get('interface_action')
-    	    # Print the message that triggered this script
-    	    print(f'Logged message: {message_text}')
-    	    # Prepare a command to run
-    	    command = f'sudo ip link set {interface_name} {interface_action}'.split()
-    	    # Execute a command
-    	    subprocess.run(command)
-
-	if __name__ == '__main__':
-    	    try:
-        	# Run script actions and exit
-        	process_event()
-    	        exit(0)
-    	    except Exception as err:
-        	# Exit properly in case if something in the script goes wrong
-            	print(f'Error running script: {err}')
-            	exit(1)
+      #!/usr/bin/env python3
+      #
+      # VyOS event-handler script example
+      from os import environ
+      import subprocess
+      from sys import exit
+
+      # Perform actions according to requirements
+      def process_event() -> None:
+          # Get variables
+          message_text = environ.get('message')
+          interface_name = environ.get('interface_name')
+          interface_action = environ.get('interface_action')
+          # Print the message that triggered this script
+          print(f'Logged message: {message_text}')
+          # Prepare a command to run
+          command = f'sudo ip link set {interface_name} {interface_action}'.split()
+          # Execute a command
+          subprocess.run(command)
+
+      if __name__ == '__main__':
+          try:
+              # Run script actions and exit
+              process_event()
+              exit(0)
+          except Exception as err:
+              # Exit properly in case if something in the script goes wrong
+              print(f'Error running script: {err}')
+              exit(1)
+
+.. start_vyoslinter
diff --git a/docs/configuration/service/mdns.rst b/docs/configuration/service/mdns.rst
index b4ca1fd1..8a26722e 100644
--- a/docs/configuration/service/mdns.rst
+++ b/docs/configuration/service/mdns.rst
@@ -1,5 +1,6 @@
+#############
 mDNS Repeater
--------------
+#############
 
 Starting with VyOS 1.2 a :abbr:`mDNS (Multicast DNS)` repeater functionality is
 provided. Additional information can be obtained from
diff --git a/docs/configuration/system/flow-accounting.rst b/docs/configuration/system/flow-accounting.rst
index a339df75..0664eac7 100644
--- a/docs/configuration/system/flow-accounting.rst
+++ b/docs/configuration/system/flow-accounting.rst
@@ -84,7 +84,9 @@ CLI command. You may disable using the local in-memory table with the command:
 
 .. cfgcmd:: set system flow-accounting syslog-facility <facility>
 
-   TBD
+   Set the syslog facility for flow-accounting log messages. Supported values
+   include ``daemon``, ``local0`` through ``local7``, and other standard syslog
+   facilities.
 
 Flow Export
 -----------
@@ -165,6 +167,8 @@ display captured network traffic information for all configured interfaces.
 
    Show flow accounting information for given `<interface>`.
 
+   .. stop_vyoslinter
+
    .. code-block:: none
 
      vyos@vyos:~$ show flow-accounting interface eth0
@@ -178,11 +182,15 @@ display captured network traffic information for all configured interfaces.
      eth0        00:53:01:b2:22:48  00:53:02:58:a2:92  192.0.2.100               192.0.2.14            40006          22  tcp            16        146        1     9444
      eth0        00:53:01:b2:22:48  00:53:02:58:a2:92  192.0.2.100               192.0.2.14                0           0  icmp          192         27        1     4455
 
+   .. start_vyoslinter
+
 .. opcmd:: show flow-accounting interface <interface> host <address>
 
    Show flow accounting information for given `<interface>` for a specific host
    only.
 
+   .. stop_vyoslinter
+
    .. code-block:: none
 
      vyos@vyos:~$ show flow-accounting interface eth0 host 192.0.2.14
@@ -191,3 +199,5 @@ display captured network traffic information for all configured interfaces.
      eth0        00:53:01:b2:22:48  00:53:02:58:a2:92  192.0.2.100  192.0.2.14       40006          22  tcp            16        197        2    12940
      eth0        00:53:01:b2:22:48  00:53:02:58:a2:92  192.0.2.100  192.0.2.14       40152          22  tcp            16         94        1     4924
      eth0        00:53:01:b2:22:48  00:53:02:58:a2:92  192.0.2.100  192.0.2.14           0           0  icmp          192         36        1     5877
+
+   .. start_vyoslinter
diff --git a/docs/configuration/system/lcd.rst b/docs/configuration/system/lcd.rst
index 808d45a2..3fcf01dd 100644
--- a/docs/configuration/system/lcd.rst
+++ b/docs/configuration/system/lcd.rst
@@ -1,8 +1,8 @@
 .. _system-display:
 
-********************
+####################
 System Display (LCD)
-********************
+####################
 
 The system LCD :abbr:`LCD (Liquid-crystal display)` option is for users running
 VyOS on hardware that features an LCD display. This is typically a small display
diff --git a/docs/configuration/system/sysctl.rst b/docs/configuration/system/sysctl.rst
index 06e15031..1fedb9bd 100644
--- a/docs/configuration/system/sysctl.rst
+++ b/docs/configuration/system/sysctl.rst
@@ -4,7 +4,11 @@
 Sysctl
 ######
 
-This chapeter describes how to configure kernel parameters at runtime.
+.. note:: This page is a stub and needs expansion. Contributions
+   welcome via the `VyOS documentation repository
+   <https://github.com/vyos/vyos-documentation>`_.
+
+This chapter describes how to configure kernel parameters at runtime.
 
 ``sysctl`` is used to modify kernel parameters at runtime.  The parameters
 available are those listed under /proc/sys/. 
diff --git a/docs/configuration/trafficpolicy/index.rst b/docs/configuration/trafficpolicy/index.rst
index 5414ce77..13cfb9dc 100644
--- a/docs/configuration/trafficpolicy/index.rst
+++ b/docs/configuration/trafficpolicy/index.rst
@@ -53,29 +53,29 @@ They can be **decimal** prefixes.
 
    .. code-block:: none
 
-	kbit  (10^3)    kilobit per second
-	mbit  (10^6)    megabit per second
-	gbit  (10^9)    gigabit per second
- 	tbit  (10^12)   terabit per second
-	
-	kbps  (8*10^3)  kilobyte per second
-	mbps  (8*10^6)  megabyte per second
-	gbps  (8*10^9)  gigabyte per second
-	tbps  (8*10^12) terabyte per second
+    kbit  (10^3)    kilobit per second
+    mbit  (10^6)    megabit per second
+    gbit  (10^9)    gigabit per second
+    tbit  (10^12)   terabit per second
+    
+    kbps  (8*10^3)  kilobyte per second
+    mbps  (8*10^6)  megabyte per second
+    gbps  (8*10^9)  gigabyte per second
+    tbps  (8*10^12) terabyte per second
 
 Or **binary** prefixes.
 
    .. code-block:: none
 
-	kibit (2^10 = 1024)    kibibit per second
-	mibit (2^20 = 1024^2)  mebibit per second
-	gibit (2^30 = 1024^3)  gibibit per second
-        tbit  (2^40 = 1024^4)  tebibit per second
+    kibit (2^10 = 1024)    kibibit per second
+    mibit (2^20 = 1024^2)  mebibit per second
+    gibit (2^30 = 1024^3)  gibibit per second
+    tbit  (2^40 = 1024^4)  tebibit per second
 
-	kibps (1024*8)	       kibibyte (KiB) per second
-	mibps (1024^2*8)       mebibyte (MiB) per second
-        gibps (1024^3*8)       gibibyte (GiB) per second
-        tibps (1024^4*8)       tebibyte (TiB) per second
+    kibps (1024*8)         kibibyte (KiB) per second
+    mibps (1024^2*8)       mebibyte (MiB) per second
+    gibps (1024^3*8)       gibibyte (GiB) per second
+    tibps (1024^4*8)       tebibyte (TiB) per second
 
 
 Suffixes
@@ -88,7 +88,7 @@ A *bit* is written as **bit**,
         kbit (kilobits per second)
         mbit (megabits per second)
         gbit (gigabits per second)
-	tbit (terabits per second)
+        tbit (terabits per second)
 
 while a *byte* is written as a single **b**.
 
@@ -134,10 +134,13 @@ configuring it.
    identify it, it also defines its priority.
 
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set qos policy <policy> <policy-name> class <class-ID> match <class-matching-rule-name>
 
+.. start_vyoslinter
 
 In the command above, we set the type of policy we are going to
 work with and the name we choose for it; a class (so that we can
@@ -199,10 +202,14 @@ is based on marks done by the firewall,
 
 You can also write a description for a filter:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set qos policy shaper MY-SHAPER class 30 match MY-FIRST-FILTER description "My filter description"
 
+.. start_vyoslinter
+
 
 
 .. note:: An IPv4 TCP filter will only match packets with an IPv4 header
@@ -281,9 +288,11 @@ you want to do with the traffic of that class, what specific
 Traffic-Control treatment you want to give it. You will have different
 possibilities depending on the Traffic Policy you are configuring.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
-   vyos@vyos# set qos policy shaper MY-SHAPER class 30 
+   vyos@vyos# set qos policy shaper MY-SHAPER class 30
    Possible completions:
       bandwidth    Available bandwidth for this policy (default: auto)
       burst        Burst size for this class (default: 15k)
@@ -299,7 +308,8 @@ possibilities depending on the Traffic Policy you are configuring.
       queue-type   Queue type for default traffic (default: fq-codel)
       set-dscp     Change the Differentiated Services (DiffServ) field in the IP header
       target       Acceptable minimum standing/persistent queue delay (default: 5)
-   
+
+.. start_vyoslinter
 
 For instance, with :code:`set qos policy shaper MY-SHAPER
 class 30 set-dscp EF` you would be modifying the DSCP field value of packets in
@@ -1140,9 +1150,11 @@ parameters.
                    Random Early Detection (RED)
 
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
-   vyos@vyos# set qos policy shaper HTB class 10 
+   vyos@vyos# set qos policy shaper HTB class 10
    Possible completions:
       bandwidth    Available bandwidth for this policy (default: auto)
       burst        Burst size for this class (default: 15k)
@@ -1159,6 +1171,8 @@ parameters.
       set-dscp     Change the Differentiated Services (DiffServ) field in the IP header
       target       Acceptable minimum standing/persistent queue delay (default: 5)
 
+.. start_vyoslinter
+
 
 
 .. note:: If you configure a class for **VoIP traffic**, don't give it any
@@ -1174,6 +1188,8 @@ Example
 A simple example of Shaper using priorities.
 
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
    set qos policy shaper MY-HTB bandwidth '50mbit'
@@ -1195,6 +1211,8 @@ A simple example of Shaper using priorities.
    set qos policy shaper MY-HTB default priority '7'
    set qos policy shaper MY-HTB default queue-type 'fair-queue'
 
+.. start_vyoslinter
+
 .. _CAKE:
 
 CAKE
@@ -1255,8 +1273,8 @@ edge.
 
 .. cfgcmd:: set qos policy cake <text> flow-isolation triple-isolate
 
-   **(Default)** Flows are defined by the 5-tuple, fairness is applied over source and
-   destination addresses and also over individual flows.
+   **(Default)** Flows are defined by the 5-tuple, fairness is applied
+   over source and destination addresses and also over individual flows.
 
 .. cfgcmd:: set qos policy cake <text> rtt
 
diff --git a/docs/configuration/vpn/index.rst b/docs/configuration/vpn/index.rst
index d0121abd..6d38e5b5 100644
--- a/docs/configuration/vpn/index.rst
+++ b/docs/configuration/vpn/index.rst
@@ -13,12 +13,4 @@ VPN
    pptp
    rsa-keys
    sstp
-
-
-pages to sort
-
-.. toctree::
-   :maxdepth: 1
-   :includehidden:
-
    dmvpn
diff --git a/docs/configuration/vpn/ipsec/index.rst b/docs/configuration/vpn/ipsec/index.rst
index e454e2f6..973c76de 100644
--- a/docs/configuration/vpn/ipsec/index.rst
+++ b/docs/configuration/vpn/ipsec/index.rst
@@ -12,10 +12,4 @@ IPsec
    remoteaccess_ipsec
    troubleshooting_ipsec
 
-pages to sort
-
-.. toctree::
-   :maxdepth: 1
-   :includehidden:
-
 
diff --git a/docs/configuration/vpn/ipsec/remoteaccess_ipsec.rst b/docs/configuration/vpn/ipsec/remoteaccess_ipsec.rst
index 1a41d987..50499160 100644
--- a/docs/configuration/vpn/ipsec/remoteaccess_ipsec.rst
+++ b/docs/configuration/vpn/ipsec/remoteaccess_ipsec.rst
@@ -1,7 +1,11 @@
 .. _remoteaccess_ipsec:
 
+############################
 IPSec IKEv2 Remote Access VPN
-=============================
+############################
+
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
 
 Internet Key Exchange version 2 (IKEv2) is a tunneling protocol, based on IPsec,
 that establishes a secure VPN communication between VPN devices, and defines
diff --git a/docs/configuration/vpn/ipsec/troubleshooting_ipsec.rst b/docs/configuration/vpn/ipsec/troubleshooting_ipsec.rst
index fdeb347d..f0f2e208 100644
--- a/docs/configuration/vpn/ipsec/troubleshooting_ipsec.rst
+++ b/docs/configuration/vpn/ipsec/troubleshooting_ipsec.rst
@@ -4,6 +4,9 @@
 Troubleshooting Site-to-Site VPN IPsec
 ######################################
 
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
+
 ************
 Introduction
 ************
@@ -26,6 +29,8 @@ Checking IKE SA Status
 
 The next command shows IKE SAs' statuses.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
  vyos@vyos:~$ show vpn ike sa
@@ -317,6 +322,8 @@ The reason of this problem is showed on the responder side.
  Jun 23 14:13:19 charon[2440]: 01[ENC] <PEER|7> generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]
  Jun 23 14:13:19 charon-systemd[2440]: generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]
 
+.. start_vyoslinter
+
 Traffic selectors **10.0.2.0/24 === 10.0.0.0/24** are unacceptable on the
 responder side.
 
diff --git a/docs/configuration/vpn/openconnect.rst b/docs/configuration/vpn/openconnect.rst
index 11824e50..0262b3f2 100644
--- a/docs/configuration/vpn/openconnect.rst
+++ b/docs/configuration/vpn/openconnect.rst
@@ -4,6 +4,9 @@
 OpenConnect
 ###########
 
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
+
 OpenConnect-compatible server feature has been available since Equuleus (1.3).
 Openconnect VPN supports SSL connection and offers full network access. SSL VPN
 network extension connects the end-user system to the corporate network with
@@ -37,10 +40,14 @@ client that fetches a certificate from Let's Encrypt an open certificate
 authority launched by the EFF, Mozilla, and others and deploys it to a web 
 server.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   sudo certbot certonly --standalone --preferred-challenges http -d <domain name>
 
+.. start_vyoslinter
+
 Server Configuration
 ====================
 
@@ -63,6 +70,8 @@ authentication + OTP key can be used. Alternatively, OTP authentication only,
 without a password, can be used.
 To do this, an OTP configuration must be added to the configuration above:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set vpn openconnect authentication mode local <password-otp|otp>
@@ -71,6 +80,8 @@ To do this, an OTP configuration must be added to the configuration above:
   set vpn openconnect authentication local-users username <user> otp-length <otp-length (optional)>
   set vpn openconnect authentication local-users username <user> token-type <token-type (optional)>
 
+.. start_vyoslinter
+
 For generating an OTP key in VyOS, you can use the CLI command 
 (operational mode):
 
@@ -81,9 +92,21 @@ For generating an OTP key in VyOS, you can use the CLI command
 User Certificate Authentication
 ===============================
 
-You can configure users to be authenticated by certificate by setting the authentication mode to certificate, and defining what field (by OID) in the certificate will be used to identify the username. Two pre-defined shortcuts for Common Name (OID 2.5.4.3) and User ID (OID 0.9.2342.19200300.100.1.1) have been provide as cn or uid. Otherwise a specific OID value must be provided.
+You can configure users to be authenticated by certificate by setting
+the authentication mode to certificate, and defining what field (by OID)
+in the certificate will be used to identify the username. Two pre-defined
+
+.. stop_vyoslinter
+
+shortcuts for Common Name (OID 2.5.4.3) and User ID
+(OID 0.9.2342.19200300.100.1.1) have been provided as cn or uid.
 
-The user's certificate must be signed by the certificate authority defined in the configuration for it to be validated for authentication.
+.. start_vyoslinter
+
+Otherwise a specific OID value must be provided.
+
+The user's certificate must be signed by the certificate authority
+defined in the configuration for it to be validated for authentication.
 
 .. code-block:: none
 
@@ -95,14 +118,17 @@ The user's certificate must be signed by the certificate authority defined in th
 Verification
 ************
 
-.. code-block:: none
+.. stop_vyoslinter
 
+.. code-block:: none
 
   vyos@vyos:~$ sh openconnect-server sessions
   interface    username    ip             remote IP    RX       TX         state      uptime
   -----------  ----------  -------------  -----------  -------  ---------  ---------  --------
   sslvpn0      tst         172.20.20.198  192.168.6.1  0 bytes  152 bytes  connected  3s
 
+.. start_vyoslinter
+
 .. note:: It is compatible with Cisco (R) AnyConnect (R) clients.
 
 *******
@@ -114,6 +140,8 @@ SSL Certificates generation
 
 Follow the instructions to generate CA cert (in configuration mode):
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos# run generate pki ca install ca-ocserv
@@ -151,6 +179,8 @@ Follow the instructions to generate server cert (in configuration mode):
   2 value(s) installed. Use "compare" to see the pending changes, and "commit" to apply.
   [edit]
 
+.. start_vyoslinter
+
 Each of the install command should be applied to the configuration and commited
 before using under the openconnect configuration:
 
@@ -168,6 +198,8 @@ Openconnect Configuration
 
 Simple setup with one user added and password authentication:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set vpn openconnect authentication local-users username tst password 'OC_bad_Secret'
@@ -178,6 +210,8 @@ Simple setup with one user added and password authentication:
   set vpn openconnect ssl ca-certificate 'ca-ocserv'
   set vpn openconnect ssl certificate 'srv-ocserv'
 
+.. start_vyoslinter
+
 To enable the HTTP security headers in the configuration file, use the command:
 
 .. code-block:: none
@@ -191,6 +225,8 @@ Adding a 2FA with an OTP-key
 First the OTP keys must be generated and sent to the user and to the 
 configuration:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@vyos:~$ generate openconnect username tst otp-key hotp-time
@@ -222,13 +258,19 @@ configuration:
   # To add this OTP key to configuration, run the following commands:
   set vpn openconnect authentication local-users username tst otp key 'ebc1c91b13848ce0bb67d9212934546e41803cfa'
 
+.. start_vyoslinter
+
 Next it is necessary to configure 2FA for OpenConnect:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set vpn openconnect authentication mode local password-otp
   set vpn openconnect authentication local-users username tst otp key 'ebc1c91b13848ce0bb67d9212934546e41803cfa'
 
+.. start_vyoslinter
+
 Now when connecting the user will first be asked for the password 
 and then the OTP key.
 
@@ -254,6 +296,8 @@ outlines the set of configuration options that are allowed. This can be
 leveraged to apply different sets of configs to different users or groups of
 users.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   sudo mkdir -p /config/auth/ocserv/config-per-user
@@ -263,6 +307,8 @@ users.
   set vpn openconnect authentication identity-based-config directory /config/auth/ocserv/config-per-user
   set vpn openconnect authentication identity-based-config default-config /config/auth/ocserv/default-user.conf
 
+.. start_vyoslinter
+
 .. warning:: The above directory and default-config must be a child directory
   of /config/auth, since files outside this directory are not persisted after an
   image upgrade.
@@ -297,6 +343,8 @@ connect/disconnect, data transferred, and so on.
 
 Configure an accounting server and enable accounting with:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set vpn openconnect accounting mode radius
@@ -304,12 +352,16 @@ Configure an accounting server and enable accounting with:
   set vpn openconnect accounting radius server 172.20.20.10 port 1813
   set vpn openconnect accounting radius server 172.20.20.10 key your_radius_secret
 
+.. start_vyoslinter
+
 .. warning:: The RADIUS accounting feature must be used with the OpenConnect
   authentication mode RADIUS. It cannot be used with local authentication.
   You must configure the OpenConnect authentication mode to "radius".
 
 An example of the data captured by a FREERADIUS server with sql accounting:
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   mysql> SELECT username, nasipaddress, acctstarttime, acctstoptime, acctinputoctets, acctoutputoctets, callingstationid, framedipaddress, connectinfo_start FROM radacct;
@@ -318,3 +370,5 @@ An example of the data captured by a FREERADIUS server with sql accounting:
   +----------+---------------+---------------------+---------------------+-----------------+------------------+-------------------+-----------------+-----------------------------------+
   | test     | 198.51.100.15 | 2023-01-13 00:59:15 | 2023-01-13 00:59:21 |           10606 |              152 | 192.168.6.1       | 172.20.20.198   | Open AnyConnect VPN Agent v8.05-1 |
   +----------+---------------+---------------------+---------------------+-----------------+------------------+-------------------+-----------------+-----------------------------------+
+
+.. start_vyoslinter
diff --git a/docs/configuration/vpn/rsa-keys.rst b/docs/configuration/vpn/rsa-keys.rst
index 0508522f..e7584563 100644
--- a/docs/configuration/vpn/rsa-keys.rst
+++ b/docs/configuration/vpn/rsa-keys.rst
@@ -2,6 +2,10 @@
 ########
 RSA-Keys
 ########
+
+.. TODO:: Convert raw command blocks in this file to cfgcmd/opcmd
+   directives for command coverage tracking.
+
 RSA can be used for services such as key exchanges and for encryption purposes.
 To make IPSec work with dynamic address on one/both sides, we will have to use
 RSA keys for authentication. They are very fast and easy to setup.
@@ -9,6 +13,8 @@ RSA keys for authentication. They are very fast and easy to setup.
 First, on both routers run the operational command "generate pki key-pair 
 install <key-pair nam>>". You may choose different length than 2048 of course.
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   vyos@left# run generate pki key-pair install ipsec-LEFT
@@ -23,6 +29,8 @@ install <key-pair nam>>". You may choose different length than 2048 of course.
   set pki key-pair ipsec-LEFT private key 'MIIEvgIBADAN...'
   [edit]
 
+.. start_vyoslinter
+
 Configuration commands will display.
 Note the command with the public key 
 (set pki key-pair ipsec-LEFT public key 'MIIBIjANBgkqh...'). 
@@ -51,13 +59,19 @@ On the RIGHT:
 
 Now you are ready to setup IPsec. The key points:
 
-1. Since both routers do not know their effective public addresses, we set the local-address of the peer to "any".
-2. On the initiator, we set the peer address to its public address, but on the responder we only set the id.
-3. On the initiator, we need to set the remote-id option so that it can identify IKE traffic from the responder correctly.
-4. On the responder, we need to set the local id so that initiator can know who's talking to it for the point #3 to work.
+1. Since both routers do not know their effective public addresses,
+   we set the local-address of the peer to "any".
+2. On the initiator, we set the peer address to its public address,
+   but on the responder we only set the id.
+3. On the initiator, we need to set the remote-id option so that it
+   can identify IKE traffic from the responder correctly.
+4. On the responder, we need to set the local id so that initiator
+   can know who's talking to it for the point #3 to work.
 
 On the LEFT (static address):
 
+.. stop_vyoslinter
+
 .. code-block:: none
 
   set vpn ipsec interface eth0
@@ -105,3 +119,5 @@ On the RIGHT (dynamic address):
   set vpn ipsec site-to-site peer 192.0.2.10 local-address any
   set vpn ipsec site-to-site peer 192.0.2.10 tunnel 1 local prefix 192.168.99.2/32  # Additional loopback address on the local
   set vpn ipsec site-to-site peer 192.0.2.10 tunnel 1 remote prefix 192.168.99.1/32 # Additional loopback address on the remote
+
+.. start_vyoslinter