Nmap and Retransmissions
When scanning a network or device where a firewall, packet filter, or some other type of filtering is in place, much of the Nmap scan consists of retransmissions and delays between retransmissions. The delays associated with these retransmissions are significant, and you may find that controlling retransmissions can result in a marked improvement for total scan time.
How Nmap Retransmissions Occur
Nmap’s primary focus is to provide the most accurate port scanning results possible. During a normal scan, Nmap is constantly adjusting packet timings, retransmission amounts, and scanning delays.
Unfiltered Ports
On a network where the port is unfiltered, the first two packets of the TCP three-way handshake proceed normally, without any type of delay:
Filtered Ports
If the port is filtered, the first SYN packet to the remote device will be met with silence. This doesn’t sit well with Nmap, because Nmap isn’t sure where the communication process broke down. Did the end station not receive the transmission? Was the response from the target lost on the way back? Or was there something in the middle that prevented the conversation from ever starting?
Because of these open questions, Nmap doesn’t give up after the first missing response. Nmap waits an appropriate amount of time and then repeats the request again. Depending on a number of different timing factors, Nmap may retransmit the request multiple times before finally giving up and marking the port as “filtered.”
In network terms, this retransmission process takes a huge amount of time. If the Nmap scan consists of multiple filtered ports, this retransmission process makes a noticeable difference in the speed of the overall scan.