You are not alone, I have also seen this. I do not think that this is common to set devices to reset ICMP. My guess is that it was set for troubleshooting and then not taken off. I have seen what you are describing and the way I dealt with it was to take ICMP out of the template. Most likely the devices that you are going after will respond to one of the well known ports in the template and you can continue on with doing other work along side squashing vulns on your network. This is the very reason why these setting are exposed to us so we can change them to fit our environment. Every environment is a little different. Rapid7 has an option that is passed to the nmap they distribute as part of nexpose/insighvm to ignore the TCP resets as mentioned by @landon_dalke. However ICMP resets, are not accounted for and an ICMP reset will trigger an asset to be identified as alive. It is like you knocked on a door and then you hear someone shout “nobody is home, go away now!”. Then you get out your notepad and note, they said nobody is home, so wait a minute they are home…you almost got me. 16k times per scan.
If you only had a few networks like this, you could just modify a template for that section of the network. Dealing with 16k, you need to isolate that either from the template or have the network firewall rules adjusted.
Thoughts to deal with this and 16k assets:
1> Remove ICMP from your template. (Most likely the bulk of your assets are responding on something more than ICMP anyway.)
2> Ask the network team to allow ICMP from your scanner. If you explain to them that this will help you manage your license and if they could allow ICMP, then you can get a better asset list.
3> Ask the network team to remove the deny. (Maybe it was set for testing and not disabled after.)
4> Stop doing a discovery and pipe in the assets to your sites using automation.
5> Ask R7, in the nicest way possible, to add an ignore ICMP rest option.