Really wierd issue

Benn5325 · November 5, 2018, 11:48pm

FreePBX 13.0.195.18
Asterisk 13.23.1

Last week our network was hit with a DDoS attack. Well several to be exact.
Not sure if it’s related, but since Friday our FreePBX has been totally jacked up and I’m totally stumped.

Firstly, all of a sudden most users couldn’t dial out. Inbound calls were no problem.
All endpoints are registered, just nothing when trying to call out.
They would get dead air, then a fast busy and call failed.
We found today, that it was something with the codec. (We have a lot of Aastra endpoints)
For some reason now we need to change the codec option in the endpoint from All to Basic, then they start working again.

Or next problem now is that audio drops on the calls after 1 min.
I’ve made no changes to the server except for regular module updates. This system has been running perfectly for 1 1/2 years and all of a sudden it’s decided to take a dump on me… Anyone got any ideas??

Log from one call below:

e[0me[0mConnected to Asterisk 13.23.1 currently running on maopbx (pid = 20227)
maopbx*CLI> sip set debug peer 2644

maopbx*CLI>
e[0KSIP Debugging Enabled for IP: 10.36.199.115

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
REGISTER sip:10.36.209.10 SIP/2.0
Via: SIP/2.0/UDP 10.36.199.115:5060;branch=z9hG4bK578683035;rport
From: sip:[email protected];tag=1631568111
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 4251 REGISTER
Contact: sip:[email protected]:5060;reg-id=1;+sip.instance=“urn:uuid:00000000-0000-1000-8000-000B826F09FD”
Authorization: Digest username=“2644”, realm=“asterisk”, nonce=“4541538a”, uri=“sip:10.36.209.10”, response=“17ab0e11e8589059f68f819863b25a07”, algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream GXV3275 1.0.3.158
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (14 headers 0 lines) —
Sending to 10.36.199.115:5060 (NAT)
Sending to 10.36.199.115:5060 (NAT)

<— Transmitting (no NAT) to 10.36.199.115:5060 —>
SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 10.36.199.115:5060;branch=z9hG4bK578683035;received=10.36.199.115;rport=5060

From: sip:[email protected];tag=1631568111

To: sip:[email protected];tag=as37ba0c0a

Call-ID: [email protected]

CSeq: 4251 REGISTER

Server: FPBX-13.0.195.18(13.23.1)

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“71a113b6”

Content-Length: 0

<------------>

e[Kmaopbx*CLI>
e[0KScheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
REGISTER sip:10.36.209.10 SIP/2.0
Via: SIP/2.0/UDP 10.36.199.115:5060;branch=z9hG4bK844303824;rport
From: sip:[email protected];tag=1631568111
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 4252 REGISTER
Contact: sip:[email protected]:5060;reg-id=1;+sip.instance=“urn:uuid:00000000-0000-1000-8000-000B826F09FD”
Authorization: Digest username=“2644”, realm=“asterisk”, nonce=“71a113b6”, uri=“sip:10.36.209.10”, response=“a0828f21d97969e9ac27b8020e5117bb”, algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream GXV3275 1.0.3.158
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->

e[Kmaopbx*CLI>
e[0K— (14 headers 0 lines) —
Sending to 10.36.199.115:5060 (no NAT)

e[Kmaopbx*CLI>
e[0KReliably Transmitting (no NAT) to 10.36.199.115:5060:
OPTIONS sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK70cc863d

Max-Forwards: 70

From: “Unknown” sip:[email protected];tag=as1d84cad0

To: sip:[email protected]:5060

Contact: sip:[email protected]:5060

Call-ID: [email protected]:5060

CSeq: 102 OPTIONS

User-Agent: FPBX-13.0.195.18(13.23.1)

Date: Mon, 05 Nov 2018 21:43:23 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

Content-Length: 0

<— Transmitting (no NAT) to 10.36.199.115:5060 —>
SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.36.199.115:5060;branch=z9hG4bK844303824;received=10.36.199.115;rport=5060

From: sip:[email protected];tag=1631568111

To: sip:[email protected];tag=as37ba0c0a

Call-ID: [email protected]

CSeq: 4252 REGISTER

Server: FPBX-13.0.195.18(13.23.1)

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

Expires: 3600

Contact: sip:[email protected]:5060;expires=3600

Date: Mon, 05 Nov 2018 21:43:23 GMT

Content-Length: 0

<------------>

e[Kmaopbx*CLI>
e[0KScheduling destruction of SIP dialog ‘[email protected]:5060’ in 6400 ms (Method: NOTIFY)
Reliably Transmitting (no NAT) to 10.36.199.115:5060:
NOTIFY sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK06dff48d

Max-Forwards: 70

From: “Unknown” sip:[email protected];tag=as24e55db0

To: sip:[email protected]:5060

Contact: sip:[email protected]:5060

Call-ID: [email protected]:5060

CSeq: 102 NOTIFY

User-Agent: FPBX-13.0.195.18(13.23.1)

Event: message-summary

Content-Type: application/simple-message-summary

Content-Length: 87

Messages-Waiting: no

Message-Account: sip:*[email protected]

Voice-Message: 0/0 (0/0)

Scheduling destruction of SIP dialog ‘[email protected]’ in 32000 ms (Method: REGISTER)

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK70cc863d
From: “Unknown” sip:[email protected];tag=as1d84cad0
To: sip:[email protected]:5060;tag=350807559
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Supported: replaces, path, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK06dff48d
From: “Unknown” sip:[email protected];tag=as24e55db0
To: sip:[email protected]:5060;tag=64705959
Call-ID: [email protected]:5060
CSeq: 102 NOTIFY
Supported: replaces, path, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->

e[Kmaopbx*CLI>
e[0K— (10 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5060’ Method: NOTIFY

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:23] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘“BOS Conference Room” sip:[email protected]:5060;tag=2dca55dfd2’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:26] e[1;31mERRORe[0m[19860][C-000004ad]: e[1;37mres_pjsip_header_funcs.ce[0m:e[1;37m454e[0m e[1;37mfunc_read_headere[0m: This function requires a PJSIP channel.

e[Kmaopbx*CLI>
e[0KAudio is at 19866

e[Kmaopbx*CLI>
e[0KAdding codec ulaw to SDP

e[Kmaopbx*CLI>
e[0KAdding codec alaw to SDP

e[Kmaopbx*CLI>
e[0KAdding codec gsm to SDP

e[Kmaopbx*CLI>
e[0KAdding non-codec 0x1 (telephone-event) to SDP

e[Kmaopbx*CLI>
e[0KReliably Transmitting (no NAT) to 10.36.199.115:5060:
INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK07aaaccf

Max-Forwards: 70

From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e

To: sip:[email protected]:5060

Contact: sip:[email protected]:5060

Call-ID: [email protected]:5060

CSeq: 102 INVITE

User-Agent: FPBX-13.0.195.18(13.23.1)

Date: Mon, 05 Nov 2018 21:43:26 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

P-Asserted-Identity: “WIRELESS CALLER” sip:[email protected]

Content-Type: application/sdp

Content-Length: 285

v=0

o=root 624221981 624221981 IN IP4 10.36.209.10

s=Asterisk PBX 13.23.1

c=IN IP4 10.36.209.10

t=0 0

m=audio 19866 RTP/AVP 0 8 3 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:3 GSM/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=maxptime:150

a=sendrecv

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK07aaaccf
From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e
To: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Supported: replaces, path, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->

e[Kmaopbx*CLI>
e[0K— (10 headers 0 lines) —

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK07aaaccf
From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e
To: sip:[email protected]:5060;tag=21412931
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Contact: sip:[email protected]:5060
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow-Events: talk, hold
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (12 headers 0 lines) —

e[Kmaopbx*CLI>
e[0Ksip_route_dump: route/path hop: sip:[email protected]:5060

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK07aaaccf
From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e
To: sip:[email protected]:5060;tag=21412931
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Contact: sip:[email protected]:5060
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Type: application/sdp
Content-Length: 271

v=0
o=2644 8000 8000 IN IP4 10.36.199.115
s=SIP Call
c=IN IP4 10.36.199.115
t=0 0
m=audio 5004 RTP/AVP 0 8 101
a=sendrecv
a=rtcp:5005 IN IP4 10.36.199.115
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<------------->

e[Kmaopbx*CLI>
e[0K— (12 headers 13 lines) —

e[Kmaopbx*CLI>
e[0KFound RTP audio format 0

e[Kmaopbx*CLI>
e[0KFound RTP audio format 8

e[Kmaopbx*CLI>
e[0KFound RTP audio format 101

e[Kmaopbx*CLI>
e[0KFound audio description format PCMU for ID 0

e[Kmaopbx*CLI>
e[0KFound audio description format PCMA for ID 8

e[Kmaopbx*CLI>
e[0KFound audio description format telephone-event for ID 101

e[Kmaopbx*CLI>
e[0KPeer audio RTP is at port 10.36.199.115:5004

e[Kmaopbx*CLI>
e[0Ksip_route_dump: route/path hop: sip:[email protected]:5060

e[Kmaopbx*CLI>
e[0Kset_destination: Parsing sip:[email protected]:5060 for address/port to send to

e[Kmaopbx*CLI>
e[0Kset_destination: set destination to 10.36.199.115:5060

e[Kmaopbx*CLI>
e[0KTransmitting (no NAT) to 10.36.199.115:5060:
ACK sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK1180e1bb

Max-Forwards: 70

From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e

To: sip:[email protected]:5060;tag=21412931

Contact: sip:[email protected]:5060

Call-ID: [email protected]:5060

CSeq: 102 ACK

User-Agent: FPBX-13.0.195.18(13.23.1)

Content-Length: 0

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>

<------------->

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:39] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected]:5060;tag=2cff4af0b5’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:42] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected]:5060;tag=9670fde5fe’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:49] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected];tag=SP15dcf4af15dfff579’

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>

<------------->

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:49] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected]:5060;tag=4298be6f86’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:43:55] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘Training 3 sip:[email protected]:5060;tag=b57699712cf66fd’

e[Kmaopbx*CLI>
e[0KReally destroying SIP dialog ‘[email protected]’ Method: REGISTER

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:00] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘“Alicia Gilson” sip:[email protected]:5060;tag=33ab74bb5d’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:09] e[1;31mWARNINGe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m4068e[0m e[1;37mretrans_pkte[0m: Retransmission timeout reached on transmission [email protected] for seqno 103 (Non-critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>

<------------->

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:17] e[1;31mWARNINGe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m4068e[0m e[1;37mretrans_pkte[0m: Retransmission timeout reached on transmission [email protected] for seqno 120 (Non-critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:19] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected];tag=SP15dcf4af15dfff579’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:22] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘sip:[email protected]:5060;tag=9e5927ba86’

e[Kmaopbx*CLI>
e[0KReliably Transmitting (no NAT) to 10.36.199.115:5060:
OPTIONS sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK5084e137

Max-Forwards: 70

From: “Unknown” sip:[email protected];tag=as7e136109

To: sip:[email protected]:5060

Contact: sip:[email protected]:5060

Call-ID: [email protected]:5060

CSeq: 102 OPTIONS

User-Agent: FPBX-13.0.195.18(13.23.1)

Date: Mon, 05 Nov 2018 21:44:23 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE

Supported: replaces, timer

Content-Length: 0

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK5084e137
From: “Unknown” sip:[email protected];tag=as7e136109
To: sip:[email protected]:5060;tag=219836969
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Supported: replaces, path, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->

e[Kmaopbx*CLI>
e[0K— (10 headers 0 lines) —

e[Kmaopbx*CLI>
e[0KReally destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:24] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘“Chris Cummins” sip:[email protected]:5060;tag=73b969df85’

e[Kmaopbx*CLI>
e[0K[2018-11-05 15:44:26] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘“Patty Shepherd” sip:[email protected]:5060;tag=f9857d8498’

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>

<------------->

e[Kmaopbx*CLI>
e[0KScheduling destruction of SIP dialog ‘[email protected]:5060’ in 6400 ms (Method: INVITE)
set_destination: Parsing sip:[email protected]:5060 for address/port to send to
set_destination: set destination to 10.36.199.115:5060
Reliably Transmitting (no NAT) to 10.36.199.115:5060:
BYE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK22f4994b

Max-Forwards: 70

From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e

To: sip:[email protected]:5060;tag=21412931

Call-ID: [email protected]:5060

CSeq: 103 BYE

User-Agent: FPBX-13.0.195.18(13.23.1)

X-Asterisk-HangupCause: Normal Clearing

X-Asterisk-HangupCauseCode: 16

Content-Length: 0

e[Kmaopbx*CLI>
e[0K
<— SIP read from UDP:10.36.199.115:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.36.209.10:5060;branch=z9hG4bK22f4994b
From: “WIRELESS CALLER” sip:[email protected];tag=as47f5217e
To: sip:[email protected]:5060;tag=21412931
Call-ID: [email protected]:5060
CSeq: 103 BYE
Contact: sip:[email protected]:5060
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream GXV3275 1.0.3.158
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (11 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5060’ Method: INVITE

e[Kmaopbx*CLI> sip set deb
e[0K[2018-11-05 15:44:41] e[1;31mERRORe[0m[19954][C-000004af]: e[1;37mres_pjsip_header_funcs.ce[0m:e[1;37m454e[0m e[1;37mfunc_read_headere[0m: This function requires a PJSIP channel.

e[Kmaopbx*CLI> sip set debug o
e[0K[2018-11-05 15:44:42] e[1;33mNOTICEe[0m[22082]: e[1;37mchan_sip.ce[0m:e[1;37m17309e[0m e[1;37mcheck_authe[0m: Correct auth, but based on stale nonce received from ‘LAX Conference Room sip:[email protected]:5060;tag=c6174d1a5f8c04a’

e[Kmaopbx*CLI> sip set debug off

maopbx*CLI>
e[0KSIP Debugging Disabled

e[Kmaopbx*CLI> exit

Asterisk cleanly ending (0).
Executing last minute cleanups
e[0me]0;root@maopbx:~a[root@maopbx ~]# exit

Benn5325 · November 6, 2018, 11:44am

Just to add to this… We are behind a Sophos Firewall (Again, been working fine for several years) so not using the built in firewall. Sip trunk from Comcast. So calls go from FreePBX - Comcast Adtran then out.
Several remote locations all connecting over our WAN. No real issues in the past until now.

Benn5325 · November 6, 2018, 4:26pm

And to add a bit more. A full trace of a call from outside.
Caller dials in, all good for about 1 min 30 the caller cannot hear anything
https://pastebin.freepbx.org/view/aab9cf36

Benn5325 · November 7, 2018, 1:30am

Anyone???

cynjut · November 7, 2018, 2:47pm

OK - there are so many things these symptoms could be that it’s going to be hard to get a consensus view. What kinds of things did you do to stop the attack? Changing the router and/or the firewall (which may or may not be the same device) configuration may or may not cause problems like this.

One important thing to understand is that neither the DDOS ir FreePBX’s response to it were likely to cause these problems. The codec one, for example, could either be a coincidence or a response to the standard “first step” when responding to an attack like this: update all the firmware on all of the devices in the network. We have been tracking several “codec related” problems over the past few weeks where the “standard” codecs work but many of the “specialty” codecs stop working.

Resetting the codec setting may not actually be part of your solution. It could be that resetting that option causes something else to reset (think of it as a “reboot”) which, once it’s reset, negotiates a better set of options for the phone.

So, there are a few things you could look at:

The router/firewall config sounds like it got zapped.

My theory is that the session timeouts in the router are losing the NAT connections. There are other things that can do that, but most of them would be accompanied by a “failure to respond to our critical packet” (or similar) errors in /var/log/asterisk/full.

The changes to the Sophos to stop the DDOS may also be killing your RTP connections.

The RTP traffic looks “largely” like different, unrelated traffic from the SIP connection. If your connection is getting made and works, and then quits, it is often a session-timeout variable set too tight.

One of the things that many people do to prevent attacks like the one you described can cause this specific problem:

They have the 5060 port forwarded to the PBX server, but don’t forward the 10000-20000 ports (the RTP audio traffic) to the PBX. This causes the connection opened on the random UDP port process in the call setup to eventually timeout and fail, which kills your audio.

Of course, there are lots of other things that could be problematic, but the elephant of a problem set needs to be cut down to bite-sized pieces before we can help you. Check the forums for people that are using Sophos as their primary firewall - they have some settings that can help you.

Benn5325 · November 7, 2018, 5:50pm

Thanks Dave…

Looking at the forum about Sophos. Only real solution I see is to roll back Asterisk. I don’t have a issue with that, but how far can we go back… We’re on 13.23.1 Can I go back to say 13.14.0

Benn5325 · November 7, 2018, 6:21pm

Found the roll back details. Gonna try that

Benn5325 · November 7, 2018, 7:36pm

Rollback didn’t make any difference.

One thing we have notices… Audio loss is From the handset to the external caller/called
The RTP traffic is only one way. If we put the call on hold then go back top the call, two way audio is fine again for a couple of mins, then drops to one way again. Hold and back to call gives two way audio again

cynjut · November 7, 2018, 8:01pm

Nope - audio is always from the handset to the Asterisk process to the external caller. Asterisk is a back-to-back user agent, so there is no direct connection from the user to the external caller ever.

This is sounding more and more like either an Asterisk keep-alive problem or a router port session timeout problem. The fact that you interrupt the connection with an On-Hold action just amplifies that. Look through the archive for “30 seconds” and look at some of the threads that talk about one-way audio after a period of time.

system · November 14, 2018, 8:01pm

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