@thx2000 I wish I would have seen this earlier, but there’s another thread addressing this issue, and I submitted a pull request with similar fixes.
You are correct that the bug involved here is that once an IP passes through the whitelist once, it is never entitled to it again since it never leaves xt_recent WHITELIST list. And, the monitoring service will only grant whitelist status to a packet that attempts to authenticate with a password. When a dynamic IP changes, the device behind the NAT doesn’t know to reregister, and the Qualify keep-alive packets are hitting the rate limits. This has nothing to do with fail2ban.
The thread is here:
And pull request is here:
https://git.freepbx.org/projects/FREEPBX/repos/firewall/pull-requests/92/overview
We’ve added a whitelist that allows any IP 90 seconds to register, and once it does it is removed from the whitelist so that when it deregisters it will be entitled to it again.
The only unsolved issue with my prorpsed patch is that fail2ban is running and will bam devices that fail auth. While this isn’t the issue in this thread, I’m suggesting that once a registered device is on an IP, no blocking should occur on that IP. Imagine a site with 100 endpoints, and a sleepy sysadmin mistypes credentials on one phone, the entire site will DoS by fail2ban. This scenario is far more likely than a brute force attack coming from the same IP where there are legitimate users.
LMK what you think.