From owner-freebsd-questions@FreeBSD.ORG Mon Jun 6 19:16:34 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4A1516A41C for ; Mon, 6 Jun 2005 19:16:34 +0000 (GMT) (envelope-from nkinkade@fastmail.fm) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39EBE43D1F for ; Mon, 6 Jun 2005 19:16:33 +0000 (GMT) (envelope-from nkinkade@fastmail.fm) Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 58D01C9CBD1; Mon, 6 Jun 2005 15:16:31 -0400 (EDT) X-Sasl-enc: GHBwBccRUmYXD5m6aSNhddSxwpXTDYkbso2LIFdV+7wi 1118085389 Received: from gentoo-npk.bmp.ub (unknown [206.27.244.136]) by www.fastmail.fm (Postfix) with ESMTP id 14B0788; Mon, 6 Jun 2005 15:16:28 -0400 (EDT) Received: from nkinkade by gentoo-npk.bmp.ub with local (Exim 4.21) id 1DfN5I-0005ge-SK; Mon, 06 Jun 2005 13:16:28 -0600 Date: Mon, 6 Jun 2005 13:16:28 -0600 From: Nathan Kinkade To: ben@stonehenge-net.com Message-ID: <20050606191628.GA21690@gentoo-npk.bmp.ub> Mail-Followup-To: ben@stonehenge-net.com, freebsd-questions@freebsd.org References: <21064.66.201.44.146.1118079993.squirrel@mailhenge.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline In-Reply-To: <21064.66.201.44.146.1118079993.squirrel@mailhenge.com> X-PGP-Fingerprint: 3FDF A406 B149 3959 A8CB C5A9 3B46 4812 D852 7E49 User-Agent: Mutt/1.5.6i Sender: Cc: freebsd-questions@freebsd.org Subject: Re: strange network behaviour X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nathan Kinkade List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 19:16:34 -0000 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 06, 2005 at 10:46:33AM -0700, ben@stonehenge-net.com wrote: > on Friday i set up 4 old celeron boxes as DNS servers for a client. after > about 5 minutes, their ability to reach the network vanishes... they can't > ping their router, and inbound network traffic vanishes. rebooting fixes > the problem... for another ~ 5 min. >=20 > the only things running are chrooted bind, postfix, and webmin. ipfw is > on, with firewall_type=3D"open". i've also tried it with ipfw disabled. >=20 > The same thing happens with my laptop, which is also running 5-STABLE as > of about noon on friday. >=20 > I know this sounds like a network issue, but is there anything in the > system that might cause thist type of behavior? it doesn't seem to be the > hardware - my laptop is a pentium M centrino system with a bg nic, and > they're old Celeron 500 machines with fxp nics. >=20 > the kernel config is attached, in case i've done something really stupid > in there >=20 > thanks, >=20 > ben What is your default rule for IPFW? I once had a similar problem in a setup that included an IPFW machine in bridge mode. I would turn on the firewall and everything worked fine for about 5 or 10 minutes, after which everything broke down. The setup looked like this: [gateway (cisco)] <--> [ipfw (bridge mode)] <--> [internal net] It turns out what was happening was that the ipfw machine running in bridge mode with a default rule of deny was not allowing ARP requests to pass between the gateway and the internal net. As soon as the ARP entries expired on the internal net, access to the external network broke down because ARP lookups for the gateways IP address were failing because of the IPFW machine. In the end we had to set the default IPFW rule to accept and add two rules before that denying any TCP or UDP packets. I'm not sure if this has anything to do with your situation, but I though I'd throw it out there as one possiblity that involves IPFW. Nathan --C7zPtVaVf+AK4Oqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCpKEMO0ZIEthSfkkRAlGvAJ4uhj7pAsRFkJOZwTKVle7pEJofQgCdFSHu lQouxGS0TewvcjKC8JFHiRI= =Hxh8 -----END PGP SIGNATURE----- --C7zPtVaVf+AK4Oqc--