ipset not completely working in mangle:PREROUTING

ipset not completely working in mangle:PREROUTING

[imnozi]

iptables v1.8.7 (legacy)
ipset v6.34, protocol version: 6

I have four sets:
  - blockSetHost (hash:ip)
  - blockSetNet (hash:net)
  - whiteSetHost (hash:ip)
  - whiteSetNet (hash:net)

I added rules to match the block sets in filter to INPUT, FORWARD and OUTPUT. The rules match and jump to chain blDrop. In blDrop, if either white set matches, control returns. If no match, the packet is dropped.

This works well in filter. But there's one artifact. The blocked packets are 'accounted' to the internal server where they would have gone.

To fix this, I added the rules below to mangle. Here in mangle, the white sets never match and all of the packets (that matched the block sets) are dropped.

Is this another instance of 'it doesn't work in mangle or in PREROUTING'?

Thanks,
Neal

----
The rules used in mangle; eth3 is internet:
-A blDrop -m set --match-set whiteSetNet src -j RETURN
-A blDrop -m set --match-set whiteSetHost src -j RETURN
-A blDrop -j DROP

-A PREROUTING -i eth3 -p udp -m set --match-set blockSetHost src -m state --state NEW -j blDrop
-A PREROUTING -i eth3 -p tcp -m set --match-set blockSetHost src -m state --state NEW -j blDrop
-A PREROUTING -i eth3 -p udp -m set --match-set blockSetNet src -m state --state NEW -j blDrop
-A PREROUTING -i eth3 -p tcp -m set --match-set blockSetNet src -m state --state NEW -j blDrop

Re: ipset not completely working in mangle:PREROUTING

[Kerin Millar]

On Tue, 26 May 2026, at 1:57 AM, imnozi@gmail.com wrote:
> iptables v1.8.7 (legacy)
> ipset v6.34, protocol version: 6
>
> I have four sets:
>   - blockSetHost (hash:ip)
>   - blockSetNet (hash:net)
>   - whiteSetHost (hash:ip)
>   - whiteSetNet (hash:net)
>
> I added rules to match the block sets in filter to INPUT, FORWARD and 
> OUTPUT. The rules match and jump to chain blDrop. In blDrop, if either 
> white set matches, control returns. If no match, the packet is dropped.
>
> This works well in filter. But there's one artifact. The blocked 
> packets are 'accounted' to the internal server where they would have 
> gone.

The meaning of this isn't altogether clear. I presume that you are referring to counters in some capacity.

>
> To fix this, I added the rules below to mangle. Here in mangle, the 
> white sets never match and all of the packets (that matched the block 
> sets) are dropped.

Be sure that you need to match on the NEW state. Otherwise, -t raw -A PREROUTING makes for a less expensive way of dropping ingress packets at the border.

>
> Is this another instance of 'it doesn't work in mangle or in PREROUTING'?

This is unlikely. Both -m set and -m state work in the same way across tables, though the raw table precludes matching on conntrack state.

>
> Thanks,
> Neal
>
> ----
> The rules used in mangle; eth3 is internet:
> -A blDrop -m set --match-set whiteSetNet src -j RETURN
> -A blDrop -m set --match-set whiteSetHost src -j RETURN
> -A blDrop -j DROP
>
> -A PREROUTING -i eth3 -p udp -m set --match-set blockSetHost src -m 
> state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetHost src -m 
> state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p udp -m set --match-set blockSetNet src -m 
> state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetNet src -m 
> state --state NEW -j blDrop

An iptables-save -c dump would be preferable. These excerpts don't unambiguously qualify the containing table names. In particular, there is no way for the reader to determine whether the chain named "blDrop" in whatever table that may be is acting in the same way as the chain named "blDrop" that may still exist - or have once existed - in another table.

-- 
Kerin Millar

Re: ipset not completely working in mangle:PREROUTING

[imnozi]

On Tue, 26 May 2026 02:57:38 +0100
"Kerin Millar" <kfm@plushkava.net> wrote:

> On Tue, 26 May 2026, at 1:57 AM, imnozi@gmail.com wrote:
> > iptables v1.8.7 (legacy)
> > ipset v6.34, protocol version: 6
> >
> > I have four sets:
> >   - blockSetHost (hash:ip)
> >   - blockSetNet (hash:net)
> >   - whiteSetHost (hash:ip)
> >   - whiteSetNet (hash:net)
> >
> > I added rules to match the block sets in filter to INPUT, FORWARD and 
> > OUTPUT. The rules match and jump to chain blDrop. In blDrop, if either 
> > white set matches, control returns. If no match, the packet is dropped.
> >
> > This works well in filter. But there's one artifact. The blocked 
> > packets are 'accounted' to the internal server where they would have 
> > gone.  
> 
> The meaning of this isn't altogether clear. I presume that you are referring to counters in some capacity.

'In some capacity', yes; setting connmarks to identify types of traffic, then using those marks and '-j ACCOUNT' with specific tnames lets us have a nice CGI page with bar meters that cleanly displays various traffic levels, and other 'reports'.

> 
> >
> > To fix this, I added the rules below to mangle. Here in mangle, the 
> > white sets never match and all of the packets (that matched the block 
> > sets) are dropped.  
> 
> Be sure that you need to match on the NEW state. Otherwise, -t raw -A PREROUTING makes for a less expensive way of dropping ingress packets at the border.

I've been matching only NEW packets, letting ESTABLISHED conns close themselves. Later I might add rules to catch ESTABLISHED packets that match the block list but not the white list, then hit TCP packets with tcp-reset and all others (blocked) with icmp-admin-prohibited. (This method does work well to shut down conns instantly: "None shall pass.")

> 
> >
> > Is this another instance of 'it doesn't work in mangle or in PREROUTING'?  
> 
> This is unlikely. Both -m set and -m state work in the same way across tables, though the raw table precludes matching on conntrack state.

OK. So ipset *should* work in mangle:PREROUTING. Can the same chain name be used simultaneously in multiple tables (though if not, the pre-defined chains shouldn't work)? I'll experiment some more; I'll even try specifying state NEW in blDrop even though only NEW packets get there. I've been blind to mistakes before.

> 
> >
> > Thanks,
> > Neal
> >
> > ----
> > The rules used in mangle; eth3 is internet:
> > -A blDrop -m set --match-set whiteSetNet src -j RETURN
> > -A blDrop -m set --match-set whiteSetHost src -j RETURN
> > -A blDrop -j DROP
> >
> > -A PREROUTING -i eth3 -p udp -m set --match-set blockSetHost src -m 
> > state --state NEW -j blDrop
> > -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetHost src -m 
> > state --state NEW -j blDrop
> > -A PREROUTING -i eth3 -p udp -m set --match-set blockSetNet src -m 
> > state --state NEW -j blDrop
> > -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetNet src -m 
> > state --state NEW -j blDrop  
> 
> An iptables-save -c dump would be preferable. These excerpts don't unambiguously qualify the containing table names. In particular, there is no way for the reader to determine whether the chain named "blDrop" in whatever table that may be is acting in the same way as the chain named "blDrop" that may still exist - or have once existed - in another table.
> 

Those four rules in mangle:PREROUTING are the only ones that send packets to mangle:blDrop which contains the same rules as filter:blDrop.

I logged into my external VPS and ssh'ed back; this worked. I exited that session, added that IP to both the white list and the block list and tried to SSH back again. Neither counter on the white list checks increased, but the DROP counter did increase and the SSH connection was blocked. I then removed those rules and the chain from mangle:PREROUTING and did the same again, this time watching the counters in filter:blDrop. This time one of the white list counters did increase and the connection went through. At first glance, it looks like the set match didn't work in mangle:blDrop.

Again, I'll experiment some more; maybe I missed a special incantation or chanted it at the wrong cadence. :)

If you want, I'll send you a complete 'iptables-save -c'; it's about 800 lines. Unless you want I should pare it down some more. 

Thanks,
Neal

Re: ipset not completely working in mangle:PREROUTING

[Jozsef Kadlecsik]

Hi,

On Mon, 25 May 2026, imnozi@gmail.com wrote:

> On Tue, 26 May 2026 02:57:38 +0100
> "Kerin Millar" <kfm@plushkava.net> wrote:
>
>> On Tue, 26 May 2026, at 1:57 AM, imnozi@gmail.com wrote:
>>> iptables v1.8.7 (legacy)
>>> ipset v6.34, protocol version: 6

That's pretty old. Still it has no effect on the subject.

> OK. So ipset *should* work in mangle:PREROUTING.

Yes, but please note: if some data it should match on is missing at that 
stage/chain (like incoming-outgoing interface), then it "won't work".

> Can the same chain name be used simultaneously in multiple tables 
> (though if not, the pre-defined chains shouldn't work)?

No, all tables are independent of each other, including the predefined 
chains.

Best regards,
Jozsef

Re: ipset not completely working in mangle:PREROUTING

[Slavko]

Dňa 26. 5. o 9:51 Jozsef Kadlecsik napísal(a):
>>> On Tue, 26 May 2026, at 1:57 AM, imnozi@gmail.com wrote:
>>>> iptables v1.8.7 (legacy)
>>>> ipset v6.34, protocol version: 6
> 
> That's pretty old. Still it has no effect on the subject.

I have even older ipset/iptables (v6.32/v1.4.21) on my router and it 
works as expected in manlge's PREROUTING chain:

   16M  975M drlst_drop  all  --  *      *       0.0.0.0/0  0.0.0.0/0 
match-set droplst src

That is only excerpt, it is after accept of ESTABLISHED,RELATED and in 
chain based on input interface...

regards

-- 
Slavko
https://www.slavino.sk/

Re: ipset not completely working in mangle:PREROUTING

[imnozi]

OUT! OUT, demons of stupidity! Or to use a slightly more modern saw, artificial intelligence is no match for natural stupidity.

It works much better when I also add the VPS IP to the *whitelist*!

Sorry about the noise. Sigh.

Thanks,
Neal


On Mon, 25 May 2026 20:57:36 -0400
<imnozi@gmail.com> wrote:

> iptables v1.8.7 (legacy)
> ipset v6.34, protocol version: 6
> 
> I have four sets:
>   - blockSetHost (hash:ip)
>   - blockSetNet (hash:net)
>   - whiteSetHost (hash:ip)
>   - whiteSetNet (hash:net)
> 
> I added rules to match the block sets in filter to INPUT, FORWARD and OUTPUT. The rules match and jump to chain blDrop. In blDrop, if either white set matches, control returns. If no match, the packet is dropped.
> 
> This works well in filter. But there's one artifact. The blocked packets are 'accounted' to the internal server where they would have gone.
> 
> To fix this, I added the rules below to mangle. Here in mangle, the white sets never match and all of the packets (that matched the block sets) are dropped.
> 
> Is this another instance of 'it doesn't work in mangle or in PREROUTING'?
> 
> Thanks,
> Neal
> 
> ----
> The rules used in mangle; eth3 is internet:
> -A blDrop -m set --match-set whiteSetNet src -j RETURN
> -A blDrop -m set --match-set whiteSetHost src -j RETURN
> -A blDrop -j DROP
> 
> -A PREROUTING -i eth3 -p udp -m set --match-set blockSetHost src -m state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetHost src -m state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p udp -m set --match-set blockSetNet src -m state --state NEW -j blDrop
> -A PREROUTING -i eth3 -p tcp -m set --match-set blockSetNet src -m state --state NEW -j blDrop