[Freeswitch-users] Security vs compatibility / NAT etc

[Colin Morelli]

If you're going to route calls over the public internet I *highly*
recommend using TLS and SRTP. Generally speaking the computational overhead
for most encryption is negligible these days compared to the value and
safety it provides to you and your users.

For convenience it would be reasonable to terminate TLS in Kamailio and
send unencrypted SIP traffic to FS over the local network. RTP streams are
easy to secure as long as clients support it.

Are there concerns you have with enabling TLS+SRTP?

Best,
Colin
On Thu, Jun 30, 2016 at 1:18 PM Rick Jarvis <rick.jarvis at magicmail.mooo.com>
wrote:

> That’s really helpful, thank you Colin! Yes, the prime concern is handling
> NAT for the remote phones, so am just starting to look into Kamailio now. A
> lot to get my head around, if only it was a FreeSWITCH module! ;)
>
> So WRT to the security element, am I correct in thinking that people don’t
> generally worry about anyone piecing together unencrypted phone calls out
> on the net somewhere? Just worried that it might be risk that blows up in
> my face one day…?
>
> On 30 Jun 2016, at 14:39, Colin Morelli <colin.morelli at gmail.com> wrote:
>
> Rick,
>
> (Sorry for the long email, hopefully it's helpful)
>
> It sounds like you're mostly concerned with FS initiating calls to
> handsets behind NAT, is that correct?
>
> If so, what you probably want is SIP outbound (RFC 5626). It's the best
> way to avoid NAT issues with clients. Under this model, clients keep a
> persistent connection open to the server. The server is responsible for
> using that connection to deliver INVITEs to the client, thus avoiding the
> need to ever open its own connection.
>
> In my (relatively limited) experience with FS, it was able to act like a
> SIP outbound server, but it doesn't directly advertise it and supporting
> SIP outbound is really outside of the core scope of what FS does. So, in my
> setup, I use Kamailio to provide the SIP outbound support. A brief
> description of my setup (which seems to work fine with clients behind NAT)
>
> Kamailio edge proxy cluster (provides SIP outbound support to clients,
> allows public SIP traffic)
> Kamailio proxy + registrar (only allows SIP traffic from inside the local
> network, provides registration support)
> Freeswitch (only allows SIP traffic from inside the local network, has a
> public IP address and open firewall for RTP traffic).
>
> So, a registration from a client hits the Kamailio edge proxy, which parks
> the socket connection and sends it on to the second Kamailio
> proxy/registrar. When FS needs to make outbound calls to clients, it hits
> the Kamailio proxy/registrar, which forwards it to the edge proxy that has
> an existing connection the client and uses it to deliver the invite (this
> is all handled by Kamailio with it's outbound, path, registrar, and usrloc
> modules).
>
> Note your setup might not require the use of two layers of proxies before
> FS. In my case, I keep registrations off of FS so it's only handling calls.
> If you have registrations in FS, you can likely just have a Kamailio edge
> proxy for advertising SIP outbound support, and have it proxy all traffic
> into FS.
>
> With this setup, FS will receive SIP traffic from Kamailio, and advertise
> (in the SDP) its public IP address for RTP media (which needs to be allowed
> through the firewall). Freeswitch will then open what it refers to as an
> auto-adjust window for the RTP media. In other words, FS will assume that
> the first address/port to send RTP media to the RTP port configured for a
> call is the remote client for that call. As a result, FS is able to cope
> with clients behind NAT on the media side as well. I believe this feature
> is enabled by default, but you may have to enable it - you'd have to check
> the docs on this one.
>
> With those two pieces combined you should be able to get past any NAT
> issues without the need for STUN/TURN. Unless you bypass media on FS, in
> which case you're going to need those.
>
> Hopefully that helps you out a bit.
>
> Best,
> Colin
>
> On Thu, Jun 30, 2016 at 8:52 AM Rick Jarvis <
> rick.jarvis at magicmail.mooo.com> wrote:
>
>> I’d be interested to hear what different people use to provide some level
>> of security for remote end-users such as homeworkers, and to get round NAT
>> issues.
>>
>> We currently use OpenVPN, as this is built into the firmware of Yealink
>> handsets (it’s a great feature, I’m not sure why more handset manufacturers
>> don’t do this?!). The pros are that not only is it secure, but it also
>> removes any problems with NAT for the RTP streams.
>>
>> The downsides are that it is complicated (and downright frustrating
>> sometimes) to set up, and there are additional things to consider such as
>> the server configuration and overheads.
>>
>> TLS/SSL with SRTP is another option, but my understanding of this is that
>> it can cause NAT problems, with FreeSWITCH trying to initiate control
>> channels back to the phone for inbound calls. In fact, I’ve always had
>> problems with getting phones to work when behind NAT anyway, even without
>> SSL/TLS. STUN can be used to ascertain the IP, but how do you handle
>> situations where multiple handsets are behind NAT - you can’t open all RTP
>> ports to all handsets at once?!!
>>
>> Would be very interested to hear thoughts and methods on these points.
>>
>> Thanks
>> R
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160630/b6c4a7a0/attachment.html