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@domain" I
get:
"Contact": "sip:redacted@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@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@domain>;tag=63384276
To:<sip:redacted@domain>
Call-ID:598699451-1508...@bjc.bgi.a.baf
CSeq: 3158 REGISTER
Contact:<sip:redacted@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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
