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
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. thank you
fabian
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:
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
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 will try TCP and also adding some extra NAT handling configuration to the proxy.
thank you again
----------------------------------------
Date: Wed, 22 May 2013 10:14:15 +0200 From: klaus.mailinglists@pernau.at To: sr-users@lists.sip-router.org CC: fborot@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:
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
On 5/22/13 3:49 PM, 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 will try TCP and also adding some extra NAT handling configuration to the proxy.
you can also try using NULL cypher for tls in order to see the content in clear text.
Cheers, Daniel
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@pernau.at To: sr-users@lists.sip-router.org CC: fborot@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:
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
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@pernau.at To: fborot@hotmail.com CC: sr-users@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@pernau.at To: sr-users@lists.sip-router.org CC: fborot@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:
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
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@pernau.at To: fborot@hotmail.com CC: sr-users@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@pernau.at To: sr-users@lists.sip-router.org CC: fborot@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:
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
Hello,
On 5/23/13 5:47 PM, Klaus Darilion wrote:
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.
fyi, the latest default config file uses this approach with contact/uri alias, so you may look at it and see how to replace the old approach that replaced the contact address.
Cheers, Daniel
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@pernau.at To: fborot@hotmail.com CC: sr-users@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@pernau.at To: sr-users@lists.sip-router.org CC: fborot@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:
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
"FB" == Fabian Borot fborot@hotmail.com writes:
FB> modparam("tls", "private_key", "./privkey.pem")
FB> I see some encrypted packets from kamailio to the client but I don't FB> know what is inside. Any help would be very appreciated.
If you record the full packet trace, wireshark can use your privkey.pem to decode the tls handshake, recover the session key, and use that to decode the payload packets.
Cf http://wiki.wireshark.org/SSL for details.
-JimC -- James Cloos cloos@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
On May 22, 2014, at 6:46 PM, James Cloos cloos+openser-users@jhcloos.com wrote:
If you record the full packet trace, wireshark can use your privkey.pem to decode the tls handshake, recover the session key, and use that to decode the payload packets.
Cf http://wiki.wireshark.org/SSL for details.
This is true if you are not using an ephemeral Diffie Hellman cypher suite.
HTH --FC
"FC" == Frank Carmickle frank@carmickle.com writes:
JC>> If you record the full packet trace, wireshark can use your privkey.pem JC>> to decode the tls handshake, recover the session key, and use that to JC>> decode the payload packets.
FC> This is true if you are not using an ephemeral Diffie Hellman cypher suite.
Good point. A quick test shows that contacting asterisk-11 over tls/tcp negotiates rsa key exchange; kamailio does better and agrees to ECDHE-RSA.
If the trace is of kama talking to asterisk ephemeral is not likely. Asterisk-12 may be better; I cannot test right now. Nor can I test freeswitch.
-JimC
On May 23, 2014, at 12:43 PM, James Cloos cloos@jhcloos.com wrote:
"FC" == Frank Carmickle frank@carmickle.com writes:
JC>> If you record the full packet trace, wireshark can use your privkey.pem JC>> to decode the tls handshake, recover the session key, and use that to JC>> decode the payload packets.
FC> This is true if you are not using an ephemeral Diffie Hellman cypher suite.
Good point. A quick test shows that contacting asterisk-11 over tls/tcp negotiates rsa key exchange; kamailio does better and agrees to ECDHE-RSA.
If the trace is of kama talking to asterisk ephemeral is not likely. Asterisk-12 may be better; I cannot test right now. Nor can I test freeswitch.
Freeswitch does support most new features of openssl 1.0.1 branch. I believe it defaults to tls1.1 currently but I believe the goal is to only enable tls1.2, with ECDHE+AES128 by default. You can certainly ask it to do what ever openssl supports, except that right now ECDHE is hardcoded to p256.
--FC
"FC" == Frank Carmickle frank@carmickle.com writes:
FC> Freeswitch does support most new features of openssl 1.0.1 branch. I FC> believe it defaults to tls1.1 currently but I believe the goal is to FC> only enable tls1.2, with ECDHE+AES128 by default. You can certainly FC> ask it to do what ever openssl supports, except that right now ECDHE FC> is hardcoded to p256.
Excellent. Happy to know that.
-JimC -- James Cloos cloos@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
On Fri, May 23, 2014 at 3:10 PM, James Cloos cloos@jhcloos.com wrote:
"FC" == Frank Carmickle frank@carmickle.com writes:
FC> Freeswitch does support most new features of openssl 1.0.1 branch. I FC> believe it defaults to tls1.1 currently but I believe the goal is to FC> only enable tls1.2, with ECDHE+AES128 by default. You can certainly FC> ask it to do what ever openssl supports, except that right now ECDHE FC> is hardcoded to p256.
Excellent. Happy to know that.
To clarify further, FreeSWITCH allows enforcement of specific TLS version up to and including TLS 1.2 (depending on underlying OpenSSL support, of course). This is a per-profile configuration setting:
https://fisheye.freeswitch.org/browse/~raw,r=fd38a255f8f1fa3fa18b1b5263990af...
"JC" == James Cloos cloos@jhcloos.com writes:
JC> Good point. A quick test shows that contacting asterisk-11 over tls/tcp JC> negotiates rsa key exchange; kamailio does better and agrees to ECDHE-RSA.
JC> If the trace is of kama talking to asterisk ephemeral is not likely.
Sorry. I forgot which thread this was on, making the above irelevant.
As such, it is more likely than not that the tls used an ephemeral suite.
In that case, to debug it, one'd have to edit kama'a tls module to leak the incoming and outgoing session keys (probably to a file) and then, AFAICT, edit wireshark to let one specify a session key to decrypt the encrytped tls session.
Just be sure never to use the leaker in production.
-JimC -- James Cloos cloos@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
-
Daniel-Constantin Mierla -
Fabian Borot -
Frank Carmickle -
James Cloos -
James Cloos -
Klaus Darilion -
Kristian Kielhofner