I have deployed dozens of FreePBXs in the last 4-5 years, versions 13,14 now 15 and responsive firewall has never worked properly for me. All PBXs are on a static IP address and no physical firewalls in between the PBX and the remote user. For the remote phones to work I always have to add the end user public IP or the remote subnet in the Firewall>Networks tab otherwise their phone will never get registered. This has been a real problem for me especially for remote users with dynamic IP address from their Internet providers. As long as their IP does not change their phones are fine. As soon as that IP changes for them, their phone gets locked out of the PBX. What am I missing here? Besides this problem (and Zulu never works too) FreePBX has been an awesome platform for me. Even with the Responsive Firewall not working right I still wont replace FreePBX for anything in the world. My workaround for the dynamic IP client side is to setup VPN routers to the end users and register the phones tru the VPN tunnel.
Exact same problem here, but its not consistent, sometimes its fine for a few days then it blocks them again and they have to be removed from connectivity â firewall â status â blocked hosts. No block reason seems to appear in the logs as far as I can tell.
Right now i have a known good user blocked and the logs show:
OUT >>> [2021-01-08 02:28:43] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-07 15:43:16] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-07 15:40:19] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-05 10:22:57] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-05 10:22:22] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-05 08:35:41] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-05 08:33:39] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-04 21:04:24] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-04 21:01:28] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-04 12:24:07] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-04 12:21:57] - /sbin/iptables -w5 -W10000 -D fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-02 13:56:27] - /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XX.XXX.XX.XXX/32 -j fpbxknownreg
OUT >>> [2021-01-02 13:55:53] - Firewall-Monitoring - XX.XXX.XX.XXX reported as good, adding to whitelist.
I am the same problem here as well. Luckily for me I only have a few users with remote phones so I have memorized their WAN IP address. once their WAN IP changes I will have memorize another set of IPs.
At random time, a valid (registered phone) IP will get blacklisted after X period. Even worse, some customers with a fixed IP will also get blocked, even if their IP is whitelisted. I could never find out why.
Perhaps one of the more experienced amongst the folks on the thread could check for an open ticket in Jira and, if there isnât one, create one. Then all of you could provide data and the team can get to the bottom of it. They donât follow the forums as closely as us âmere mortalsâ do, so they might not be seeing the issue.
If the Responsive Firewall worked correctly and reliably I would have deployed mobile clients for all my remote users long time ago. Thats their most requested feature. But there is no way for a mobile app to work well when the mobile phone is bouncing from tower to tower also changing IPs constantly and the firewal blocking all new IP even tho the client has the correct creds. Heck, I even tested the the official Zulu mobile app and after a long setup (including CLI) it never worked good. In the mean time RingCentral is killing my client base with these âfeaturesâ they offer clientsâŚespecially for remote users. We are years behind on some of this stuff.
I spent some time looking around at how this works - thereâs a monitoring PHP process that spawns itâs own thread to monitor Asterisk AMI for âsomethingâ, but I donât know what that something is.
Then there are several iptables chains that exists, called things like ATTACKER, CLAMPED, REPEAT, and SIGNALLING. These names are all self-explanitory.
The PHP code that calls to block or allow is around here.
My PHP skills arenât good enough to read that list of arrays - Iâm not sure where the logic is in that code to make any âif-thenâ logic, other than just to keep redefining the same array. The one thing I realized though, is that the hard coded times and hit counters can be modified to values that are less strict.
The line that appears to be doing the deleting of the âgoodâ rules is this one.
And lastly, there seems to be the option to have more verbose debugging if the file âfirewall.debugâ exists (as per this line). However, I tried it and the file is still blank, even with chown to asterisk:asterisk.
I, like all the rest of you, have had consistent issues with responsive firewall randomly blocking valid clients with no logging as to why it happened. I think I will try to modify the code, that once an IP is valid, it doesnât get purged from the list for 1 week (from my basic reading, it only persists for either 90 seconds or 5 minutes)
Are these single device locations? Ive seen issues where multiple devices can trigger limits since it all comes from the same IP.
Example, 8 valid accounts all send REGISTERs in a single minute. That would violate the 6 per minute rule.
Edit: Remember it is not about the account being valid it is about the activity from the IP. If someone hacked an account and was sending 10 calls a minute to high cost areas, youâll be praising the firewall blocked the bad actor IP and stopped calls.
Interesting point, I need to research that. But perhaps the way we expect this to work is that once a successful registration takes place, as long as ANY DEVICE still has an active registration from that IP then the IP should not blacklist. Ever, period. The threat of an attack coming from an authorized IP is so miniscule that itâs obviously worth the risk to leave it open than to close it and disconnect an entire site because of one misconfigured device or a flood of packets.
But regardless, weâre also all seeing that even Trusted Networks end up blacklisted as well. From looking at the code I referenced above, I believe there is a race condition somewhere, I just havenât found it yet.
Well in your scenario anything that auths correctly would be a âtrusted IPâ. Which is fine but in my example was about an account being compromised. So a bad actor gets SIP creds, auths and gets marked as a âtrustedâ IP and therefore can now make calls with no limits. You are then boned.
Also remember registrations have absolutely nothing to do with making calls. It tells the PBX where to send things. INVITEs are auth each time and if it passes that it also gets marked as a trusted IP. So there is a chance you never really see them registering once they validate they can auth.
