# Asterisk returns 401 for correctly authenticated extensions when calling **URL:** \ **Category:** Asterisk SIP\ **Created:** [October 24, 2018, 5:14pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807 "2018-10-24T17:14:27Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![vncz](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/vncz/32/2745_2.png) [@vncz](https://community.asterisk.org/u/vncz)\ **Post date:** [October 24, 2018, 5:14pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/1 "2018-10-24T17:14:28Z")
Hello guys — I’ve been an happy user of Asterisk so far and I’m now facing an issue I haven’t been able to resolve yet. I was wondering/hoping whether someone here faced the same issue and maybe can help me. I’ve one user that is working on another office which is connected through an OpenVPN connection. The guy is able to correctly authenticate in the Asterisk server and even **correctly receive calls** ; however when he tries to make any call; it does not matter if internal or external, Asterisk is answering back with `401 Unauthorized`. I’ve been trying to have a look into the logs by enabling the maximum debug level allowed in the platform it’s clearly returning 401; the strange part is that it does not really tell you the reason, so I have **NO** idea what’s wrong here: ```auto <--- Received SIP request (1180 bytes) from UDP:10.100.104.6:50218 ---> INVITE sip:3932551907@172.18.19.127;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 93.34.90.137:45058;branch=z9hG4bK-524287-1---7c1bde5ea092c950;rport Max-Forwards: 70 Contact: To: From: ;tag=367d205b Call-ID: WsV2HuMEeWqQoBezh9Plkg.. CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE Content-Type: application/sdp User-Agent: Z 5.2.19 rv2.8.99 Allow-Events: presence, kpml, talk Content-Length: 601 v=0 o=Z 0 0 IN IP4 93.34.90.137 s=Z c=IN IP4 93.34.90.137 t=0 0 m=audio 45522 RTP/AVP 106 9 3 111 0 8 97 110 112 98 101 100 99 102 a=rtpmap:106 opus/48000/2 a=fmtp:106 minptime=20; cbr=1; maxaveragebitrate=40000; useinbandfec=1 a=rtpmap:111 speex/16000 a=rtpmap:97 iLBC/8000 a=fmtp:97 mode=20 a=rtpmap:110 speex/8000 a=rtpmap:112 speex/32000 a=rtpmap:98 telephone-event/48000 a=fmtp:98 0-16 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:100 telephone-event/16000 a=fmtp:100 0-16 a=rtpmap:99 telephone-event/32000 a=fmtp:99 0-16 a=rtpmap:102 G726-32/8000 a=sendrecv [2018-10-24 18:58:08] DEBUG[10094]: res_pjsip/pjsip_distributor.c:383 find_dialog: Could not find matching transaction for Request msg INVITE/cseq=1 (rdata0x73d157b4) [2018-10-24 18:58:08] DEBUG[10094]: res_pjsip/pjsip_distributor.c:461 ast_sip_get_distributor_serializer: Calculated serializer pjsip/distributor-00000042 to use for Request msg INVITE/cseq=1 (rdata0x73d157b4) [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '10.100.104.6' into... [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '10.100.104.6' and port ''. [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify '5406086557' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify '5406034193' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify '5341696' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify '5406005158' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify 'UalaImmo' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:245 ip_identify_match_check: Source address 10.100.104.6:50218 does not match identify '0510216176' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:240 ip_identify_match_check: Source address 10.100.104.6:50218 matches identify '993-identify' [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_endpoint_identifier_ip.c:273 common_identify: Identify '993-identify' SIP message matched to endpoint 993 [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_authenticator_digest.c:454 digest_check_auth: Using default realm 'asterisk' on incoming auth '993-auth'. [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '172.18.19.127' into... [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '172.18.19.127' and port ''. [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '10.100.104.6' into... [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '10.100.104.6' and port ''. [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:172 ast_sockaddr_split_hostport: Splitting '10.100.104.6' into... [2018-10-24 18:58:08] DEBUG[10095]: netsock2.c:226 ast_sockaddr_split_hostport: ...host '10.100.104.6' and port ''. [2018-10-24 18:58:08] DEBUG[10095]: res_pjsip_nat.c:271 nat_on_tx_message: Request is being sent to local address, skipping NAT manipulation <--- Transmitting SIP response (512 bytes) to UDP:10.100.104.6:50218 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 93.34.90.137:45058;rport=50218;received=10.100.104.6;branch=z9hG4bK-524287-1---7c1bde5ea092c950 Call-ID: WsV2HuMEeWqQoBezh9Plkg.. From: ;tag=367d205b To: ;tag=z9hG4bK-524287-1---7c1bde5ea092c950 CSeq: 1 INVITE WWW-Authenticate: Digest realm="asterisk",nonce="1540400288/90ebde0908b76e093a1a141669e5a1b9",opaque="327495263dc09c32",algorithm=md5,qop="auth" Server: FPBX-14.0.4.1(13.23.0) Content-Length: 0 <--- Received SIP request (363 bytes) from UDP:10.100.104.6:50218 ---> ACK sip:3932551907@172.18.19.127;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 93.34.90.137:45058;branch=z9hG4bK-524287-1---7c1bde5ea092c950;rport Max-Forwards: 70 To: ;tag=z9hG4bK-524287-1---7c1bde5ea092c950 From: ;tag=367d205b Call-ID: WsV2HuMEeWqQoBezh9Plkg.. CSeq: 1 ACK Content-Length: 0 ``` I can also see that the phone is answering with `ACK` and aborting the call; but I can’t really figure out the reason - the user seems to be identified correctly! Any hints on how to move forward with this? ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [October 24, 2018, 5:17pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/2 "2018-10-24T17:17:00Z")
You haven’t shown the actual configuration for the endpoint, so can’t really answer on why it is doing that. ---
**Author:** ![vncz](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/vncz/32/2745_2.png) [@vncz](https://community.asterisk.org/u/vncz)\ **Post date:** [October 24, 2018, 5:18pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/3 "2018-10-24T17:18:50Z")
Here’s the current configuration: ```auto [993] type=endpoint aors=993 auth=993-auth tos_audio=ef tos_video=af41 cos_audio=5 cos_video=4 allow=ulaw,alaw,gsm,g726,g722 context=from-internal callerid=Gaetano <993> dtmf_mode=rfc4733 mailboxes=993@device mwi_subscribe_replaces_unsolicited=yes aggregate_mwi=yes use_avpf=no rtcp_mux=no ice_support=no media_use_received_transport=no trust_id_inbound=yes media_encryption=no timers=yes media_encryption_optimistic=no send_pai=yes rtp_symmetric=yes rewrite_contact=yes force_rport=yes language=it one_touch_recording=on record_on_feature=apprecord record_off_feature=apprecord ``` However regardless of that — shouldn’t the logs tell you something about why the response `401` is being returned? That would have been super helpful! P.S: I’m on Asterisk 13 — maybe you guys fixed this already in the following versions! ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [October 24, 2018, 5:19pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/4 "2018-10-24T17:19:35Z")
You’ve got an auth set, which is used for inbound authentication. Asterisk appears to be challenging for authentication as configured. It would be up to the endpoint to then send the INVITE again with credentials. ---
**Author:** ![vncz](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/vncz/32/2745_2.png) [@vncz](https://community.asterisk.org/u/vncz)\ **Post date:** [October 24, 2018, 5:20pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/5 "2018-10-24T17:20:40Z")
What I do not get though is that all the other extensions have been configured in the same way and they’re using the same client; no issues at all. The only one having such problem is this one, which is connected in VPN. I’m willing to remove the auth — shall I just remove `auth=993-auth` line? ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [October 24, 2018, 5:21pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/6 "2018-10-24T17:21:28Z")
That will disable authentication. As for why it’s not working, from the Asterisk side it is doing as it should. ---
**Author:** ![vncz](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/vncz/32/2745_2.png) [@vncz](https://community.asterisk.org/u/vncz)\ **Post date:** [October 24, 2018, 5:22pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/7 "2018-10-24T17:22:12Z")
I’m going to give it a try and see what happens. It seems to be a known issue [https://github.com/BelledonneCommunications/linphone-iphone/issues/195](https://github.com/BelledonneCommunications/linphone-iphone/issues/195) but I really do not get why only this extension is having such problem. ---
**Author:** ![vncz](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/vncz/32/2745_2.png) [@vncz](https://community.asterisk.org/u/vncz)\ **Post date:** [October 24, 2018, 7:53pm UTC](https://community.asterisk.org/t/asterisk-returns-401-for-correctly-authenticated-extensions-when-calling/76807/8 "2018-10-24T19:53:45Z")
By removing that line, it seems like the call gets processed correctly. Thanks for the help. I still do not understand why such issue is not happening for all the other clients in the office. It seems to be happening exclusively to the client connected via VPN.