3CX: not reachable, DNS error resolving FQDN, or service is not available

[Y Patrick]

I've made a change to the network with access to WAN and adjusted services accordingly. However, with 3CX (Windows installation, and then replaced with a Debian installation) I'm having such a difficult time getting 3CX working again.

I'm receiving the following log messages when registering SIP trunks on 3CX (note: I've altered my providers details).

Registration at T-123456 has failed. Destination (sip:[email protected]:5060) is not reachable, DNS error resolving FQDN, or service is not available.

05/09/2018 11:19:04 AM - [CM504005]: Registration failed for: Lc:10004(@T-123456[<sip:[email protected]:5060>]); Cause: Cause: 408 Request Timeout/REGISTER from local


Fact 1: I'm able to register SIP trunks using a Yealink phone system without any modification to the setup.

Fact 2: My hardware firewall is intercepting some packets from 3CX, flagging them as a Land Attack as the source and destination addresses are the same (of my 3CX IP server).

Fact 3: DNS is working on the 3CX server.

Fact 4: In diagnosing this issue, I changed the 3CX IP and the SIP trunks registered immediately after.

Fact 5: The router and firewall are correctly configured in respect to port forwarding etc. and there aren't any issues with access to the WAN.

Fact 6: I've tried other SIP trunk templates without any success.

Fact 7: The 3CX firewall test fails but then 3CX was working perfectly before when SIP trunks were registering.


There isn't any doubt this is a 3CX issue when looking at all the facts.


Are there any suggestions?

 

[eddv123]

Hi Y Patrick,

It simply means that your provider is not reachable.

Try rebooting your router/firewall - I have known this error to go away sometimes if you do this.

If this does not work try a ping and trace route to your provider IP - does this work correctly?

Also what are you using as your DNS server? Try changing the servers DNS to Google on the server itself (8.8.8.8) to see if this helps.

Failing that call your provider.

 

[Y Patrick]

The suggestion to reboot the router solved the issue, but not as you would have expected. The issue is with the router where after making any changes to NAT required a reboot to complete the changes, otherwise results are erratic explaining why I had such a frustrating time. I chose this brand of router over a Cisco and now regret it as Cisco routers don't have this quirk (or bug). Also, Yealink seems to be more "relaxed" with SIP trunk registration compared to 3CX which is why it was easier to get Yealink running.