[Freeswitch-users] TLS problems

[Ben Naylor]

Many thanks for the info Kristian, it has definetly been a bit of a
nightmare understanding how it all works!

Bypass_media is unfortunately unavoidable, so it looks like it's going to be
a STUN server.  You mention SIP latching/RTP proxy, would this replace the
need for a STUN server, or work alongside it?

The benefit of a STUN server is that it supports TLS, which is an absolute
requirement in our case.

Thanks again for your help.

Ben.

-----Original Message-----
From: freeswitch-users-bounces at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Kristian
Kielhofner
Sent: 13 October 2011 15:54
To: FreeSWITCH Users Help
Subject: Re: [Freeswitch-users] TLS problems

Ben,

  SIP+NAT, where do I even start ;)...

Local/near handling (STUN, TURN, ICE, etc) "Middle" handling (SIP ALG, SBC)
Far end handling (SIP latching/RTP proxy)

  Your natted devices are currently sitting behind a NAT device with a SIP
ALG (application layer gateway).  As you (correctly) guessed this device
sits and watches for SIP packets.  When it sees them it rewrites various
fields (c=, Contact:, etc) to effectively insert itself into the dialog.  It
will then (transparently) rewrite these fields between both sides of the NAT
while also handling RTP.  This would be "middle" handling.

  This works with bypass_media because your endpoints see the "fixed"
SDP fields from the ALG and know where to send media.  Because the ALG
device is unable to inspect TLS packets it can't rewrite these addresses.
Normally FreeSWITCH would insert itself in the media path (Far end
handling), proxy the media stream, and rewrite the packets to match.  With
bypass_media enabled FreeSWITCH can't do this.

  With TLS + NAT your options are:

- Configure STUN/TURN/ICE on your client (Acrobits) and cross your fingers
- Disable bypass_media in FreeSWITCH

On Thu, Oct 13, 2011 at 10:46 AM, Ben Naylor <bnaylor at sirran.com> wrote:
> Ahh yes, I forgot to mention that I am using bypass_media, apologies 
> for not mentioning this before!
>
> Logs to follow shortly......
>
> Thanks for the help,
>
> Ben
>
> -----Original Message-----
> From: freeswitch-users-bounces at lists.freeswitch.org
> [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of 
> Kristian Kielhofner
> Sent: 13 October 2011 15:39
> To: FreeSWITCH Users Help
> Subject: Re: [Freeswitch-users] TLS problems
>
> Hi Ben,
>
>  FreeSWITCH handles NAT rather well and should automatically ignore 
> the natted SDP info; using the actual send/receive RTP IP/port once 
> media arrives.  It will then leave itself in the media path (like it 
> usually does
> anyway) and magically fix SDP/RTP data to other clients.
>
>  Are you doing anything funny like bypass_media?
>
>  Please include a SIP trace and FS console logs so we can see if what 
> FreeSWITCH is doing.
>
> On Thu, Oct 13, 2011 at 8:12 AM, Ben Naylor <bnaylor at sirran.com> wrote:
>>
>> Hi all
>>
>>
>>
>> I was wondering if anyone can help me with a problem I am having with
> using TLS SIP when NAT routers are involved?
>>
>>
>>
>> The scenario is as follows –
>>
>>
>>
>> SIP UA --- > NAT firewall  --- > Internet --- > Freeswitch --- > 
>> Internet --- > NAT Firewall --- > SIP UA
>>
>>
>>
>> When I use UDP as the transport protocol, everything works fine.  
>> This is down to (correct me if I am wrong) the NAT router being able 
>> to inspect the SIP traffic, and changing the SIP INVITE message so 
>> that the public IP is used for the RTP stream.  This is seen in the 
>> following ( 1.2.3.4 = SIP UA,   50.50.50.50 = Freeswitch server) –
>>
>>
>>
>>   recv 1042 bytes from udp/[1.2.3.4]:34019 at 08:40:24.302496:
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>>    INVITE sip:1004 at 50.50.50.50 SIP/2.0
>>
>>    Via: SIP/2.0/UDP 
>> 1.2.3.4:34019;branch=z9hG4bKD8xhgo0smbsOQMUy;rport
>>
>>    Contact: <sip:1002 at 1.2.3.4:34019>
>>
>>    Max-Forwards: 70
>>
>>    From: "1002"
>> <sip:1002 at 50.50.50.50>;tag=A6E182EBB96E21919A44C50399F1BF27
>>
>>    Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY
>>
>>    Supported: replaces, path
>>
>>    User-Agent: Acrobits Softphone Business/1.8.8
>>
>>    To: <sip:1004 at 50.50.50.50>
>>
>>    Content-Type: application/sdp
>>
>>    Call-ID: 2926496CCA1C6189C90A52D821B06B5E9DBA2B32
>>
>>    CSeq: 1 INVITE
>>
>>    Proxy-Authorization: Digest
>
username="1002",realm="50.50.50.50",algorithm=MD5,uri="sip:1004 at 50.50.50.50"
> ,nonce="09195369-6474-4310-b3a6-60e7d9c780f1",qop=auth,cnonce="1b774f8
> 33fd01 
>
b5b29954c2ddc2b5457",nc=00000002,response="07bda5b4c5fa5e17f653a3e9c7a2f05e"
>>
>>    Content-Length: 241
>>
>>
>>
>>    v=0
>>
>>    o=- 10805 6353 IN IP4 1.2.3.4  < --- Public IP address used so 
>> that the
> other party knows to send the RTP stream to this address.
>>
>>    s=xynwwjx
>>
>>    c=IN IP4 1.2.3.4
>>
>>    t=0 0
>>
>>    m=audio 34962 RTP/AVP 102 3 0 8 9 101
>>
>>    a=rtpmap:101 telephone-event/8000
>>
>>    a=rtpmap:102 ILBC/8000
>>
>>    a=fmtp:102 mode=30
>>
>>    a=fmtp:101 0-15
>>
>>    a=ptime:30
>>
>>    a=sendrecv
>>
>>
>>
>> This was obtained from the Siptrace on the Freeswitch server.  The
> Freeswitch server then forwards these details to the other party.
>>
>>
>>
>> The problem occurs when TLS is used, as the NAT firewalls are unable 
>> to inspect the SIP packets.  Here is another SIPtrace on the 
>> Freeswitch server for TLS example (again I have changed the public 
>> IPs to the same as the above example) –
>>
>>
>>
>> recv 1048 bytes from tls/[1.2.3.4]:64403 at 16:00:42.271063:
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>>    INVITE sip:1002 at 50.50.50.50 SIP/2.0
>>
>>    Via: SIP/2.0/TLS 
>> 1.2.3.4:64403;branch=z9hG4bKz6qAkQj3XsYuJ5Os;rport
>>
>>    Contact: <sip:1004 at 1.2.3.4:64403;transport=tls>
>>
>>    Max-Forwards: 70
>>
>>    From: "Ben"
>> <sip:1004 at 50.50.50.50>;tag=F28D08D5E039D8FE021D08022A72F982
>>
>>    Allow: OPTIONS, INVITE, ACK, REFER, CANCEL, BYE, NOTIFY
>>
>>    Supported: replaces, path
>>
>>    User-Agent: Acrobits Softphone Business/1.8.8
>>
>>    To: <sip:1002 at 50.50.50.50>
>>
>>    Content-Type: application/sdp
>>
>>    Call-ID: 32166133760BDDAD823725B563F6A1B3989090D6
>>
>>    CSeq: 1 INVITE
>>
>>    Authorization: Digest
>
username="1004",realm="50.50.50.50",algorithm=MD5,uri="sip:1002 at 50.50.50.50"
> ,nonce="5af9829e-716d-4472-924f-84eb41d9e78e",qop=auth,cnonce="d641702
> f981e1 
>
0f3a41e074061bdb5b3",nc=00000003,response="a9f577ac37f8f367b2f839a58d43e1e0"
>
>>
>>    Content-Length: 240
>>
>>
>>
>>    v=0
>>
>>    o=- 71766 47529 IN IP4 172.16.234.176 < --- Using Private IP for 
>> the RTP details
>>
>>    s=fscmvnc
>>
>>    c=IN IP4 172.16.234.176
>>
>>    t=0 0
>>
>>    m=audio 64628 RTP/AVP 3 102 101
>>
>>    a=rtpmap:101 telephone-event/8000
>>
>>    a=rtpmap:102 ILBC/8000
>>
>>    a=fmtp:102 mode=30
>>
>>    a=fmtp:101 0-15
>>
>>    a=ptime:30
>>
>>    a=sendrecv
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>>
>>
>> As you can see, the SIP UAs are going to try and use a non-existent
> private IP address to send the RTP stream to.
>>
>> I can also confirm that the UAs are trying to do this, by looking at 
>> the
> SIP logs built in to the SIP UA client software.
>>
>>
>>
>> My (Freeswitch related) question is, am I able to set something in
> Freeswitch to change the details to be the public IP of the firewall?  
> The SIP messages include the correct IP, can the Freeswitch server use 
> this address and replace the Private IP with this one?
>>
>>
>>
>> I have heard about TLS proxies/STUn servers etc etc, but would much 
>> rather
> use Freeswitch to do this.
>>
>>
>>
>> Any suggestions are welcome, also please let me know if I have
> misunderstood any of the concepts behind SIP/VOIP and firewalls – I am 
> rather new to the VOIP game!
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Ben
>>
>>
>>
>>
>>
>>
>>
>> Ben Naylor
>>
>> Network Support Engineer
>>
>>
>>
>> T: +44 (0)207 096 1648`
>>
>> M: +44 (0)7924 349 113
>>
>> F:  +44 (0)207 150 595
>>
>> E: bnaylor at sirran.com W: www.sirran.com
>>
>>
>>
>> A: SiRRAN Communications Ltd, The Hawk Business Park, Easingwold, 
>> YO61 3FE
>>
>> Registered Office: SiRRAN Communications Ltd,. 6-9 Trinity Street 
>> Dublin 2, Ireland
>>
>>
>>
>> _____________________________________________________________
>>
>> The information contained in this e-mail and any attached documents 
>> may be
> privileged, confidential and protected from disclosure. If you are not 
> the intended recipient you may not read, copy, distribute or use this 
> information. If you have received this communication in error, please 
> notify the sender immediately by replying to this message and then 
> delete it from your system.
>>
>>
>>
>>
>>
>> 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-us
>> e
>> rs
>> http://www.freeswitch.org
>>
>
>
>
> --
> Kristian Kielhofner
>
>
> 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-use
> rs
> http://www.freeswitch.org
>
>
>
> 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-use
> rs
> http://www.freeswitch.org
>



--
Kristian Kielhofner


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