Sonic Wall NSA 4500 Firewall: SSO And Port 80 (HTTP) Only Drops Intermittently

Picture this if you will.  You have 100 or so computers/devices on the network, as well as wireless access.  All wired computers and hosted phones work great, with the exception of one wired computer.  It seems to have this one issue where when you do something on port 80 (HTTP), it works great for about 2 minutes, then it drops out for about 10 to 15 seconds.  Then it works great again for about 2 minutes.  Then drops out again.  Back and forth, it never stops.  And it IS only port 80 traffic.  Nothing else.  No, its not a DNS issue, since I can do a constant ping to www.google.com in cmd.  Guess what, the fire alarm monitoring system does the same thing as well, except they are sending a UDP packet, on port 80, out to a public IP address.  They get alarms every two minutes, then it clears up.  Then they get alarms, then it clears up.  Back and forth.  Oh yeah, the guest wireless has that same issue as well.  They have a Brocade environment sitting behind a SonicWall 4500 (in HA mode).  This is a very odd problem.
As it turns out, I found the problem to be in the firewall.  I reasoned that since I could get to the web GUI on the SonicWall while I could not get to www.google.com (when the problem happened).  I think thats logical.  So I called up SonicWall, who was NOT real willing to be helpful.  By taking a packet capture off the firewall, I proved to SonicWall tech support that their firewall was the problem.  You see, the same traffic which is allowed is also blocked.  You see it being blocked below, then allowed.  No difference in source, destination, port, etc.  All the same.  See below.

 Here is a text version of the packet capture, you compare the two:
===============
Dropped Header

Ethernet Header
 Ether Type: IP(0x800), Src=[00:24:38:c2:56:00], Dst=[02:17:c5:d8:36:44]
IP Packet Header
 IP Type: UDP(0x11), Src=[10.168.6.10], Dst=[12.29.157.29]
UDP Packet Header
 Src=[80], Dst=[80], Checksum=0xb7bb, Message Length=64 bytes
Application Header
 HTTP:
Value:[0]
DROPPED, Drop Code: 39, Module Id: 26, (Ref.Id: _4719_uyHtJcpfngKrRmv) 1:0)

===============
Allowed Header

Ethernet Header
 Ether Type: IP(0x800), Src=[00:24:38:c2:56:00], Dst=[02:17:c5:d8:36:44]
IP Packet Header
 IP Type: UDP(0x11), Src=[10.168.6.10], Dst=[12.29.157.29]
UDP Packet Header
 Src=[80], Dst=[80], Checksum=0xd698, Message Length=80 bytes
Application Header
 HTTP:
Value:[1]
Forwarded 5:2)

So I have SonicWall tech support telling me it is NOT their problem.  Its the network.  Ok, LOOK AT THIS CAPTURE!  Are you kidding me?  I was nice, but I had to argue with this guy that it was a firewall issue.  I have no ACLs on the core switch.  Nothing on the internal network would cause this.  But again, look at this capture.  I sent him the wireshark capture.  I sent him this screenshot, and he still says its wasnt his problem.
Well, when I finally convince him it IS his problem, he has to get a senior tech to look at it with him.  The senior tech ends up telling me is a SSO (single sign on) issue.  It turns out that since these particular computers and fire alarm monitoring system does not actually log into AD, for some reason the SonicWall behaves the way I described above. 
So here is what I did to fix the issue.  This was provided to me by the SonicWall tech support.  Man, I am not a SonicWall fan.