Trunk provider being blacklisted

[geoff.jukes]

Hi,

Our SIP Trunk provider keeps being blacklisted for 'Too many failed auth'. The following is logged in the Server Activity Log:

Blacklisted (Too many failed auth) IP = X.X.X.X; Failed auth: 0; unauth: 0; auth: 0; 407: 1000

We have dual WAN connections, and use STUN resolution to determine the active WAN link/IP. This works perfectly. In reverse, our Trunk provider uses SIPing messages to test the two links, so that they can deliver to the appropriate link in the event of an outage.

I suspect that 3CX is blocking due to the PING messages. I have tried to whitelist the Trunk IP, but the PBX removed it and blacklisted it again.

Has anyone seen this behavior before?

Many thanks,

Geoff

 

[SY]

Hi,
Please provide more information:
1. Please specify trunk service provider.
2. What is the "SIPing" used by the provider?
3. logs which will show that "the PBX removed it (white list entry) and blacklisted it again"

We will be glad to investigate the issue.
Thanks

 

[geoff.jukes]

Hi Stepan, thanks for the reply.

1) I am using the 'Generic' 'SIP Trunk' profile. Our provider is not in the list (it is AvalonTel via a reseller)

2) An example SIPing message is:

options sip:OUR-IP:5060 SIP/2.0
Via: SIP/2.0/UDP TRUNK-IP:5060;branch=z9hG4bKfb6ut300306gfa5mc5c1
Call-ID: 98977160ea6ba38f5ca29c546f09ae440000g41@TRUNK-IP
To: sip:ping@OUR-IP
From: <sip:ping@TRUNK-IP>;tag=f54db0349202463f3cc0596e52b22a250000g41
Max-Forwards: 0
CSeq: 73 options
P-Charge-Info: <sip:ping@TRUNK-IP>;tag=f54db0349202463f3cc0596e52b22a250000g41

3) I cannot see the entry where the whitelist was removed. I am going to re-add it now, and turn on verbose logging.

 

[geoff.jukes]

Hi,

So I think the Whitelist removal was my fault.... I think I forgot to click 'Apply' after adding the Whitelist entry :lol:

I am still curious to know about the SIPings and if that is why they are being blacklisted in the first place. If so I guess it makes sense, as a SIPing could be used as a host-discovery method.

 

[SY]

Thanks for your reply

2) An example SIPing message is:

options sip:OUR-IP:5060 SIP/2.0
Via: SIP/2.0/UDP TRUNK-IP:5060;branch=z9hG4bKfb6ut300306gfa5mc5c1
Call-ID: 98977160ea6ba38f5ca29c546f09ae440000g41@TRUNK-IP
To: sip:ping@OUR-IP
From: <sip:ping@TRUNK-IP>;tag=f54db0349202463f3cc0596e52b22a250000g41
Max-Forwards: 0
CSeq: 73 options
P-Charge-Info: <sip:ping@TRUNK-IP>;tag=f54db0349202463f3cc0596e52b22a250000g41

INVITEm           =  %x49.4E.56.49.54.45 ; INVITE in caps
ACKm              =  %x41.43.4B ; ACK in caps
OPTIONSm          =  %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
BYEm              =  %x42.59.45 ; BYE in caps
CANCELm           =  %x43.41.4E.43.45.4C ; CANCEL in caps
REGISTERm         =  %x52.45.47.49.53.54.45.52 ; REGISTER in caps
Method            =  INVITEm / ACKm / OPTIONSm / BYEm
                     / CANCELm / REGISTERm
                     / extension-method
extension-method  =  token

It is a point of misunderstanding.

 

[geoff.jukes]

Hi Stepan,

My apologies, I'm not sure what your reply means...

Are you saying that the PING packet is malformed? If so, would you mind posting the correct format? I can then send that back to the provider to ensure they conform.

Many thanks,

Geoff

 

[SY]

Hi Stepan,

My apologies, I'm not sure what your reply means...

Are you saying that the PING packet is malformed? If so, would you mind posting the correct format? I can then send that back to the provider to ensure they conform.

Many thanks,

Geoff

At first look, the problem may be related to the quote from RFC 3261.
I just trying to guess the reason...