I have seen this exact problem on many 3CX instances that are correctly setup per the 3CX documentation. The scenario occurs when you have utilized a network security appliance to, in my opinion, correctly lock down network traffic. What I do not think is well documented is the mechanism of test that is occurring when firewall checker occurs and what it is trying to assess. I had many PBX that worked 100% correctly, but failed firewall checker. I troubleshot it further and found the formula to make it work.
A valid network layer security approach is to restrict what the PBX can communicate with on certain ports and protocols.
If you create a network layer policy that allows the PBX to make connections to stun endpoint FQDNs, what I found through testing was that the connection can be allowed outbound, but in the cloud infrastructure there is a handoff, so the return packets are coming from a different IP address that does not have a PTR record registered for one of the STUN FQDNs. Since those IP addresses do not have PTR records, the network security appliance looks up those IPs and finds they are not part of the STUN FQDNs that you specified in the policy as being allowed to communicate with. Therefore it will fail. You can make the firewall checker work fine if you find those IP addresses and include them in the comms alias you have created.
I did bring this up to support who recognized what was going on, but I do not believe any modification on the cloud server side was ever made. As a result, if you are running a hardened network layer security strategy around the PBX, then this additional modification is required in order to make firewall checker work.