[SR-Users] Source Port on TLS OPTIONS from Dispatcher
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jan 13 15:24:55 CET 2021
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
>> <mailto: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
>> <http://pstnhub.microsoft.com/>") {
>> $var(domain) = $fd;
>> append_hf("Contact: <sip:$var(domain):5061;transport=tls
>> <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
>> <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
>> <sip:$var(domain):5061;transport=tls>";
>> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> <sip:$var(domain):5061;transport=tls>", "sip:sip3.pstnhub.microsoft.com;transport=tls
>> <sip:sip3.pstnhub.microsoft.com;transport=tls>", "", "From:
>> sip:$var(domain) <sip:$var(domain)>\r\nTo:
>> sip:sip3.pstnhub.microsoft.com;transport=tls
>> <sip:sip3.pstnhub.microsoft.com;transport=tls>\r\nContact:
>> <sip:$var(domain):5061;transport=tls
>> <sip:$var(domain):5061;transport=tls>>\r\n", "");
>> sleep(2);
>> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> <sip:$var(domain):5061;transport=tls>", "sip:sip2.pstnhub.microsoft.com;transport=tls
>> <sip:sip2.pstnhub.microsoft.com;transport=tls>", "", "From:
>> sip:$var(domain) <sip:$var(domain)>\r\nTo:
>> sip:sip2.pstnhub.microsoft.com;transport=tls
>> <sip:sip2.pstnhub.microsoft.com;transport=tls>\r\nContact:
>> <sip:$var(domain):5061;transport=tls
>> <sip:$var(domain):5061;transport=tls>>\r\n", "");
>> sleep(2);
>> t_uac_send ("OPTIONS", "sip:$var(domain):5061;transport=tls
>> <sip:$var(domain):5061;transport=tls>", "sip:sip.pstnhub.microsoft.com;transport=tls
>> <sip:sip.pstnhub.microsoft.com;transport=tls>", "", "From:
>> sip:$var(domain) <sip:$var(domain)>\r\nTo:
>> sip:sip.pstnhub.microsoft.com;transport=tls
>> <sip:sip.pstnhub.microsoft.com;transport=tls>\r\nContact:
>> <sip:$var(domain):5061;transport=tls
>> <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
>> <sip:100.sbc.*mydomain*.net>>;tag=3393f0703fb0ccaca74109ff37de39f5-5a503a0a
>> TO: <sip:sip3.pstnhub.microsoft.com <sip:sip3.pstnhub.microsoft.com>>
>> CSEQ: 10 OPTIONS
>> CALL-ID: 0f37a09f409a4e41-24410 at 127.0.0.1
>> <mailto: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
>> <sip:101.sbc.*mydomain*.net>>;tag=3393f0703fb0ccaca74109ff37de39f5-69555a28
>> TO: <sip:sip3.pstnhub.microsoft.com <sip:sip3.pstnhub.microsoft.com>>
>> CSEQ: 10 OPTIONS
>> CALL-ID: 0f37a09f409a4e44-24410 at 127.0.0.1
>> <mailto: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 <mailto: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 <mailto: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 <mailto:joel at textplus.com>>
>>>>>> To: "Kamailio (SER) - Users Mailing List"
>>>>>> <sr-users at lists.kamailio.org <mailto: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
>>>>>> <mailto: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
>>>>>> <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 <mailto: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 List
>>>>>> sr-users at lists.kamailio.org
>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>> --
>>>>> Daniel-Constantin Mierla -- www.asipto.com
>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>> Funding: https://www.paypal.me/dcmierla
>>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Funding: https://www.paypal.me/dcmierla
>>
>
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210113/752b3688/attachment.htm>
More information about the sr-users
mailing list