Extension unregistered troubleshooting

[Clogsdon]

I need some help troubleshooting two extensions that became unregistered overnight. These two extensions are at remote office with a total of three extension, meaning only one working extension working properly at that location. The remote site is connected via site-to-site VPN to main office where the W10 SBC resides. The 3CX PBX 16.0.4.493 is hosted in the cloud and all phones are Polycom VVX300 running FW 5.7.

I am new to 3CX and VOIP in general so my troubleshooting skills are still growing. This morning I did the following to troubleshoot the issue:

• Viewed the activity log and noticed all phones unregistered/registered at 1:00 am this morning with the exception of these two extensions
• I confirmed the SBC service was running
• I confirmed traffic was flowing from phones to SBC
• Powered cycled devices
• Deleted a phone from the extension, via web interface reset phone to factory defaults
• Surprisingly re-provisioned phone successfully
• Downgraded phone to supported FW 5.6 per 3CX manual

However the phone is still not listed in the dashboard and end user cannot make calls. These phone have been in place working without issue for about 3 months. Please advise.
Thanks,
Chad

 

[rgruber]

You may have to reinstall SBC. When you reinstall SBC, you have to make sure you reboot W10 machine that it resides on. Before you reinstall: Are you using IP or fqdn to connect to 3CX? Do you have a valid certificate for your 3CX server? Under the extension, inside the phone provisioning tab, is your provisioning method set to the SBC? Also on your VVX300, are their certificate settings under its config page?

 

[Clogsdon]

I am using FQDN to connect to 3CX with a valid certificate. I also have the provision settings for each phone correctly set to SBC.
This is a fairly new setup but has been running smoothly for more than 3 months with out issues until last night.
I was running a modified Polycom template, but I just reverted back 3CX default Polycom template for testing and still cannot get them to register.

 

[Alphabetic]

Are all 3 phones the same setup?
Is it the same time every night?
Are all 3 phones powered/networked the same?

Check what the 3 phones have in common/uncommon first.

Can you ping the SBC from the phone and vice versa?

has the IP of the phone got in the 3CX blacklist?

have you checked the activity log in 3cx for these EXT?

What do you normally do to fix this problem? Restart SBC or restart Windows?

What switch have you got at remote office?

if you factory reset a phone does it show up in 3CX?

 

[eddv123]

We have seen negative results with running SBC and VPN alongside one another, simply due to the DNS. The phones should if connecting across a VPN be connecting locally (locally routed subnet) to 3CX where if using SBC they will be going to the public FQDN.

Do you have the PBX setup in split DNS mode or public FQDN and local IP for phones ? I think the phones maybe getting confused between local and public IP/FQDN's.

How are the phones actually provisioned ?

 

[Clogsdon]

Are all 3 phones the same setup?
Is it the same time every night?
Are all 3 phones powered/networked the same?

Check what the 3 phones have in common/uncommon first.

Can you ping the SBC from the phone and vice versa?

has the IP of the phone got in the 3CX blacklist?

have you checked the activity log in 3cx for these EXT?

What do you normally do to fix this problem? Restart SBC or restart Windows?

What switch have you got at remote office?

if you factory reset a phone does it show up in 3CX?

All are identically setup and configured.
Nothing in the blacklist
Activity log indicates unregistered ID:4101
This location has an unmanged switch behind a Sophos Remote Ethernet Device (RED VPN Site to Site) connected to a Sophos XG 135.

Factory resetting does not make the phone show up

Thanks for assisting

 

[Clogsdon]

We have seen negative results with running SBC and VPN alongside one another, simply due to the DNS. The phones should if connecting across a VPN be connecting locally (locally routed subnet) to 3CX where if using SBC they will be going to the public FQDN.

Do you have the PBX setup in split DNS mode or public FQDN and local IP for phones ? I think the phones maybe getting confused between local and public IP/FQDN's.

How are the phones actually provisioned ?

I was doubtful myself when it was deployed, but deployment went flawless and has been for more than three months.

The PBX setup is using public FQDN and local IP for the phones.

These three phones are provisioned by pasting the provisioning ling in the phone and rebooted. They are different than the main office which are provisioned via DHCP opt 66. The phones will pull down the line information and change the admin password but will not register.

Thank you for contributing

 

[Clogsdon]

The third phone that was working yesterday, is not today... So all three phone at the remote office are unable to register.

 

[eddv123]

provisioned via DHCP opt 66

We always use DHCP option 66 when using VPN, if doing the manual provisioning link method this can give issue when performing operations such as auto firmware updates from the PBX I have found.

If using VPN connections purely - 2 points in regards to phones de-registering (we have experienced similar problems on some sites - which have been fixed by):

* Increasing the Phase 2 rekey timer on the VPN tunnel (and ensuring both ends match for example 28800/28800.

* Setting margintime on the IPSec firewall to 120 (known to combat stale UDP sessions).