<div><div dir="auto">Out of curiosity, is this on AWS?</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2019 at 23:33, David Villasmil <<a href="mailto:david.villasmil.work@gmail.com">david.villasmil.work@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">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.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Oct 2019 at 20:33, Joel Serrano <<a href="mailto:joel@textplus.com" target="_blank">joel@textplus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi everyone, <br><div><br></div><div>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.</div><div><br></div><div>Flow: client -> (tcp) -> load balancer -> (tcp) -> Kamailio TCP socket</div><div><br></div><div>I then did another quick test and enabled TLS, also with good results:</div><div><br></div><div><div>Flow: client -> (tls) -> load balancer -> (tls) -> Kamailio TLS socket</div><div><br></div><div>So far so good, proxy protocol works as expected.</div><div><br></div><div>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.</div></div><div><br></div><div>Flow: client -> (tls) -> load balancer -> (tcp) -> Kamailio TCP socket</div><div><br></div><div>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.</div><div><br></div><div>In this last scenario, I receive in a TCP socket, a request with TLS headers all over the place..</div><div><br></div><div><pre style="box-sizing:inherit;margin-top:4px;margin-bottom:4px;padding:8px;font-size:12px;line-height:1.50001;font-variant-ligatures:none;white-space:pre-wrap;word-break:normal;border-radius:4px;color:rgb(29,28,29);font-family:Monaco,Menlo,Consolas,"Courier New",monospace">INVITE <a href="http://sip:14a84f2016944eb0854ef0e9b71bfa10@app.mydomain.com:60655" target="_blank">sip:14a84f2016944eb0854ef0e9b71bfa10@app.mydomain.com:60655</a> SIP/2.0<br style="box-sizing:inherit">Via: SIP/2.0/TLS 192.168.1.16:60717;branch=z9hG4bK.KmUpamn5P;rport<br style="box-sizing:inherit">From: ...<br style="box-sizing:inherit">To: ...<br style="box-sizing:inherit">CSeq: 21 INVITE<br style="box-sizing:inherit">Call-ID: -j1QSnam9o<br style="box-sizing:inherit">Max-Forwards: 70<br style="box-sizing:inherit">Route: <sip:<a rel="noopener noreferrer" style="box-sizing:inherit;color:inherit;text-decoration-line:none">sbc-test2.mydomain.com:443;lr></a><br style="box-sizing:inherit">Supported: replaces, outbound<br style="box-sizing:inherit">Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE<br style="box-sizing:inherit">Content-Type: application/sdp<br style="box-sizing:inherit">Content-Length: 436<br style="box-sizing:inherit">Contact: <sip:linphone@A.B.C.D:60717;transport=tls>;+sip.instance="<urn:uuid:fabcb441-a348-49a7-948d-72448d6840eb>"</pre></div><div><br></div><div>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..</div><div><br></div><div>Is this something that will not work by design? Is there any hack I can take advantage of?</div><div><br></div><div>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.</div><div><br></div><div>Any ideas/suggestions/comments? </div><div><br></div><div>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.</div><div><br></div><div>Thanks, </div><div>Joel.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div><div><br></div>David Villasmil<div>email: <a href="mailto:david.villasmil.work@gmail.com" target="_blank">david.villasmil.work@gmail.com</a></div><div>phone: +34669448337</div></div></div>