I've got a ton more information on this issue...........
It would "appear" that SEP blocks not on IP, but on MAC address.
All of our computers run through a common switch. SEP shows the switch's MAC as the mac of all computers, even those it believes are attacking.
SEP is set to not block, that option is unchecked. IT does block, however, but it blocks only for rougly 15 to 20 seconds - here is an ongoing ping snippet when SEP triggered and started blocking - that's the length of time, and it blocks ALL ICMP pings, probably because it's blocking the core switch MAC and not an IP address. This is my workstation pinging the DC when the so-called attack occurred:
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=19ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=2ms TTL=127
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Reply from XXX.XXX.XXX.XX: bytes=32 time=1ms TTL=127
Further, I setup SEP firewall to log all ICMP packets and enabled DOS detection. I did not have to wait long - in 15 minutes, a DC stopped pinging and SEP logged an attack. However, an export of the firewall log to CAP format, then viewed in wireshark showed no pattern of attack, no long list of fragmented packets. It did show a lot of fragments, but from 2 or 3 sources. This makes me think that SEP is seeing the fragmented packets from 2 or 3 cxomputers, and sees the SWITCH MAC, and assume THAT MAC is attacking it, but gives it a single IP address of the first machine with fragmented packets.
So we have two issues with SEP.
SEP is falsly triggering.
SEP is blocking based on the MAC address of the core switch and not hte machine.
SEP is blocking when blocking is turned off or not enabled.
Now another issue- It seems we have some MTU issues here, and it's impacting VPN clients the worst, then clients coming down the ASA established tunnels. We seem to have a place where instead of reporting destination unreachable, please fragment packet, it's not responding and pings of a certain size are simply being dropped.
Note below - I should never get a timeout but should always get a packet needs fragmenting reply.......
J:\>ping -f -l XXXX XXX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1200 bytes of data:
Reply from XX.XXX.XXX.XX: bytes=1200 time=111ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1200 time=41ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1200 time=39ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1200 time=38ms TTL=127
Ping statistics for XX.XXX.XXX.XX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 38ms, Maximum = 111ms, Average = 57ms
NOTE THE TIMEOUT........... ......note
J:\>ping -f -l XXXX XX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1300 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for XX.XXX.XXX.XX:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Yet it goes here.......... so the fragmentation needed bit is not being sent, packets are being lost and dropped.
J:\>ping -f -l XXXX XX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1260 bytes of data:
Reply from XX.XXX.XXX.XX: bytes=1260 time=103ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1260 time=40ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1260 time=51ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1260 time=40ms TTL=127
Ping statistics for XX.XXX.XXX.XX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 40ms, Maximum = 103ms, Average = 58ms
J:\>ping -f -l 1406 XX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1406 bytes of data:
Reply from XX.XXX.XXX.XX: bytes=1406 time=90ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1406 time=32ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1406 time=30ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1406 time=29ms TTL=127
Ping statistics for XX.XXX.XXX.XX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 90ms, Average = 45ms
J:\>ping -f -l 1407 XX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1407 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for XX.XXX.XXX.XX:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
J:\>ping -f -l 1407 XX.XXX.XXX.XX
Pinging XX.XXX.XXX.XX with 1407 bytes of data:
Reply from XX.XXX.XXX.XX: bytes=1407 time=129ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1407 time=66ms TTL=127
Reply from XX.XXX.XXX.XX: bytes=1407 time=65ms TTL=127
Reply from XX.XXX.X.XX bytes=1407 time=64ms TTL=127
Ping statistics for XX.XXX.X.XX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 64ms, Maximum = 129ms, Average = 81ms