[Freeswitch-users] TLS problems

Thu Oct 13 18:39:15 MSD 2011

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="1b774f833fd01b5b29954c2ddc2b5457",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="d641702f981e10f3a41e074061bdb5b3",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-users
> http://www.freeswitch.org
>

--
Kristian Kielhofner