From 9ed5ac76690b3c9410dee2125a9f5e4c3f74d105 Mon Sep 17 00:00:00 2001 From: Shivani Bhardwaj Date: Fri, 5 Sep 2025 15:55:39 +0530 Subject: [PATCH] doc: make firewall table names consistent --- doc/userguide/firewall/firewall-design.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/userguide/firewall/firewall-design.rst b/doc/userguide/firewall/firewall-design.rst index fb2df96b6b..bee7f4760d 100644 --- a/doc/userguide/firewall/firewall-design.rst +++ b/doc/userguide/firewall/firewall-design.rst @@ -221,7 +221,7 @@ next table is ``app:*:*``. In ``app:*:*`` the per application layer states are all evaluated at least once. At each of these states an ``accept:hook`` is required to progress to the next state. When all available states have been accepted, the pipeline moves to the final table ``app:td`` (application layer threat -detection). A ``drop`` in the ``app_filter`` table is immediate, however and ``accept`` is +detection). A ``drop`` in the ``app:filter`` table is immediate, however and ``accept`` is conditional on the verdict of the ``app:td`` table. The default ``drop`` in one of the ``app:*:*`` tables is a ``drop:flow``. This means that the @@ -243,7 +243,7 @@ Pass rules with Firewall mode In IDS/IPS mode, a ``pass`` rule with app-layer matches will bypass the detection engine for the rest of the flow. In firewall mode, this bypass no longer happens in the same way, as ``pass`` rules do not affect firewall rules. So the detection engine is still invoked on packets of such a flow, -but the ``packet_td`` and ``app_td`` tables are skipped. +but the ``packet:td`` and ``app:td`` tables are skipped. Firewall rules ============== -- 2.47.3