Found it, online docs for SonicOS 3.x: http://help.mysonicwall.com/sw/eng/701/ui2/23000/Firewall/TCP_Settings.htm "Firewall --> TCP settings: Default TCP Connection Timeout – (Previously on the ‘Firewall > Advanced’ page). The default time assigned to Access Rules for TCP traffic. If a TCP session is active for a period in excess of this setting, the TCP connection will be cleared by the SonicWALL. The default value is 5 minutes, the minimum value is 1 minute, and the maximum value is 999 minutes. Note: Setting excessively long connection timeouts will slow the reclamation of stale resources, and in extreme cases could lead to exhaustion of the connection cache." Hope that's what you see on your SonicWall box, they're all a bit different so YMMV. 5 minutes is the default, and useless for SSH sessions. Heed the warning about freeing up stale connections, hence why I chose 120 minutes and had no noticeable side effects. You certainly can run the box out of CPU, as I have done in the past :-) Brian On Tue, May 18, 2010 at 7:29 AM, Brian Wall <kc0iog at gmail.com> wrote: > On Mon, May 17, 2010 at 3:18 PM, Jon Schewe <jpschewe at mtu.net> wrote: >> I'm trying to capture some large files from my house (on Comcast) to a >> server out of state (not on Comcast). I'm copying the files using ssh >> and a non-standard port.Things are fine for files of a couple megabytes, >> but files over say 10 megabytes stall out part way through. One night I >> got 50MB uploaded all night! So today I started up tcpdump on both ends >> and captured the traffic. I noticed an interesting thing in wireshark >> when the connection stalled out. I got a "TCP Previous segment lost" >> message on the server side and then started getting "TCP Dup ACK" on >> both ends. The server has a SonicWall firewall in front of it and is >> virtualized with vmware. My house is using dd-wrt on a Linksys router as >> my connection. Is this Comcast doing it's filtering for our protection >> or is this just something misbehaving on either firewall? > > Could very well be the Sonicwall. I had to administer one of these > trash heaps before, the default timeout for stateful connections is > set to something useless. > > I worked around it by creating an outbound rule for all TCP traffic > with a timeout of 120 minutes instead of the default (10?). There's > also a setting (sorry, don't remember where) that adjusts the global > TCP settings, and they're WRONG, horribly wrong by default. > > If I can find my Sonicwall documentation that I wrote, I'll post what > the exact TCP settings are and where to find them. Your SSH session > issue sounds identical to what I saw when I was trying to set up my > first Sonicwall 3060 Pro. > > Brian >