@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@xxxxxxxxxxxxxxx> 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.
