| Summary: | ASTERISK-27457: chan_sip: Guests disallowed via TCP (or TLS) if existing peer from same IP. | ||||
| Reporter: | Alexander Traud (traud) | Labels: | patch | ||
| Date Opened: | 2017-12-04 05:23:32.000-0600 | Date Closed: | 2018-03-21 09:35:03 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/TCP-TLS | ||
| Versions: | 13.18.3 15.1.3 | Frequency of Occurrence | |||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) allowguest_with_tcp.patch | |||
| Description: | On default, Asterisk allows any peer to call extensions in the context named _default_. This is controlled via the parameter {{allowguest=yes}} in the configuration file _sip.conf_. That context must be specified in the dialplan configuration file _extensions.conf_. Such a peer does not need to be authorized - it can be a guest. This works if everyone is connected via UDP. This does not work if
1) the guest is connected via TCP (or TLS) and 2) a peer is connected from the same IP address already. Sounds unlikely. However, if the Asterisk is behind a NAT, and a registered peer is from the same NAT, and a guest (again from the same NAT) is trying to call via that Asterisk. That is even more likely, when that Asterisk is available via a fully-qualified domain-name (FQDN) and that FQDN offers a DNS-NAPTR entry. In that case, a good VoIP/SIP client prefers to connect via TLS. Consequently in such a scenario, both peers are connected via TLS. With the current source code, that second peer is not allowed as guest but is asked to authorize. The backtrace is: {code}handle_request_invite ↳ check_user_full ↳ check_peer_ok ↳ sip_find_peer ↳ sip_find_peer_full ↳ peer_ipcmp_cb_full{code} In {{check_peer_ok}}, the third/last call to {{sip_find_peer}} (that with the socket type as parameter value) returns not NULL (as with UDP) but the first TCP connected peer. Because of this, the subsequent source code returns the SIP message Unauthorized. This issue was caused as by [this change...| http://github.com/asterisk/asterisk/commit/4596fdb788435d8fe3fdf5c70afad718b6f214da] ([Review|http://reviewboard.asterisk.org/r/354/]). The referenced, previous [change was...| http://github.com/asterisk/asterisk/commit/fbad7a508d0c8d0b0c75474d2b7f9cbbcaa9b5e1] ([Review|http://reviewboard.asterisk.org/r/236/]). This issue was reported by [~stephane.chazelas] in July 2013 [already...|http://lists.digium.com/pipermail/asterisk-dev/2013-July/061526.html] The proposed workaround does not for for guests, therefore I report this issue today. As Stephane, I am not sure what [~dvossel] was about actually. Unfortunately, we cannot ask him anymore because he left the Asterisk platform in 2012. The attached patch fixes this because with TCP, each peer has its own source port. In other words: If the source ports differ, it cannot be the already connected peer, no matter which transport. Only if the ports match, the subsequent checks should be done. | ||||
| Comments: | By: Friendly Automation (friendly-automation) 2018-03-21 09:35:03.860-0500 Change 7430 merged by Jenkins2: chan_sip: Peers with distinct source ports don't match, regardless of transport. [https://gerrit.asterisk.org/7430|https://gerrit.asterisk.org/7430] By: Friendly Automation (friendly-automation) 2018-03-21 09:44:30.577-0500 Change 7429 merged by Jenkins2: chan_sip: Peers with distinct source ports don't match, regardless of transport. [https://gerrit.asterisk.org/7429|https://gerrit.asterisk.org/7429] By: Friendly Automation (friendly-automation) 2018-03-21 09:45:30.198-0500 Change 7431 merged by Jenkins2: chan_sip: Peers with distinct source ports don't match, regardless of transport. [https://gerrit.asterisk.org/7431|https://gerrit.asterisk.org/7431] | ||||