I have been working towards a log-then-block approach to my backbone as opposed to a common block but don’t log approach. Among other reasons, a goal of this approach is to inform customers, potentially with an opt-in system or in response to complaints the Internet isn’t working right or working at all from their perspective when they likely have something doing something they have not and would not approve of often perhaps from illegally hacked devices.
For example, attempting to access private IP space. A while back I got into a discussion about how if someone could convince others that using 0.0.0.0/32 as a default for an allowed address in an allow access rule was not wise because I could even with my limited skills setup a network where I could use 0.0.0.0/32 on a device and if I did that might based on what I was observing but didn’t full test allow access where someone might think they are not allowing any access at all because they had 0.0.0/0/32 set as the only allow access IP which is the default and was claimed disabled IPv4 access. I left that on the table.
However, I am observing a possibility that PMP gear is blocking attempts to access 0.0.0.0/32 at least with ICMP because the rules I have which I’m pretty sure should be detecting, logging, then blocking are not showing that it is leaving PMP devices even though the NAT Translation Table clearly shows attempts from the customer end either by their router or other devices on their network to use ICMP and communicate with 0.0.0.0/32.
I certainly can and will review my setup. However, it is my understanding that my CPE devices should not be blocking attempts where customer devices are trying to communicate with 0.0.0.0/32 and it appears they are. And, if so, not having that traffic pass where I can detect it, log it, and only then block it in that way able to let my customer know what I observed is making it more difficult for me to automate collecting and sharing that information with concerned customers.
Ideas?