Re: [SR-Users] TLS and SIP

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(a)pernau.at > To: fborot(a)hotmail.com > CC: sr-users(a)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(a)pernau.at To: sr-users(a)lists.sip-router.org CC: >>> fborot(a)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@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@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@1.2.3.4>;tag=as37953869 To: "kamailio" >>>> <sip:kamailio@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