Firewall check and ports

[bseddon]

My experience is that the firewall checker will only complete without error if ports 5060, 5090 and 9000-9500 are open to everyone.

I know the IP addresses (CIDRs) of the people who will be accessing using the phone system. So I would like to be able to add firewall rules to restrict access to these ports from valid IP addresses to reduce the scope for attack on these ports.

Is there a way to use the firewall checker successfully with more restricted firewall access? If the firewall check has been successful once, does it matter if the firewall check will no longer succeed because of more restrictive firewall rules?

 

[leejor]

I think that ultimately, the firewall checker is a tool, there to help you diagnose any issues you may be having related to blocked ports. I believe that you have the option to skip the test (when adding a new provider), if you have ports deliberately blocked, knowing there will be a failure if run. It's use was optional, but I suspect that because many didn't realize it was even there, it has now become an automatic step, when provisioning.

If you do experience problems later on, you may have to re-visit how you have your firewall set up.

 

[bseddon]

Thanks for your comments which I read to mean that the system itself is not reliant on the result of the checker (except to the extent that port settings are valid). I shall batten down the hatches.

It certainly was a useful tool to diagnose unexpected requirements (for a novice like me) for example that outbound UDP access was required for port 3478.

 

[leejor]

One place that it does come in helpful, and may be the reason that it now "enables" itself, is that there are now additional ports used as a default, in version 14 and up. If you left your router/firewall settings (forwarding) unchanged, as when using earlier 3CX versions, there is good possibility of calls with no audio, as the ports used now go up to 9500, if using WebRTC (9255 without).

There had been a lot of "no audio" complaints, and forcing use of the Checker probably got users pointed in the right direction, and on the way to solving the problem.