| Summary: | ASTERISK-20973: Insecure=very does not work if callerId found in extention | ||
| Reporter: | Badalian Vyacheslav (slavon) | Labels: | |
| Date Opened: | 2013-01-22 23:35:50.000-0600 | Date Closed: | 2013-03-07 10:18:21.000-0600 |
| Priority: | Major | Regression? | Yes |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | 1.8.20.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Hello all.
Bug Example: I use FreePBX (but i belive that bug in asterisk) and have 1 peer and 10 extentions (assigned numbers is 100-110) Host configuration like this: [ext-ats] type=peer host=IP insecure=invite,port context=from-trunk disallow=... allow=... If i call from [ext-ats] to * and my CallerID is 100 (i have extention 100 in asterisk) i get message like "Auth failed", "username and digest mismatch", but if i call from number Callerid 1000 (i don't have extention 1000 in asterisk) param "insecure" is work as it must. In older version (1.4-1.6) insecure does not check callerid, only host and port. | ||
| Comments: | By: Rusty Newton (rnewton) 2013-01-23 09:54:09.017-0600 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Please post an Asterisk full log with VERBOSE and DEBUG messages enabled to demonstrate the issue. This issue is very likely configuration related. We'll take a quick look at the debug, but you may be referred back to user forums or mailing lists where you can get further help to narrow down the issue. By: David Woolley (davidw) 2013-01-28 05:39:02.896-0600 You seem to be referring to insecure=invite, i.e. the port option is not relevant. Although widely recommended by ITSPs, insecure=port,invite is rarely the most appropriate setting. This is a case of when presented with a security feature that is getting in the way, disable it completely, rather than using a least privilege approach. insecure never controlled the matching by extension (URI in method line). In fact it doesn't control the match at all (which is done based on IP address or From: header); it controls whether or not, once matched, a 401 response is sent if there is no authentication data on the request, but there is on the sip.conf entry. Extension matching is performed against extensions.conf, not sip.conf. The subject is misleading, because insecure=very, itself, is now ignored by Asterisk. By: Walter Doekes (wdoekes) 2013-02-18 15:02:19.956-0600 I don't think you're showing us your entire {{sip.conf}}. If you did, I think we'd see type=user/friend entries named [100]. And that would present a problem for asterisk: - is the device calling from 1.2.3.4 (the IP) now [100] or [ext-ats] ? - let's ask the device to authenticate - ext-ats will send something, and it probably won't match the CLI (see match_auth_username=yes to fix that) When the CLI is 1000, asterisk doesn't find a user/friend and will then immediately conclude that the device must be [ext-ats] => now things will work like expected. By: Matt Jordan (mjordan) 2013-03-07 10:18:16.131-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines | ||