Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
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.
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 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.
