Failed to authenticate device via 2 asterisks

alexanderzhirov · March 17, 2023, 4:25pm

Unable to log in as a user from one asterisk to another.

My task is to transfer the configuration from the Asterisk 1.4.42 (SIP) server to Asterisk 18.15.1 (PJSIP).

I will give the scheme and configurations:

Old configuration connecting two servers

10.64.21.16 - Asterisk 13.14.1 (SIP)
10.100.0.190 - Asterisk 1.4.42 (SIP)

10.100.0.190 - sip.conf:

...
[KorochaTrunk]
disallow = all
allow = ulaw
context = MainDial
hassip = yes
host = 10.64.21.16
port = 5060
type = friend
nat = no
insecure = port,invite
deny=0.0.0.0/0
permit=10.64.21.16/32
...

10.64.21.16 - sip.conf:

...
[KorochaTrunk]
disallow = all
allow = ulaw
context = MainDial
hassip = yes
host = 10.100.0.190
port = 5060
type = friend
nat = no
insecure = port,invite
deny=0.0.0.0/0
permit=10.100.0.190/32
...

That is, the server was connected without registration.

New configuration connecting two servers

10.64.21.16 - Asterisk 13.14.1 (SIP)
10.100.0.190 - Asterisk 18.15.1 (PJSIP)

10.100.0.190 - pjsip.conf:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[KorochaTrunk]
type=auth
auth_type=userpass
username=KorochaTrunk

[KorochaTrunk]
type=aor
contact=sip:10.64.21.16

[KorochaTrunk]
type=endpoint
transport=transport-udp
aor=KorochaTrunk
auth=KorochaTrunk
context=MainDial
disallow=all
allow=ulaw
direct_media=no
outbound_auth=KorochaTrunk

[KorochaTrunk]
type=identify
endpoint=KorochaTrunk
match=10.64.21.16

10.64.21.16 - sip.conf: same as old

I start making a call and the 10.64.21.16 gives such an error

NOTICE[16612][C-000008d5]: chan_sip.c:26179 handle_request_invite: Failed to authenticate device <sip:104@10.100.0.190>;tag=ukKKsL0eT57sJpH1jggD2jo7yInv25XD

and error 403 in sngrep.

Here is the call dump:

19:23:17.785578 IP (tos 0x0, ttl 61, id 2612, offset 0, flags [DF], proto UDP (17), length 905)
    10.100.0.190.5060 > 10.64.21.16.5060: SIP, length: 877
	INVITE sip:64031@10.64.21.16 SIP/2.0
	Via: SIP/2.0/UDP 10.100.0.190:5060;rport;branch=z9hG4bKPjWK4JG9MIeL4j.qqLy2DrVicCi7ciOTSP
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>
	Contact: <sip:asterisk@10.100.0.190:5060>
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8980 INVITE
	Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
	Supported: 100rel, timer, replaces, norefersub, histinfo
	Session-Expires: 1800
	Min-SE: 90
	Max-Forwards: 70
	User-Agent: Asterisk PBX 18.15.0
	Content-Type: application/sdp
	Content-Length:   235
	
	v=0
	o=- 697499486 697499486 IN IP4 10.100.0.190
	s=Asterisk
	c=IN IP4 10.100.0.190
	t=0 0
	m=audio 10586 RTP/AVP 0 101
	a=rtpmap:0 PCMU/8000
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16
	a=ptime:20
	a=maxptime:150
	a=sendrecv
19:23:17.786345 IP (tos 0x0, ttl 64, id 20941, offset 0, flags [none], proto UDP (17), length 584)
    10.64.21.16.5060 > 10.100.0.190.5060: SIP, length: 556
	SIP/2.0 401 Unauthorized
	Via: SIP/2.0/UDP 10.100.0.190:5060;branch=z9hG4bKPjWK4JG9MIeL4j.qqLy2DrVicCi7ciOTSP;received=10.100.0.190;rport=5060
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>;tag=as7a5b76c5
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8980 INVITE
	Server: Miratorg PBX
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1a3221a6"
	Content-Length: 0
	
19:23:17.805695 IP (tos 0x0, ttl 61, id 2617, offset 0, flags [DF], proto UDP (17), length 398)
    10.100.0.190.5060 > 10.64.21.16.5060: SIP, length: 370
	ACK sip:64031@10.64.21.16 SIP/2.0
	Via: SIP/2.0/UDP 10.100.0.190:5060;rport;branch=z9hG4bKPjWK4JG9MIeL4j.qqLy2DrVicCi7ciOTSP
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>;tag=as7a5b76c5
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8980 ACK
	Max-Forwards: 70
	User-Agent: Asterisk PBX 18.15.0
	Content-Length:  0
	
19:23:17.807890 IP (tos 0x0, ttl 61, id 2618, offset 0, flags [DF], proto UDP (17), length 1077)
    10.100.0.190.5060 > 10.64.21.16.5060: SIP, length: 1049
	INVITE sip:64031@10.64.21.16 SIP/2.0
	Via: SIP/2.0/UDP 10.100.0.190:5060;rport;branch=z9hG4bKPjt80V8ljsXsr6B-9pU8vFv0W0t7UiMyai
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>
	Contact: <sip:asterisk@10.100.0.190:5060>
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8981 INVITE
	Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
	Supported: 100rel, timer, replaces, norefersub, histinfo
	Session-Expires: 1800
	Min-SE: 90
	Max-Forwards: 70
	User-Agent: Asterisk PBX 18.15.0
	Authorization: Digest username="KorochaTrunk", realm="asterisk", nonce="1a3221a6", uri="sip:64031@10.64.21.16", response="57bd54525604ace391219bfb934be2fd", algorithm=MD5
	Content-Type: application/sdp
	Content-Length:   235
	
	v=0
	o=- 697499486 697499486 IN IP4 10.100.0.190
	s=Asterisk
	c=IN IP4 10.100.0.190
	t=0 0
	m=audio 10586 RTP/AVP 0 101
	a=rtpmap:0 PCMU/8000
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16
	a=ptime:20
	a=maxptime:150
	a=sendrecv
19:23:17.808161 IP (tos 0x0, ttl 64, id 20943, offset 0, flags [none], proto UDP (17), length 505)
    10.64.21.16.5060 > 10.100.0.190.5060: SIP, length: 477
	SIP/2.0 403 Forbidden
	Via: SIP/2.0/UDP 10.100.0.190:5060;branch=z9hG4bKPjt80V8ljsXsr6B-9pU8vFv0W0t7UiMyai;received=10.100.0.190;rport=5060
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>;tag=as7a5b76c5
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8981 INVITE
	Server: Miratorg PBX
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	Content-Length: 0
	
19:23:17.827559 IP (tos 0x0, ttl 61, id 2624, offset 0, flags [DF], proto UDP (17), length 398)
    10.100.0.190.5060 > 10.64.21.16.5060: SIP, length: 370
	ACK sip:64031@10.64.21.16 SIP/2.0
	Via: SIP/2.0/UDP 10.100.0.190:5060;rport;branch=z9hG4bKPjt80V8ljsXsr6B-9pU8vFv0W0t7UiMyai
	From: <sip:104@10.100.0.190>;tag=46wVsd18do.Fr4DJ0HDhlVO8zPrsYCBo
	To: <sip:64031@10.64.21.16>;tag=as7a5b76c5
	Call-ID: FNaqHd5qtH0d-szhoEMFry3H6evWuNXm
	CSeq: 8981 ACK
	Max-Forwards: 70
	User-Agent: Asterisk PBX 18.15.0
	Content-Length:  0

Tell me, please, in which direction should this problem be considered? I’ve already run out of ideas.

david551 · March 17, 2023, 5:01pm

Probably the result of misusing type=friend, when you should use type=peer. NB although the type=friend on the “Trunk” is unwise, it is actually a host=dynamic entry for user 104 that is likely causing the problem. With chan_sip, type=user matches always take precedence over type=peer ones, so, if the user part of the From header matches one, that will be used in preference to the host match. (type=friend is a union of type=peer and type=user.)

Note that insecure=invite does nothing here, as you have no secret and the actual configuration does not need insecure=port.

nat=no is not necessary except in rare cases. In this case the default is perfectly adequate.

ambiorixg12 · March 17, 2023, 10:33pm

“auth=”, is used for inbound authentication. If static IP addresses are used, there is no need to use incoming INVITE authentication.

david551 · March 18, 2023, 11:13am

The OPs presented configuration isn’t trying to authenticate. As noted, it is probably a host=dynamic; type=friend entry for 104, that he thought too unimportant to include, that is trying to authenticate here.

However, there can still be valid reasons to use user password authentication with IP based identification, especially if you are in an environment with students, who may have access from inside your main firewall. Successful toll fraud doesn’t require responses to get back to the fraudster.

alexanderzhirov · March 18, 2023, 11:20am

Security in my case is excluded, since the network is localized and without access to the global network.

Thanks! I will keep in mind for the future.

I tried to set the parameter from_user=KorochaTrunk and my call was successful. Is it possible to provide this authentication through this user, and the identification of the call by the actual number?

david551 · March 18, 2023, 11:37am

Best practice, is to use something unpredictable, like the MAC address for user based identification, but that means you have to lookup the dialstring to to use with any Asterisk extension.

For chan_sip, but not chan_pjsip, local phones should be type=peer, to avoid this, unless they share IP addresses.

For a tie line, you can use Remote-Party-ID or P-Asserted-Identity, for the caller ID, and leave the From user free for identification, in which case it need not look like a phone number.

Also, you should try not to design a system with the same extension number on two sites, but if you do, you should modify the caller ID, sent over the tie line, to include the other end’s tie line access prefix.

alexanderzhirov · March 18, 2023, 1:40pm

It seems your suggestion has worked. The call goes through and the user’s data is transmitted in the call.

alexanderzhirov · March 20, 2023, 5:03am

After all, the outgoing trunk number is not displayed on the device receiving the call, but is displayed as KorochaTrunk.

david551 · March 20, 2023, 10:58am

Have you set Asterisk to trust RPID or PAI?

alexanderzhirov · March 20, 2023, 11:04am

Em… Probably not Could you share some information?

david551 · March 20, 2023, 11:08am

github.com

jcollie/asterisk/blob/master/configs/sip.conf.sample#L340


      
          ;
          ;parkinglot=plaza               ; Sets the default parking lot for call parking
                                          ; This may also be set for individual users/peers
                                          ; Parkinglots are configured in features.conf
          ;language=en                    ; Default language setting for all users/peers
                                          ; This may also be set for individual users/peers
          ;tonezone=se			; Default tonezone for all users/peers
                                          ; This may also be set for individual users/peers
          
          
;relaxdtmf=yes                  ; Relax dtmf handling
          ;trustrpid = no                 ; If Remote-Party-ID should be trusted
          ;sendrpid = yes                 ; If Remote-Party-ID should be sent (defaults to no)
          ;sendrpid = rpid                ; Use the "Remote-Party-ID" header
                                          ; to send the identity of the remote party
                                          ; This is identical to sendrpid=yes
          ;sendrpid = pai                 ; Use the "P-Asserted-Identity" header
                                          ; to send the identity of the remote party
          ;rpid_update = no               ; In certain cases, the only method by which a connected line
                                          ; change may be immediately transmitted is with a SIP UPDATE request.
                                          ; If communicating with another Asterisk server, and you wish to be able
                                          ; transmit such UPDATE messages to it, then you must enable this option.

alexanderzhirov · March 20, 2023, 11:33am

Now everything works! Thank you so much for your help!

system · April 19, 2023, 11:33am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.