Cannot log in to 3CX Instance - not firewall issue - incorrect username or password

[rowebilly1]

We have a 3CX instance that was installed using 3CX PBX Express onto our AWS Lightsail about 3 months ago.
The Admin account has worked without an issue until Thursday. We attempt to log in and get "Incorrect Username or Password"
We even restarted the instance without any luck.
It is not a firewall issue because we are accessing the instance from a few IP addresses that are whitelisted and have worked previously.
We even created a Windows VM on the same network subnet at AWS Lightsail and tried to log into the instance 'locally' without success.

We have not customized the installation; we have not SSH'd into the instance and touched anything. All instances remain ONLINE without us intervening.
We have about 8 instances and this is the only one with the issue.

We have SSH access, Partner Portal access, and Backups sent automatically to our Server.
I was able to ensure the Admin password was what we have on file from viewing the data in the backup.

I can SSH into the instance as if I was in front of the Server. We also have the Server in our Partner Portal.

Why can we not log into the instance?

Everything shows UP on our Partner Portal. The ONLY odd thing I see is the count of Extensions is '1'.
Our other instances show the TRUE amount of extensions configured.

Not sure how to proceed here. Is this a new bug?

 

[cobaltit]

Are backups still running? So you have one from after the password issue started and can still verify the password (and username) is the same?

 

[rowebilly1]

Are backups still running? So you have one from after the password issue started and can still verify the password (and username) is the same?

Yes, that is correct. We have a FULL backup from installation - 10/12/2020 - and then the scheduled backups from 12/21/2020. We are not sure when the issue started.

 

[cobaltit]

I think you misunderstood. It looks to be a username or password issue. You would want a backup from AFTER the issue started to confirm the username and password is still the same as you think it is. So this would be from 12/31 or later if last Thursday is the Thursday you are referencing. Otherwise you can just restore the instance from your most recent backup since presumably nothing has changed if you couldn't login.

 

[JohnS_3CX]

Since you see only 1 extension being listed, it might be possible that someone redeployed the PBX by mistake, so who else has access to the 3CX customer portal other than yourself? Perhaps ask colleagues to make sure.

In addition, you will not be able to login using your password in case you enabled console restrictions and did not provide a static IP from which you can always connect. Your password will be denied,

 

[rowebilly1]

I think you misunderstood. It looks to be a username or password issue. You would want a backup from AFTER the issue started to confirm the username and password is still the same as you think it is. So this would be from 12/31 or later if last Thursday is the Thursday you are referencing. Otherwise you can just restore the instance from your most recent backup since presumably nothing has changed if you couldn't login.

I have reviewed backups from before it happened and after (yesterday when you asked about the backups) and the username and password are the same.
The backup I referenced was from 1/3/2021 at 10 PM.

Since you see only 1 extension being listed, it might be possible that someone redeployed the PBX by mistake, so who else has access to the 3CX customer portal other than yourself? Perhaps ask colleagues to make sure.

In addition, you will not be able to login using your password in case you enabled console restrictions and did not provide a static IP from which you can always connect. Your password will be denied,

Myself and another technician who brought this issue to my awareness. He is the Account Manager for this client.
I checked the SIP Registration and it is registered to two IP addresses. One of them was the instance we couldn't log into and the other is another instance where I am able to log in to.

So you're right. Somehow a new instance was created...
I browsed to the IP addresses from our SIP provider and was able to log into the one.

Both have the SAME 3CX FQDN.

Not sure how that is possible.

 

[NickD_3CX]

The only way I can think is that someone installed the second instance using the same license key that you had on the first.
This would mean that the second instance "stole" the FQDN from the first, so everytime you use the FQDN to connect, your are going to the second instance.

The only solution I see here is to confirm this (access the first using its IP instead of FQDN). If it is like this, delete the second instance, then restart all the services of the first instance and check if the FQDN changes back to the IP of the first.
If not, on the first instance go to Settings --> Network, set IP to Dynamic, then restart all services again.

 

[rowebilly1]

The only way I can think is that someone installed the second instance using the same license key that you had on the first.
This would mean that the second instance "stole" the FQDN from the first, so everytime you use the FQDN to connect, your are going to the second instance.

The only solution I see here is to confirm this (access the first using its IP instead of FQDN). If it is like this, delete the second instance, then restart all the services of the first instance and check if the FQDN changes back to the IP of the first.
If not, on the first instance go to Settings --> Network, set IP to Dynamic, then restart all services again.

Hello,

From what I understand, you cannot redeploy the same license key/instance without releasing the FQDN first. My colleague had to restore an instance a few months ago and had that issue - had to release the FQDN first and then redeploy.
So we aren't sure how this happened. No one redeployed the instance.
We have one instance for this client in our Customer Portal and it was the wrong instance.
We cannot find the 'bad' instance anywhere. It says Amazon IP but it is not in our account.
Perhaps this was accidentally deployed to 3CX cloud?

We confirmed this IP address was the correct instance and able to log in.
We released the FQDN from the bad instance by logging into Customer Portal and releasing FQDN.
The instance disappeared from our portal.
We rebooted the good instance.
Then went into Settings and enabled Instance Manager.
It appeared on our Customer Portal. 5 minutes later the FQDN worked and went to the correct instance.
The Customer Portal NOW shows the correct amount of extensions.
(I knew adding that little thing I noticed in my initial post may have helped someone figure out the issue!)

We do not know where the 'bad' instance is hosted.
Is it possible that one of my colleagues may have deployed it on the 3CX cloud (trial back in October when we deployed it)?

 

[NickD_3CX]

It could be that someone installed 3CX manually and not via the Customer Portal, and that way you can use the same License Key, but as you have seen the hard way, that is not a good idea....

Could you send me the first 8 digits of you license key in a PM to see what I can find? No promises, but it may give me some clues as to where it was activated and how that may help.

 

[rowebilly1]

It could be that someone installed 3CX manually and not via the Customer Portal, and that way you can use the same License Key, but as you have seen the hard way, that is not a good idea....

Could you send me the first 8 digits of you license key in a PM to see what I can find? No promises, but it may give me some clues as to where it was activated and how that may help.

Yes I will send it.
I just don't know where the instance is located -- we do not have it on our AWS account. We would like to stop it so it doesn't register/steal the FQDN.