Responsive Firewall blocking Trusted Networks

I’m having an issue with the Responsive Firewall for one of my FreePBX installations. I have found that for this installation, IP Addresses placed in either the “Local” or “Trusted” zones are being blocked by the Responsive Firewall as “attackers”, causing all of the SIP endpoints at these locations to go offline.

I have not been able to ascertain exactly why; as I’ve been unable to locate a log file specifically for what is an “attacker”; nor have I been able to find a single reference to any login failures, etc in the asterisk log.

As far as I can tell, it’s marking these as “attackers” due to normal traffic. Further, IP Addresses in the “Local” or “Trusted” zones should not be checked for this behavior.

Any suggestions?

This sounds like more of the equivalent of “Fail2Ban” getting angry with the way your devices are interacting with the server. Logs would help…

No, it was not fail2ban; that’s under “Intrusion Detection” and is managed differently.

Fail2Ban does not enter items into the “Responsive Firewall” blocked hosts, and the firewall blocked hosts does not enter items into the ‘Intrusion Detection’ list.

They are completely independent.

I couldn’t agree more, but if you’ll read my post you’d see that I can’t find any logs referencing any problem at all, nor can I find any logs for the “Responsive Firewall” to see what it’s doing. I’d be happy to find them if somebody could point me at the documentation; but as far as I can tell, there isn’t any documentation that indicates where (or even if) this information is available.

1 Like

I’m pretty sure I was clear it wasn’t fail2ban, but that’s splitting hairs.

Just so we’re both clear I understand how the system works:

There are three security pieces in the system that all balance on the same pinhead of allowing the right traffic and blocking the wrong traffic. These are the Responsive Firewall (which only manages select SIP, PJ-SIP, and IAX traffic), the System Admin Intrusion Detection controls, and the Integrated Firewall in the PBX.

The Integrated Firewall is the “master gatekeeper” (if enabled) and allows traffic from various sources, including your Local and Trusted networks and certain ports open to the world. The Responsive Firewall, if enabled, will take over the management of SIP, PJ-SIP, and IAX traffic, allowing or blocking traffic from untrusted networks based on “Fail2Ban-like” heuristics. Below all of these are Intrusion Detection, which also uses “fail2ban-like” processes and only deals with the traffic that actually makes it through the Integrated firewall and onto the execution platform.

If machines in your trusted network are doing things that cause them to get blocked in Intrusion Detection, your choices are bicameral - you can deal with it through automation by fully utilizing the Intrusion Detection options (whitelisting, blacklisting, manually modifying triggers and indicators, etc.) or you can do it through administration (find out who’s phone/desktop/kid is failing passwords enough times to trip an intrusion alert and tell them to stop).

Each of these pieces has every step logged. Some (like ID) use several logs as their source document and log their actions in one of the files in /var/log (I don’t remember which one). Others (like RF) will report their actions into one of the logs (asterisk/full, IIRC for RF).

I’m not sure which log the information you need is dropped into, but all of the logs for this should be in the directory /var/log. I know there are several security logs in there - which one? I’m not sure, but one of them is logging the traffic that is tripping intrusion detection.

Sorry no, not clear at all. Your post read as “I think it’s fail2ban causing the problem”.

It’s not “fail2ban-like”, it is fail2ban :wink:

As I stated in the OP, nothing is being blocked in ID/fail2ban, it’s only showing up in Responsive Firewall/Blocked Hosts. The two lists are completely independent in the UI and Firewall.

I have, of course, reviewed all of those logs. Not one. single. error. No timeouts. No failed authentication. Nothing.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.