So I have been looking at the Zulu UC app for android. It is complicated to have an always on vpn with Android and the Freepbx certificate manager let’s encrypt options expect http auth to work. Which means the FreePBX website needs to be accessible from the general web.
So my question… is it now recommended that FreePBX is exposed over the internet?
I am looking at a lot of trouble to get android vpns working for Zulu and there isn’t an easy way to have auto on/off based on the phone having a local wifi connection or not. Letting clients access FreePBX via internet would certainly simplify things. But it’s always been my understanding that the pbx should only offer local access.
I use UCP/WebRTC phone over the Internet, something similar to Zulu.
It seems to me that the expectation (by FreePBX designers/developers) is that these tools are accessed over the Internet. VPN adds a lot of complexity, to what end?
Where is/was the recommendation that FreePBX not be used over the Internet?
FreePBX comes with authentication, authorization, encryption, firewall, intrusion detection (signature checking system), and fail2ban. This is a pretty complete toolbox for deploying a server on the Internet.
Thanks for the reply. I do not have specific references anymore. It has been quite a few years since I looked at this. But I remember reading about companies having large SIP bills from compromised pbx servers and the takeaway was do not directly place the pbx server on the internet. And I believe I had read that recommendation in several places… but my memory could be wrong?
My current plan was to proxy http traffic to the local pbx and require vpn for all other traffic. But I was curious if the effort was wasted with newer versions of freepbx
That is one take-away. Another would be understand what the weak point was that caused the compromise and solve that.
I admit to playing dumb a little. I know a few folks who say hide your PBX from the internet. I say it’s not necessary if you secure your server with the aforementioned included tools. Comes down to your comfort level and willingness to endure inconvenience and technical complexity. Your HTTPS proxy seems good as long as you are able to proxy websockets through it too, as you’ll need that for the webrtc component.
These comments reflect my personal opinion, etc etc.
I think a lot of deployers and users don’t have security in mind at all which is problematic. You can say “secure your system” but it’s an afterthought.
I’ve seen (and continue to see) deployments with just poor security practices. Extension = password, passwords of 1234, anonymous calling allowing outbound calling.
If you treat security as a first class requirement and practice, then being public is fine.
