From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 04:30:48 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93BA816A420 for ; Mon, 5 Nov 2007 04:30:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7A51413C4A6 for ; Mon, 5 Nov 2007 04:30:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 04 Nov 2007 20:05:47 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BE2B31268EF; Sun, 4 Nov 2007 20:05:46 -0800 (PST) Message-ID: <472E96BE.4050504@elischer.org> Date: Sun, 04 Nov 2007 20:06:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Gardner Bell References: <932971.53959.qm@web88014.mail.re2.yahoo.com> In-Reply-To: <932971.53959.qm@web88014.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 04:30:48 -0000 Gardner Bell wrote: > I'm hoping some of you can help me out with the problem that I'm having > as I'm not very good when it comes to networking.. > > I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my > LAN's firewall/router. After I initially access certain http sites, > particularly google groups and yahoo web mail I'm noticing subsequent > attempts take > 2mins to resolve the next link that I am interested in > reading. > > This appears to be caused by rule 01000 as the counter increases each > time I access one of the above mentioned sites. > > Short of removing this rule, is there any other way that I can fix this > issue? Below is a listing of my present ruleset and a tcpdump of a > Windows XP machine trying to access a link on google groups. > > regards, > > Gardner > > mx1# ipfw show > 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any > 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 > 00400 0 0 deny log logamount 10 ip from any to any not > verrevpath in > 00500 0 0 deny log logamount 10 ip from any to any ipoptions > ssrr,lsrr,rr,ts in > 00600 0 0 deny ip from any to any frag > 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 > 00800 1081 452405 divert 8668 ip from any to any via bge0 > 00900 0 0 check-state > 01000 36 17682 deny tcp from any to any established > 01100 2704 853904 allow ip from any to any via bge1 keep-state > 01200 262 57586 allow tcp from any to any dst-port 80 keep-state > 01300 0 0 allow tcp from any to any dst-port 443 keep-state > 01400 102 7752 allow udp from me to any dst-port 123 keep-state > 01500 0 0 allow tcp from me to any dst-port 53 setup keep-state > 01600 169 30563 allow udp from me to any dst-port 53 keep-state > 01700 0 0 allow tcp from any to any dst-port 1863 setup > keep-state > 01800 0 0 allow log logamount 10 udp from any to > 255.255.255.255 dst-port 68 in via bge0 > 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 > keep-state > 02000 0 0 deny log logamount 10 ip After many years fo doing ipfw rules at work I've cone to the conclusion that one needs to be more explicit about what is going on that most ipfw rulesets are: for example: Assuming bge0 is on the outside, and bge1 is on the inside... #split to incoming and outgoing (from this system) packets. ipfw add 1 skipto 1000 ip from any to any in ############ Output interface sorting ############# # now do output processing. Split up according to interface: ipfw add 100 allow ip from any to any via lo0 ipfw add 110 skipto 3400 ip from any to any out xmit bge0 ipfw add 120 skipto 2400 ip from any to any out xmit bge1 # what is left? should never happen. ipfw add 130 drop log ip from any to any ########### Input interface sorting ###########\ # split up according to source interface. # do checking for lo0 an dloopback addr. ipfw add 1000 accept ip from any to any via lo0 ipfw add 1010 drop log ip from any to 127.0.0.1/8 ipfw add 1020 skipto 2300 ip from any to any recv bge0 ipfw add 1030 skipto 3300 ip from any to any recv bge1 # should never happen so log it: ipfw add 1040 drop log ip from any to any ##################################################### ####### Per interface - per-direction filters ####### ##################################################### ######################################## #### Inside Interface input filters #### # trust the inside. ipfw add 2300 accept ip from any to any #### Inside interface output filters ### # things to do for packets leaving towards the inside. ipfw add 2400 allow ip from any to any ################################# #### Outside interface input #### # process packets coming in from the Internet. # do special processing for packets not of interest to NATD. ipfw add 3300 skipto 1260 ip from any to not me # If they are aimed at our inside address, pass them to NATD. # it should pass on packets that are just to us if set up right. ipfw add 3310 divert 8668 ip from any to me # packets diverted and reinjected come here ipfw add 3320 accept ip from any to any # for now no special processing.. ipfw add 3360 drop log ip from any to any #### Outside Interface output#### # things we need to do for packets leaving via bge0 to the Internet. # Nat packets that are suitable. Don't wast time NATing other packets. ipfw add 3400 divert 8668 ip from not me to any recv bge1 #nat'd packets will turn up here when re-injected. ipfw add 3410 allow ip from any to any. now you can put in rules that are specific to exactly certain traffic and know what the h*ck is going on. >