named counters vs flush ruleset

named counters vs flush ruleset

[Victor Julien]

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?

Thanks!
Victor

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

Re: named counters vs flush ruleset

[Pablo Neira Ayuso]

Hi Victor,

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?

Re: named counters vs flush ruleset

[Victor Julien]

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
----------------------------------------------

Re: named counters vs flush ruleset

[Pablo Neira Ayuso]

Hi Victor,

On Sun, Feb 09, 2025 at 11:58:56AM +0100, Victor Julien wrote:
> 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.

I see, you are using a table that contains rules for metering only.

> 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; }

Maybe you could use?

  flush table ip filter

to leave the table and chain in place. Similar semantics to
iptables -F.

> ...
> # 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?

I wonder if you could consolidate all in one single table:

  flush table ip filter

leaves table, chain and counters intact.

Re: named counters vs flush ruleset

[Victor Julien]

Hi Pablo,

On 26-02-2025 00:47, Pablo Neira Ayuso wrote:
>>>> 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"
>>

[...]

>>
>> 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.
> 
> I see, you are using a table that contains rules for metering only.

Do you see disadvantages for this?


>> 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; }
> 
> Maybe you could use?
> 
>    flush table ip filter
> 
> to leave the table and chain in place. Similar semantics to
> iptables -F.

I kind of want to avoid reading which tables and chains already exist, 
and craft a .nft file that will do "the right thing" when loaded into a 
fresh system or when loaded as a ruleset "reload".

`flush table ip filter` is invalid if `ip filter` doesn't exist yet, 
while `destroy table ip filter` works even if `ip filter` doesn't exist.

A create + flush also doesn't work, as create fails if the table already 
exists.

So far this is the only scheme I've been able to come up with that 
allows me to "blindly" load a rules, so w/o caring about whether the 
relevant tables and chain exist or not.

Cheers,
Victor

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