• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Solved 3cx port forwarding

Status
Not open for further replies.

Petersang

Forum User
Joined
Jan 21, 2021
Messages
56
Reaction score
4
Hello team i have configure all port forwarding for my pbx but the firewall checker still show me the full cone test fail.

Any help ?
 
Last edited:
What firewall? If your port forwarding is correct but the checker still fails it's usually one of three things:

- Incorrect port forwarding
- SIP ALG is on
- Double NAT or Carrier NAT
 
The Firewall is fortigate, all ports is working i can access from anywhere with 5001 rtp ports is working 5060 and 5061 works too but the firewall cheker still showing me full cone test fail, maybe because cannot ping the public ip of my pbx ?
 
i have resolve 50% of my problem because in my firewall only my country can see the public ip of my pbx now i have test with firewall cheker only 9000-10999 show me done like this photo
 

Attachments

  • Screenshot_20210515_191118.jpg
    Screenshot_20210515_191118.jpg
    310.5 KB · Views: 21
Hi Firas,

Did you reboot the Fortigate after you disabled SIP ALG?
 
The only way i have its to rebooting the fortigate but the firewall is not only deployed for 3cx because the firewall is in datacenter and there is more other vms of others customers i can't reboot the firewall
 
Hi Firas,

Well I suggest putting in a maintenance window somewhere in a weekend night and then reboot the Fortigate.
I'm afraid that's all we can suggest you to do on this forum.
 
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.
 
The 3CX Firewall checker article does not include a list of the IP addresses involved nor does it include all the FQDNs involved. These can be identified through observing the traffic flows if a DNS proxy is used. We don't expect 3CX to explain how to run the PBX behind a network layer security appliance that has been setup with very strict hardened flows. But it would be helpful if all the FQDNs involved were included in the article.
If 3CX does not want to disclose IP addresses, there should be no issue disclosing the FQDNs involved. The only FQDN mentioned is stun.3cx.com, but that's not enough to be included in an alias for allowed endpoints in order to make the firewall checker work. This was the state of the firewall checker in 11/2020.
 
The guide does indeed only mention one FQDN, though, when running the 3CX Firewall checker, you can actually see more(which ones depends on your 3CX configuration):
1621252243262.png

That said, the IPs these FQDNs resolve to are not the only ones used during the firewall test so even if these are also allowed it would still not be enough. You can of course observer the traffic during the firewall test in order to determine what other IPs and ports are involved, however, we cannot guarantee that the configuration applied on the network level will always be valid as these IP's/Ports may change at any time without warning. This is one of the reasons we do not provide a static list of IPs.
 
Has any improvement been made on ensuring that all of the IP addresses involved in the stun FQDNs have PTR records that match? I found the firewall checker was failing because outbound traffic to the stun FQDNs would occur, but then return traffic came from a different IP address that did not have a PTR record that resolved to one of the stun FQDNs. This caused a situation where unless the network layer security said that anything could make these inbound connections to the PBX, that traffic would be blocked. When I raised the issue to support in November, it was a known issue. Verifying that the IP addresses involved had PTR records that match the appropriate STUN FQDNs would resolve the issue. Unfortunately, this is not something that we can control. That is 3CX controlled only.
 
I found the firewall checker was failing because outbound traffic to the stun FQDNs would occur, but then return traffic came from a different IP address that did not have a PTR record that resolved to one of the stun FQDNs
As per our guide this is actually on purpose as described in Test 2.

What you could do, is simply have the firewall checker pass the test before locking down the network and once done, proceed with implementing all required network restrictions. From that moment on, if you ever face 3CX issues and need to submit a support case, do note that you will first have to lift all network restrictions and make sure that you can pass the firewall checker while the issue is being investigated by our team.

The alternative would be to analyze the network traffic required for the 3CX firewall test and therefore implement the appropriate configuration on the network level. However do remember that the IPs/FQDNs may change without warning or they may also be different each time you run firewall test, so maintaining this configuration may require more effort.
 
Hi Chris, thanks but neither is a viable option from my perspective. Disabling security is not a viable approach, nor allowed in the regulated environments we manage. Instead what is viable is to get to the root cause. We cannot be disabling security just to engage support.

I'm not asking for 3CX to provide a solution to how to do network layer security around the PBX. I simply identified a problem that the PTR records were missing for 3CX hosted and controlled assets and that fixing that would fix the problem for everyone running the PBX in a more hardened network security strategy. I raised the issue to support. They confirmed the issue. The issue should have been escalated from there to improve the back end management of the 3CX cloud hosted assets to verify that PTR records existed for owned assets. That's all that would be needed to fix it.

Keep in mind that I'm not asking for help here. I was providing it. Another 3CX customer was stating that they were having the same problem and the recommended solutions were to reboot the network layer security appliance, which may not have been the actual solution to the problem.
 
I completely understand what you are saying, but, do be reminded that the 3CX Firewall checker is only there to act as a guide in regards to network configuration. Even if PTR records existed for every IP, it would still not resolve issues such as having SIP Provider's IPs being blocked due to hardened network configurations. Therefore, if all network requirements of the SIP Provider are known and have all been incorporated in your network configuration, failing the 3CX Firewall checker will only be a presentation inconvenience which you can easily get rid of by temporarily lifting all restrictions, passing the test(should not take more than 20 minutes), and then restoring all desired network restrictions.
 
Speaking as a network security architect and CISO, temporarily lifting all restrictions on a WAN facing asset is not an allowed approach in regulatorily compliant environments. I would be laughed out of a change management meeting if I advocated that approach. It's just not allowed. It is colloquially referred to as "over-troubleshooting". We have to document and justify configuration changes. They are recorded and audited. We protect assets also in the utility industry like gas pipelines and power plants. Over-troubleshooting is not allowed. I hope the information I have conveyed here at least helps some other customers who may be faced with the same challenges.
 
In sophis XG works but fortigate no
 
Thanks my problem with my firewall bug
 
  • Like
Reactions: NickD_3CX
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Forum statistics

Threads
141,632
Messages
748,963
Members
144,748
Latest member
Murad88
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.