[SR-Users] TLS and SIP

[Fabian Borot]

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