Fri Jul 4 19:01:27 2025 user.info banIP-1.5.6-r1[30546]: add IP '103.176.78.178' (expiry: 1h) to blocklist.v4 set
Fri Jul 4 19:01:29 2025 user.info banIP-1.5.6-r1[30546]: add IP range '0.0.0.0/0' (source: ID, IDNIC ::: expiry: 1h) to blocklist.v4 set
Saw this in my logs, can this be prevented to that 0.0.0.0/0 gets added?
With banIP 1.5.6-r6, I’ve noticed that automatic IP address banning based on Log Terms no longer works. I also tried adjusting the Log Count to 1 (and other values like 2, 3, 4, etc.), but it still didn’t take effect. The last entry in /etc/banip/banip.blocklist was added on 2025-06-24.
Tried looking for answers online/docs but couldn't so asking here:
Can banip support wildcards for website names, like *.website.com or similar instead of exact website url/name?
Can banip be applied to only specific IPs within the LAN? or it blocks for ALL users of the network? it would be very useful to be able to block a TV or other device, but all else is unfiltered..
Does anybody know if banIP handles NAT64 for instance with ASN based blocking? For example if it would block 192.0.2.0/24 additionally there would need to be a block for 64:ff9b::192.0.2.0/120 in case the default NAT64 prefix is used. Is this supported?
Thanks so much for that tip!!! sorry if this is off-topic for banIP plugin two more related questions:
in the screenshot u uploaded, 3 examples each saying different thing, are these effectively the same ?
"Returns 0.0.0.0" , "Returns NULL" and "Returns NXDOMAIN" ? or each one is handled differently from client/server ? I suspect these are all same, just referred to differently..
same as original 2nd question, can such filtering be applied to only specific IPs within the LAN? say a TV or kids PC will be blocked more than other devices on same network.
oh, wait, regarding #1, maybe the trailing "/#" returns 0.0.0.0 (which is similar to Null) but without the "#" at end, it returns NXDOMAIN.. will play a bit, thanks
The address 192.0.2.1 is meant for examples. Using different separators is generally supported in tools, but it's not really important what kind of notation is used as my question doesn't relate to directly adding addresses. Try for instance ping 64:ff9b::192.0.2.1 and you'll see it automatically maps it to 64:ff9b::c000:201. My example uses 64:ff9b:: as it's the default NAT64 prefix.
With jool, 192.0.2.1 would actually become 64:ff9b::192.0.2.1 or 64:ff9b::c000:201 with the default configuration. I'm not sure where 2002:c000:201:: comes from, I haven't seen such addresses from jool.
My question was related to ASN based blocking though. I imagine that based on an ASN, banIP generates a large list of both IPv4 and IPv6 subnets for blocking. In case a connection is using NAT64, the corresponding IPv6-mapped addresses for the IPv4 subnets would need to be added to the blocklist for it to work. For this banIP needs to be aware of the NAT64-prefix that's in use and generate corresponding IPv6 subnets. If 192.0.2.0/24 would be blocked, also 64:ff9b::192.0.2.0/120 or 64:ff9b::c000:200/120 would need to be blocked. If anybody knows whether such feature is there, I'd be curious to learn!
That was my thought. Because the latter one can be read/used by banip. It can be used to create nft rules directly too. You just mentioned 64:ff9b::192.0.2.1 which would not work.
This was just an example for translation generally. In the end its c000:201 what is relevant here. The "prefix" is not. The 2002 is a spcial case here for 6to4 over the internet.
BanIP should block the address 64:ff9b::c000:200. Just try it. It should block 64:ff9b::c000:200/120 also. While 64:ff9b::192.0.2.1 should not work. What I tried to tell you.
Why should banip apply this automatically? I'm not aware that such a feature exists here. It would be a waste of ressources. Most ppl. do not deal with NAT64. But maybe the DEV's are open if you would contribute such an add-on feature.
Null / 0.0.0.0 are one in the same. DNS lookups will return 0.0.0.0 as the IP address, effectively resulting in your network clients not connecting to the actual FQDN / IP.
DNS lookup of FQDNs that are NXDOMAIN will treat it as if the domain is invalid. Again, the end result is that your clients will not connect to anything. Also, in the system log you will see an NXDOMAIN result in the entry for the DNS lookup.
(Note: to mitigate the risk of your users changing to alternate DNS servers to circumvent this, you will need to lock down your network to not allow use of external / 3rd party DNS servers. )
If you only have one instance of DNSMASQ running, then the lookup results would be identical globally for all clients on your network using your router for DNS queries.
Technically, you could run a second instance of DNSMASQ on the router and have it listening on an alternate port (or even interface) - then set the clients you want excepted from the DNS filtering to use the 2nd instance.
Here is a post discussing the topic. Help with dnsmasq instances
BTW, unlike BanIP, the connection isn't being blocked - it just isn't occurring because no valid address will be returned for the DNS lookup of the domain / subdomain, etc.