Re: ipset -R

[Mr Dash Four <mr.dash.four@googlemail.com>]

> What if:
>
> -m set ! --match-set $WHITELIST src -m set --match-set $BLACKLIST src -j DROP
>   
Yeah, never thought of that before, thanks, though this would increase 
processing time as I have to include that extra 'whitelist' non-match in 
every iptables '--match-set' statement I have where my blacklist sets 
are involved (and I have quite a lot of them!). It would be better if I 
just delete the whitelist members permanently once at the beginning and 
just forget about it (though as Jozsef hinted yesterday that may not 
work in 5.x and 6 any more - see below).

The second statement (in both of your posts) won't be needed as I simply 
propagate the resulting non-match throughout the ip chain (the packets 
therefore could be dropped for a variety of other reasons regardless of 
whether they belong to the 'whitelist' or not, which is what I wanted to 
have in a first place).

Jozsef, you mentioned yesterday that ipset 5.x (and I presume 6.0+ also) 
does not implement ip range 'readjustment' any more. If so, what happens 
when I list the set below:

ipset -F test
ipset -A test 10.1.1.0/24
ipset -D test 10.1.1.12
ipset -L test

> -m set --match-set $WHITELIST src -j ACCEPT
>   
That won't be needed as I simply want the packet to be propagated down 
the ip chain as normal (the packet could be dropped for other reasons 
and the fact that it belongs to the whitelist won't matter - its sole 
purpose is for punching holes in my blacklist, then it should be treated 
as any other packet).