What’s the general consensus here regarding connecting remote phones - VPN or TLS only?
For reference, I’m an IT professional who’s been installing FreePBX servers for about 15 years, having a network background and holding the belief that nothing beats a VPN for network security, assuming that the preshared key isn’t something stupidly easy to brute force.
All installed PBX appliances use a ZyXel business grade firewall at the perimeter, and none use the built-in Sangoma responsive firewall - perhaps it’s silly, but I don’t trust it. Since FreePBX SysAdmin started including a built-in VPN server, I’ve been using it like crazy to deploy remote phones, forwarding ONLY UDP 1194 to the PBX, SIP only from VOIP Innovations IP addresses, and RTP from everywhere. The only remote phones not using VPN have their static source IP allowed through the firewall. Nothing else is open. Even the GUI is not accessible via WAN.
Thus far (fingers crossed), none have been hacked the traditional weak-password way.
Now…my experience with VPN has been love-hate, at best. It works - I can fix the apparently random issue which occur 2-4 times per year - and I know the phones are secure. Most of the time, it’s certificate renewals causing breakdowns. Sometimes, it’s stupid stuff like a particular client refuses to connect, but a new one will work fine.
Also, not all phones are supported and that’s kind of a bummer.
So, I’m looking for increased reliability with no reduction in security. With TLS security improving, I’ve started to think seriously about moving away from VPN. I’m hoping that any of you can shed a light I have not seen yet. My opinions are exactly that and I am not married to any of them.
VPN is the best approach for limiting points of attack. If the situation allows for it, run the VPN. That being said, if there are constraints that impact your ability to successfully deploy and manage the VPN several groups do not use VPN. By changing the SIP and RTP ports to nonstandard ones, you will eliminate most of “attacks” right off the bat. Coupled with Sangama’s Responsive Firewall and Fail2Ban, you are in a pretty good place.
Take this further with making sure you are not exposing the management ports, and by making outbound dial patters that insulate you from “pay” numbers, time of day restrictions, max time, etc. and you will be pretty robust and secure.
TLS transport requires the client to ‘know the name’ of the certificate being checked, there is no requirement that that certificate be issued by a well known CA but if you reuse the one that your webserver is using , then it is often relatively easy to have that certificate name leaked. if you use an intermediary TCP server like haproxy with ‘strict SNI checking’ enforced , you can certify the connection there and forward the TCP level connection to your PBX. This way IP based connection would be blindsided and use of a possibly leaked LetsEncrypt type certificate also would ‘not pass Go or be allowed to collect $200’
In many years I have not seen any significant attempts against TLS on 5061.
Haproxy is a reverse proxy for HTTP(s) and TCP(s) so no, You probably need a real SIP proxy like kamailio, DSipRouter is a gooey front end that manages Kamailio as a front end and Asteri et al. as usable backends.
You will want a good session board controller, also known as sip proxy. I use the ingate Siperator product but there are many options out there.
From a enterprise perspective its nice to have the ability to open a support ticket. In terms of issues I have used the ingates with asterisk for over a year with no SBC issues in production. I have had asterisk issues over the year.
It is a love / hate relationship with Ingate. They are expensive and once working work well. But sometimes setup and matching to asterisk can require tickets with them. A working combo is asterisk 20.3.0 and there latest release 6.4.2.
I’ve been stalking the SBC concept for a while, having even spoken with a rep at Telco Bridges about FreeSBC. Ultimately, I wasn’t sure which way to go and what kind of infrastructure would be required so I kept plugging along with VPN phones.
I’ll be looking at all your suggestions and hopefully reply back again in about 2-3 weeks.