From: Shivani Bhardwaj Date: Fri, 5 Sep 2025 10:25:39 +0000 (+0530) Subject: doc: make firewall table names consistent X-Git-Tag: suricata-8.0.1~18 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F13817%2Fhead;p=thirdparty%2Fsuricata.git doc: make firewall table names consistent --- 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 ==============