My own WAN IP is blacklisted, also user agent questions

[Aaron WVHP]

Hello all. First post here. I searched before posting, so please forgive me if my search terms did not land me to the answers I seek.

I'm new-ish to 3cx, but not new to VoIP or networking. Just playing around with 3cx to see if it can be a viable solution for replacing our existing, rock solid Avaya IP Office platform we already have.

I come to the 3cx experts with a question about 3cx auto-blacklisting IP addresses, specifically my 3cx blocking its own WAN IP. I'm fine removing the self-blacklisting, but I suppose the question I have is why did it blacklist it's own NAT'd WAN IP? (3cx VM lives in a DMZ behind my firewall, the IP in question is assigned to the DMZ vLAN, so it's 3cx's public ip)

The Description given is:
PBX: blocked for too many failed authentications; User-Agent: Avaya IP Phone 1120E

....which then takes me to my second question:

Where do you define which User-Agent Strings are allowed to connect to 3cx so I can stop this or at least slow it down? Having the PBX's own WAN IP blacklisted is pretty much a no-go, lol.

That being in the Blacklist Description is why I thought the question should be part of this thread, instead of it's own.


Thanks in advance for any insight.

 

[cobaltit]

You would want to whitelist the IP. It's not getting blocked because of the user-agent, but because of the failed authentication. But if you did want to make changes, as long as you are no on 3CX hosted you used to be able to find that in the advanced parameters. But making changes there is not supported, and may not even work anymore.


As far as why it's getting blacklisted that is a networking question, not a 3CX question. 3CX will block whatever it sees as the source of the infraction. In this case, something (presumably your firewall) is re-writing traffic to make it look like your WAN IP is the source.

 

[JohnS_3CX]

Hi Aaron and welcome to 3CX!

It will block the IP address that is sees as a source coming from your network, if that IP triggers the security protocols.

This user agent is not what is being blocked here, so you gain nothing by manipulating the user agent. You need to make sure the phone signs in with the correct credentials, but it also needs to be sitting on the correct network: either on the same LAN subnet as the PBX.

You can whitelist the IP, but if your network setup is such that it makes ALL traffic appear to arrive from that IP then you would be defeating your own security in a sense.. This is not a recommended network setup, the PBX needs to be able to see the true source IP in order to function as designed (both security-wise and SIP-wise). We have seen similar cases before where people locked themselves out entirely by manipulating traffic in a way the system was not designed to be deployed in.

What is the expected setup? Put 3CX behind your public firewall, and port forward whatever 3CX needs.
The system will be able to differentiate between public traffic, and local RFC1918 traffic