Responsive Firewall Blocking Legitimate SIP Registrations

We received 19 separate support tickets over the past 24 hours for customers whose endpoints were no longer registered to their system. In many cases, they were extensions that were not part of the main office and were located at home / remote locations. Investigations found that the IPs had been added to the blocked list in the FreePBX Firewall. We were able to remove them from the blocked list and manually whitelist the IP, which allowed registration. However, responsive firewall was enabled for CHAN_SIP and these same endpoints have been successfully registering from dynamic IP addresses previously.

Affected systems are running 10.13.66-13 to 10.13.66-20 and are located in two of our datacenters.

All logs were searched for entries matching the IPs in question and all we could find were informational messages regarding Challenge Succesful and succesful registration messages.

As a short term solution, we’ve had to assign CHAN_SIP to allow registrations from anywhere in the External zone, as we have numerous clients with dynamic IPs and cannot risk any more incidents.

Has anyone else experienced recent issues with Responsive Firewall acting in this manner?

This has been reported before, and the prevailing wisdom was that the phones are logging in too many times per hour (I think it was per hour) and tripping the hacking flag.

There have been several discussions about this, along with several suggestions for different settings that can make your life easier.

The route you’ve chosen is OK until the dynamic addresses change. If you want to continue on that route, consider adding Dynamic DNS to your remote clients. This will help your white listing.

A better solution would be to look at what’s causing the client phones to lagged and/or log off. Asterisk doesn’t like having to reconnect phones all the time and the Adaptive Firewall reflects that.

There are also “Qualify” (IIRC) settings that might help. Resetting the QUALIFY setting to check more often can keep the phones connected and keep the routes through the router open.

Hi Dave,

Thanks for your timely and thorough response.

I will proceed with enabling Dynamic DNS wherever possible. For those cases where it is not possible and the user has an IP address that changes frequently, we will have to keep the Chan_Sip port publicly exposed.

We use a combination of VoIPMonitor and Homer to monitor our infrastructure and are able to capture registration attempts. I also combed through the logs for two affected systems and did not find any excessive lagged or “unreachable” instances. At the time of the incident, the endpoints simply became unreachable and there was no entry in the fail2ban log indicating a reason.

What I find particularly unusual is that this problem manifested all at once, across a good number of systems in multiple sites, when we had only seen it once or twice over the last 12 months. It causes me to wonder what might have changed in such a short time.