IP address "detecting"

[Sublight]

Please let this just be me being stupid.

Like other reports, this system stopped registering its Trunks around Sept 1. No one noticed due to covid. The system would not re-register after service restarts, vm reboot, trunk recreation, nor using IP instead of DNS so an update was performed. We can talk about that later.

The new, additional, issue is IP is "detecting" on dashboard.

Dynamic IP but it has not changed since the last known working state.
XXXX.co.3cx.us FQDN resolves correctly.
All internal IPs and ports are allowed OUT through the firewall.
Log indicates there are issues talking to the pre-configured 3CX Stun servers: stun-us.3cx.com, stun2.3cx.com, and stun3.3cx.com

Log has (on each service restart):
"Your public IP has changed and 3CX updated your FQDN records from X.X.X.X to ."
"STUN server 54.39.182.217:3478 could not be reached (time out three times). It could be that the STUN server you are using is down or a network problem is preventing STUN resolutions. This might cause problems if you use VoIP Providers."

• 3CX Version, e.g. Standard Annual 16.0.7.1078
• Server OS, e.g. Debian
• Is the 3CX Server Hosted and where? VM on-prem hosted
• Trunk Provider? voip.ms
• Has the Firewall Checker passed: NO (error: Value cannot be null. (Parameter 'address')
• Are custom Phone Templates being used: NO

I would prefer not to blow this install away and start over. Help is much appreciated.

 

[Evolute IT]

Sounds like DNS resolution issue.

Try pinging "activation.3cx.com"

 

[Sublight]

Sounds like DNS resolution issue.

Try pinging "activation.3cx.com"

Thanks for responding.

The address resolves to 151.80.125.88 but does not respond to ping. It also does not respond to ping from a phone on cellular data.

Edit: I can successfully ping any of my test domains but I can not ping anything from *.3cx.com. Same results from a cellular network.

 

[luke87]

Sounds like some ports are blocked on your firewall.

 

[Evolute IT]

Thanks for responding.

The address resolves to 151.80.125.88 but does not respond to ping. It also does not respond to ping from a phone on cellular data.

Edit: I can successfully ping any of my test domains but I can not ping anything from *.3cx.com. Same results from a cellular network.

Ping is disabled on those servers so no they won't reply. But the IP sounds good so DNS resolution might not be the issue at all.

Just to be sure, what DNS is the server currently using?

 

[Sublight]

DNS routes to Active Directory -> Pi Hole -> Google

Nothing in AD to mess it up. Pi Hole has *.3cx.com whitelisted.

Out of curiosity, I set the External IP Configuration to Static Public IP and the system works, the truck registers and makes calls. @luke87 seems like my ports are fine.

Should I switch back to Dynamic?

 

[Evolute IT]

DNS routes to Active Directory -> Pi Hole -> Google

Nothing in AD to mess it up. Pi Hole has *.3cx.com whitelisted.

Out of curiosity, I set the External IP Configuration to Static Public IP and the system works, the truck registers and makes calls. @luke87 seems like my ports are fine.

Should I switch back to Dynamic?

You can try but if the STUN does not reply, next time the IP changes your system will stop working again.

 

[Sublight]

Any idea what the deal with STUN is then? The Firewall Check all passed except the 3CX Tunneling Proxy because port 5090 is blocked on purpose.

 

[cobaltit]

DNS routes to Active Directory -> Pi Hole -> Google

Nothing in AD to mess it up. Pi Hole has *.3cx.com whitelisted.

Out of curiosity, I set the External IP Configuration to Static Public IP and the system works, the truck registers and makes calls. @luke87 seems like my ports are fine.

Should I switch back to Dynamic?

What you should do is remove AD and the PI hole and go direct to Google DNS for now. You should also unblock 5090 (not sure why it would be blocked in the first place as it is secure) and pass the firewall test. Then once everything is working you can go back to blocking 5090 and using your original DNS. You also don't mention what hypervisor you are running the VM under although I don't think that is the problem in this case