From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 5 16:57:20 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E2216A4CE for ; Fri, 5 Dec 2003 16:57:20 -0800 (PST) Received: from tyberius.abccom.bc.ca (tyberius.abccom.bc.ca [204.239.167.97]) by mx1.FreeBSD.org (Postfix) with SMTP id AECF243F75 for ; Fri, 5 Dec 2003 16:57:18 -0800 (PST) (envelope-from jon@abccom.bc.ca) Received: (qmail 73951 invoked by uid 1000); 6 Dec 2003 00:57:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Dec 2003 00:57:35 -0000 Date: Fri, 5 Dec 2003 16:57:35 -0800 (PST) From: Jon Simola To: freebsd-ipfw@freebsd.org In-Reply-To: <6.0.0.22.2.20031205202453.02a0fd78@202.179.0.80> Message-ID: <20031205163656.H38868-100000@tyberius.abccom.bc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: bridged ipfw problem in FreeBSD 5.2beta X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2003 00:57:20 -0000 On Fri, 5 Dec 2003, Ganbold wrote: > Bridging work just fine, but after 4 hours it doesn't work. It happened > 3 times, all after 4 hours of operation. Machine itself was working > fine, only it seems it doesn't forward packets from internal interface > to external or internal interface didn't receive anything. This sounded awfully familiar to me, so I did a little looking. I had a similar problem that I never completely tracked down, but I believe it had something to do with a bunch of devices (DLink DSL modems) that came poorly configured. This was on a 4.4-STABLE era FreeBSD box. Perhaps 5.2Beta is a bit too bleeding edge for you, I'm still testing a 5.1-RELEASE box and my servers are still on the 4-STABLE track. Anyways, at one point, there was 40 of those modems all trying to arp for a single IP address and the bridging code was constantly spewing bridge collision errors. After a while, the firewall completely stopped passing traffic until rebooted. My solution was to block the traffic from the MAC address range of those DSL modems as the first ipfw rule. > Can somebody tell me where I did wrong in config files? Is it problem > with NIC or problem with bridge? Or is it problem related to arp? My compliments on the amount of detail you've provided. I don't see anything obvious, other that the slightly confusing aspect of explictly numbering ipfw rules for the first half of the script. > ${fwcmd} pipe 41 config bw 0kbit/s > ${fwcmd} pipe 42 config bw 0kbit/s > > ${fwcmd} add 60 pipe 41 all from 202.179.xxx.xxx/27 to any in via fxp1 > ${fwcmd} add 61 pipe 42 all from any to 202.179.xxx.xxx/27 in via fxp0 That gave me a good chuckle, I would guess that you've shut off a customer's access for some reason. Giving them 0 bandwidth is certainly a solution that had never crossed my mind. > options TCPDEBUG > options IPSTEALTH TCPDEBUG is undocumented, and IPSTEALTH may not be required. I don't use IPSTEALTH myself, never saw a real need. Might want to try without them, TCPDEBUG sounds scary. > net.link.ether.inet.max_age=1200 > > net.inet.ip.sourceroute=0 > net.inet.ip.accept_sourceroute=0 > net.inet.icmp.bmcastecho=0 > net.inet.icmp.maskrepl=0 > > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > > net.inet.ip.fw.dyn_ack_lifetime=3600 > net.inet.ip.fw.dyn_udp_lifetime=10 > net.inet.ip.fw.dyn_buckets=1024 These look fairly good to me, I haven't had to go so far as touching most of them on my current box (P4 2.4GHz, with 2 Intel Pro100 and a 3C905, peaking at 40Mbit) --- Jon Simola | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS