When I scan one host(A) on my local network with nmap from another computer(B) on the same subnet it shows all 1000 ports closed. When I scan the other computer(B) with nmap from computer(A) it shows 999 ports filtered and one closed port. Both of the computers are running the same operating system and are connected by Lan cables to a wireless router. Why would one show mostly filtered ports and the other mostly closed ports and which would be the worse case of the two?

I used the command "nmap 192.168.1.X" on both machines to scan the other machine. Why the differing behaviour?

  • 1
    Filtered means there was no response. Closed means the connection was refused. When posting here about tool responses, it helps to post the command you used.
    – schroeder
    Dec 19, 2016 at 8:08
  • We need to know exactly which kind of scanning are you doing because depending on it, a "no response" can mean different things. Dec 19, 2016 at 8:18
  • I used the plain Jane "nmap 192.168.1.x" for both machines no extra settings. Why should one computer behave differently than the other when they are on the same network.
    – Joe
    Dec 19, 2016 at 23:02

3 Answers 3


Why would one show mostly filtered ports and the other mostly closed ports and which would be the worse case of the two?

Assuming that you are describing a TCP (full or SYN) scan, then the difference has to do with the way the different hosts deal with unwanted packets. Closed vs. Filtered does not represent much difference in security terms; in both cases, traffic is not permitted. It's how it's not permitted that makes the difference.

A quick primer - to set up a TCP connection, the Client and Server exchange three packets, the so-called "TCP 3-way Handshake":

Client -> Server: SYN       ("Can you hear me?")
Server -> Client: SYN/ACK   ("Yes, I can hear you.  Can you hear me?")
Client -> Server: ACK       ("Yes!  Let's get talkin'!")

Nmap uses this exchange in two basic ways:

In an nmap SYN scan (-sS), nmap sends a SYN and waits for a SYN/ACK back. If it gets one, instead of sending ACK it sends a RST to reset the connection instead of sending an ACK to finish nailing it up. This has the advantage that the scan only touches the OS, not the application level; since the OS won't tell applications about a connection until it's up and running, the applications won't be logging the connections made by the scanner.

In an nmap TCP scan (-sT), nmap sends a SYN, waits for a SYN/ACK, and then sends an ACK to finish the connection. This is a "surer" scan in that it proves full connectivity is possible, but it is noisier in the logs.

The thing in common, here, is that nmap waits for the SYN/ACK to determine if the port is open. But there are three possible "responses", depending on how the target is configured:

Server -> Client: SYN/ACK   ("Port is open, application is listening")


Server -> Client: RST       ("Port is closed, server told the client so")


Server -> Client: (nothing) ("Port doesn't seem to respond, but not sure why")

Now, the latter two states represent different firewall configurations. A firewall that is configured to block traffic will respond with a RST, giving nmap a clear signal that the port is unavailable. On the other hand, a firewall that is configured to silently drop traffic will not respond at all. Nmap draws a negative inference here and assumes access to the port is being filtered by a firewall.

And that's why you see closed on one system and filtered on the other. In the first case, the host or firewall is returning RST in order to block unwanted packets, which gives nmap an unequivocal signal that the port is closed. In the other, the firewall is silently dropping packets rather than noisily rejecting them, and nmap can only infer that the ports are closed.

In Security terms, there's no real difference. In both cases your packets are not reaching the server. In some cases an attacker can make inferences about your security posture and concerns from the way and the places you apply blocking or filtering, but that's a subtle aspect of reconnaissance, and much less important than actually blocking traffic you don't want.

There is one important caution that you need to have when scanning. If a target is configured to block connections, and send you a RST for each attempt, then scanners may interpret non-response as an open port, rather than a filtered port. The scanner says "Hmm, 65534 ports responded with a RST, but 1 port did not. That port must be open!" But if there's any packet loss - which can happen when scanning over the Internet, or even scanning locally with an aggressive enough (fast packets) scan profile - then that missing RST might be a lost packet rather than any indication of what filtering is or is not in place. It's good practice to verify open ports manually after the scan, especially if you see open ports that don't make any sense (e.g., very high ports).

When I scan the other computer(B) with nmap from computer(A) it shows 999 ports filtered and one closed port.

Understanding how scans work - as above - may allow us to interpret their results more clearly. What I would infer from these results is that 999 ports are being silently dropped by the firewall, but that one port is being permitted through to the computer(B) by the firewall, and that that port is actually closed (not listening) on the host. So where the firewall is configured to silently drop, the actual host will respond with a RST like it's supposed to.


I'll have to guess because your post contains no specifics about the target, the scan mode used or the sophistication of the network, but this sounds like an active part of your network is interfering with the scan.

I have a cheap Sitecom router from a few years ago and it has a specific feature to block common actions like NMap scans and pings of death.

  • "[Two computers] connected by LAN cables to a wireless router" pretty much describes the "sophistication of the network".
    – techraf
    Dec 19, 2016 at 8:24
  • If the router is >5 years old, the chances are low it will contain IDS-like functions. Newer routers will sometimes have this on by default
    – J.A.K.
    Dec 19, 2016 at 8:47

I don't think the router would interfere with the scanning result - if it's a router which has some sort of intrusion detection and blocks the traffic, it should do so in both directions. My assumption is that the firewall configurations on the machines themselves are different.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .