0

I have two almost identical embedded hosts that I am scanning with NMAP on the specific UDP port 47808.

On host 192.168.2.12 NMAP returns after a while with: 192.168.2.12. nmap

while on 192.168.2.24 NMAP immediately returns with: 192.168.2.24 nmap

In both cases the host replies with an ICMP Type 3 Code 3 message, but for 192.168.2.12 NMAP keeps scanning, while for 192.168.2.24 it returns immediately after first ICMP answer.

This is the first ICMP answer from 192.168.2.12: 192.168.2.12 icmp

while this is the first ICMP from 192.168.2.24: 192.168.2.24 icmp

Both are Type 3 Code 3 messages but for 192.168.2.24 there is a different payload.

Why does NMAP stop immediately for 192.168.2.24 even if the ICMP type and code are identical to 192.168.2.12 ?

Here is the 192.168.2.12 NMAP packet trace: 192.168.2.12 trace

and here it is for 192.168.2.24: 192.168.2.24 trace

Even if both ICMP packets are Type 3 Code 3, NMAP identifies 192.168.2.12 answer as Destination Unreachable while 192.168.2.24 as Port Unreachable.

Why this different classification for two packets with the same Type and Code?

1
  • nmap isn't inherently a security tool. And you are asking a ICMP protocol and traffic question. Commented Nov 13, 2024 at 10:57

1 Answer 1

2

In order to understand which destination IP and port is unreachable the clients needs to parse the payload inside the received ICMP unreachable message, which contains parts of the original transmitted packet. From this the original IP header can be extracted and from this the original destination IP and port.

For 192.168.2.12 this included payload seems to be broken, as can also be seen in the screenshot ("Internet protocol, bogus version (3)") - which is clearly not the expected original IPv4 packet. That's why the ICMP unreachable cannot be associated with any transmitted data and will simply be ignored.

For 192.168.2.24 instead the included payload contains a proper IP header so that the original target can be extracted. This then can be sucessfully associated with transmitted data, so that nmap knows that the target is unreachable.

Why 192.168.2.12 sends back bogus data is not clear. Might be intentional (but why?), might be a bug.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.