Packet Filter Logging Question

I found this thread and think my question is in the same vain....

For reasons I don't understand, I very recently started seeing most of my dropped source host packets now coming from a series of IP that are resolved to *.deploy.akamitechnologies.com. I am seeing this on several Astaro setups that I maintain.

I believe this dropped traffic is try to reach client web browser sessions but for reasons I don't understand these packets are getting dropped. This seems to be causing very slow web browser behavior that was not previously observed.....

I think this behavior started on upgrade to 8.2 version. I also think that the Intrusion Protection is involved. Though almost all of the clients using two of the ASGs as their WAN Gateway are Macintoshs but the IP alerts are reporting Dropping traffic for various Windows related intrusion attempts.
Examples of IP Alerts being seen now: 
EXPLOIT Internet Explorer DOM mergeAttributes memory corruption attempt
DOS Squid Proxy invalid HTTP response code denial of service attempt
WEB-CLIENT Windows Vista feed headlines cross-site scripting attack attempt

My overall question is are others see this NEW pattern?
Secondly, is any of this traffic being blocked in error?
Third, is something about Akami Technology caching servers or whatever they are doing, causing these false alarms or are they really bad packets or ..... in fact ..... is it possible the the Akamai servers are actually allow the creation of bad traffic either rougue traffic or just badly delayed traffic so that the client browser session or ASG itself is no longer accepting traffic on these High Ports 50,000s by the time it is being sent back?

Thoughts on how to narrow down my ponderings and save me to paying attention to false alarms....

Thank in advance to any comments.

Hi, TJ, and welcome to the User BB!

Please show a few lines from the full Packet Filter (not the "Live") log so that we can see the details.  Same for the Intrusion Prevention items you suspect.

Cheers - Bob
PS In general, it's easier to get help here when you post actual messages and pictures than your description of what you see.  I know that I'm a visual-tactile learner and that I have to "translate" descriptions before I can see what's happening.

I'm not sure if it's the same thing as TJSoftWorks is experiencing but I've been trying to understand why some internal systems aren't able to view some content coming from Akamai sources.

For instance, trying to view the Steve Jobs tribute on Apple's campus (Apple - Apple Events - Celebrating Steve), the content looks like it's being streamed from Akamai but blocked by the firewall. Here's just one of  the lines from the firewall logs:

2011:10:28-16:07:48 mcrouter ulogd[5835]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth4" srcmac="0:22:2d:9d:51:eb" dstmac="0:1b:21:c8:8d:9f" srcip="204.201.160.83" dstip="[mywanip]" proto="17" length="1432" tos="0x00" prec="0x00" ttl="52" srcport="6972" dstport="6970" 

I tried setting up a rule to allow this traffic but I must be doing something wrong as traffic is still blocked.

Trying to hit this tribute site is the first time I've seen Akamai sources rejected although I have seen akamai mentioned in many executive reports with dropped packets. I just never tried to identify them.

I had the same experience, so I dug a bit...

That's an uninvited packet, and there's no reason to let it in - Astaro's telling you in doesn't know what to do with it, so if you allow it in, the bits will just immediately go to bit heaven.  It turns out that that's the Apple Quicktime server trying to re-establish what it thinks is a failed connection.

I turned the proxy off, and had no problem loading the site.  The question was whether turning off AV for the site would solve the problem or if the proxy had to be avoided altogether.

For some strange reason, the Firewall Live Log did not show the drops like the one from reelmccoy.  Each time the firewall log filled up with those, I found an attempt in the Web Filter log to load the movie from http://209.234.250.*.  I tried an AV Exception for ^https?://209\.234\.250\., but that didn't work, so the only possible solution is to avoid the proxy.

For the transparent proxy, that means adding a network definition for 209.234.250.0/24 to the 'Skip transparent mode destination' list.  In a Standard mode, http://209.234.250.* should be added to the Proxy Settings Exceptions in the PC.

Cheers - Bob