Nmap places ports in open|filtered state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

I read this on nMap port scanning basics.

  • Open ports for which protocol? TCP and UDP have ports, which, although they use the same numbers, are completely different. IP doesn't have ports.
    – Ron Maupin
    Oct 8, 2017 at 4:23
  • open|filtered is the six port states recognized by Nmap, It says that in this scan Nmap cannot determined if port is open or filtered because some open ports give no response, thats why I wanted to know in which case this happens, cuz as far as I know open ports accepts TCP/UDP connections Oct 8, 2017 at 4:28
  • No, a TCP port is not the same as a UDP port, For example, TCP port 9876 is different than UDP port 9876, and both can be used at the same time. TCP and UDP do things very differently. TCP creates connections, and it will respond to a handshake request, but UDP does not.
    – Ron Maupin
    Oct 8, 2017 at 4:32

2 Answers 2


It sounds from your comment that you do not understand what a port is. A port is an address for some layer-4 protocols. TCP and UDP use ports, but other layer-4 protocols use something different, or nothing at all. Trying to use a UDP address (port) with TCP, or vice versa, will not work. That would be like trying to use an IPX or IPv6 address with IPv4. Just because TCP and UDP use the same numbers for their addressing doesn't mean that the ports are the same thing.

When a port is Open, that means that an application has requested the use of the protocol, either specifically requesting a port number of the protocol, or simply accepting a random port number that the protocol decides for the application.

TCP uses handshaking to facilitate its reliability. When a TCP port is open, another host trying to connect will begin the handshake. If the port is closed, or the handshake is incorrect, then TCP responds with a RST.

UDP, being unreliable, doesn't have a handshake, and it doesn't respond, although the application using the UDP port may respond.

  • you mentioned that a port is an address for some layer-4 protocols. can you give an example, and thank you for ur answer Oct 8, 2017 at 7:33
  • 2
    TCP and UDP are layer-4 protocols that use addresses (ports).
    – Ron Maupin
    Oct 8, 2017 at 15:36

You should read the descriptions of the individual types of scan https://nmap.org/book/man-port-scanning-techniques.html

UDP is a connectionless protocol. The network stack responds with an error if the port it closed, but if the port is open it just quietly delivers the packet up the stack to the server application. If the server application gets a legitimate request it will likely send a response, but if the packet does not look like a legitimate request it will often just silently drop it.

The problem is that nmap does not know what protocol the server is trying to serve (though sometimes it can make an educated guess based on the target port number). So when it gets no response it doesn't know if that was because the packet was dropped by a firewall or because the server process didn't respond to the particular probe packet

Similarly for the IP protocol scan (note: this scan uses the "port" number options to select the protocol numbers). Nmap can report "protocol unreachable" errors but it can't tell the difference between the packet being dropped by the firewall and the protocol implementation on the target simply choosing to ignore a malformed packet.

For the TCP FIN/null/xmas scans, these are packets sent with an unexpected (not used in normal TCP communication) combination of flags and if sent to an open port the TCP spec says these should simply be discarded. OTOH if the port is closed then the packets meet an earlier rule which triggers a "rst" response. Again the scanner can't tell the difference between a packet received by the target that caused no action to be taken and a packet that was dropped by a firewall.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.