When you say UDP timeouts have been increased to mitigate those issues the problem is that FreePBX does not have control over the UDP timeouts on the intermediate translator routers. There is really nothing that can be done outside of that other than the freepbx server and the phone being configured to just hammer the heck out of each other sending vast quantities of keepalives. But that also assumes that the router or routers in between aren’t doing something stupid. My testing has shown that maintaining a VoIP phone registration through every translating router I have tested with including Cisco’s enterprise code, is a tremendous carpshoot.
I myself run a softphone on my laptop and use it from coffee shops, etc. when I am on the road so I am no stranger to this. Sometimes I can leave the softphone going for an hour or two. Other times I have to close and reopen the softphone program to make a call every time. You are welcome to try to solve this problem with theory but I think you are wasting your time and for the amount of trouble you will go through tuning that prefect setup, a VPN could have been setup with a lot less trouble.
If you read my post above, you’ll see that the Responsive Firewall is also blocking remote IPs connected via site to site VPNs (no NAT or PAT), so going to the trouble of setting up VPNs won’t fix the root issue.
How could that be? Every VPN gear I have ever worked with uses a subnet of private IP addresses for the remotes that is routable and known to the VPN concentrator, and never changes. So if you cut 192.168.100.0/24 for your VPN server to use to assign remotes, that would be added into the list of private subnets in the FreePBX configuration and exempted from the firewall.
Surely you don’t allow the firewall to block your private subnets? Because if you do I think you don’t understand the purpose of the firewall. The firewall exists for when people port forward outside IP addresses to an inside IP address on your FreePBX system. It detects when malevolent people on the outside are repeatedly trying to guess authentication credentials. If you have a malevolent player on the INSIDE that is trying to guess credentials then your security is already compromised and the FreePBX firewall just gives a false sense of security.
You are aware that FreePBX has a spot in the configuration specifically for you to list all your private inside subnets, aren’t you? Perhaps you are not?
I’m not going to spend time explaining site to site VPNs. DHCP is not involved, though. It’s straight routing.
And the point is that we should not have to whitelist IPs like this; the responsive firewall should NOT be blocking them. And it is. Across a half-dozen installs right now.
Silly question, but for your sites connected via VPN, do you have the INTERFACE they connect on trusted in the Sangoma Firewall? You still have to do that regardless if they’re VPN, public IP, etc., or whitelist the VPN subnets
Not until today, and it had been fine for months like that; with the Responsive Firewall not getting in the way.
Today I found the IP of the remote phone blocked. I unblocked and whitelisted the remote subnet.
So it will work, and this isn’t how it’s supposed to work, and it’s an enormous problem for one-off phones connecting over the internet from locations with dynamic public IPs. Every day we’re having to update IPs in the whitelists.
The firewall is intended to protect from dynamic endpoints, from phones logging in from untrusted networks where there is no consistency in the IP assignments. It is useless if the FreePBX server NEVER has to allow for outside incoming SIP from the Internet. If you are an admin of a FreePBX system that doesn’t have to expose it to incoming VoIP calls from the outside you WOULDN’T. You would just turn off the firewall completely since it’s unnecessary and make sure there’s no port forwarding to it.
You have a network where all your phones are coming in from known subnets that you assigned. You therefore have a solution in front of you that would take 10 minutes to implement and you would be done with it and you could go on to other things - and that solution is add all your trusted subnets to the list of trusted subnets so the firewall ignores them.
I don’t completely understand your complaint. On one post you say all your phones are coming in from VPNs. In another you say you also have problems from phones coming in from dynamically assigned public IP addresses.
As I said, there are problems with running extensions over the Internet not inside a VPN that are more than just the firewall acting up. The firewall is a poor substitute, a last ditch attempt to make a horrible situation better. Unless your remote phones are all encrypting their calls, your VoIP going over the public internet can easily be evesdropped there’s some fun videos on YouTube that show how to use Cain and Able to do it. Lots of phones out there have very poor password control they won’t allow passwords longer than 8 characters, and many admins use poor passwords anyway. So why fight against use of a VPN? You can, for free, setup an OpenVPN server, run OpenVPN clients on your single dynamic hosts and softphones on those machines. That solves the firewall issue as well as protects your calls as well as fixes any timeout issues.
I have news for you we got another 10 months to go before a vaccine is going to be widely available. Until then you are going to have a lot of folks at home. If you are going to have your security with it’s back door hanging wide open for a year, your gonna get gunned. You are acting like this business is “just a few months and we can go back to normal” and this remote from home stuff is a bandaid you are looking forward to tearing off.
I am the OP, I think my question has become lost in the arguing by others. My question was not about VPN, but about dynamic IP endpoints floating around behind NAT endpoints, on the internet getting blocked by the firewall when there is no abnormal behavior. My thread was kind of hijacked
We support 20+ FreePBX installs. Some have no external endpoints. Some are dynamic only. Some are branch office with site to site VPNs: It’s every combination.
And my point is that the Responsive Firewall is blocking IPs that it shouldn’t. These aren’t all natted devices connecting over the internet, devices connecting over site to site VPNs via routing are affected, as are devices that have been working fine for months in their current config.
@thx2000 I will see if I can retrieve the fail2ban logs. I’m not sure where they are, and will hunt.
Now you are changing the premise. You stated that there WAS abnormal behavior - you saw phones getting rate-limited first, before being blocked. I provided a very likely possibility which was NATs were interfering. There are other possible causes. The firewall blocking is a symptom, find the cause. Either it’s NAT or something else.
If you try the VPN solution and it fixes it, then that gives you more information in solving the puzzle does it not? If it does not fix it that also gives more information. You won’t solve the problem without more digging and trying a VPN on one of them is one of the tools in your arsenal. If you won’t use all your tools, then you are fighting this problem handicapped. Not wise, in my view, but suit yourself.
Devices connecting over site to site VPNs - SHOULD NOT be affected since their subnets are known. So let’s ignore those ones and look at the Internet traffic.
So this was working fine for months - that is actually a good thing. You say you had a config that worked fine for months. Now it isn’t. Logically something changed. So look for changes in your network. If there are none, no updates, no changes in any of the network gear in the path, your ISP hasn’t done anything to your downlead - no updates or changes to freepbx, no changes to the phones, etc. etc. etc. - then it’s a variable such as a path on the Internet that has changed. Maybe your ISP is now using carrier pigeons to move packets. But before arriving at that conclusion have you checked for all possible changes on the stuff you control?
Logically if you changed nothing and nothing under your control changed, then your ISP is effing with you. Your remote VPNs are all coming through that same ISP connection that your remote non-VPN’s are using, right? So if your ISP is screwing you - it’s going to affect all those too even if inside a VPN. If this explanation tracks your symptoms then Occam’s Razor…
I’m happy to try VPN. Rolling that out quickly to all our systems (we’re a hosted provider with hundreds) is a challenge.
The intent originally was to see if others had experienced this, and/or if any fix was found. I fully understand how NAT plays a role here and agree what you said MAY be at play…
My post was kind of hijacked is all I was referring to and turned into an argument. I appreciate your help and time here.
Your problem illustrates why so many people spent so much money building out private networks to fight the Internet back in the early to mid 90’s. Of course they all failed but the one thing they had that the Internet doesn’t have is that you could control the network. With the Internet, you are forced to trust that the intermediate network between you and your destination aren’t going to mess around with your traffic to suit their own purposes. Even a VPN doesn’t give you that because you are still depending on the underlying transport being under the control of someone else.
The only answer we have to this - and it’s pretty terrible - is to tell people to use the same ISP as their key peer uses. If your most important thing is working from home and good connectivity to your office, use the same ISP as your office. If it’s solid phones, use the same ISP as what your hosted provider uses.
In your sleuthing have you asked the people with problems who they are using as their internet provider for home? Perhaps there is a commonality there? In my area a week ago there was a massive routing problem between Frontier and Comcast that lasted a couple hours. One of my customers got a bunch of users reporting problems and asked me to contact the users. Of course, all users with problems were on the ISP my customer wasn’t using.