From owner-freebsd-questions Tue Apr 10 12:27:34 2001 Delivered-To: freebsd-questions@freebsd.org Received: from switch01.switch.no (c13048.catch.sdsl.no [217.8.130.48]) by hub.freebsd.org (Postfix) with ESMTP id CA86737B422 for ; Tue, 10 Apr 2001 12:27:29 -0700 (PDT) (envelope-from ros@switch.no) Received: by switch01.switch.no with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Apr 2001 21:20:05 +0200 Message-ID: From: Roger Svenning To: Trevin Chow Cc: questions@FreeBSD.ORG Subject: SV: Firewall rules causing SSH disconects? Date: Tue, 10 Apr 2001 21:19:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Make sure you don't have any IP address conflicts on the network, either involving your local machine or the server. This is just a long shot but it happened to me some weeks ago and it took me days to figure out as the disconnects sometimes occured just seconds after I connected and sometimes it took several hours. I've also had a problem with some dedicated firewalls that disconnects idle connections after a given amount of time. -Roger > -----Opprinnelig melding----- > Fra: David Kelly [mailto:dkelly@hiwaay.net] > Sendt: 10. april 2001 21:15 > Til: Trevin Chow > Kopi: questions@FreeBSD.ORG > Emne: Re: Firewall rules causing SSH disconects? > > > On Mon, Apr 09, 2001 at 09:43:01PM -0700, Trevin Chow wrote: > > Hi everyone, > > > > I'm just wondering what possible firewall rules (if any) could cause > > problems with random SSH disconnections. I'm trying to > troubleshoot my > > situation here, and I'm unsure if it has to do with failing > routers on the > > internet somewhere, or my own configuration. > > > > The situatino is basically that I'm able to connect via SSH > to my box > > remotely, but I'll get disconnected after a varying amount of time. > > > > Is it possible that a firewall rule is causing this? I > wouldn't think > > so..but I could be wrong. Anyone else have any ideas about > this? someone > > else mentioned to try turning "KeepAlive" to off to see > what happens, but > > that didn't solve anything. > > Ascend/Lucent Pipelines have a brain dead method of pruning their > connection state tables. The default is once every 24 hours > but once the > max (~500) its terribly hard to get out because its not smart > enough to > delete the oldest to make room for new. And it doesn't appear to be > smart enough to drop the state on close. We usually discovered this > limit in 12 to 18 hours of runtime so I set the purge at 2 > hours. Works > for most everyone but if I don't keep my ssh link fairly busy the > connection is dropped by the firewall. > > Then again this might have more to do with NAT in the Pipeline than > firewall altho the two are hard to tell apart. > > So this might be what is happening to you too if there is a Lucent > SecureConnect Firewall between endpoints. > > Playing with keep-state and check-state in ipfw I found the default > timer values to be way too fast. Only played with it for about an hour > but observed connection states were dropped when netstat said > the socket > was still open, and my applications were crying because they too were > upset about their connections failing. > > Maybe I wrote the ipfw rule(s) wrong. Used a simple "allow > all outgoing > tcp connection from this host to any and keep-state". Maybe it was > keeping state of "connection in progress" when I intended only the act > of connecting was allowed to establish a pass rule between two hosts. > > -- > David Kelly N4HHE, dkelly@hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message