<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Good day all</p>
<p>I'm picking up a weird issue where $si is reflecting the IP
address of the contact rather then the IP packet header.</p>
<p>If I run "opensips-cli -x mi ul_show_contact location
redacted@domain" I get:<br>
</p>
"Contact": <a class="moz-txt-link-rfc2396E" href="sip:redacted@1.2.3.1:45066">"sip:redacted@1.2.3.1:45066"</a>,<br>
"Received": <a class="moz-txt-link-rfc2396E" href="sip:102.132.225.36:45066">"sip:102.132.225.36:45066"</a>,
<p>When I look at my logs, it logged:</p>
ACL mismatch for <u><b>udp:1.2.3.1:45066</b></u> on REGISTER
request for redacted@domain with auth-user redacted; ACL:
"redacted".<br>
xlog ("ACL mismatch for $socket_in(proto):<b>$si</b>:$sp on $rm
request for $var(req_user)@$var(domain) with auth-user $au; ACL:
\"$avp(acl)\".\n");
<p>So it seems that, within this particular router, $si is actually
being set to the contact IP rather than the IP source address.</p>
<p>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.</p>
<p>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.</p>
<p>I do have the following which may or may not be relevant:<br>
</p>
<pre> force_rport();
if (nat_uac_test(23)) {
if (is_method("REGISTER")) {
fix_nated_register();
setbflag("NAT");
} else {
fix_nated_contact();
setflag("NAT");
}
}
</pre>
<p>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.</p>
<p>I cannot retrospectively sniff the registration that caused this,
however, I have sniffer a subsequent REGISTER packet from the same
endpoint:</p>
<pre>2023/01/29 18:47:46.104058 102.132.225.36:45066 -> x.x.x.x:5060
REGISTER <a class="moz-txt-link-freetext" href="sip:domain">sip:domain</a> SIP/2.0
Via: SIP/2.0/UDP 1.2.3.1:45066;branch=z9hG4bK1021971937;rport
From: <a class="moz-txt-link-rfc2396E" href="sip:redacted@domain"><sip:redacted@domain></a>;tag=63384276
To: <a class="moz-txt-link-rfc2396E" href="sip:redacted@domain"><sip:redacted@domain></a>
Call-ID: <a class="moz-txt-link-abbreviated" href="mailto:598699451-15089-1@BJC.BGI.A.BAF">598699451-15089-1@BJC.BGI.A.BAF</a>
CSeq: 3158 REGISTER
Contact: <a class="moz-txt-link-rfc2396E" href="sip:redacted@1.2.3.1:45066"><sip:redacted@1.2.3.1:45066></a>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-C074AD4C7D1E>"
Authorization: Digest username="redacted", realm="domain", nonce="63d6a350000179c64cd75dec932c20a438d014ba0ed633e2", uri=<a class="moz-txt-link-rfc2396E" href="sip:domain">"sip:domain"</a>, 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
</pre>
<p>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. <br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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)?</p>
<p>Could the following, in any shape or form, ever result in $si
being re-set to a new value:</p>
<pre>if ( $(si{ip.matches,$(avp(acl){csv.value,$var(i)})}) == 1 )
</pre>
<p>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".<br>
</p>
<p>I'm using OpenSIPS 3.1.13.</p>
<p>Thanks</p>
<p><br>
</p>
</body>
</html>