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

[abayoumi21]

This behavior is not uncommon and usually depends on how the firewall handles the traffic and how Nmap interprets the response.

Even if the traffic logs and packet captures show that the Palo Alto is dropping the traffic, Nmap may still report the port as open depending on the scan type and the response it receives. For example:

• If the firewall sends a TCP RST, Nmap may interpret the port as closed.

• If the firewall silently drops the packet, Nmap may classify it as filtered.

• If another device in the path (load balancer, upstream firewall, IDS/IPS, etc.) responds to the SYN request, Nmap may report the port as open, even though the Palo Alto is dropping the traffic.

Since the issue only appears in production and not in the lab, I would investigate environmental differences such as:

• Asymmetric routing (return traffic bypassing the firewall)

• Upstream devices responding on behalf of the server

• Different Nmap scan types (e.g., -sS vs -sT)

• NAT behavior or policy differences in production

• Whether the firewall is configured to send TCP resets instead of silently dropping traffic

As a validation step, you can also test using telnet or nc to confirm whether a full TCP handshake is actually completed. Additionally, capturing traffic on both ingress and egress interfaces of the firewall can confirm whether any SYN-ACK is being generated from another device.

[wally4]

Hello @abayoumi21 

Thank you for your reply. 

I kind of understand it more thanks to your explanation and i will recheck some of the stuff that you suggested.

Best Regards,
wally