[OpenSIPS-Users] Wrong TCP socket being used on TLS registrations

[Bogdan-Andrei Iancu]

Hi Ray,

The "tcp_accept_aliases" should be harmless if there is no "alias" param 
received in the incoming requests. If no such parameter is pushed by the 
end-devices, there is 0 impact.

And indeed, this has a really ugly side effect for the (CG)NAT'd 
devices. But let's give it a try, disable this option and try the 
testing again, to see if the right conn is selected.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com

On 9/22/23 5:03 AM, Ray Jackson wrote:
>
> Hi Bogdan,
>
> Yes, we have the following enabled in our config:
>
> tcp_accept_aliases=1
>
> I assume this is the culprit then and we are inadvertently sending 
> calls down the wrong TCP socket here to the wrong user due to this 
> being enabled?  This is quite a nasty setting to have enabled when we 
> are dealing with CGNAT'd customers who are sharing public IP addresses 
> but are completely unrelated users!
>
> I will disable this setting and see if that clears up the issue for 
> us.  We have in fact had another case just today of the same issue 
> happening (User A is receiving User B's incoming calls!)
>
> Thanks for highlighting this and let me know if there is anything else 
> I should look at in our config.
>
> Thanks,
>
> Ray
>
> On 19/09/23 9:30 pm, Bogdan-Andrei Iancu wrote:
>
>> Hi Ray,
>>
>> Do you use any TCP aliasing options in your cfg ?
>>
>> Regards,
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    https://www.opensips-solutions.com
>>    https://www.siphub.com
>> On 9/2/23 3:17 AM, Ray Jackson wrote:
>>>
>>> Hi all,
>>>
>>> I'm facing a weird issue which I think is related to broken TCP 
>>> socket reuse logic where the wrong client is receiving incoming 
>>> calls due to the wrong socket being used for the incoming INVITE.
>>>
>>> The scenario is when I have 2 clients registering using TLS behind 
>>> NAT at the same Public IPv4 address and both clients are using the 
>>> same private port number.  So client 1 registers and the Via and 
>>> contact header looks like:
>>>
>>> Via: SIP/2.0/TLS 
>>> 192.168.42.162:5062;branch=z9hG4bK1409895926;rport;alias Contact: 
>>> <sip:201 at 192.168.42.162:5062;transport=tls>;reg-id=2;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD928AC4>"
>>>
>>> Client 2 registers from behind the same Public IPv4 address and the 
>>> Via and contact header looks like:
>>>
>>> Via: SIP/2.0/TLS 192.168.42.186:5062;branch=z9hG4bK-aff1f3b3 
>>> Contact: <sip:202 at 192.168.42.186:5062;transport=tls>;expires=300
>>>
>>> The location table shows Client 1 received field of 103.212.1.2:5062 
>>> and Client 103.212.1.2:23456
>>>
>>> When a call comes in for Client 1 the location lookup seems to 
>>> return the correct 'received' address and port (e.g. 
>>> 103.212.1.2:5062) and all the logs indicate that this is where the 
>>> SIP INVITE *should* be going to (in the $du field).  However when 
>>> you check the SIP traffic it selects Client 2's socket and the 
>>> traffic goes to port 23456 instead of 5062.
>>>
>>> I think this is related somehow to the TCP port reuse logic inside 
>>> Opensips.  My suspicion is that Opensips is looking at the Contact 
>>> or Via port number (which is the same for both client 1 and 2) and 
>>> then somehow mapping this to the wrong TCP received socket.
>>>
>>> Does anybody have any suggestions here?  Should I be fixing the NAT 
>>> in the Contact header (using fix_nated_contact).  I read somewhere 
>>> that you shouldn't rewrite the Contact header to avoid problems with 
>>> sending a different Contact URI to the client on calls.  Or is this 
>>> issue more related to the Via header and the TCP port reuse logic 
>>> looking at this port instead of the actual received port when 
>>> choosing the outgoing socket?
>>>
>>> FYI: I am using both force_rport() and fix_nated_register() for 
>>> incoming registrations from these clients and matching_mode of 0 in 
>>> usrloc.  However, I am not using fix_nated_contact() for registrations.
>>>
>>> Thanks,
>>>
>>> Ray
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230926/58f5a846/attachment-0001.html>