[SR-Users] TLS in-dialog set_forward_no_connect()and upstream TLS LCR gateway
Anthony Joseph Messina
amessina at messinet.com
Sun Sep 15 03:34:06 CEST 2019
I'm going to keep testing against the issue I originally reported, and
probably wait until after 5.3 is released. My issue may also be related to a
combination of TCPOPS keepalive not keeping the proper connection open for
UAC -> Kamailio/LCR -> TLS Gateway
The connection that's kept open to the TLS Gateway is the original forward of
the INVITE
<Kamailio IP>:<ephemeral port> -> <TLS Gateway>:<Port 5061>
The subsequent in-dialog connections (such as BYE from the UAC to the TLS
Gateway) don't use the original TLS connection so they are prevented from re-
connecting to the TLS Gateway.
Again, I have to do more testing to clear up the root issue on my end.
Also, for a more compact config, would the following achieve the same thing...
route[NATMANAGE] {
#!ifdef WITH_NAT
if(is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
### Add the command here....
set_forward_no_connect();
}
}
}
...
On Wednesday, September 11, 2019 1:21:34 AM CDT Daniel-Constantin Mierla
wrote:
> It no longer looks like an issue related to set_reply_no_connect() or
> set_forward_no_connect() added by the commit you referenced. Those were
> added to prevent attempting to connect to devices behind the nat (in
> that case the device has to maintain the connection, otherwise nobody
> can connect back to it) as well as prevent someone in the wild sending a
> request then closing the connection, without waiting for the reply,
> which is typically routed back to via, commonly with an ephemeral port.
>
> The follow up commit I did it in master recently is no longer setting
> the flag for requests within dialog, but I understand you have
> connection problems for requests within dialog, am I right?
>
> Cheers,
> Daniel
>
> On 10.09.19 01:08, Anthony Joseph Messina wrote:
> > 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/20190914/c54a1509/attachment.sig>
More information about the sr-users
mailing list