[Freeswitch-users] TLS problems

Thu Oct 13 18:54:08 MSD 2011

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="1b774f833fd01
> 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="d641702f981e1
> 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-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
>
>
>
> 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
>

-- 
Kristian Kielhofner