Whitelist doesn`t work with lan IP’s

Hello @hatto,

You have encountered a strict architectural security feature of the plugin, but we completely understand your Docker use-case.

By design, web application firewalls are built to protect against public internet threats. To prevent attackers from attempting “IP Spoofing” by forging internal IP headers, the Advanced IP Blocker engine categorically rejects Private/LAN IPs (like 172.16.x.x, 192.168.x.x, 10.x.x.x) from the active Whitelist processor at the very first layer of execution. This is why clicking “Unblock” or manually adding the Docker subnet doesn’t work—the engine intentionally drops private IPs from standard evaluation.

However, since Docker environments heavily rely on internal container-to-container API communication (especially with WooCommerce), we understand you need a bypass.

Immediate Solutions for your Docker Container:

1. Advanced Rules Engine (Recommended): Instead of using the standard Whitelist, you can create a custom rule that acts before the blocklist engine kicks in.
   • Go to Security > Advanced Rules.
   • Create a Rule named “Allow Docker LAN”
   • Condition: IP Range Is 172.16.0.0/12
   • Action: Allow (This tells the plugin to fully trust and bypass checks for this Docker subnet).
2. Trusted Proxies (If the container acts as a reverse proxy): If that 172.16.0.2 IP belongs to an Nginx/Traefik Docker container serving as a proxy for the outside world, you must go to Security > Settings > IP Detection and add 172.16.0.2 to the “Trusted Proxies” text area. This will instruct the plugin to look past the Docker LAN IP and correctly identify and log the external public IPs.

Note: In our next update, we will consider relaxing the strict FILTER_FLAG_NO_PRIV_RANGE check specifically on the manual Whitelist to better support modern containerized CI/CD and API workflows out of the box.