Alternatives to OpenVPN for FreePBX on cell phone...
-
@Coreytay said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam I found this while looking for alternative also. http://dsiprouter.org/
Not a lot of info obvious on the page.
-
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
-
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@Pete-S : I've increased the default timeout from 10 120 to 300 900.
We'll see if a) the connection remains stable b) if battery usage decreases.I don't want to disable encryption as FreePBX automatically generates the client config and I don't want to have to custom edit each.
Unless this can be configured strictly on the server side like keepalive?
Any progress on this?
I don't know how freepbx does the openvpn config files but you should have a setting on what cipher to run. That information ends up in both the client and server config files. To disable encryption you set the cipher to none.
You should probably turn of compression too as voip is already compressed. Just takes more battery power to compress something that is compressed already.
-
@Pete-S : within the GUI there are no available options for tailoring OpenVPN unfortunately.
The client config that it generates is :
# Configuration automatically generated via Sysadmin RPM # MODIFICATIONS TO THIS FILE WILL BE OVERWRITTEN. # Generated at: Sun, 13 Jan 2019 03:33:14 +0000 client dev tun proto udp resolv-retry 60 nobind persist-key persist-tun remote-cert-tls server ca sysadmin_ca.crt cert sysadmin_client1.crt key sysadmin_client1.key comp-lzo verb 3 remote x.x.x.x 1194 remote x.x.x.x 1194The server config is :
# Configuration automatically generated via Sysadmin RPM # MODIFICATIONS TO THIS FILE WILL BE OVERWRITTEN. # Generated at: Sun, 13 Jan 2019 03:33:14 +0000 port 1194 proto udp dev tun topology subnet ca sysadmin_ca.crt dh sysadmin_dh.pem crl-verify sysadmin_crl.pem cert sysadmin_server1.crt key sysadmin_server1.key ifconfig-pool-persist ipp.txt #keepalive 10 120 keepalive 300 900 comp-lzo persist-key persist-tun verb 3 client-config-dir ccd ccd-exclusive status sysadmin_server1-status.log 10 status-version 3 script-security 2 server 10.8.0.0 255.255.255.0Note the header stating that this file will be overritten so I'm not certain how "permanent" this will be nor do I see information regarding encryption type (though do see the compression).
-
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
that's where I was. I get that it is a proxy, but I don't get what problem it is solving. It seems to just move the problem, not remove it.
-
@Pete-S said in Alternatives to OpenVPN for VoiP on cell phone...:
You should probably turn of compression too as voip is already compressed. Just takes more battery power to compress something that is compressed already.
Good point, watch for double compression.
-
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
that's where I was. I get that it is a proxy, but I don't get what problem it is solving. It seems to just move the problem, not remove it.
Well if the proxy can solve the firewall lockout issue on mobile devices and changing IPs... but then, if the Proxy can solve it - why can't the firewall in FreePBX?
-
@Dashrender : FreePBX uses a really stupid implementation IMO.
The responsive firewall bans a user if they have connected but not registered in X time. This is sane.
But fail2ban remains on with it and bans the IP before the responsive firewall is given time to check for registration. -
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
that's where I was. I get that it is a proxy, but I don't get what problem it is solving. It seems to just move the problem, not remove it.
Well if the proxy can solve the firewall lockout issue on mobile devices and changing IPs... but then, if the Proxy can solve it - why can't the firewall in FreePBX?
But how can it? Sounds like all it does is disable the firewall, right? You can do that by just... disabling it! Seems pretty silly to implement an entirely separate system just to work around a firewall that you can just turn off with a button.
-
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
that's where I was. I get that it is a proxy, but I don't get what problem it is solving. It seems to just move the problem, not remove it.
Well if the proxy can solve the firewall lockout issue on mobile devices and changing IPs... but then, if the Proxy can solve it - why can't the firewall in FreePBX?
But how can it? Sounds like all it does is disable the firewall, right? You can do that by just... disabling it! Seems pretty silly to implement an entirely separate system just to work around a firewall that you can just turn off with a button.
eh? I have no idea how it actually works.
But assuming it takes more false hits to get something blocked in this proxy's firewall than it does in FreePBX's firewall, then that would solve the problem.
But then the question is can FreePBX's firewall be changed to make it wait say 30 second from connection to logon before blocking it (this is just a guess, I don't know why it's actually failing/blocking the remote phones other than of course it's coming from a new IP).
-
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered. -
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller : Yeah, I'm not really certain what that software does..
"dSIPRouter can be used to implement different use cases within minutes"Ummm, then this shows a few examples but I'm not certain of the use case for any of these...
that's where I was. I get that it is a proxy, but I don't get what problem it is solving. It seems to just move the problem, not remove it.
Well if the proxy can solve the firewall lockout issue on mobile devices and changing IPs... but then, if the Proxy can solve it - why can't the firewall in FreePBX?
But how can it? Sounds like all it does is disable the firewall, right? You can do that by just... disabling it! Seems pretty silly to implement an entirely separate system just to work around a firewall that you can just turn off with a button.
eh? I have no idea how it actually works.
But assuming it takes more false hits to get something blocked in this proxy's firewall than it does in FreePBX's firewall, then that would solve the problem.
Sure, but that's not even suggested as a possibility. If that's happening, then great, but that's like saying "why is this rock better than a car" and then responding "well if the rock goes faster, costs less and gets better gas mileage." Well sure, but why would we think that about a rock?
-
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
But then the question is can FreePBX's firewall be changed to make it wait say 30 second from connection to logon before blocking it (this is just a guess, I don't know why it's actually failing/blocking the remote phones other than of course it's coming from a new IP).
No, I don't believe that it can be tuned in any way.
-
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
But then the question is can FreePBX's firewall be changed to make it wait say 30 second from connection to logon before blocking it (this is just a guess, I don't know why it's actually failing/blocking the remote phones other than of course it's coming from a new IP).
No, I don't believe that it can be tuned in any way.
Well, not by us anyway.
-
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered./sigh - so they know the problem - and still haven't solved it.
I know it could mean 1000 or 100,000 more hits, but if the lengthen the time before the ban wouldn't that solve it? What's the chance of hitting a correct password when randomly guessing 100,000 times versus (what is it today?)?
-
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered./sigh - so they know the problem - and still haven't solved it.
I know it could mean 1000 or 100,000 more hits, but if the lengthen the time before the ban wouldn't that solve it? What's the chance of hitting a correct password when randomly guessing 100,000 times versus (what is it today?)?
It would certainly help. But just fixing the mechanism is the better approach.
-
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered./sigh - so they know the problem - and still haven't solved it.
I know it could mean 1000 or 100,000 more hits, but if the lengthen the time before the ban wouldn't that solve it? What's the chance of hitting a correct password when randomly guessing 100,000 times versus (what is it today?)?
It would certainly help. But just fixing the mechanism is the better approach.
which mechanism? you mean the approach to look at the registration in real time, instead of every 15 seconds? I suppose - I have no idea what kind of load that would put on the system?
-
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered./sigh - so they know the problem - and still haven't solved it.
I know it could mean 1000 or 100,000 more hits, but if the lengthen the time before the ban wouldn't that solve it? What's the chance of hitting a correct password when randomly guessing 100,000 times versus (what is it today?)?
It would certainly help. But just fixing the mechanism is the better approach.
which mechanism? you mean the approach to look at the registration in real time, instead of every 15 seconds? I suppose - I have no idea what kind of load that would put on the system?
Right, that when there is a change it triggers a new registration which checks authentication. There are proposals for how to do it, but nothing done about it.
Trivial load, way, way, way less than running a VPN.
-
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@scottalanmiller said in Alternatives to OpenVPN for VoiP on cell phone...:
@Dashrender said in Alternatives to OpenVPN for VoiP on cell phone...:
@manxam said in Alternatives to OpenVPN for VoiP on cell phone...:
From Sangoma a year ago. Still no progress made on this it seems...
The problem is after your phone registers is slamming the server with packets before the firewall is picked up it was registered as their is a delay so after 10 packets which happen really fast for some reason on your client it gets blacklisted.
To solve this we need to move the checking for registration to watch the AMI so we see it real-time instead of checking every 15 seconds like we do now as your client is slamming the server with packets before we see it registered./sigh - so they know the problem - and still haven't solved it.
I know it could mean 1000 or 100,000 more hits, but if the lengthen the time before the ban wouldn't that solve it? What's the chance of hitting a correct password when randomly guessing 100,000 times versus (what is it today?)?
It would certainly help. But just fixing the mechanism is the better approach.
which mechanism? you mean the approach to look at the registration in real time, instead of every 15 seconds? I suppose - I have no idea what kind of load that would put on the system?
Right, that when there is a change it triggers a new registration which checks authentication. There are proposals for how to do it, but nothing done about it.
Trivial load, way, way, way less than running a VPN.
Yet, we still haven't seen a solution to this. thoughts as to why? No one is really using it? I find that hard to believe - perhaps people try and just give up instead of complaining/reporting it.
-
@Dashrender : From reading their forum and reddit, it appears that most people give up and go the VPN route.
There's never been a clear and concise answer from Sangoma.There were a few mentions of Zulu as an alternative, but Zulu 3 is the only supported version currently and both iOS and Android in beta for (~6 months with only one-or-two updates each in that time) The android beta does not get notification of calls unless it's currently sitting open on the device.
