🚀 go-pugleaf

Similar issue here. The adobe update client connects through a chain of proxies (ISA performing caching, then a McAfee device performs virus checking).
Similar issue here. The adobe update client connects through a chain of proxies, first a Microsft ISA server, then a McAfee device performs virus checking on downloaded content.

Viewed from the workstation, the client establishes a TCP connection to ISA, then sends its GET request for the update file URL. Most recently,
ardownload.adobe.com/pub/adobe/reader/win/8.x/8.1.3/enu/AdbeRdr813_en_US.msi

An ACK is sent from ISA to the client. After 15 seconds, no data is received at the client, and the client sends a RST to the proxy. This is followed one second later by a new TCP connection establishment, a GET request, 15 seconds, and a RST. The pattern repeats indefinitely.

Somewhere in our proxy chain the RST packet is not being transmitted. I suspect the McAfee device, which continues to download every requested file. Over a couple hours, a single adobe update client can request hundreds update files. With update files often in excess of 30 MB, this traffic, on top of our normal 50-70% utilization, saturates the 20MB internet pipe we have available for our 2300 users.

The McAfee device has a data trickling feature (which I've seen in other similar web anti-virus proxies). This feature is disabled here. Data trickling allows small amounts of data to be periodically sent to waiting clients as a sort of "keep-alive". Once the whole file is downloaded and virus scanned, the remainder is transferred to the client. We're experimenting with data trickling, configured to send data to the client every ten seconds in order to prevent the 15 second timeout and retry pattern we've been seeing.

Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA