Re: [OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
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: ;reg-id=2;+sip.instance="" 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: ;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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
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: ;reg-id=2;+sip.instance="" 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: ;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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
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: ;reg-id=2;+sip.instance="" 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: ;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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
Hi, again,
Did this work any time before?
I have force_rport(), fix_nated_register() active and as follows:
if (nat_uac_test("diff-ip-src-contact")) {
if (is_method("REGISTER")) {
fix_nated_register();
setbflag("NAT");
} else {
fix_nated_contact(); <
setflag("NAT");
}
}
But in my tcpdump I only see 1 natted address. Which would mean opensips
suddenly forgets the register with the other natted address
fix_nated_register().
we would like to see both natted ip adresses. The public IPv4 address is the
only one addressed.
Regards
Ronald
September 2, 2023 at 2: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: **
> ;**reg-id=**2;+sip.instance="
> urn:uuid:--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: **
> ;expire**s=**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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
Hi Ray, I am interested the solution or comments you receive. I have a similar problem. I have no voice or oneway voice on one of the clients. But I could work around it as I am using softphones on iphones as client. My work around was to turn wifi off on one of the clients, so this client gets the public IP of the phone subscription. But I still have this problem is both clients are in the same NAT. Regards, Ronald September 2, 2023 at 2: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: ** > ;**reg-id=**2;+sip.instance=" > urn:uuid:--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: ** > ;expire**s=**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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Wrong TCP socket being used on TLS registrations
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: ;reg-id=2;+sip.instance="" 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: ;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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
