From owner-freebsd-net@FreeBSD.ORG Thu Jun 17 18:59:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D15816A4CE for ; Thu, 17 Jun 2004 18:59:41 +0000 (GMT) Received: from mx01.bos.ma.towardex.com (mx01.bos.ma.towardex.com [65.124.16.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35CE243D5F for ; Thu, 17 Jun 2004 18:59:41 +0000 (GMT) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 451B52F900; Thu, 17 Jun 2004 14:59:02 -0400 (EDT) Date: Thu, 17 Jun 2004 14:59:02 -0400 From: James To: Staffan Ulfberg Message-ID: <20040617185902.GA24198@scylla.towardex.com> References: <200406161646.49893.rneese@adelphia.net> <87zn73kmv9.fsf@multivac.fatburen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zn73kmv9.fsf@multivac.fatburen.org> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: IPFW questions X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2004 18:59:41 -0000 natd is a daemon userland process which performs way poorly than a kernel process. its fine for small office/home use, but definately not at the traffic level you are pushing. you can consider using ipnat (kldload ipl.ko; man -a ipnat) for NAT rules, and use ipfw for rest of packet filtering. hope it helps.. -J On Thu, Jun 17, 2004 at 03:13:30AM +0200, Staffan Ulfberg wrote: > I sent an article similar to this a few days ago to c.u.b.freebsd.misc > but didn't get any responses, so I'll try here instead. Please bear > with the long mail... And thanks in advance for any new insights! > > I have an IPFW2 firewall and would like to get a few random things > clarified/solved: > > > FIRST QUESTION: I'm currently filtering ip_input, ip_output, and > bdg_forward packets. What would the differnce be if I filtered > ether_demux and ether_output_frame packets instead of > ip_input/ip_output? The ipfw man page says this: > > Note that as packets flow through the stack, headers can be > stripped or added to it, and so they may or may not be available > for inspection. E.g., incoming packets will include the MAC header > when ipfw is invoked from ether_demux(), but the same packets will > have the MAC header stripped off when ipfw is invoked from > ip_input(). > > What headers are added in ip_input/ip_output, compared to the ethernet > layer equivalents? What kind of filtering could be problematic if > trying to do all filtering on layer2 packets? I've noticed the ip > address, at least, is available, since filtering my bridged traffic > works as expected. > > How about natd? Does natd assume that traffic is sent to the divert > socket from ip_input/ip_output? > > > SECOND QUESTION: When using IPSEC (tunnel mode), what is the flow of > packets through the firewall? My guess (that i'd like to verify) is > that when a machine on my internal network transmits a packet that is > destined to go through the ipsec tunnel, the packet gets in as usual > from fxp3, going through ether_demux and ip_input. Then, the kernel > wraps the packet inside an ESP packet, and that packets goes through > ip_output and ether_output_frame on fxp0. When receiving an ESP > packet, exactly the reverse happens: in through fxp0 ether_demux and > ip_input, unwrapped, and then out through ip_output and > ehter_output_frame on fxp3. Correct? > > > THIRD QUESTION: I currently use a 1100 MHz Celeron machine with a quad > dc card as a firewall. I tried switching that for a 300 MHz Geode GX1 > machine with quad fxp interfaces (actually, this machine: > http://www.evalue-tech.com/evalueweb/products/specifications/ENA-540.cfm). > This doesn't work very well, however, due to bad performance. > > Would your guess be that tuning the system could make it work well, or > is it obvious that the machine is too slow for the task? (I tried > ifconfig -link0 and DEVICE_POLLNING, so far without any luck...) > > I'm using FreeBSD 4.10 and IPFW2 with BRIDGE and IPDIVERT (for > natd) support. It's connected like this: > > Firewall > +-----------------+ > | fxp1 +------ web/mail server > Internet -------+ fxp0 | > | fxp3 +------ internal network (4 machines) > +-----------------+ (10.0.3.2-10.0.3.5) > > fxp0 and fxp1 are bridged. Packets to/from fxp3 are routed through > natd. All interfaces are 100 Mbps, and the Internet connection is 24 > Mbps. > > This is a snapshot from top, when transferring about 1mbps (total for > outgoing and incoming traffic through all ports): > > CPU states: 1.5% user, 0.0% nice, 44.2% system, 54.3% interrupt, 0.0% idle > Mem: 6296K Active, 28M Inact, 11M Wired, 12K Cache, 13M Buf, 10M Free > Swap: > > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU > COMMAND > 71 root 63 0 476K 328K RUN 23.6H 93.07% 93.07% natd > > I've read and understand that ipfilter or pf might be faster regarding > nat, but last I checked, ipfilter could not filter bridged packets. > Has this changed, or could pf do that? As a last resort, any way of > getting ipfw and ipfilter work concurrently, with ipfw filtering the > bridged traffic, and ipfilter doing the other stuff? > > > FOURTH QUESTION: My server (on fxp1) complains like this, about 10 > times a day: > > Apr 22 12:41:47 multivac /kernel: arp: 212.247.27.202 moved from > 00:80:c8:b9:1a:fa to 00:80:c8:b9:1a:f9 on fxp0 > Apr 22 12:41:47 multivac /kernel: arp: 212.247.27.202 moved from > 00:80:c8:b9:1a:f9 to 00:80:c8:b9:1a:fa on fxp0 > > (Yes, that machine too has an Intel interface--I'm saying this only > not to cause any confusion about "fxp0" in the log message.) > > The ip address is my firewall's external address, and the two ethernet > addresses are the addresses of the firewall's fxp0 and fxp1. I assume > this has to do with the fact that the two interfaces are bridged, but > fxp1 does not even have an IP address... It's not a big problem in > itself, but maybe it indicates something wrong with my setup? > > Staffan > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net