FreePBX | Register | Issues | Wiki | Portal | Support

PBX Blocking Remote site again


(Edrick Smith) #1

So basically a month later exactly the system once again blocked this one site. A simple reboot allows it to register again. Other remote extensions are not affected.

So does anyone have ideas for what I can do to actually figure out what’s causing this?


(Franck Danard) #2

Just read the logs.
If the IP is blocked on your side, try to read iptables rules.
# iptables -L

Next.
Into Freepbx menu / System Admin / check Intrusion Detection.

For the other side:
Check Asterisk logs to find when the issue appeared and try to see if the ip is unreachable and why (wrong password, etc).

Just an idea like that.


(Tom Ray) #3

Is the remote location on a dynamic IP and you are using Responsive Firewall? Did the remote location lose connectivity due to any reason (power, ISP, etc)?

Remote locations that have multiple devices can trigger the Responsive Firewall or even iptables because it can be n requests from y ip address in x seconds and triggering the rate limiting.


(Edrick Smith) #4

There’s 3-4 extensions there on two devices. One is a SIP Phone with two extensions registered and one is a ATA adapter with 1 or 2 extensions registered. It is a dynamic address but hasn’t changed and has been whitelisted in firewall and system admin > intrusion detection.

But randomly at different points it will block all registrations from that IP still, even though the IP hasn’t changed. But it doesn’t show up in any of the gui locations that its been whitelisted in.

So perhaps IP Tables is blocking it for some reason? As it seems like it would need to be a system process vs. a FreePBX plugin as its been white listed in those locations.

Does a simple reboot of the machine clear out the IP table bans or is there another process that does?

There were no power issues, IP changes, it will just randomly start blocking sometimes a few times a week others once a month. It ran 2 - 3 months initially with no issue


(Itzik) #5

Curious. Why are you saying it’s ‘blocking’ when you don’t see it being blocked anywhere.

It could be your router killing SIP Sessions.

Did you look at the logs?


(Edrick Smith) #6

As I said the “fix” is to reboot the PBX not the router. The customer side router is not what is rejecting the traffic. As you said in the other post to check SIP ALG and it is not enabled also. Once rebooting the FreePBX the phones all re-register no problem. Nothing needs to be done to the router to get traffic flowing again, It is something on FreePBX. So again that is why I asked what “services” are simply cleared out by rebooting the FreePBX box? The problem is it’s so intermitent its hard to track down. As when it happened this most recent time they rebooted the box before I could look and see if there was any active attempts at that time. As soon as the box is rebooted the issue goes away.

I can use my SIP phone on my mobile along with there’s a singular desk phone at another site that works fine. So as was mentioned it seems to perhaps be something limiting the connection. But sometimes its only after a month, sometimes after a week, sometimes after a few days.

So it sounds perhaps its IPTables, if so im trying to better understand why it will be fine with the amount of connections for x period of time then all of the sudden start blocking it when nothing has changed at the remote site.


(Tom Ray) #7

So where is this IP being banned? Is it under the Firewall services or is it under Intrusion Detection? There are two things that are happening here.

If you are using Responsive Firewall you will have in iptables. These are the rate limiting rules. These are checked for each request hitting the machine.

Chain fpbxrfw (1 references)
target prot opt source destination
ACCEPT all – anywhere anywhere recent: CHECK seconds: 90 hit_count: 1 name: WHITELIST side: source mask: 255.255.255.255
all – anywhere anywhere recent: SET name: REPEAT side: source mask: 255.255.255.255
all – anywhere anywhere recent: SET name: DISCOVERED side: source mask: 255.255.255.255
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 10 hit_count: 50 name: REPEAT side: source mask: 255.255.255.255
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 86400 hit_count: 1 name: ATTACKER side: source mask: 255.255.255.255
fpbxshortblock all – anywhere anywhere recent: CHECK seconds: 60 hit_count: 10 name: SIGNALLING side: source mask: 255.255.255.255
all – anywhere anywhere recent: SET name: SIGNALLING side: source mask: 255.255.255.255
fpbxattacker all – anywhere anywhere recent: CHECK seconds: 86400 hit_count: 100 name: REPEAT side: source mask: 255.255.255.255
ACCEPT all – anywhere anywhere

Intrusion Detection, on the other hand, is Fail2Ban which means that it is checking logs for activity based on what you have set in Intrusion Detection. So you very well could be triggering that will how often it checks the log and how many results trigger it.

As for why does rebooting the PBX fix this problem, simple. Rebooting causes iptables to be flushed and thus clears your IP from being blocked.


(Edrick Smith) #8

That’s what I was trying to verify or at least point in a direction. So it sounds like an iptables based thing so I will have to check further in that direction and see what the logs are there and if I have the IP whitelisted there.


#9

Fail2ban at version less than 0.9

fail2ban-client -V

does not retain bans over a restart but the log line(s) that triggered inserting the rule into iptables would be logged as a ‘banned’ line in the fail2ban log. if its not there it was another iptables rule.


(system) closed #10

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