[SR-Users] SSL Offloading with AWS ELB or Google GSLB and Kamailio

David Villasmil david.villasmil.work at gmail.com
Thu Oct 10 00:34:53 CEST 2019


Out of curiosity, is this on AWS?

On Wed, 9 Oct 2019 at 23:33, David Villasmil <david.villasmil.work at gmail.com>
wrote:

> It looks pretty clear to me. I think whenever kamailio “sees” that
> protocol specification it will switch to that. Have you tried forcing the
> socket? Just wondering whether that would work.
>
> On Wed, 9 Oct 2019 at 20:33, Joel Serrano <joel at textplus.com> wrote:
>
>> Hi everyone,
>>
>> I was giving a try to setup Kamailio with a Cloud TCP load balancer in
>> front, taking advantage of the newly added proxy protocol compatibility and
>> my initial tests went very well.
>>
>> Flow: client -> (tcp) -> load balancer -> (tcp) -> Kamailio TCP socket
>>
>> I then did another quick test and enabled TLS, also with good results:
>>
>> Flow: client -> (tls) -> load balancer -> (tls) -> Kamailio TLS socket
>>
>> So far so good, proxy protocol works as expected.
>>
>> I wanted to go one step further and see if I could somehow offload SSL
>> operations at the load balancer level, and leave kamailio handling plain
>> tcp.
>>
>> Flow: client -> (tls) -> load balancer -> (tcp) -> Kamailio TCP socket
>>
>> This partially worked, and before I start digging into what I have to do
>> to get it completely working, I'd like to know if anyone already has a
>> similar setup, or even if Kamailio is able to handle such a scenario, the
>> reason I'm asking is because of the headers, etc.
>>
>> In this last scenario, I receive in a TCP socket, a request with TLS
>> headers all over the place..
>>
>> INVITE sip:14a84f2016944eb0854ef0e9b71bfa10 at app.mydomain.com:60655 SIP/2.0
>> Via: SIP/2.0/TLS 192.168.1.16:60717;branch=z9hG4bK.KmUpamn5P;rport
>> From: ...
>> To: ...
>> CSeq: 21 INVITE
>> Call-ID: -j1QSnam9o
>> Max-Forwards: 70
>> Route: <sip:sbc-test2.mydomain.com:443;lr>
>> Supported: replaces, outbound
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
>> Content-Type: application/sdp
>> Content-Length: 436
>> Contact: <sip:linphone at A.B.C.D:60717;transport=tls>;+sip.instance="<urn:uuid:fabcb441-a348-49a7-948d-72448d6840eb>"
>>
>>
>> I then forward this request via UDP to subsequent proxies for further
>> processing, on the replies, my payload information back to the client
>> should be TLS, although sent via a TCP socket..
>>
>> Is this something that will not work by design? Is there any hack I can
>> take advantage of?
>>
>> The goal would be for Kamailio to handle TLS headers via TCP socket, as
>> the client expects TLS information, but the actual traffic should go in
>> plan TCP, and the load balancer will take care of re-encrypting before
>> replying to the client.
>>
>> Any ideas/suggestions/comments?
>>
>> I hope this email is understandable, I find it complicated to detail the
>> exact problem, feel free to ask any questions if you don't understand
>> anything.
>>
>> Thanks,
>> Joel.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Regards,
>
> David Villasmil
> email: david.villasmil.work at gmail.com
> phone: +34669448337
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191009/d14a3f24/attachment.html>


More information about the sr-users mailing list