Solved 3CX 16.1 Linux 503 DNS issues with SIP Trunks

[A-A-ron]

I have been setting up a new 3CX instance for a client and am running the Linux version. It has passed all the firewall checks but seems to be having DNS issues with the SIP trunk. We are going with Flowroute as the SIP provider as it is 3CX approved. When I set it up I get a DNS error 503


I did a ping and I can resolve that address and also I can do a nslookup successfully via the linux command line:



So DNS is working on the backend. If I put the IP that it resolved to instead of the FQDN the trunk comes up and registers successfully. I also tried another trunk I have working on a 15.5 system on this 16.1 instance and I have the same issues, I get the 503 error. If I put this trunk on the 15.5 instance with FQDN it works as expected. I then looked at the resolve.conf file and that looks correct

and also the interface config


Is there another file that the 3CX is using to call on DNS queries for SIP trunks that I might have missed? I have searched the forums and the only other thing I saw was to add transport-tcp in front of the FQDN and that didn't work either. I can only get this trunk or the other one I borrowed from another system to test with to register if I put in the IP and not the FQDN, yet DNS seems to be working on the rest of the system as it does pass the firewall check and is able to reach out to 3CX as well. Any help would be appreciated.

Thanks,

 

[JohnS_3CX]

Hi @A-A-ron

The best thing to do in this case in order to investigate further, open two MC tabs: one with the services page and one with the capture page (Activity log).

1. Start the capture
2. restart the SIP Service while capture is still running
3. wait for the services to restart and the system to try to register by resolving the flowroute FQDN
4. end the capture and filter for DNS requests in WireShark to see what happens

Note: We checked the Flowroute FQDN you use and it appears to resolve just fine from here and will register successfully.

 

[Marcel Odermatt]

I have the same issue, but different Provider. It's been a while ago since i invested time in investigation this issue. As far as I can remember, the log said something like the dns lookup is done with a specific flag. Othe than the dns lookup from terminal. An this specific lookup with this flag will not be answered or is getting a empty answer. The trunk will never register. I had the Problem only with one ISP, but i'm not 100% sure, thats a ISP related issue. But it wasn't possible to further investigate together with the ISP, the Ticket should still be open, but they will never answer

 

[A-A-ron]

I ran the pcap and I do see that from the NIC it can resolve DNS for flowroute to 34.226.36.34 which is exactly what I get from the back end. What I see interesting is then it starts using the local loopback to do further queries for the SRV records and also get request timeouts for ICMP from the local loopback. Is this normal to use the loopback address instead of the NIC interface to address for the request?
If I'm not mistaken the local loopback from what I see in the default IPTables on the linux side is set to drop packets. The IPTables rules were all created by the 3cx installer and I have not modified those and I also compared them to the working 15.5v I have running on the same ISP circuit and it matches the same. I am by far not a linux or wireshark expert but I have attached the filtered pcap and IPTables if there is something that I am missing here or possibly something else that might be going on.

Thanks again for the assistance

 

[JohnS_3CX]

Indeed this is not expected behavior and I cannot replicate it on mine (which has the same IP tables as yours).

Have you installed any other packages that did not come with the 3CX ISO or made any other changes beyond the IP tables? It seems from the capture that whatever is happening, it's on the machine and not the network.

 

[Marcel Odermatt]

Hi, i did some dumps too. From two different systems, one works fine, the other fails... I hope i set the filters right, if not, just tell me.

 

[A-A-ron]

It turns out it was a bad install. I was able to open a ticket and work with a tech and we tried to enable the verbose logging and as soon as I restarted the services it crashed the database and wouldn't restart the services. The tech tried to rebuild the system from linux ssh but no luck. Had to create a new vm with a fresh install and then restored the backup I had of the system and was able to restore and everything came up and is working now. So looks like it was a corrupt install.

 

[JohnS_3CX]

Hi @A-A-ron

I'm glad it was resolved