Why the Firewall Checker Does Not Lie

[KaterinaK_3CX]

Read the guide.

 

[PeterCheng]

Hello sir,
Because what I wireshark is almost the same with the guide.
For test 2 in the guide, what should be the correct response?
Thanks.

Peter

 

[NickD_3CX]

Hello sir,
Because what I wireshark is almost the same with the guide.
For test 2 in the guide, what should be the correct response?
Thanks.

Hi Peter,

In Test 2, the PBX sends the STUN request to IP A of the STUN Server, but then the STUN server replies from IP B which the PBX doesn't know.

The example in the screenshot shows that the PBX sends 3 requests without getting a response. This means that basically the screenshot of Test 2 shows a failed attempt.

 

[PeterCheng]

Hi Peter,

In Test 2, the PBX sends the STUN request to IP A of the STUN Server, but then the STUN server replies from IP B which the PBX doesn't know.

The example in the screenshot shows that the PBX sends 3 requests without getting a response. This means that basically the screenshot of Test 2 shows a failed attempt.

Hello Nick,

So Test 1 ans 2 result is just like what we've done now. We're using Palo Alto FW and also have Load Balancer (FortiADC) to do the 1-to-1 NAT.
Right now call between mobile phone app and laptop app (inside/outside Office) are normal, but we don't have a SIP trunk to VoIP service provider. We are planning to test the SIP trunk soon , but the FW checker result always bothers me. If There's something wrong with my configuration, would you give me the direction so that I can try to fix it? Thanks.

Peter

 

[NickD_3CX]

Hello Nick,

So Test 1 ans 2 result is just like what we've done now. We're using Palo Alto FW and also have Load Balancer (FortiADC) to do the 1-to-1 NAT.
Right now call between mobile phone app and laptop app (inside/outside Office) are normal, but we don't have a SIP trunk to VoIP service provider. We are planning to test the SIP trunk soon , but the FW checker result always bothers me. If There's something wrong with my configuration, would you give me the direction so that I can try to fix it? Thanks.

With Providers/SIP Trunks, this may indeed be a problem especially if they use different Media Servers, which is very common, because there will be cases where your PBX will receive UDP packets from "unknown" source IPs (what Test 2 tests).

Unfortunately there is not a lot more I can advise you, other that it's a good idea to first get this fixed before putting a SIP Trunk in.
Most firewalls have different ways o doing things and configuring, but if you are looking for examples of how to correctly configure other firewalls, in case it gives you some hint, there are a few guides you can see here:
https://www.3cx.com/docs/manual/firewall-router-configuration/#h.jtpzj3r4slqq

 

[PeterCheng]

Hello Nick,
Thanks for your feedback.
I believe that it's our PA FW issue, becasue I can see lots of packets were dropped by our FW (it should be the test packets coming from 3CX stun server). I did the wireshark and found 3cx pbx sent request to 54.39.182.217, but no response. and inside some other response changed-address attribute showed the ip is 51.79.116.90. I then checked our PA firewall for this ip and found lofs of packets coming from 51.69.116.90 have been dropped by firewall. And if I filter the FW traffic log when clicked 3cx firewall checker, I can see indeed the dropped packets from 51.79.116.90, it should be the reason why I cannot pass the 3cx firewall checker!

We will think about such behavior and how to avoid the check mechanism in the PA FW, thanks.

Peter

 

[NickD_3CX]

Hello Nick,
Thanks for your feedback.
I believe that it's our PA FW issue, becasue I can see lots of packets were dropped by our FW (it should be the test packets coming from 3CX stun server). I did the wireshark and found 3cx pbx sent request to 54.39.182.217, but no response. and inside some other response changed-address attribute showed the ip is 51.79.116.90. I then checked our PA firewall for this ip and found lofs of packets coming from 51.69.116.90 have been dropped by firewall. And if I filter the FW traffic log when clicked 3cx firewall checker, I can see indeed the dropped packets from 51.79.116.90, it should be the reason why I cannot pass the 3cx firewall checker!

We will think about such behavior and how to avoid the check mechanism in the PA FW, thanks.

Peter

That's it!
Exactly, if you find dropped packets from the IP that was referenced in the other STUN Requests, that is what is causing Test 2 to fail.

Once you fix that, from your description, it should make the Firewall Checker pass as well.

 

[PeterCheng]

Hello Nick,
After checking PA firewall rules and the document "https://www.3cx.com/docs/manual/firewall-router-configuration/", right now everything's fine. Firewall checker can pass successfully. Thanks for help.

Peter

 

[ChrisC_3CX]

@PeterCheng
Excellent! Glad to see you got this resolved!