It would be nice if the blacklist and whitelist worked together such that the most specific entry takes precedence. I'd rather whitelist one IP address than remove a /16 subnet from the blacklist.

My precise usecase here is that I host a minecraft server on a LAN, this LAN is also connected via VPN to other friends LANs. its all one big LAN. This means all the IP addresses used are private addresses, in the 192.168./16, and 10./8 ranges. This works well for our servers we host, it does not work well with the blacklist in CC: Tweaked.

I would like to allow some addresses to be accessed by the http & websocket apis, we have some servers hosted on this LAN/VPN that users would like to connect to, in the mean time I've gone and removed both CIDR ranges from the blacklist because I trust my users, but I am ever security conscious and would prefer a precise whitelist.

I propose that the whitelist and blacklist takes the precedence of the most precise entry, whichever is most specific.

A whitelist of 10.0.0.1 should override a blacklist of 10./8, a whitelist of google.co.nz should override a blacklist of google.*, meanwhile a blacklist of google.co.nz/search should override the forementioned whitelist.

I'm aware this complicates what is a simple system at this stage, but it does make it far more useful.

If one goes this route, it feels like it'd be cleaner to explicitly list what's allowed/denied, rather than trying to determine what address is higher priority than what.

I'm somewhat thinking an iptables-esque list:

S:rules <
  DENY 127.0.0.0/8
  DENY 10.0.0.0/8
  DENY 172.16.0.0/12
  DENY 192.168.0.0/16
  DENY fd00::/8
  ALLOW *
>

This is more explicit and less magic, which always seems like a win. However, for simple configurations it's definitely harder to understand :/.

I actually think your solution is better, its one table instead of two, the rules are listed out in order, provided we document which order the precedence occurs (First match or last match) it may be a good improvement.

I also think we have some immunity to "complicated" here because the kind of users to modify a blacklist or whitelist have probably worked with this stuff before and are likely sufficiently experienced to get it correct.

I'm reading your example here as "First match", whichever entry matches first, wins. So for my example in the OP I would have

S:rules <
  ALLOW 192.168.0.27
  ALLOW 10.0.0.1
  DENY google.co.nz/search*
  ALLOW google.co.nz*
  DENY google.*
  DENY 127.0.0.0/8
  DENY 10.0.0.0/8
  DENY 172.16.0.0/12
  DENY 192.168.0.0/16
  DENY fd00::/8
  ALLOW *
>

As I understand the current whitelist/blacklist, blacklist is checked first, then whitelist is checked. Is this correct?

If so that means upgrading the config will be easy as copying the blacklist rows as DENY first, and then copying the whitelist rows as ALLOW second.