Using nmap to do a protocol discovery (nmap myhost -sO) identifies the following on my target. Note reason switch is also used.

1        open  icmp    echo-reply ttl 255
6        open  tcp     proto-response ttl 255

If I then add the -f to fragment the packets to evade ids / firewall (nmap myhost -sO -f)

the scan no longer reports TCP as a protocol and only reports ICMP

1        open  icmp    echo-reply ttl 255

Why does fragmenting the packets stop detection of TCP, is the firewall actively dropping these or does it not understand them?


I tried manually setting mtu in increments of 8 until I discovered TCP again and this occurs at mtu 24 . So nmap myhost -sO -mtu 24

and it's back to

1        open  icmp
6        open  tcp
  • can you sniff on the target side to see if they are being dropped? We can't tell you what the firewall or the host is doing without more data
    – schroeder
    Commented Mar 8, 2017 at 15:08
  • No, i'm not able to do that. I was hoping to get an idea of what this type of response might indicate as this doesn't appear to be a regular case. I have added further info to the original post
    – iainpb
    Commented Mar 8, 2017 at 15:21

1 Answer 1


Most likely you have a firewall somewhere that is dropping packets for which it cannot make a determination of policy. A MTU of 24 is enough for the full IP header plus the source and destination ports of the TCP header. The next lowest valid MTU is 16, which is not enough to include the destination IP address. The firewall probably does not reassemble packets, so without enough to make a determination it drops the inbound packet. For ICMP, on the other hand, all that is needed may be the protocol number.

You must log in to answer this question.

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