[SR-Users] TLS and SIP

[Klaus Darilion]

Hi Fabian!

See http://www.kamailio.org/wiki/tutorials/tls/testing-and-debugging for 
TLS debugging.

fix_nated_contact() is old-style NAT traversal. It basically works, but 
is a bit intrusive and may cause problems with strict clients. Nowadays 
add_contact_alias() and handle_ruri_alias() is the preferred method.

If you can not disable the ALG and run into problems, it may be possible 
to bypass the ALG by using a different port instead port 5060.

regards
Klaus

On 23.05.2013 15:59, Fabian Borot wrote:
> Thank you guys, I added this line "fix_nated_contact();" and it made the trick. Unfortunately I can not change the SIP-ALG on the firewall.
> I am curious about the null cipher option, is there an example of the TLS configuration tutorials?
> thank you again
>
> ----------------------------------------
>> Date: Thu, 23 May 2013 10:13:35 +0200
>> From: klaus.mailinglists at pernau.at
>> To: fborot at hotmail.com
>> CC: sr-users at lists.sip-router.org
>> Subject: Re: [SR-Users] TLS and SIP
>>
>>
>>
>> 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