[SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway

Anthony Joseph Messina amessina at messinet.com
Tue Sep 10 01:08:58 CEST 2019


I still ran into some trouble when one side was NAT'd.

Am I correct in thinking that it would be undesirable to maintain a TCP/TLS 
connection to an upstream TLS gateway that is using the well-known port 5061?

I was thinking this may be a case for TCP_REUSEPORT and force_send_socket, but 
that seems a little complex seeing as I can just let Kamailio reconnect (when 
necessary) rather than preventing the outbound TLS from connecting when it 
would otherwise succeed.

I'll try and work through more detailed configuration scenarios.  -A

On Monday, September 9, 2019 2:12:07 AM CDT Daniel-Constantin Mierla wrote:
> Hello,
> 
> I relaxed that condition to not connect on forwarding only for initial
> requests going though nat. Can you test with latest master and see how
> is going for your use case?
> 
> Cheers,
> Daniel
> 
> On 09.09.19 02:00, Anthony Joseph Messina wrote:
> > In preparation for the 5.3 release, I've been testing the following
> > configuration change for TCP/TLS connections:
> > 
> > https://github.com/kamailio/kamailio/commit/
> > 8bba208fe6ae7ccb4c92362b8c33f1530b9f56da
> > 
> > route[REQINIT] {
> > 
> >         # no connect for sending replies
> >         set_reply_no_connect();
> >         if(has_totag()) {
> >         
> >                 # no connect for requests within dialog
> >                 set_forward_no_connect();
> >         
> >         }
> > 
> > This change creates issues when a UAC TLS INVITE routes to an upstream
> > gateway using TLS to port 5061 (via the LCR module).  Kamailio sends the
> > initial outbound TLS connection from a local ephemeral port.  The TCPOPS
> > tcp_keepalive_enable function issues keepalives from the local ephemeral
> > port to the gateway port 5061:
> > 
> > https://kamailio.org/docs/modules/stable/modules/
> > tcpops#tcpops.f.tcp_keepalive_enable
> > 
> > Even so, the TLS connection eventually times out, after which in-dialog
> > requests from the UAC are no longer able to reach the upstream gateway.
> > 
> > ERROR: tm [../../core/forward.h:293]: msg_send_buffer(): tcp_send failed
> > WARNING: tm [t_fwd.c:1570]: t_send_branch(): sending request on branch 0
> > failed
> > ERROR: sl [sl_funcs.c:372]: sl_reply_error(): stateless error reply used:
> > Unfortunately error on sending to next hop occurred (477/SL)
> > 
> > I figure I must be doing something wrong with my TCPOPS here.  Is a TLS
> > connection to an upstream gateway supposed to be maintained throughout the
> > duration of a call?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190909/1d223ad7/attachment.sig>


More information about the sr-users mailing list