1) How many systems are exhibiting this behavior? What OS version and service pack are they running? Are they current with updates? Same notes regarding Internet Explorer: what version, and are they patched up current?
2) On a "problem" PC, try temporarily using a different browser - Firefox or Chrome, or upgrading to a newer IE, and see if the problem presents. If not, you may have a corrupt IE installation, undetected malware, problem IE version, etc. If the problem is only present in IE, then consider removing and reinstalling IE, moving to another browser, updating to a newer IE, patching IE, etc.
3) Temporarily connect one of the "problem" PC's directly to the outside network, bypassing the firewall. Does the problem occur?
4) Windows clients close inactive TCP sessions by default in 240 seconds (4 minutes). You can reduce this timeout to cause hanging sessions to drop faster, but that's really just a band-aid until you figure out the underlying issue. Don't reduce too much or you'll get dropped sessions on slow links:
http://msdn.microsoft.com/en-us/library/aa560610%28BTS.10%29.aspxI
f you want to monitor traffic on the outside of your firewall, you will need a sniffer with a compatible interface. Is there an ethernet lan segment between the firewall and the isp router? If so, and there there isn't already one, install an ethernet hub (simplest thing to do) or a switch capable of port mirroring on that segment and attach your sniffer to the hub/switch.
If the interface is not ethernet (serial, frame, t1/e1/frac), ISDN, DOCSIS, etc.), then you'll need a sniffer with a compatible interface.
I'm not that familiar with SonicWall, but Cisco devices support packet capture and logging of dropped packets, so it is often possible to use built-ind debugging and logging capabilities without needing to resort to an outside capture device.
Experiment to determine what operations are causing the hanging sessions. Once you can reproduce it, capture as short a conversation as possible between the PC and the remote host (Google host), once from inside the firewall, and once from outside. Even better, if you can, capture both simultaneously on two sniffers. (Remember that on the inside interface it will be between a private address and a public address, but on the outside interface, it will be NATted to a public address, so you will probably just have to filter on the Google host address. Try to do this at a time when you can minimize or eliminate other traffic to this address.
Compare packet-by packet, and see if there is a final inbound ACK (shows on the outside capture, but missing on the inside capture) that is getting filtered or dropped by the firewall. If not, then you probably have an issue on the individual PC(s).
LAST_ACK means that the client application (IE, in this case) has issued a close(), and sent a FIN, and is is waiting for one last ACK from the server application.
http://tangentsoft.net/wskfaq/articles/debugging-tcp.html
- Gary Patterson
