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