How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

hello everyone,

I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10.

If I understand correctly, the following will block traffic originating from that IP range.

nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop


But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine.

The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent.

Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers".

So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables.


Thanks a lot in advance.



Here's my nftables.conf file:

:::::
#!/usr/sbin/nft -f

flush ruleset

table inet filter {

    chain input {
        type filter hook input priority 0; policy drop;

        iifname lo accept

        # ssh for internal network
        ip saddr 192.168.0.0/16 tcp dport 22 counter accept
        ct state established,related accept

        # Avoid brute force on ssh
        tcp dport 22 ct state new limit rate 10/minute accept

        # Early drop of invalid connections
        ct state invalid drop

        # VsFTPD
        ip saddr 192.168.0.0/16 tcp dport 20 counter accept
        ip saddr 192.168.0.0/16 tcp dport 21 counter accept
        ip saddr 192.168.0.0/16 tcp dport 990 counter accept
        ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept


        # ICMP & IGMP
        ip saddr 192.168.0.0/16 icmp type echo-request counter accept
        icmp type echo-request counter drop
        ip protocol igmp drop

        # Everything else
        reject with icmpx type port-unreachable

        log flags all counter drop
        log prefix "[nftables] Input Denied: " flags all counter drop
    }
}
:::::

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[zrm]

On 10/1/19 19:22, Jags wrote:
> hello everyone,
> 
> I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10.
> 
> If I understand correctly, the following will block traffic originating from that IP range.
> 
> nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop
> 
> 
> But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine.
> 
> The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent.
> 
> Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers".
> 
> So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables.
> 
> 
> Thanks a lot in advance.

A torrent client could try to connect to a peer in either direction, so 
if you don't want communication with that IP range at all then you would 
also want a rule to drop packets in the OUTPUT chain with that address 
range as the daddr. You may also want to use reject rather than drop in 
that case because the then the client will figure out that the peer is 
not available faster.

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

@zrm  thank you so much for the reply.


(1) Would it be something like this:

:::::
chain output {
                type filter hook output priority 0; policy accept;

                ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject
    }
:::::

Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here.

Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely.


(2) In addition to the OUTPUT chain, I've added this into INPUT chain too:

:::::
chain input {
                type filter hook input priority 0; policy drop;

                ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop
    }
:::::


So how should I modify the either or both of the above please... many thanks.







‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 3, 2019 7:00 PM, zrm <zrm@trustiosity.com> wrote:

> On 10/1/19 19:22, Jags wrote:
>
> > hello everyone,
> > I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10.
> > If I understand correctly, the following will block traffic originating from that IP range.
> > nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop
> > But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine.
> > The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent.
> > Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers".
> > So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables.
> > Thanks a lot in advance.
>
> A torrent client could try to connect to a peer in either direction, so
> if you don't want communication with that IP range at all then you would
> also want a rule to drop packets in the OUTPUT chain with that address
> range as the daddr. You may also want to use reject rather than drop in
> that case because the then the client will figure out that the peer is
> not available faster.

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Reindl Harald]

Am 04.10.19 um 11:45 schrieb Jags:
> @zrm  thank you so much for the reply.
> 
> 
> (1) Would it be something like this:
> 
> :::::
> chain output {
>                 type filter hook output priority 0; policy accept;
> 
>                 ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject
>     }
> :::::
> 
> Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here.
> 
> Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely.
> 
> 
> (2) In addition to the OUTPUT chain, I've added this into INPUT chain too:
> 
> :::::
> chain input {
>                 type filter hook input priority 0; policy drop;
> 
>                 ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop
>     }
> :::::
> 
> 
> So how should I modify the either or both of the above please... many thanks

it's the same as with iptables

"established,related" allows responses and so when your client made a
connection to a peer data from this peer is allowed back

order matters and there is no point to change the outbound policy to DROP

the policy is applied after all rules  and the first mathcing action
wins, everywhere

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

Should I modify it to the following:

:::
chain output {
                type filter hook output priority 0; policy accept;

                ip daddr 123.0.0.0/8 counter reject  }
:::

and

:::
chain input {
                type filter hook input priority 0; policy drop;

                ip saddr 123.0.0.0/8 counter drop  }
:::


Many thanks.





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 4, 2019 10:18 AM, Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.10.19 um 11:45 schrieb Jags:
>
> > @zrm thank you so much for the reply.
> > (1) Would it be something like this:
> > :::::
> > chain output {
> > type filter hook output priority 0; policy accept;
> >
> >                 ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject
> >     }
> >
> >
> > :::::
> > Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here.
> > Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely.
> > (2) In addition to the OUTPUT chain, I've added this into INPUT chain too:
> > :::::
> > chain input {
> > type filter hook input priority 0; policy drop;
> >
> >                 ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop
> >     }
> >
> >
> > :::::
> > So how should I modify the either or both of the above please... many thanks
>
> it's the same as with iptables
>
> "established,related" allows responses and so when your client made a
> connection to a peer data from this peer is allowed back
>
> order matters and there is no point to change the outbound policy to DROP
>
> the policy is applied after all rules and the first mathcing action
> wins, everywhere

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Reindl Harald]

Am 04.10.19 um 12:44 schrieb Jags:
> Should I modify it to the following:
> 
> :::
> chain output {
>                 type filter hook output priority 0; policy accept;
> 
>                 ip daddr 123.0.0.0/8 counter reject  }
> :::
> 
> and
> 
> :::
> chain input {
>                 type filter hook input priority 0; policy drop;
> 
>                 ip saddr 123.0.0.0/8 counter drop  }
> :::

surely, and that on top of the ruleset before any accept-rule, there is
no point to mention "ct state" when you just want to block communication
from and to a ip unconditionally

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

Thank you so much.

Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain.

Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting".


Here's my complete nftables.conf:


xxxxx
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
                type filter hook input priority 0; policy drop;

                iifname lo accept

--->            ip saddr 123.0.0.0/8 counter drop

                # Early drop of invalid connections
                ct state invalid drop
                ct state established,related accept

                # ICMP & IGMP
                ip saddr 192.168.0.0/16 icmp type echo-request counter accept
                icmp type echo-request counter drop
                ip protocol igmp drop

                # ssh for internal network
                ip saddr 192.168.0.0/16 tcp dport 22 counter accept

                # Avoid brute force on ssh
                tcp dport 22 ct state new limit rate 10/minute accept

                # VsFTPD
                ip saddr 192.168.0.0/16 tcp dport 20 counter accept
                ip saddr 192.168.0.0/16 tcp dport 21 counter accept
                ip saddr 192.168.0.0/16 tcp dport 990 counter accept
                ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept

                ct state new drop
                # Everything else
                drop

                log flags all counter drop
                log prefix "[nftables] Input Denied: " flags all counter drop
    }
        chain output {
                type filter hook output priority 0; policy accept;

--->            ip daddr 123.0.0.0/8 counter reject
    }
}
xxxxx






‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 4, 2019 11:05 AM, Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.10.19 um 12:44 schrieb Jags:
>
> > Should I modify it to the following:
> > :::
> > chain output {
> > type filter hook output priority 0; policy accept;
> >
> >                 ip daddr 123.0.0.0/8 counter reject  }
> >
> >
> > :::
> > and
> > :::
> > chain input {
> > type filter hook input priority 0; policy drop;
> >
> >                 ip saddr 123.0.0.0/8 counter drop  }
> >
> >
> > :::
>
> surely, and that on top of the ruleset before any accept-rule, there is
> no point to mention "ct state" when you just want to block communication
> from and to a ip unconditionally

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Reindl Harald]

Am 04.10.19 um 14:21 schrieb :
> Thank you so much.
> 
> Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain.

shouldn't matter at all because a packet can only be output or input and
not both

>                 # Early drop of invalid connections
>                 ct state invalid drop
>                 ct state established,related accept

switch both of them! you have far more packets from legit traffic than
invalid ones and hence "established,related" should always be the first
rule in any stateful filter with exceptions like the topic

not sure about nftables but with iptables i would just place the drop
stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack
and consider place it in a ipset for the case the list becomes longer
becasue then you have only one rule and a lightning fast hash-lookup no
matter how much entries

> Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting".
> 
> 
> Here's my complete nftables.conf:
> 
> 
> xxxxx
> #!/usr/sbin/nft -f
> 
> flush ruleset
> 
> table inet filter {
>         chain input {
>                 type filter hook input priority 0; policy drop;
> 
>                 iifname lo accept
> 
> --->            ip saddr 123.0.0.0/8 counter drop
> 
>                 # Early drop of invalid connections
>                 ct state invalid drop
>                 ct state established,related accept
> 
>                 # ICMP & IGMP
>                 ip saddr 192.168.0.0/16 icmp type echo-request counter accept
>                 icmp type echo-request counter drop
>                 ip protocol igmp drop
> 
>                 # ssh for internal network
>                 ip saddr 192.168.0.0/16 tcp dport 22 counter accept
> 
>                 # Avoid brute force on ssh
>                 tcp dport 22 ct state new limit rate 10/minute accept
> 
>                 # VsFTPD
>                 ip saddr 192.168.0.0/16 tcp dport 20 counter accept
>                 ip saddr 192.168.0.0/16 tcp dport 21 counter accept
>                 ip saddr 192.168.0.0/16 tcp dport 990 counter accept
>                 ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept
> 
>                 ct state new drop
>                 # Everything else
>                 drop
> 
>                 log flags all counter drop
>                 log prefix "[nftables] Input Denied: " flags all counter drop
>     }
>         chain output {
>                 type filter hook output priority 0; policy accept;
> 
> --->            ip daddr 123.0.0.0/8 counter reject
>     }
> }

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

> not sure about nftables but with iptables i would just place the drop
> stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack
> and consider place it in a ipset for the case the list becomes longer
> because then you have only one rule and a lightning fast hash-lookup no
> matter how much entries


Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client.

So should I just add a new table "raw" (and place this table at the top):

xxxxxxxxx
table inet raw {
        chain prerouting {
                type filter hook prerouting priority 0; policy accept;
                ip saddr 123.0.0.0/8 counter drop
        }
        chain output {
                type filter hook output priority 0; policy accept;
                ip daddr 123.0.0.0/8 counter reject
        }
xxxxxxxxx


Now do I need POSTROUTING chain in there too?

From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables

"postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook."


Thank you so much.





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 4, 2019 1:06 PM, Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.10.19 um 14:21 schrieb :
>
> > Thank you so much.
> > Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain.
>
> shouldn't matter at all because a packet can only be output or input and
> not both
>
> >                 # Early drop of invalid connections
> >                 ct state invalid drop
> >                 ct state established,related accept
> >
>
> switch both of them! you have far more packets from legit traffic than
> invalid ones and hence "established,related" should always be the first
> rule in any stateful filter with exceptions like the topic
>
>
> > Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting".
> > Here's my complete nftables.conf:
> > xxxxx
> > #!/usr/sbin/nft -f
> > flush ruleset
> > table inet filter {
> > chain input {
> > type filter hook input priority 0; policy drop;
> >
> >                 iifname lo accept
> >
> >
> > ---> ip saddr 123.0.0.0/8 counter drop
> >
> >                 # Early drop of invalid connections
> >                 ct state invalid drop
> >                 ct state established,related accept
> >
> >                 # ICMP & IGMP
> >                 ip saddr 192.168.0.0/16 icmp type echo-request counter accept
> >                 icmp type echo-request counter drop
> >                 ip protocol igmp drop
> >
> >                 # ssh for internal network
> >                 ip saddr 192.168.0.0/16 tcp dport 22 counter accept
> >
> >                 # Avoid brute force on ssh
> >                 tcp dport 22 ct state new limit rate 10/minute accept
> >
> >                 # VsFTPD
> >                 ip saddr 192.168.0.0/16 tcp dport 20 counter accept
> >                 ip saddr 192.168.0.0/16 tcp dport 21 counter accept
> >                 ip saddr 192.168.0.0/16 tcp dport 990 counter accept
> >                 ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept
> >
> >                 ct state new drop
> >                 # Everything else
> >                 drop
> >
> >                 log flags all counter drop
> >                 log prefix "[nftables] Input Denied: " flags all counter drop
> >     }
> >         chain output {
> >                 type filter hook output priority 0; policy accept;
> >
> >
> > ---> ip daddr 123.0.0.0/8 counter reject
> > }
> > }

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Reindl Harald]

Am 04.10.19 um 16:28 schrieb Jags:
>> not sure about nftables but with iptables i would just place the drop
>> stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack
>> and consider place it in a ipset for the case the list becomes longer
>> because then you have only one rule and a lightning fast hash-lookup no
>> matter how much entries
> 
> 
> Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client.
> 
> So should I just add a new table "raw" (and place this table at the top):
> 
> xxxxxxxxx
> table inet raw {
>         chain prerouting {
>                 type filter hook prerouting priority 0; policy accept;
>                 ip saddr 123.0.0.0/8 counter drop
>         }
>         chain output {
>                 type filter hook output priority 0; policy accept;
>                 ip daddr 123.0.0.0/8 counter reject
>         }
> xxxxxxxxx
> 
> 
> Now do I need POSTROUTING chain in there too?
> 
> From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables
> 
> "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook"
you don't need chains where you don't place rules

disclaimer: i use iptables and plan to switch to iptables-nft over the
long, so nftables may have sbtle different behavior

however, it turned out to have way better performance for a big firewall
setup place as much as possible in "-t mangle PREROUTING" (ct state
invalid) and "-t raw PREROUTING" because less processing of packets

not sure if "table inet raw" hast the same semantic (before conntrack,
before routing)" but if it can have a postrouting hook i doubt because
that's not possible for "-t raw" in iptables given that in this table
there is no routing decision possible

look at the image to get a picture, i can't help with nfstables itself
https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Neal P. Murphy]

On Fri, 4 Oct 2019 17:10:05 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.10.19 um 16:28 schrieb Jags:
> >> not sure about nftables but with iptables i would just place the drop
> >> stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack
> >> and consider place it in a ipset for the case the list becomes longer
> >> because then you have only one rule and a lightning fast hash-lookup no
> >> matter how much entries  
> > 
> > 
> > Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client.
> > 
> > So should I just add a new table "raw" (and place this table at the top):
> > 
> > xxxxxxxxx
> > table inet raw {
> >         chain prerouting {
> >                 type filter hook prerouting priority 0; policy accept;
> >                 ip saddr 123.0.0.0/8 counter drop
> >         }
> >         chain output {
> >                 type filter hook output priority 0; policy accept;
> >                 ip daddr 123.0.0.0/8 counter reject
> >         }
> > xxxxxxxxx
> > 
> > 
> > Now do I need POSTROUTING chain in there too?
> > 
> > From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables
> > 
> > "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook"  
> you don't need chains where you don't place rules
> 
> disclaimer: i use iptables and plan to switch to iptables-nft over the
> long, so nftables may have sbtle different behavior
> 
> however, it turned out to have way better performance for a big firewall
> setup place as much as possible in "-t mangle PREROUTING" (ct state
> invalid) and "-t raw PREROUTING" because less processing of packets

The top of mangle:PREROUTING is the best place to DROP packets you already know you never want to process, route or forward, such as INVALID packets, TEST net addresses, and blacklisted public IPs and IP ranges. But remember that you might not know all addresses until table filter when NAT is involved.

> 
> not sure if "table inet raw" hast the same semantic (before conntrack,
> before routing)" but if it can have a postrouting hook i doubt because
> that's not possible for "-t raw" in iptables given that in this table
> there is no routing decision possible
> 
> look at the image to get a picture, i can't help with nfstables itself
> https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

Could someone please clarify RAW/MANGLE tables in regards to Nftables.

I could not find any details in Nftables wiki specifically for RAW/MANGLE tables. While I find Gentoo wiki for Nftables much more friendlier: https://wiki.gentoo.org/wiki/Nftables#Tables

xxx
Tables: A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate an iptables-like structure, but anything might do.

Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet
xxx

My question is, since Nftables doesn't have predefined tables, just by naming a table: "table inet raw", does it becomes a RAW table or not? If not, what do I have to do?

I thank you all so much.


For now I have added this to my nftables.conf

xxxxx
table inet raw {
        chain prerouting {
                type filter hook prerouting priority 0; policy accept;
                ip saddr 123.0.0.0/8 counter drop
          }
        chain output {
                type filter hook output priority 0; policy accept;
                ip daddr 123.0.0.0/8 counter reject
         }
}
xxxxx








‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 4, 2019 3:10 PM, Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.10.19 um 16:28 schrieb Jags:
>
> > > not sure about nftables but with iptables i would just place the drop
> > > stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack
> > > and consider place it in a ipset for the case the list becomes longer
> > > because then you have only one rule and a lightning fast hash-lookup no
> > > matter how much entries
> >
> > Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client.
> > So should I just add a new table "raw" (and place this table at the top):
> > xxxxxxxxx
> > table inet raw {
> > chain prerouting {
> > type filter hook prerouting priority 0; policy accept;
> > ip saddr 123.0.0.0/8 counter drop
> > }
> > chain output {
> > type filter hook output priority 0; policy accept;
> > ip daddr 123.0.0.0/8 counter reject
> > }
> > xxxxxxxxx
> > Now do I need POSTROUTING chain in there too?
> > From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables
> > "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook"
>
> you don't need chains where you don't place rules
>
> disclaimer: i use iptables and plan to switch to iptables-nft over the
> long, so nftables may have sbtle different behavior
>
> however, it turned out to have way better performance for a big firewall
> setup place as much as possible in "-t mangle PREROUTING" (ct state
> invalid) and "-t raw PREROUTING" because less processing of packets
>
> not sure if "table inet raw" hast the same semantic (before conntrack,
> before routing)" but if it can have a postrouting hook i doubt because
> that's not possible for "-t raw" in iptables given that in this table
> there is no routing decision possible
>
> look at the image to get a picture, i can't help with nfstables itself
> https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Anton Rieger]

>Could someone please clarify RAW/MANGLE tables in regards to Nftables.

Short story short:
They doesn't exist anymore, but you can change priorities to simulate them.

Long answer:
A table in nftables is identified by:
    1) Their name
    2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6)
Currently only the ``dormant'' flag is supported meaning the table is not evaluated any more

A table is a container for chains.
A chain  is a container for rules.
There are two types of chains:
    1) base chain
    2) regular chain
A base chain must specify a ``type'', ``hook'' and ``priority''.
They need them, as these chains are entry points of packets from the network stack.
You can use these to reconstruct the predefined iptables chains by naming them the same.

Each type is bound to certain families hooks:
    filter) Standard type can be used everywhere.
    nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks
         Performs NAT based on conntrack entries.
         Only first packet of a connection traverses this chain.
         Specify conntrack details here.
    route) Must be ip or ip6 and only provides the output hook.
           If accepted and IP header changes a new route lookup is performed.
           Use this to e.g. implement policy routing selectors.

Quirks:
netdev needs filter and ingress hook and device parameter is mandatory.
arp only supports input/output hooks.

So you can see, that the most used type is filter.
To order with chain gets triggered in which order is determined by the priority parameter.
This can either be a signed integer (lower values have precedence) or standard priority names.
These standard priority names are labeled to match xtables default values:

raw      := -300 (ip,ip6,inet) all hooks
mangle   := -150 (ip,ip6,inet) all hooks
dstnat   := -100 (ip,ip6,inet) prerouting
filter   :=    0 (ip,ip6,inet,arp,netdev) all hooks
security :=   50 (ip,ip6,inet) all hooks
srcnat   :=  100 (ip,ip6,inet) postrouting

Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat
You can also use addition/subtraction in your definitions.
So their order is basically the same.
All this information is well documented in nft(8)

>Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet
Should be updated to include the ``netdev'' family (for ingress handling)

>My question is, since Nftables doesn't have predefined tables, just by naming a table: 
>"table inet raw", does it becomes a RAW table or not?
It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or 
ip6 family packets.

> If not, what do I have to do?
You have to add at least one chain with the priority ``raw''.
So to match iptables:

```
table inet raw {
    chain PREROUTING {
        type filter hook prerouting priority raw; policy accepted;
    }

    chain OUTPUT {
        type filter hook output priority raw; policy accepted;
    }
}
```
Please note that ``policy accept'' is the default choice thus defining it here
is just for better understanding.

>For now I have added this to my nftables.conf
>
>xxxxx
>table inet raw {
>        chain prerouting {
>                type filter hook prerouting priority 0; policy accept;
>                ip saddr 123.0.0.0/8 counter drop
>          }
>        chain output {
>                type filter hook output priority 0; policy accept;
>                ip daddr 123.0.0.0/8 counter reject
>         }
>}
>xxxxx
Please note a priority of 0 is equal to ``filter''.

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

@Anton Rieger, thank you so much.



(1)
> You have to add at least one chain with the priority ``raw''.
> So to match iptables:

This is the answer I was looking for.


Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this.

http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields

I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300"


Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error:

From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields

nft add chain raw prerouting {type filter hook prerouting priority -300\;}

While I think, what it should be (at least when run in Bash on Debian/Ubuntu):

nft add chain raw prerouting '{ type filter hook prerouting priority -300; }'

I figured this difference out a while ago from Arch wiki page:

https://wiki.archlinux.org/index.php/Nftables#Base_chain



(2)
AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table:

table inet raw {
        chain prerouting {
                type filter hook prerouting priority -300; policy accept;
                ip saddr 123.0.0.0/8 counter drop
        }
        chain output {
                type filter hook output priority -300; policy accept;
                 ip daddr 123.0.0.0/8 counter reject
        }
}


(3)
Just before I read your mail, I found these pages:

(a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev

I found this very interesting: "This family provides the ingress hook,
that allows you to classify packets that the driver has just passed up to the networking stack."

(b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

(c) "Mandatory to specify the device where the chain will be attached":
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains

So I have added this "devfilter" table:


table netdev devfilter {
        chain ingress {
                type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept;
                ip saddr 123.0.0.0/8 counter drop
       }
}


Now I think with "netdev/ingress", there's no need for prerouting  within "raw" table,
as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now.


I truly thank you all...





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 4, 2019 8:30 PM, Anton Rieger <rieger@jikken.de> wrote:

> > Could someone please clarify RAW/MANGLE tables in regards to Nftables.
>
> Short story short:
> They doesn't exist anymore, but you can change priorities to simulate them.
>
> Long answer:
> A table in nftables is identified by:
> 1) Their name
> 2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6)
> Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''.
> They need them, as these chains are entry points of packets from the network stack.
> You can use these to reconstruct the predefined iptables chains by naming them the same.
>
> Each type is bound to certain families hooks:
> filter) Standard type can be used everywhere.
> nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks
> Performs NAT based on conntrack entries.
> Only first packet of a connection traverses this chain.
> Specify conntrack details here.
> route) Must be ip or ip6 and only provides the output hook.
> If accepted and IP header changes a new route lookup is performed.
> Use this to e.g. implement policy routing selectors.
>
> Quirks:
> netdev needs filter and ingress hook and device parameter is mandatory.
> arp only supports input/output hooks.
>
> So you can see, that the most used type is filter.
> To order with chain gets triggered in which order is determined by the priority parameter.
> This can either be a signed integer (lower values have precedence) or standard priority names.
> These standard priority names are labeled to match xtables default values:
>
> raw := -300 (ip,ip6,inet) all hooks
> mangle := -150 (ip,ip6,inet) all hooks
> dstnat := -100 (ip,ip6,inet) prerouting
> filter := 0 (ip,ip6,inet,arp,netdev) all hooks
> security := 50 (ip,ip6,inet) all hooks
> srcnat := 100 (ip,ip6,inet) postrouting
>
> Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat
> You can also use addition/subtraction in your definitions.
> So their order is basically the same.
> All this information is well documented in nft(8)
>
> > Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet
>
> Should be updated to include the ``netdev'' family (for ingress handling)
>
> > My question is, since Nftables doesn't have predefined tables, just by naming a table:
> > "table inet raw", does it becomes a RAW table or not?
>
> It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or
> ip6 family packets.
>
> > If not, what do I have to do?
>
> You have to add at least one chain with the priority ``raw''.
> So to match iptables:
>
>     table inet raw {
>         chain PREROUTING {
>             type filter hook prerouting priority raw; policy accepted;
>         }
>
>         chain OUTPUT {
>             type filter hook output priority raw; policy accepted;
>         }
>     }
>
>
> Please note that ``policy accept'' is the default choice thus defining it here
> is just for better understanding.
>
> > For now I have added this to my nftables.conf
> > xxxxx
> > table inet raw {
> > chain prerouting {
> > type filter hook prerouting priority 0; policy accept;
> > ip saddr 123.0.0.0/8 counter drop
> > }
> > chain output {
> > type filter hook output priority 0; policy accept;
> > ip daddr 123.0.0.0/8 counter reject
> > }
> > }
> > xxxxx
>
> Please note a priority of 0 is equal to ``filter''.

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[sean darcy]

On 10/4/19 5:27 PM, Jags wrote:
> @Anton Rieger, thank you so much.
> 
> 
> 
> (1)
>> You have to add at least one chain with the priority ``raw''.
>> So to match iptables:
> 
> This is the answer I was looking for.
> 
> 
> Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this.
> 
> http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields
> 
> I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300"
> 
> 
> Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error:
> 
>  From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields
> 
> nft add chain raw prerouting {type filter hook prerouting priority -300\;}
> 
> While I think, what it should be (at least when run in Bash on Debian/Ubuntu):
> 
> nft add chain raw prerouting '{ type filter hook prerouting priority -300; }'
> 
> I figured this difference out a while ago from Arch wiki page:
> 
> https://wiki.archlinux.org/index.php/Nftables#Base_chain
> 
> 
> 
> (2)
> AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table:
> 
> table inet raw {
>          chain prerouting {
>                  type filter hook prerouting priority -300; policy accept;
>                  ip saddr 123.0.0.0/8 counter drop
>          }
>          chain output {
>                  type filter hook output priority -300; policy accept;
>                   ip daddr 123.0.0.0/8 counter reject
>          }
> }
> 
> 
> (3)
> Just before I read your mail, I found these pages:
> 
> (a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev
> 
> I found this very interesting: "This family provides the ingress hook,
> that allows you to classify packets that the driver has just passed up to the networking stack."
> 
> (b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
> 
> (c) "Mandatory to specify the device where the chain will be attached":
> https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains
> 
> So I have added this "devfilter" table:
> 
> 
> table netdev devfilter {
>          chain ingress {
>                  type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept;
>                  ip saddr 123.0.0.0/8 counter drop
>         }
> }
> 
> 
> Now I think with "netdev/ingress", there's no need for prerouting  within "raw" table,
> as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now.
> 
> 
> I truly thank you all...
> 
> 
> 
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 4, 2019 8:30 PM, Anton Rieger <rieger@jikken.de> wrote:
> 
>>> Could someone please clarify RAW/MANGLE tables in regards to Nftables.
>>
>> Short story short:
>> They doesn't exist anymore, but you can change priorities to simulate them.
>>
>> Long answer:
>> A table in nftables is identified by:
>> 1) Their name
>> 2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6)
>> Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''.
>> They need them, as these chains are entry points of packets from the network stack.
>> You can use these to reconstruct the predefined iptables chains by naming them the same.
>>
>> Each type is bound to certain families hooks:
>> filter) Standard type can be used everywhere.
>> nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks
>> Performs NAT based on conntrack entries.
>> Only first packet of a connection traverses this chain.
>> Specify conntrack details here.
>> route) Must be ip or ip6 and only provides the output hook.
>> If accepted and IP header changes a new route lookup is performed.
>> Use this to e.g. implement policy routing selectors.
>>
>> Quirks:
>> netdev needs filter and ingress hook and device parameter is mandatory.
>> arp only supports input/output hooks.
>>
>> So you can see, that the most used type is filter.
>> To order with chain gets triggered in which order is determined by the priority parameter.
>> This can either be a signed integer (lower values have precedence) or standard priority names.
>> These standard priority names are labeled to match xtables default values:
>>
>> raw := -300 (ip,ip6,inet) all hooks
>> mangle := -150 (ip,ip6,inet) all hooks
>> dstnat := -100 (ip,ip6,inet) prerouting
>> filter := 0 (ip,ip6,inet,arp,netdev) all hooks
>> security := 50 (ip,ip6,inet) all hooks
>> srcnat := 100 (ip,ip6,inet) postrouting
>>
>> Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat
>> You can also use addition/subtraction in your definitions.
>> So their order is basically the same.
>> All this information is well documented in nft(8)
>>
>>> Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet
>>
>> Should be updated to include the ``netdev'' family (for ingress handling)
>>
>>> My question is, since Nftables doesn't have predefined tables, just by naming a table:
>>> "table inet raw", does it becomes a RAW table or not?
>>
>> It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or
>> ip6 family packets.
>>
>>> If not, what do I have to do?
>>
>> You have to add at least one chain with the priority ``raw''.
>> So to match iptables:
>>
>>      table inet raw {
>>          chain PREROUTING {
>>              type filter hook prerouting priority raw; policy accepted;
>>          }
>>
>>          chain OUTPUT {
>>              type filter hook output priority raw; policy accepted;
>>          }
>>      }
>>
>>
>> Please note that ``policy accept'' is the default choice thus defining it here
>> is just for better understanding.
>>
>>> For now I have added this to my nftables.conf
>>> xxxxx
>>> table inet raw {
>>> chain prerouting {
>>> type filter hook prerouting priority 0; policy accept;
>>> ip saddr 123.0.0.0/8 counter drop
>>> }
>>> chain output {
>>> type filter hook output priority 0; policy accept;
>>> ip daddr 123.0.0.0/8 counter reject
>>> }
>>> }
>>> xxxxx
>>
>> Please note a priority of 0 is equal to ``filter''.
> 
> 
>

Or use netdev to drop the packets when they first show up at the interface:

table netdev netdev1 {
	chain ingress1 {
                 type filter hook ingress device etho priority 0 ;
                 ip saddr 123.0.0.0/8 counter drop
         }
}

Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10

[Jags]

@Sean

thank you.

> Or use netdev to drop the packets when they first show up at the interface:
>
> table netdev netdev1 {
> chain ingress1 {
> type filter hook ingress device etho priority 0 ;
> ip saddr 123.0.0.0/8 counter drop
> }
> }

As I've mentioned in the previous mail, now I have this in place:

xxxxx
table netdev devfilter {
    chain ingress {
    type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept;
    ip saddr 123.0.0.0/8 counter drop
    }
}

table inet raw {
    chain output {
    type filter hook output priority -300; policy accept;
    ip daddr 123.0.0.0/8 counter reject
    }
}
xxxxx





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, October 6, 2019 5:26 PM, sean darcy <seandarcy2@gmail.com> wrote:

> On 10/4/19 5:27 PM, Jags wrote:
>
> > @Anton Rieger, thank you so much.
> > (1)
> >
> > > You have to add at least one chain with the priority ``raw''.
> > > So to match iptables:
> >
> > This is the answer I was looking for.
> > Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this.
> > http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields
> > I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300"
> > Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error:
> > From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields
> > nft add chain raw prerouting {type filter hook prerouting priority -300\;}
> > While I think, what it should be (at least when run in Bash on Debian/Ubuntu):
> > nft add chain raw prerouting '{ type filter hook prerouting priority -300; }'
> > I figured this difference out a while ago from Arch wiki page:
> > https://wiki.archlinux.org/index.php/Nftables#Base_chain
> > (2)
> > AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table:
> > table inet raw {
> > chain prerouting {
> > type filter hook prerouting priority -300; policy accept;
> > ip saddr 123.0.0.0/8 counter drop
> > }
> > chain output {
> > type filter hook output priority -300; policy accept;
> > ip daddr 123.0.0.0/8 counter reject
> > }
> > }
> > (3)
> > Just before I read your mail, I found these pages:
> > (a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev
> > I found this very interesting: "This family provides the ingress hook,
> > that allows you to classify packets that the driver has just passed up to the networking stack."
> > (b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
> > (c) "Mandatory to specify the device where the chain will be attached":
> > https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains
> > So I have added this "devfilter" table:
> > table netdev devfilter {
> > chain ingress {
> > type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept;
> > ip saddr 123.0.0.0/8 counter drop
> > }
> > }
> > Now I think with "netdev/ingress", there's no need for prerouting within "raw" table,
> > as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now.
> > I truly thank you all...
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, October 4, 2019 8:30 PM, Anton Rieger rieger@jikken.de wrote:
> >
> > > > Could someone please clarify RAW/MANGLE tables in regards to Nftables.
> > >
> > > Short story short:
> > > They doesn't exist anymore, but you can change priorities to simulate them.
> > > Long answer:
> > > A table in nftables is identified by:
> > >
> > > 1.  Their name
> > > 2.  Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6)
> > >     Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''.
> > >     They need them, as these chains are entry points of packets from the network stack.
> > >     You can use these to reconstruct the predefined iptables chains by naming them the same.
> > >
> > >
> > > Each type is bound to certain families hooks:
> > > filter) Standard type can be used everywhere.
> > > nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks
> > > Performs NAT based on conntrack entries.
> > > Only first packet of a connection traverses this chain.
> > > Specify conntrack details here.
> > > route) Must be ip or ip6 and only provides the output hook.
> > > If accepted and IP header changes a new route lookup is performed.
> > > Use this to e.g. implement policy routing selectors.
> > > Quirks:
> > > netdev needs filter and ingress hook and device parameter is mandatory.
> > > arp only supports input/output hooks.
> > > So you can see, that the most used type is filter.
> > > To order with chain gets triggered in which order is determined by the priority parameter.
> > > This can either be a signed integer (lower values have precedence) or standard priority names.
> > > These standard priority names are labeled to match xtables default values:
> > > raw := -300 (ip,ip6,inet) all hooks
> > > mangle := -150 (ip,ip6,inet) all hooks
> > > dstnat := -100 (ip,ip6,inet) prerouting
> > > filter := 0 (ip,ip6,inet,arp,netdev) all hooks
> > > security := 50 (ip,ip6,inet) all hooks
> > > srcnat := 100 (ip,ip6,inet) postrouting
> > > Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat
> > > You can also use addition/subtraction in your definitions.
> > > So their order is basically the same.
> > > All this information is well documented in nft(8)
> > >
> > > > Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet
> > >
> > > Should be updated to include the ``netdev'' family (for ingress handling)
> > >
> > > > My question is, since Nftables doesn't have predefined tables, just by naming a table:
> > > > "table inet raw", does it becomes a RAW table or not?
> > >
> > > It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or
> > > ip6 family packets.
> > >
> > > > If not, what do I have to do?
> > >
> > > You have to add at least one chain with the priority ``raw''.
> > > So to match iptables:
> > >
> > >      table inet raw {
> > >          chain PREROUTING {
> > >              type filter hook prerouting priority raw; policy accepted;
> > >          }
> > >
> > >          chain OUTPUT {
> > >              type filter hook output priority raw; policy accepted;
> > >          }
> > >      }
> > >
> > >
> > > Please note that ``policy accept'' is the default choice thus defining it here
> > > is just for better understanding.
> > >
> > > > For now I have added this to my nftables.conf
> > > > xxxxx
> > > > table inet raw {
> > > > chain prerouting {
> > > > type filter hook prerouting priority 0; policy accept;
> > > > ip saddr 123.0.0.0/8 counter drop
> > > > }
> > > > chain output {
> > > > type filter hook output priority 0; policy accept;
> > > > ip daddr 123.0.0.0/8 counter reject
> > > > }
> > > > }
> > > > xxxxx
> > >
> > > Please note a priority of 0 is equal to ``filter''.
>
> Or use netdev to drop the packets when they first show up at the interface:
>
> table netdev netdev1 {
> chain ingress1 {
> type filter hook ingress device etho priority 0 ;
> ip saddr 123.0.0.0/8 counter drop
> }
> }