[SR-Users] Source Port on TLS OPTIONS from Dispatcher
Sergey Basov
sergey.v.basov at gmail.com
Thu Jan 14 19:04:30 CET 2021
Hi All,
For TCP proto this is normal behaviour, originating from random port.
To work with TLS/TCP on client side you need set insecure=port for Asterisk
(this just for example).
I have another issue, options in dialog(TCP/TLS) to check if dialog alive,
they are sending from random port, but in my case dialog was established
and call running.
But when I have time I will make debug, tcp dump and open issue on tracker.
--
WBR
Sergey Basov
ср, 13 янв. 2021 г., 16:29 Daniel-Constantin Mierla <miconda at gmail.com>:
> SIP transactions are decoupled from the transport layer, by specs, the
> connections have to be reused for the same target ip/port.
>
> Cheers,
> Daniel
> On 12.01.21 16:51, Charles Phillips wrote:
>
> It is my understanding that for outbound connections, subsequent
> transactions to the same destination IP:port reuse an existing TLS socket
> (if one exists) by design. By the logs, it appears that this matching
> takes place early in the processing so there is no regard for a new
> outbound transaction that has different SNI. Is this correct? Is there a
> way to force a new outbound TLS connection for a new transaction based on
> some other identifier?
>
>
> - Charles Phillips
>
>
>
>
> On Jan 11, 2021, at 9:00 AM, Charles Phillips <charles at rustybike.com>
> wrote:
>
> That is what I figured was happening. I have tried sending it back to a
> standard routing block, but perhaps I am doing it incorrectly.
>
> When I try to send it back to a regular routing block I get the following
> error:
>
> CRITICAL: tm [tm.c:1754]: _w_t_relay_to(): unsupported route type: 64
>
> Config:
>
> event_route[tm:local-request] {
> sip_trace();
> if(is_method("OPTIONS") && $ru =~ "pstnhub.microsoft.com") {
> $var(domain) = $fd;
> append_hf("Contact: <sip:$var(domain):5061;transport=tls>\r\n");
> xlog("L_INFO", “TEAMS Contact: $var(domain)\r\n");
> route(TEAMS_SEND);
> }
> xlog("L_INFO", "Sent out tm request: $mb\n");
> }
>
> route[TEAMS_SEND] {
> $var(domain) = $fd;
> $xavp(tls=>server_name) = $var(domain);
> $xavp(tls[0]=>server_id) = $var(domain);
> $du = "sip:$var(domain):5061;transport=tls";
> t_relay();
> }
>
>
> For testing, I also tried generating the packets in a normal route using
> t_uac_send and controlling it with rtimer. As ugly a hack that this
> approach is, it did manage to create the packets and set the xavp as
> required (although, it certainly wouldn’t help dispatcher know if a gateway
> is offline…). Additional trouble is that if a second domain attempts to
> send OPTIONS packets in the while loop (see below) it goes out the same TLS
> connection, so it is rejected.
>
> Config:
>
> route["PING-TEAMS"] {
> sql_query("db", "select domain from domain;", "domain_list");
> $var(i) = 0;
> while ($dbr(domain_list=>[$var(i),0]) != $null) {
> $var(domain) = $dbr(domain_list=>[$var(i),0]);
> xlog(“OPTIONS from domain name $var(domain)");
> $xavp(tls=>server_name) = $var(domain);
> $xavp(tls[0]=>server_id) = $var(domain);
> $du = "sip:$var(domain):5061;transport=tls";
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", "
> sip:sip3.pstnhub.microsoft.com;transport=tls", "", "From: sip:$var(domain)\r\nTo:
> sip:sip3.pstnhub.microsoft.com;transport=tls\r\nContact: <
> sip:$var(domain):5061;transport=tls>\r\n", "");
> sleep(2);
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", "
> sip:sip2.pstnhub.microsoft.com;transport=tls", "", "From: sip:$var(domain)\r\nTo:
> sip:sip2.pstnhub.microsoft.com;transport=tls\r\nContact: <
> sip:$var(domain):5061;transport=tls>\r\n", "");
> sleep(2);
> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls", "
> sip:sip.pstnhub.microsoft.com;transport=tls", "", "From: sip:$var(domain)\r\nTo:
> sip:sip.pstnhub.microsoft.com;transport=tls\r\nContact: <
> sip:$var(domain):5061;transport=tls>\r\n", "");
> sleep(5);
> $var(i) = $var(i) + 1;
>
> }
> }
>
> 200 from MS on domain 0:
>
> 2021/01/11 08:48:31.291048 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 200 OK
> FROM: <sip:100.sbc.*mydomain*.net
> >;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
> TO: <sip:sip3.pstnhub.microsoft.com>
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e41-24410 at 127.0.0.1
> VIA: SIP/2.0/TLS
> *myip*:5061;branch=z9hG4bK9306.42d92227000000000000000000000000.0
> CONTENT-LENGTH: 0
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>
>
> 403 from MS on domain 1:
>
> 2021/01/11 08:49:39.755005 52.114.7.24:5061 -> *myip*:52606
> SIP/2.0 403 Forbidden
> FROM: <sip:101.sbc.*mydomain*.net
> >;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
> TO: <sip:sip3.pstnhub.microsoft.com>
> CSEQ: 10 OPTIONS
> CALL-ID: 0f37a09f409a4e44-24410 at 127.0.0.1
> VIA: SIP/2.0/TLS
> *myip*:5061;branch=z9hG4bK4306.973e1562000000000000000000000000.0
> REASON: Q.850;cause=63;text="00cce062-66c6-45a4-8b5c-ccd48b71a9f6;Provided
> Trunk FQDN '101.sbc.*mydomain*.net' is not allowed. Connection allows
> ollowing fqdns: 100.sbc.*mydomain*.net, 100.sbc.*mydomain*.net."
> CONTENT-LENGTH: 0
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
> SERVER: Microsoft.PSTNHub.SIPProxy v.2020.12.28.1 i.ASEA.0
>
>
>
> - Charles Phillips
>
>
>
>
> On Jan 11, 2021, at 4:13 AM, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
> Hello,
>
> the xavp_cfg set in the event_route is not propagated (kept) to the moment
> when the message is sent out to tls. The event_route[tm:local-request] is
> executed when the local request is constructed, terminated before sending
> out, so whatever avp/xavp is set in the event route are deleted when the
> block execution is terminated.
>
> It requires another solution here, I am thinking about what can be done
> and will be added soon in the master branch.
>
> Meanwhile, a workaround is to look traffic back to kamailio so the routing
> happens over request_route block, where you can set the xavp.
>
> Cheers,
> Daniel
> On 08.01.21 22:23, Charles Phillips wrote:
>
> Thanks Daniel, I needed some certainty to get unstuck. It appears that
> the problem is actually related to the TLS config. I am using multiple TLS
> configs, so it looks like the problem may be that the server_name server_id
> are not being set, so the reply is returning to the default TLS config.
> Not to mention that when I set the testing domains certs under the default
> config, it works...
>
> This is observed in the logs:
>
> tls_get_connect_server_name(): xavp with outbound server name not found
> tls_get_connect_server_id(): xavp with outbound server id not found
> tls_complete_init(): Using initial TLS domain TLSc<default>
>
> Is there a way to set this with xavp_cfg in the event_route? I have read
> that section and tried may combinations, but since the OPTIONs packets from
> the dispatcher module do not seem to traverse the standard routes, I am not
> sure how to handle this.
>
> Any advice would be greatly appreciated!
>
>
> - Charles Phillips
>
>
>
>
> On Jan 8, 2021, at 12:56 PM, Daniel-Constantin Mierla <miconda at gmail.com>
> wrote:
>
> Hello,
>
> there is an option that you can set to reuse the port for tcp/tls
> connections, but even so it is a best effort and it is not going to ensured
> -- all these are practically flags set to the sockets and the kernel (tcp
> stack) decides after all.
>
> Anyhow, the rport is mainly useful for connectionless communication, like
> UDP. For tcp/tls, the SIP specs demand to reuse the existing connections.
> As I did several Kamailio-MSTeams interconnectivity deployments, I can tell
> that the source port was never a problem. The TLS connection is kept open
> and MSTeams sends back traffic on it.
>
> Cheers,
> Daniel
> On 08.01.21 14:32, Charles Phillips wrote:
>
> Thanks for the quick response Joel. Yes, I have read the article and I
> have tested and confirmed that I am correctly appending the contact header
> (I probably should have left that in the snippet for clarity). Below is an
> example of Kamailio setting up the connection. It is going out port 46245
> this time, but it is random.
>
> 07:59:23.572319 IP *my.kamailio.server*.46245 > *ms.teams.server*.sip-tls:
> Flags [P.], seq 1:518, ack 1, win 502, length 517
> 07:59:23.802458 IP *ms.teams.server*.sip-tls > *my.kamailio.server*.46245:
> Flags [P.], seq 1:3767, ack 518, win 2051, length 3766
>
> The TLS connection shows as successful in the logs.
>
>
> - Charles
>
>
> Date: Thu, 7 Jan 2021 19:12:10 -0800
> From: Joel Serrano <joel at textplus.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Source Port on TLS OPTIONS from Dispatcher
> Message-ID:
> <CAMtXxQnLtEyD=40cwKembxiyj3D778eK=+5JD7sL4CvYbYXF1g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Charles,
>
> I don't think your issue is rport, make sure you are setting the Contact
> header correctly.
>
> Have you checked this blog post:
> https://skalatan.de/en/blog/kamailio-sbc-teams ?
>
> There is a specific section that talks about how to tell Kamailio to send
> the OPTIONS like MS Teams wants them.
>
> Good luck,
> Joel.
>
>
> On Jan 7, 2021, at 7:31 PM, Charles Phillips <charles at rustybike.com>
> wrote:
>
> Hello all. As they say in radio, “long time listener, first time caller”
>
> Anyway, I am having trouble getting past the following road block and any
> help would be greatly appreciated.
>
> Kamailio version is 5.4.3
>
> When attempting to use dispatcher to send OPTIONS packets to several TLS
> destinations, the packets are leaving the Kamailio server on random ports.
> This is a problem because the servers I am sending the OPTIONS to (MS
> Teams) are enforcing rport so the responses are returned to a port that
> Kamailio is not listening on. I have tried to force the socket in the
> event route (relevant parts of snippet below) but it does not appear to
> help. I should also mention that I am not behind NAT and the TLS socket is
> specified in the dispatcher attrs.
>
> event_route[tm:local-request] {
> sip_trace();
>
>
> $fs = “tls:**ip-address**:5061”;
>
>
> }
>
> I have used Kamailio as a TLS server for many projects, but this is my
> first time as a client. I am sure I am missing something.
>
> - Charles
>
>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210114/c002e50c/attachment.htm>
More information about the sr-users
mailing list