topic Re: port issue / nmapping in Next-Generation Firewall Discussions

port issue / nmapping

wally4 — Wed, 11 Feb 2026 12:50:48 GMT

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

Re: port issue / nmapping

wally4 — Wed, 11 Feb 2026 12:52:36 GMT

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

Re: port issue / nmapping

TomYoung — Wed, 11 Feb 2026 17:24:39 GMT

Hi @wally4 ,

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

Thanks,

Tom

Re: port issue / nmapping

wally4 — Thu, 12 Feb 2026 08:08:33 GMT

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,

Re: port issue / nmapping

TomYoung — Thu, 12 Feb 2026 13:02:41 GMT

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

Re: port issue / nmapping

wally4 — Thu, 12 Feb 2026 13:09:25 GMT

Hello @TomYoung

Thank you for your answer.

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

Best Regards,

wally

Re: port issue / nmapping

wally4 — Mon, 16 Feb 2026 08:01:47 GMT

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

Re: port issue / nmapping

TomYoung — Mon, 16 Feb 2026 13:30:31 GMT

Hi @wally4 ,

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

Thanks,

Tom

Re: port issue / nmapping

wally4 — Mon, 16 Feb 2026 13:33:28 GMT

Hello @TomYoung

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

Best Regards,
wally

Re: port issue / nmapping

TomYoung — Mon, 16 Feb 2026 13:36:42 GMT

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

Re: port issue / nmapping

abayoumi21 — Tue, 03 Mar 2026 10:48:30 GMT

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.

Re: port issue / nmapping

wally4 — Sun, 08 Mar 2026 09:28:36 GMT

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