End Point Analysis Scans Hanging

This issue wasn’t being seen from all remote workstations as it turned out to be dependant upon the type of Internet connection users were connecting from. For Example: A connection from a DSL line using PPPoE (PPP over Ethernet) consistently failed, whilst other connections, such as PPPoA (PPP over ATM) worked flawlessly. Further testing proved that this was due to an MTU issue. A further understanding of the situation located a common firewall configuration error that was preventing the Path MTU Discovery (PMTU-D) process from sending ICMP type 3 (Destination Unreachable) code 4 (Fragmentation Needed and Don’t Fragment was Set) messages to the Server. Therefore, after the initial connection, and once the server was sending enough data to fill a 1500-byte packet, it was simply not being received by the client. The ISP at the client end was dropping the packet and sending back an ICMP destination unreachable message telling the server what the largest packet size is that it can use. If it does not get the ICMP destination unreachable message, the server will never receive an acknowledgement from the client, and will therefore resend the 1500-byte packet over and over again until the client sends a connection reset. However, during this period of time the EPA scan process may seem to be hung and after some time will eventually fail.

Note that this issue can also be seen by providers that use private WANs that use network tunnels connected via VPN technologies. Some of these tunnels can have reduced MTUs.

The ICMP Destination Unreachable message contains a code which describes the reason that the destination is unreachable. It should be noted that ICMP is an integral part of the Internet and should not be filtered without due consideration for the effects it may cause.

This situation is commonly referred to as a Path MTU Discovery black hole.

Related posts:

1. The Myth Surrounding Various End-Point Analysis Scans

Tagged as: cag, EPA