[OpenSIPS-Users] $si showing contact address

[Gregory Massel]

Good day all

I'm picking up a weird issue where $si is reflecting the IP address of 
the contact rather then the IP packet header.

If I run "opensips-cli -x mi ul_show_contact location redacted at domain" I 
get:

"Contact": "sip:redacted at 1.2.3.1:45066",
"Received": "sip:102.132.225.36:45066",

When I look at my logs, it logged:

ACL mismatch for _*udp:1.2.3.1:45066*_ on REGISTER request for 
redacted at domain with auth-user redacted; ACL: "redacted".
xlog ("ACL mismatch for $socket_in(proto):*$si*:$sp on $rm request for 
$var(req_user)@$var(domain) with auth-user $au; ACL: \"$avp(acl)\".\n");

So it seems that, within this particular router, $si is actually being 
set to the contact IP rather than the IP source address.

Note that this check is done only after the MD5 authentication has 
completed. Even if the source failed to NAT the packet and arrived with 
spoofed IP source IP 1.2.3.1, it would never get to this point as I 
would first reply with a SIP 401 requesting authentication and they 
would never actually receive that 401 message and never be able to send 
me back an authenticated request.

If this were happening all the time, I'd expect to see tons of log 
entries with RFC1918 IP addresses, however, I don't and, in fact, this 
is an extreme rare log entry.

I do have the following which may or may not be relevant:

         force_rport();
         if (nat_uac_test(23)) {
                 if (is_method("REGISTER")) {
                         fix_nated_register();
                         setbflag("NAT");
                 } else {
                         fix_nated_contact();
                         setflag("NAT");
                 }
         }

However, I still don't understand why $si would ever reflect anything 
other then the actual source IP address as per the IP packet header.

I cannot retrospectively sniff the registration that caused this, 
however, I have sniffer a subsequent REGISTER packet from the same endpoint:

2023/01/29 18:47:46.104058 102.132.225.36:45066 -> x.x.x.x:5060
REGISTERsip:domain  SIP/2.0
Via: SIP/2.0/UDP 1.2.3.1:45066;branch=z9hG4bK1021971937;rport
From:<sip:redacted at domain>;tag=63384276
To:<sip:redacted at domain>
Call-ID:598699451-15089-1 at BJC.BGI.A.BAF
CSeq: 3158 REGISTER
Contact:<sip:redacted at 1.2.3.1:45066>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD4C7D1E>"
Authorization: Digest username="redacted", realm="domain", nonce="63d6a350000179c64cd75dec932c20a438d014ba0ed633e2", uri="sip:domain", response="e549d1261c9cc5534aa0783db28529
", algorithm=MD5
Max-Forwards: 70
User-Agent: redacted
Supported: path
Expires: 180
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

The script logged $si as 1.2.3.1 at 16:56:32, however, the above was 
sniffer at 18:47:46 and the script did NOT log 1.2.3.1.

I initially considered that www_authorize() versus pv_www_authorize() 
may be introducing this, so I flushed my cache to ensure that I'd tested 
using both. It's not related to this.

It really seems to be extremely arbitrary. There are tens of thousands 
of endpoints registered and, if this was happening consistently, I would 
expect to see at least hundreds, even thousands of such log entries, 
however, I've only found ONE so far.

It appears to be to be a bug, however, before logging as such I would 
like to verify whether, perhaps, there is a valid case where $si may be 
reset to a contact IP (e.g. by one of the NAT helper functions)?

Could the following, in any shape or form, ever result in $si being 
re-set to a new value:

if ( $(si{ip.matches,$(avp(acl){csv.value,$var(i)})}) == 1 )

And, no, I never accidentally used '=' instead of '==' and the value of 
$avp(acl) would have been "165.165.0.0/16,102.132.128.0/17".

I'm using OpenSIPS 3.1.13.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230129/a4e592b3/attachment.html>