port issue / nmapping

[wally4]

Hi everyone,

I’m facing a strange issue and would appreciate your input.

We created a security policy to block certain ports. When we check the traffic logs and packet captures, they clearly show that the traffic is being dropped. However, when we run an Nmap scan, it still reports the ports as open, even though they should be closed.

I also checked for any active sessions related to those ports, but there are none.

We repeated the same test in two different lab environments, and everything worked as expected — Nmap showed the ports as closed. However, when we tested again in the production environment, the issue came back.

Is this normal behavior? The logs and packet captures confirm the traffic is being dropped, but Nmap still shows the ports as open in production.

Has anyone experienced something similar or have any idea what might be causing this?

Thanks in advance!

Version 11.1.6-h10

[wally4]

Extra info:
I checked for asymmetric routing or if the traffic is working from a different gateway/route, but everything appears that it is correctly configured  

[TomYoung]

Hi @wally4 ,

Do you have any applications listed in the security policy block rule?

Thanks,

Tom

[wally4]

Hello @TomYoung 

Thank you for your response.

I attempted to block the application associated with the port in question; however, the port continues to appear as open during our nmap scans.

For example, in the test environment, port 5060 shows as closed. In the production environment, however, it appears as open. Since SIP operates on port 5060, I created a rule to block the SIP application, but the port is still reachable.

When we perform the scan directly from server to server, the port correctly shows as closed. However, when the scan includes the firewall in the path, nmap reports the port as open.

I will be uploading a PDF that explains the test environment results. The document shows the expected behavior that we would like to replicate in the production environment. The rules and configurations appear to be the same in both environments, yet the results are different.

Best Regards,

[TomYoung]

Hi @wally4 ,

That behavior is indeed strange.  There is an additional piece of information that you should know.  If you include an application in a block rule, the NGFW will still allow a few packets in order to correctly identify the application.  The best practice in this case is to block port 5060, and leave the application field blank.  Then the NGFW will drop all packets on port 5060.  I have seen this behavior on multiple vendor NGFWs, and it is expected.

Thanks,

Tom

[wally4]

Hello @TomYoung 

Thank you for your answer.

I will try that and check if it was the main reason.

Best Regards,

wally

[wally4]

Hello @TomYoung 

Hope you are doing well.

I blocked port 5060 and left the application field blank as you suggested, but we are still seeing the same issue.

Is there a way we can test whether this might be a false positive? It appears that traffic is being dropped when it attempts to pass through the port, but the scan is still reporting it as open.

Thanks & Regards,
wally

[TomYoung]

Hi @wally4 ,

Could you 1st confirm that you see the traffic hitting your block rule in the traffic logs?

Thanks,

Tom

[wally4]

Hello @TomYoung 

Yes, the block rule is dropping the traffic to that port. That's why I find this case abnormal.

Best Regards,
wally

[TomYoung]

Hi @wally4 ,

That is abnormal.  I have configured block rules the same on my NGFWs and tested them with a port scanner as you did.  My NGFW drops the traffic.  Something is off.

Thanks,

Tom