Solved Unable to reach 3CX Updates server. Check your internet connection and try again.

[jakorsme]

https://downloads-us.3cx.com/downloads/v160

Can't access downloads/update server from within 3cx console.

"Unable to reach 3CX Updates server. Check your internet connection and try again."

If I enter the URL in the web browser directly I get a 404 response.

 

[jakorsme]

So you said it's a new VM. I'm not a VMWare guy but I've seen threads where using the E1000 vs the VMNETx interface (or maybe it's the other way around) resolved things. What NIC emulation are you using?

Started out with the problem occurring with the VMXNET3 vnic as I use on my other VMs by default.
Brentt suggested the E100e vnic, so I created a new vm using it and installed the 3cx-debian iso on it with the e100 vnic. Then restored the 3cx backup. Essentially same unaffected issue. Although with this install the 5015 didn't connect and I had to do a 3cx shell prompt config. I think it was a coincidence that it flaked out at point of connecting on 5015.

 

[jakorsme]

...although he seems to want to blame 3CX itself.

It's not so much that I want to blame the 3cx application itself, but I'm just using best practice on isolating the issue and it only occurs on this single vm that's running Debian and 3CX 6. Nothing else on the network is affected. Maybe it's the Debian and technically not the 3CX application at all. I don't know.

 

[BrenttG]

The only thing left that i can fathom as a last resort, is go signup for a free 3CX license so you get a key you can do some testing with, and spin up a clean VM, with that key, and DO NOT restore the backup, and do not perform any custom tweaking, changes, etc, go full vanilla, and see if the issue still exists.

Leave it as rudimentary basic as possible, and with a different internal IP, and just let it sit there and see if it exhibits the same behaviour. I wouldnt bother setting up the NAT rules, or porting it outside immediately, or running firewall tester, just let it run and see if it does the same thing with going unreachable.

I have seen instances where strange or corrupt configurations have cause services to crash and self right, but not in a long time.

Other then that Im at a loss, as even with our extensive use of vmware we have never seen this before, but we are using all Dell Officially supported hardware for vmware, that is on the hardware support list, not saying your's in particular isnt, but we have no way to know.

 

[BrenttG]

ACTUALLY, a last moment thought that is super easy to check has come to mind.

While the management console is reachable, on your own PC, and assuming you are on the same local subnet as it is, ping it, and then run "arp -a" and note its mac address down.

When it goes offline, repeat the process and see if the mac address has changed, or is absent entirely.

 

[jakorsme]

I notated the mac addr - we'll see.

 

[JohnS_3CX]

The vanilla install that Brentt mentioned is a good way to eliminate additional factors, there are some changes that when done in Debian will entirely mess up your installation (corrupted files/permissions) and will stop the updater with the above error.

 

[jakorsme]

Ok - I've identified the issue (with pointers from Brentt on IP/Mac addr).

The 3CX server is alternating between two mac addresses for its IP. One is the correct one (where connections work) and the other is the bogus/"conflicting one.

I searched online for the manufacturer of the conflicting mac addr and it is Apple.
It turns out it is the mac address of my iphone (WTH?)

So:
0:C:29:4B:7F:8A = good address
70:F0:87:7D:F09 = Duplicate address used by iPhone

I'm changing my iphone to a non conflicting static and hopefully the problem will cease.

 

[BrenttG]

Ok - I've identified the issue (with pointers from Brentt on IP/Mac addr).

The 3CX server is alternating between two mac addresses for its IP. One is the correct one (where connections work) and the other is the bogus/"conflicting one.

I searched online for the manufacturer of the conflicting mac addr and it is Apple.
It turns out it is the mac address of my iphone (WTH?)

So:
0:C:29:4B:7F:8A = good address
70:F0:87:7D:F09 = Duplicate address used by iPhone

I'm changing my iphone to a non conflicting static and hopefully the problem will cease.

So the moral of the story is:
VMware was working properly.
3CX was working properly.

You had a network issue caused by an Iphone getting the same IP as your 3CX server and causing a conflict.

Configure your DHCP server to not hand out that ip, IE a reservation, or if you have static ip'd the iphone, as you stated you are not a fan of DHCP, well thats on you.

The Iphone brought your network and your server to its knees.

In case you couldnt tell, i hate apple stuff, closed minded tech, lock you in, made in china by foxconn, needlessly proprietary, milk you of all your money, and most of their software is stolen from open source.....

 

[jakorsme]

I also excluded the 3CX static ip from the dhcp address pool (from at least our main dhcp server).
It looks like I'm going to have to take some time to configure dhcp to a smaller finite range (as much as I've always disliked it) as there's a bunch of mobile devices using it apparently.

 

[cobaltit]

Heh.. not a fan of Apple products myself (at least for business use) but the fact that it was an iPhone is neither here nor there. As usual, most problems here boil down to networking and this is another example. Glad it's resolved!

 

[JohnS_3CX]

Glad to hear it was resolved, thanks for updating the thread