Occasional Trunk failure DNS resolution

[Colin911]

I have an unsupported trunk that DOES work but occasionally fails. It has just worked for 5 days or so, previously was off for a day and a half, then worked for about a week.

This is the error I get.

Registration at 3940707 has failed. Destination (sip:voip.[domain].com:5061;transport=TLS;lr;maddr=6xxx.xxx.xxx.xxx) is not reachable, DNS error resolving FQDN, or service is not available.

I can ping the sip provider domain and IP from the 3cx instance server console. The sip host of course claims there is nothing wrong on their side and have whitelisted the 3cx instance's IP

I've toggled the 3cx instance firewall to to test without a firewall to no avail. Rebooted it also to no avail. Also tried to put the IP address les of the registrar and proxy instead of the domain, no effect.

The 3cx instance is hosted on Digital Ocean and up to date

Any ideas on what else to try? It is odd because the exact same settings sometimes work for many days, then it stops. It does seem to me like there is an IP ban that is happening somewhere, but since I can ping, I'm thinking no.

If the issue is not on the 3cx side, how do I prove it is on the host side?

Many thanks in advance.

 

[leejor]

Unfortunately, the error message is rather vague, giving three possible problems, which isn't much help. You might want to use something like Wireshark, running it until the problem re-surfaces. It may pinpoint exactly what is happening, which may help you figure out why it is happening.
Intermittent problems are the worse to diagnose as you just have to wait until it happens again, and then try to figure out what the cause is. Sometimes there seems to be no rhyme nor reason.

One thing you might try is changing the DNS server, if you have not already done so.

Process of elimination.

 

[KyriacosS_3CX]

Also see if you can disable IPv6 in case that is what's failing.

 

[Colin911]

Thank you. IPv6 is off ..

 

[Colin911]

Maybe I should edit the hosta file to make custom.DNS entry on the local server?

 

[SteveITS]

Just to be clear it's not necessarily a DNS problem. The error just means "I can't connect, for some reason."

When it's down you can try dig/nslookup on the 3CX server, or pinging the hostname/IP. (it sounds like pinging by IP works, at least?)

Is the 3CX blocklist blocking the IP by any chance?

 

[Colin911]

When it was down I was able to ping both the domain and the associated IP. So I agree not likely a DNS issue

I did check the IP block list and the destination IP of the sip provider has always been on the list and set to Allow

 

[SteveITS]

I would up the verbosity of the activity log, when this occurs, and see if it helps. The trunk should try to reconnect every minute or so IIRC.

 

[Colin911]

We were able to get the registration back by changing the registrar address and saving a few times and doing a test call.

The sip provider is convinced this is something wrong on 3cx side

 

[Colin911]

To be clear, the settings at the end were the same, we just toggled them back and forth

 

[Colin911]

I would up the verbosity of the activity log, when this occurs, and see if it helps. The trunk should try to reconnect every minute or so IIRC.

Turns out I already had logging as verbose and forgot to look there. This is the error we were getting during the outage.

[CM504005]: Registration failed for: Lc:10002(@3940707[<sip:10002@voip.[domain].com:5060/TLS>]); Cause: Cause: 503 Certificate Name Mismatch/REGISTER from local

 

[KyriacosS_3CX]

Seems SIP provider is using a cluster of servers, and one does not have the certificate name it should - DNS caching would mean sometimes you get given that ones IP, and are stuck with it until the DNS refreshes. You can check if you can disable secure SIP, if it's not a requirement for you, else the source node of the bad cert would need to be identified.

Check what IP the PBX things belongs to that host name when the connection is up and down - ping/host - and see if they differ.

 

[YiannisH_3CX]

This guide should also help identify the issue.

 

[Colin911]

Seems SIP provider is using a cluster of servers, and one does not have the certificate name it should - DNS caching would mean sometimes you get given that ones IP, and are stuck with it until the DNS refreshes. You can check if you can disable secure SIP, if it's not a requirement for you, else the source node of the bad cert would need to be identified.

Check what IP the PBX things belongs to that host name when the connection is up and down - ping/host - and see if they differ.

When the trunk is down, the domain pings correctly to the same IP Address as when it is up.

 

[YiannisH_3CX]

503 Certificate Name Mismatch

This error means that the common name the providers server is advertising during the TLS handshake does not match the "Registrar/Server" value you have in your trunk settings.
The fact that it sometimes works and other times it does not, could come down to various factors. The provider might change the DNS priority pointing to different servers or he might switch servers in the background while the IP remains the same.
Does your provider have SRV records or does it have a wildcard certificate?

Are you using a supported provider? If so who is it? We might be able to help if we know the provider and it's settings.

 

[Colin911]

Unsupported trunk. But I have asked the sip provider to review this thread to see if it helps.