FreePBX External/Remote Extensions
-
@aaronstuder said in FreePBX External/Remote Extensions:
@RamblingBiped said:
So for option #1 I'm looking at using a non-standard port number for SIP registration, credentials, and (eventually) limiting the registration to a single public IP address. With all of that in place, that should reasonably be secure correct?
Yes, but will you have a fixed IP?
Yes, the last time he did this trip that was the case.
-
I still like option 2 the best
Doesn't seem too bad to do.
HOW TO GET YEALINK PHONES CONNECTING OVER VPN
http://www.jsimmons.co.uk/2012/12/05/how-to-get-yealink-phones-connecting-over-vpn/OpenVPN road warrior installer for Debian, Ubuntu and CentOS
https://github.com/Nyr/openvpn-installIf you don't want to use linux you can use windows (Hint: Use Linux
) -
@aaronstuder said in FreePBX External/Remote Extensions:
@scottalanmiller So @gjacobse has a fixed IP?
No
-
@RamblingBiped said in FreePBX External/Remote Extensions:
@scottalanmiller said in FreePBX External/Remote Extensions:
@aaronstuder said in FreePBX External/Remote Extensions:
@scottalanmiller said in FreePBX External/Remote Extensions:
Option #1 will work and you can manage the security implications in a reasonable way.
How does NTG handle that?
Firewall limits on one side and extension capabilities on the other. If you limit the usefulness of hacking an extension you can, for some companies, bring the risk to effectively zero. Only works reliably if you can do the latter.
So for option #1 I'm looking at using a non-standard port number for SIP registration, credentials, and (eventually) limiting the registration to a single public IP address. With all of that in place, that should reasonably be secure correct?
Never use non-standard ports. There is zero security there, but it does cause other problems for you. Security through obscurity doesn't slow down at attacker in any way, but it does flag you as someone who misunderstands security but has something worth protecting (a low hanging fruit target.) If you are going to expose things, expose them. Don't consider obscurity.
Limiting to a single IP address is normally plenty of security for normal use cases. Traffic is still unencrypted, but so is normal phone traffic and people don't complain there.
-
@RamblingBiped said in FreePBX External/Remote Extensions:
@aaronstuder said in FreePBX External/Remote Extensions:
@RamblingBiped said:
So for option #1 I'm looking at using a non-standard port number for SIP registration, credentials, and (eventually) limiting the registration to a single public IP address. With all of that in place, that should reasonably be secure correct?
Yes, but will you have a fixed IP?
Yes, the last time he did this trip that was the case.
Yup, that will work just fine.
-
@aaronstuder said in FreePBX External/Remote Extensions:
I still like option 2 the best
Doesn't seem too bad to do.
HOW TO GET YEALINK PHONES CONNECTING OVER VPN
http://www.jsimmons.co.uk/2012/12/05/how-to-get-yealink-phones-connecting-over-vpn/OpenVPN road warrior installer for Debian, Ubuntu and CentOS
https://github.com/Nyr/openvpn-installIf you don't want to use linux you can use windows (Hint: Use Linux
)Definitely option 2 is best AND is more flexible should moving around or whatever come up.
-
@scottalanmiller said in FreePBX External/Remote Extensions:
@aaronstuder said in FreePBX External/Remote Extensions:
I still like option 2 the best
Doesn't seem too bad to do.
HOW TO GET YEALINK PHONES CONNECTING OVER VPN
http://www.jsimmons.co.uk/2012/12/05/how-to-get-yealink-phones-connecting-over-vpn/OpenVPN road warrior installer for Debian, Ubuntu and CentOS
https://github.com/Nyr/openvpn-installIf you don't want to use linux you can use windows (Hint: Use Linux
)Definitely option 2 is best AND is more flexible should moving around or whatever come up.
I think at this point I am going to get Option #1 up and running, and then work on implementing #2.
-
Option #1 up and running. Now to work on the OpenVPN part of the equation...
-
@RamblingBiped said in FreePBX External/Remote Extensions:
Option #1 up and running. Now to work on the OpenVPN part of the equation...
Use option 1 and simply restrict the IP that is allowed through the NAT at the firewall.
-
@RamblingBiped said in FreePBX External/Remote Extensions:
Option #1 up and running. Now to work on the OpenVPN part of the equation...
I have set this up but then ran into the problem of the OpenVPN port being blocked. Slightly hard to change once out in the wild.
-
@JaredBusch said in FreePBX External/Remote Extensions:
@RamblingBiped said in FreePBX External/Remote Extensions:
Option #1 up and running. Now to work on the OpenVPN part of the equation...
I have set this up but then ran into the problem of the OpenVPN port being blocked. Slightly hard to change once out in the wild.
On which end?
-
@JaredBusch said in FreePBX External/Remote Extensions:
@RamblingBiped said in FreePBX External/Remote Extensions:
Option #1 up and running. Now to work on the OpenVPN part of the equation...
I have set this up but then ran into the problem of the OpenVPN port being blocked. Slightly hard to change once out in the wild.
That is a really good point. We've had some issues with OpenVPN failing/being blocked in Asia and had to resort to obfuscating the traffic via SSL encapsulation; which is unfortunately not an option with the Yealink phones. Chances are that wouldn't be a problem in UK, but I like the safe not sorry approach... And, Murphy's law usually rings true when you give it the opportunity...
-
@scottalanmiller said in FreePBX External/Remote Extensions:
@JaredBusch said in FreePBX External/Remote Extensions:
@RamblingBiped said in FreePBX External/Remote Extensions:
Option #1 up and running. Now to work on the OpenVPN part of the equation...
I have set this up but then ran into the problem of the OpenVPN port being blocked. Slightly hard to change once out in the wild.
On which end?
The remote end obviously. As I have full control of the server side.
