403 Forbidden - NGINX

[Benjamin Williams]

One of the Windows 3CX PBX instances that we manage is throwing the following error when attempting to connect to the management console.



So here is what we know - the error occurs under the following conditions: it doesn't matter what browser is used, whether you attempt to access the PBX internally or externally, by IP address or by way of FQDN, everything results in the same 403 Forbidden Error Message.

I have manually bounced all of the services and even restarted the server that 3CX is installed on; same error persists.

Some other misc. info that I will share: the call flow on the PBX is still working without issue; meaning, inbound/outbound calls are working just fine. In fact, the backs are still running each night as well. I mean, it seems like the majority of functionality is in tact other than being able to manage the dang thing.

1. 3CX is running on a Windows VM
2. 3CX is v18 Update 4 I believe (Professional)
3. The VM is running Windows Server 2019 Standard build 1809 (not hosted in the cloud, this is on-prem)
4. IP Phone Make/Models: Yealink headsets (T-42s)
5. Firewall Checker Passed
6. No recent changes from either a firewall and/or 3CX perspective.

 

[Benjamin Williams]

I inadvertently posted this to the wrong forum - it looks like it was moved over to the correct forum - adding a 'bump' to the thread for better visibility.

 

[Saqqara]

Check out - https://www.3cx.com/community/threads/services-not-starting-after-reboot.84953/

 

[Benjamin Williams]

Did the '3CX-services-not-running' problem described in the link above also impact the Windows version of 3CX? That is the instance of mine that is currently being impacted... From what I can tell, every single one of my 3CX services (according to the windows services.msc) are up and running; I am wondering if maybe just stripping out 3CX and restoring from the latest backup will resolve the problem? I'm a bit apprehensive in doing this only because everything at the moment is working fine; that is, inbound/outbound phones calls work, the daily backup I have configured is working, we are still getting certain alerts from the PBX. (I just can't hit the management console)...

Thanks for your response.

 

[Saqqara]

Sorry , did not read you have then windows version.

if you run services.msc , are all the 3cx services started ?. If not try to start the stop services.

the services that are stopped, change the startup type to automatically-delay

if you have a backup, maybe worth uninstalling 3cx and reinstalling - just make sure the backup file is outside of 3cx folders

 

[Benjamin Williams]

Thanks, all of the services are able to start; all services appear to be up/running... (at least according to the Windows services.msc module)...

 

[bryanc@direct-automation.]

Same issue here. all services are running. i can get to the Web Client but not the management console

 

[Charles_3CX]

As a first step, ensure the 3CX system is the latest version of U 8 build 935.

If running on update 4 see below:

• Take a backup
• Download to a safe location
• Uninstall the current outdated system
• Download the latest installer
• Install and restore the backup

Then, check which URL and port you use to access the management console.

And depending on where you are trying to access, external or internal?

For example
If local (internal), use HTTP://IP_adress: port. If using the default HTTP port of 5000, enter HTTP://IP_adress:5000
If external, use https://fqdn: port If using the default HTTP port of 5001, enter https://fqdn:5001

 

[Benjamin Williams]

This same issue happened 2 or maybe even 3 additional times after I originally started this thread (same customer). In the end, I never ended up identifying a resolution. (I literally spent months on trying to find an answer) ...

In my case, the problem appears to have been introduced after failed firmware update(s). (Note: The majority of the PBX's I manage are set to auto-update and I've never had a problem w/this approach, w/the exception of this particular instance). At any rate, it was observed that a large quantity of files were missing from one of the Program Files installation folders (I can't recall exactly which folder at the moment). In the end, I just gave up - I converted this office to a Debian instance of 3CX and have never had the problem re-emerge.

 

[bryanc@direct-automation.]

For us, it was our antivirus killing the update and subsequent install attempts. We use trend micro and had to add exceptions to get the install to work. Something I would have rather not done, considering 3cx was recently distributing compromised software in their Windows client. Even worse, when I called 3cx "support" they told me I should just not run AV at all.

 

[Charles_3CX]

For us, it was our antivirus killing the update and subsequent install attempts. We use trend micro and had to add exceptions to get the install to work. Something I would have rather not done, considering 3cx was recently distributing compromised software in their Windows client. Even worse, when I called 3cx "support" they told me I should just not run AV at all.

I dont think not running AV would have been advised, although the compromised version for the desktop has now been fully fixed.

But is it not advised when installing software or running updates for any other software, not just for 3CX, that AV be disabled for the installation or update?

 

[bryanc@direct-automation.]

I don't think not running AV would have been advised, although the compromised version for the desktop has now been fully fixed.

But is it not advised when installing software or running updates for any other software, not just for 3CX, that AV be disabled for the installation or update?

A great example of why you would not want to disable AV during installs/updates is the 3cx web client compromise. We are an MSP so we provide AV on all of our clients machines .We are currently moving our customers from ESET to Trend Micro. When the compromised 3cx client dropped, Trend detected it and block the install. ESET unfortunately did not. We actually found out about the compromise early because our customers that use Trend called to complain that their softphone was not working.