Brian, It automatically kills TCP connections that last longer than 5 minutes? That's crazy! Why does it do that? To protect against SYN scans overloading the server or something similar? Harry On Tue, May 18, 2010 at 7:39 AM, Brian Wall <kc0iog at gmail.com> wrote: > 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 > > > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20100518/42833515/attachment-0001.htm