Re: named counters vs flush ruleset

On 08-02-2025 22:49, Pablo Neira Ayuso wrote:
> On Sat, Feb 08, 2025 at 03:35:27PM +0100, Victor Julien wrote:
>> Hi all,
>>
>> I'm working on finally supporting nftables in Vuurmuur.
>>
>> In the iptables support, I have special rules per interface to get per iface
>> packets and bytes. Essentially my tool reads the iptables -vnL output and
>> parses all the things. When a user applies a ruleset change, Vuurmuur reads
>> the most current values, constructs a new input file to `iptables-restore`
>> and loads the rules. This works but is tedious, and also lacks some
>> precision as we are not counting the packets/bytes while Vuurmuur is
>> working.
>>
>> In the nftables support, I'm more or less looking at the same logic. The
>> ruleset is build as a .nft file that is loaded with `nft -f`.
>>
>> Now I found the the named counter feature, and also the json output `nft -j
>> list counters`. This combination seems perfect.
>>
>> I guess my main question is if we can make these counters persistent
>> somehow. As part of the ruleset reload, I issue a `flush ruleset`, which
>> also removes the counters.
>>
>> So can we make counters survive a `flush ruleset`, or is there a better way
>> to load a new ruleset?
> 
> Would it work for you to destroy all other existing objects (not the
> table and counters) instead?

Thanks Pablo. Here's what I'm thinking now:

I create an additional table "vrmr_accounting"

table ip vrmr_accounting {
         counter vrmr_enp1s0 {
                 packets 17546 bytes 3901328
         }

         chain INPUT {
                 type filter hook input priority -100; policy accept;
                 iifname "enp1s0" counter name "vrmr_enp1s0" comment 
"lan-nic"
         }

         chain OUTPUT {
                 type filter hook output priority dstnat; policy accept;
                 oifname "enp1s0" counter name "vrmr_enp1s0"
         }

         chain FORWARD {
                 type filter hook forward priority -100; policy accept;
                 iifname "enp1s0" counter name "vrmr_enp1s0"
                 oifname "enp1s0" counter name "vrmr_enp1s0"
         }
}

Then I create regular a regular filter table, where the normal rules are 
created. My assumption is that due to the lower priority value the 
`vrmr_accounting` table goes first in the processing.

In my reload instead of a `flush ruleset`, I do:

# clear existing tables/rules
destroy table ip filter
...
add table ip filter
add chain ip filter INPUT { type filter hook input priority 0; policy 
drop; }
add chain ip filter OUTPUT { type filter hook output priority 0; policy 
drop; }
add chain ip filter FORWARD { type filter hook forward priority 0; 
policy drop; }

...
# clear accounting chains (incl rules), but not the counter itself
add table ip vrmr_accounting
destroy chain ip vrmr_accounting INPUT
destroy chain ip vrmr_accounting OUTPUT
destroy chain ip vrmr_accounting FORWARD
add chain ip vrmr_accounting INPUT { type filter hook input priority 
-100; policy accept; }
add chain ip vrmr_accounting OUTPUT { type filter hook output priority 
-100; policy accept; }
add chain ip vrmr_accounting FORWARD { type filter hook forward priority 
-100; policy accept; }
...
add counter ip vrmr_accounting vrmr_enp1s0
add rule ip vrmr_accounting INPUT iifname "enp1s0" counter name 
vrmr_enp1s0 comment lan-nic
...

This appears to leave the counters intact.

Does this make sense to you?

Cheers,
Victor

-- 
----------------------------------------------
Victor Julien
https://www.inliniac.net/
PGP: https://www.inliniac.net/victorjulien.asc
----------------------------------------------