[SR-Users] TLS and SIP

Klaus Darilion klaus.mailinglists at pernau.at
Thu May 23 10:13:35 CEST 2013



On 22.05.2013 15:49, Fabian Borot wrote:
> Thank you Klaus, good idea, but I forgot to mention that when I
> configure the client w/o TLS using regular SIP/UDP/5060 I dont have
> that problem. When the BYE from the called side comes it is sent to
> the calling side without any problems. But I do see that the Contact
> and VIA reach the Proxy with Public IP:Ports (our NAT automatically
> changes the internal IP/ports by the Public ones really well). The
> IP:Port in the VIA, CONTACT are the same that the request brings at
> layer3 and 4 as well. So I don't bother doing the extra NAT
> configuration in the office. Maybe since the actual content of the
> TLS SIP call is encrypted the firewall does not change the and then
> they should reach the proxy with the private IP:Ports, causing this
> problem.

I think you just found the problem yourself. History showed that NAT 
traversal in the proxy is much more reliable then using the SIP-ALG in 
the firewall.

Thus, if you start using NAT traversal in the proxy, it would be good to 
disable the SIP-ALG in the firewall, as this often causes problems when 
multiple nodes try to be smart.

> I will try TCP and also adding some extra NAT handling configuration
> to the proxy.

I would suggest to disable the SIP-ALG in the NAT/firewall. Then start 
with UDP and TCP, and if the they work switch to TLS.

Using the NULL cipher as suggested by Daniel is a good idea, but 
requires that your client allows to configure the TLS cipher.

regards
Klaus


>
> thank you again
>
>
>
>
>
> ----------------------------------------
>> Date: Wed, 22 May 2013 10:14:15 +0200 From:
>> klaus.mailinglists at pernau.at To: sr-users at lists.sip-router.org CC:
>> fborot at hotmail.com Subject: Re: [SR-Users] TLS and SIP
>>
>>
>>
>> On 21.05.2013 21:54, Fabian Borot wrote:
>>> Hi
>>>
>>> I am using Kamailio 4.0.1 in front of an asterisk servers farm to
>>> handle TLS with our clients and providers. The idea is to have
>>> kamailio "talking" SIP/UDP/5060 and TLS/TCP/5061 with the
>>> customers and providers and regular SIP/UDP/5060 with our
>>> internal asterisk servers.
>>>
>>> So far at least for the customers it looks like it can work. But
>>> I have a problem, when the call is established and the called
>>> person hangs up, the BYE from the called person to the calling
>>> person is ignored. Only when the calling person hangs up first
>>> the call is terminated properly.
>>>
>>> This is what I have been able to see:
>>>
>>> 1- Customer starts the TLS handshake/connection. 2- Kamailio
>>> authenticate it, then routes the call to the asterisk server
>>> using regular SIP/UDP/5060 but I see that it is inserting 2
>>> Record Routes in the INVITE:
>>>
>>> Record-Route: <sip:192.168.1.58;r2=on;lr=on>
>>>
>>> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on>
>>>
>>> 3- The Contact on that INVITE to the asterisk also comes like
>>> this:
>>>
>>> Contact: <sip:94167032 at 172.31.196.21:53325;transport=tls>
>>
>> Next time please show the whole message (without SDP) as Via would
>> be interesting too.
>>>
>>> 4- The ACK sent to the asterisk once it accepts the call (200 OK)
>>> also has those 2 Record-Routes:
>>>
>>> Record-Route: <sip:192.168.1.58;r2=on;lr=on>
>>>
>>> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on>
>>>
>>> 5- The call is established, once the called person decides to
>>> hang up the BYE looks like this:
>>>
>>> BYE sip:94167032 at 172.31.196.21:53325;transport=tls SIP/2.0 Via:
>>> SIP/2.0/UDP 192.168.1.59:5060;branch=z9hG4bK40fa1c23;rport Route:
>>> <sip:192.168.1.58;r2=on;lr=on>,<sip:192.168.1.58:5061;transport=tls;r2=on;lr=on>
>>>
>>>
Max-Forwards: 70
>>> From: <sip:3030500 at 1.2.3.4>;tag=as37953869 To: "kamailio"
>>> <sip:kamailio at 1.2.3.4>;tag=788cd7c892df40f3b1967112395e2ca4
>>> Call-ID: f9fe65daf1074219be26cb0c224339f1 CSeq: 102 BYE
>>> User-Agent: Asterisk PBX 11.3.0 X-Asterisk-HangupCause: Normal
>>> Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0
>>>
>>> My kamailio TLS config is shown below:
>>>
>>> enable_tls=yes
>>>
>>> loadmodule "tls.so"
>>>
>>> # ----- tls params ----- modparam("tls", "config",
>>> "/usr/local/kamailio-4.1//etc/kamailio/tls.cfg") modparam("tls",
>>> "private_key", "./privkey.pem") modparam("tls", "certificate",
>>> "./kamailio1_cert.pem") modparam("tls", "ca_list",
>>> "./calist.pem") modparam("tls", "verify_certificate", 1)
>>> modparam("tls", "require_certificate", 1)
>>>
>>> The TLS client that I am using is called Blink.At this point I
>>> don't know whether kamailio is sending the BYE using TLS to the
>>> customer and waiting for the 200 OK from the customer or whether
>>> kamailio does not like something in the BYE and that is why is
>>> ignoring it.
>>>
>>> I see some encrypted packets from kamailio to the client but I
>>> don't know what is inside. Any help would be very appreciated.
>>
>> I guess this is a NAT problem (or similar) and the proxy is not
>> able to signal requests back to the client. When the client sends
>> the INVITE, the client opens a TLS connection (or uses the one
>> which was established during REGISTER). This existing TLS
>> connection must be used by the proxy to send requests to the
>> client. Therefore you have to use NAT traversal methodes, eg.
>> add_contact_alias() or the new outbound stuff.
>>
>> Anyway - first disable TLS und try TCP. TCP has the exact same
>> problems but is much easier to debug. Only if TCP work fine, then
>> try to use TLS.
>>
>> regards Klaus



More information about the sr-users mailing list