Firewall test always fails

[GLMCC]

Hi

We have 3CX Pro 16.0.493 on an onsite windows server. When we first updated to v16 update the firewall test kept failing even though we made no changes apart from the update but I just left it as everythng was working fine eg. inbound.outbonud calls, softphones etc.

I would like to find out why it fails even though everything seems to be working fine. We have a Draytek 2926 router with the correct ports forwarded to the machine with 3CX on. Below are the firewall results. These were the same with Windows firewall on or off.

resolving 'stun-eu.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX SIP Server... failed (How to resolve?)
stopping service... done
detecting SIP ALG... not detected
testing port 5060... not reachable (How to resolve?)
starting service... done
testing 3CX Tunneling Proxy... failed (How to resolve?)
stopping service... done
testing port 5090... not reachable (How to resolve?)
starting service... done
testing 3CX Media Server... failed (How to resolve?)
stopping service... done
testing ports [9000..9398]... failed (How to resolve?)
testing port 9000... not reachable (How to resolve?)
testing port 9002... not reachable (How to resolve?)
testing port 9004... not reachable (How to resolve?)
testing port 9006... not reachable (How to resolve?)
testing port 9008... not reachable (How to resolve?)
testing port 9010... not reachable (How to resolve?)
testing port 9012... not reachable (How to resolve?)
testing port 9014... not reachable (How to resolve?)
testing port 9016... not reachable (How to resolve?)
testing port 9018... not reachable (How to resolve?)
testing port 9020... not reachable (How to resolve?)
testing port 9022... not reachable (How to resolve?)
testing port 9024... not reachable (How to resolve?)
testing port 9026... not reachable (How to resolve?)
testing port 9028... not reachable (How to resolve?)
testing port 9030... not reachable (How to resolve?)
testing port 9032... not reachable (How to resolve?)
testing port 9034... not reachable (How to resolve?)
testing port 9036... not reachable (How to resolve?)
testing port 9038... not reachable (How to resolve?)
testing port 9040... not reachable (How to resolve?)
testing port 9042... not reachable (How to resolve?)
testing port 9044... not reachable (How to resolve?)
testing port 9046... not reachable (How to resolve?)
testing port 9048... not reachable (How to resolve?)
testing port 9050... not reachable (How to resolve?)
testing port 9052... not reachable (How to resolve?)
testing port 9054... not reachable (How to resolve?)
testing port 9056... not reachable (How to resolve?)
testing port 9058... not reachable (How to resolve?)
testing port 9060... not reachable (How to resolve?)
testing port 9062... not reachable (How to resolve?)
testing port 9064... not reachable (How to resolve?)
testing port 9066... not reachable (How to resolve?)
testing port 9068... not reachable (How to resolve?)



all ports in between fail but i had to delete to fit message in



testing port 10998... not reachable (How to resolve?)

 

[cobaltit]

3CX will take care of Windows firewall rules when it's installed so it's definitely not that. Is this the new server? You mentioned moving your install to a new Windows server in another thread. If you didn't upgrade your rules to the new destination IP address that could be the issue if it used to pass. Also if you haven't already, be sure to follow this configuration guide:

https://www.3cx.com/docs/draytek-firewall-configuration/

 

[GLMCC]

Hi. We have had this problem even when 3CX was on the previous machine. It started when we upgraded to v 15 or 16 within the last 12 months. We are also already following the Draytek config guide.

 

[diamond9]

For the firewall to fail and not report back on what ports, it looks like the 3cx server is going out on 1 IP address and trying to come back on another, do you have a range of external addresses or just a single?

i.e 1.1.1.1/32 or 1.1.1.1/29?

 

[GLMCC]

We just have one external static IP.

 

[kent3]

Are you able to reach the management console (port 5001) using the fqdn from an alternative internet?

 

[JohnS_3CX]

Hi @GLMCC

Your firewall checker result says unreachable. Have you modified the Windows hosts file by any chance?

Perhaps your DNS server is resolving the STUN servers incorrectly? Don't confuse the IP resolution with the IP reachability in this case.

To get the "not reachable" message the IPs of the 3CX stun servers must resolve to something invalid OR must resolve to something that your firewall does note allow either because of it being too strict or because of geoblocking for example.

 

[Alphabetic]

So your firewall test fails on ports only.
So you turned windows firewall off and it made no difference, so it's not Windows firewall.
Are you doing any load balancing on the Draytek? or played with QoS?
If you go to https://whatsmyip.org does that WAN address mirror what your FQDN resolves to?
Is the draytek the only firewall you have or have you another perimeter network?
Have you got these ports forwarded to another place? a NAS box maybe?
Have you been too restrictive under the Firewall settings of your Draytek? (Filtering rules data or call)

 

[GLMCC]

@kent3 Yes remote access via FQDN works fine.

@JohnS_3CX , nothing on the hosts file is changes and we had the same issue when 3CX was installed on a different machine

@kieferschild We have QOS or load balancing. WAN matches FQDN. We have just the Draytek and ports only forward to 3CX.

I will look through all the firewall rules to see if anything could be causing the issue

 

[Alphabetic]

Make sure on your inbound rule (NAT) you've specified the correct WAN to come in on. Safe to use "ALL".

You have created them under open ports and not port redirection?

 

[JohnS_3CX]

Hello,

The basic common factor between the two machines you tested is your network.

I have a suspicion that if you were to physically bypass the draytek you would get a completed firewall test.

Can you try this? It would quickly eliminate the PBX machine and OS as a possible issue, leaving you to focus on the network to find the solution and saving you some time. Hope this checks out for you