Accidentally created new instance with another PBX's current FQDN

Status
Not open for further replies.

TDJ211

Bronze Partner
Basic Certified
Joined
May 10, 2020
Messages
24
Reaction score
3
Stupid Google autofill used an existing FQDN on a new instance I was creating inside PBX express. I noticed as soon as I saw the installation had finished. This happened about 30 mins ago. Luckily its the evening so I at least have some time to plan for the worst.

I tried deleting the new PBX and changing the External IP Configuration from static to dynamic of the existing PBX to get it to update. But so far it still points to that now deleted PBX.

This existing PBX has 50+ extension. The office phones of this PBX I can update remotely which is about 10-15 extensions but the rest are the 3CX app. The app uses the FQDN correct? If so, does that mean I would have to contact every single app user and have them rescan QR code? That would suck. Thats worst case scenario I guess.

Is there anything I can do with the FQDN? Will the existing PBX eventually update the FQDN to point back to itself? Or is there some kind of security/certificate thing where the FQDN has been hijacked by the new one and there is no return?

Any help would be greatly appreciated as this is our biggest VOIP customer.
 
So it shouldn't have been able to use the FQDN unless it also used the key, otherwise anyone would be able to hijack other people's FQDNs. So what exactly happened here?

Try refreshing the license information on the existing instance and see what happens.
 
  • Like
Reactions: TDJ211
So it shouldn't have been able to use the FQDN unless it also used the key, otherwise anyone would be able to hijack other people's FQDNs. So what exactly happened here?

Try refreshing the license information on the existing instance and see what happens.

Yea, thats what I was thinking. This is weird.

Thanks, refreshing is a good idea. Even if it works, its gonna take some time to proliferate
 
So if I have to change the FQDN inside the PBX. Is that possible or do I have to nuke it and restore from backup? Oh wait, the backup might have the FQDN inside it.

Do I have to start from scratch??
 
The FQDN is definitely resolving to the new IP according to my router and online DNS queries.

But all of the extensions are still showing connected to PBX. Its just a matter of time I guess. How long can I expect this to last?

Also this site is using Mikrotik and looks like I can set a static DNS entry to spoof the DNS resolution as a temp fix for the office phones tomorrow morning. That will buy me some time. The office phones are the highest priority.

EDIT: Nevermind, DNS spoofing obviously isnt going to work as the phones/SBC appear to be usibg their own DNS servers, not the router. That would be too easy,.
 
Last edited:
EDIT: Nevermind, DNS spoofing obviously isnt going to work as the phones/SBC appear to be usibg their own DNS servers, not the router. That would be too easy,.
They usually use 8.8.8.8 by default, but should follow DHCP over that tho.
But all of the extensions are still showing connected to PBX. Its just a matter of time I guess. How long can I expect this to last?
6 hours for Std and Pro. 5min for Ent.
 
  • Like
Reactions: TDJ211
*
 
Last edited:
First of all, because it wasn't 100% clear, delete the new PBX you created with the same License Key/FQDN and leave only the one that should remain.

After doing this, try:
  1. Setting the remaining PBX to Dynamic Public IP
  2. Restart all 3CX Services
  3. Wait 30 minutes
  4. Seth Public IP back to Static
  5. Restart all 3CX Services again
After this, it is a waiting game for the DNS propagation, although settings Google DNS on all the devices that you can does speed up things.
 
OK thanks.

Last night I wasnt able to solve the FQDN problem but I was able to get the office phones back up temporarily

I redirected the SBC DNS queries from the Mikrotik router to a local static DNS entry. I could see from the ping that it was pinging the correct IP (logged into lightsail account and enabled ICMP) and could see from the nat rule counters it was working but I still couldnt connect. I then realized we have the Flowroute DID using DNS as well. Changed it to the static IP and within a few minutes I was able to dial in and hear the IVR.

Whew...the app is an issue but its something we can live with for now.
 
Got this response from 3CX support and it worked. Basically what NickD said. Just a few less steps.

You can restart the service which is "3CX PhoneSystem 01 System Server" so that will update the 3CX ERP with the IP of the PBX and then update your DNS A record too.
Since the other PBX is still running, then you should leave it as-is and all should work as it was and you do need to rescan QR codes of the APP.
Thanks everyone for your responses. Ill report back if the app needs rescanning or not.
 
  • Like
Reactions: NickD_3CX
Status
Not open for further replies.

Forum statistics

Threads
111,974
Messages
590,083
Members
164,901
Latest member
Silent_Guru