From owner-freebsd-ipfw Sun Feb 9 7:17:28 2003 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 DE43237B405 for ; Sun, 9 Feb 2003 07:17:26 -0800 (PST) Received: from mail0.ewetel.de (mail0.ewetel.de [212.6.122.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BD1143F3F for ; Sun, 9 Feb 2003 07:17:25 -0800 (PST) (envelope-from Peter.Ewert@ewetel.de) Received: from ewetel.de (dynadsl-080-228-66-219.ewetel.net [80.228.66.219]) by mail0.ewetel.de (8.12.1/8.12.1) with ESMTP id h19FHGbq012222 for ; Sun, 9 Feb 2003 16:17:17 +0100 (MET) Message-ID: <3E4670F4.8010507@ewetel.de> Date: Sun, 09 Feb 2003 16:17:08 +0100 From: Peter Ewert Reply-To: Peter.Ewert@ewetel.de User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG Subject: Is the RED implementation correct? X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CheckCompat: OK Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, ipfw pipe 1 config bw 100kbit/s queue 50 red 0.002/5/15/0.1 sets up a 50 slot queue with limited bandwitdh and RED queue management. In particular it calculates the parameters for setting up a lookup table, which is used for calculating the average queue length for recently exhausted queues. 1) I do not understand the calculation of the pipe.fs.lookup_weight in ipfw.c/ipfw2.c: weight = 1 - w_q; for (t = pipe.fs.lookup_step; t > 0; --t) weight *= weight; pipe.fs.lookup_weight = (int)(weight * (1 << SCALE_RED)); which gives for typical parameters a lookup_weight equal to zero due to the small accuracy of the fixed point notation and the relative fast convergence of ((1-w_q)^(2^pipe.fs.lookup_step)) -> 0 for weight<1. I would have expected something like: weight = 1 - w_q; for (t = (int)(3. / (w_q*lookup_depth)); t > 0; --t) weight *= (1 - w_q); pipe.fs.lookup_weight = (int)(weight * (1 << SCALE_RED)); which calculates weight as weight=(1-w_q)^(3/(w_q*lookup_depth)). This would make more sense to me as weight should not depend on s (ticks for sending medium-sized packet). Together with the following lines from ip_dummynet.c: for (i = 1; i < x->lookup_depth; i++) x->w_q_lookup[i] = SCALE_MUL(x->w_q_lookup[i - 1], x->lookup_weight); we would have a correct initialized lookuptable in w_q_lookup. 2) The line s = clock.hz * avg_pkt_size * 8 / pipe.bandwidth; in ipfw.c/ipfw2.c should give a "better" accuracy for s using floating point division: s = clock.hz * avg_pkt_size * 8 / (double)pipe.bandwidth; 3) In ip_dummynet.c: I think in q->avg=(t < fs->lookup_depth) ? SCALE_MUL(q->avg,fs->w_q_lookup[t]) : 0; the 32Bit multiply overflows. Using SCALE_MUL((int64_t) q->avg, (int64_t)(fs->w_q_lookup[t])) should solve the problem. Any comments? Regards, Peter Ewert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Feb 10 4: 0:43 2003 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 076E337B401; Mon, 10 Feb 2003 04:00:38 -0800 (PST) Received: from mx1.lublin.pl (mx1.lublin.pl [212.182.63.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFC1243F93; Mon, 10 Feb 2003 04:00:36 -0800 (PST) (envelope-from pawmal@unia.3lo.lublin.pl) Received: from proxy.zin.lublin.pl ([212.182.126.66]:26748 "EHLO towah-xp") by mx1.lublin.pl with ESMTP id ; Mon, 10 Feb 2003 13:00:17 +0100 From: "Pawel Malachowski" Organization: unidentified flying modems To: Maxim Konovalov Date: Mon, 10 Feb 2003 13:00:33 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-2 Content-transfer-encoding: 8BIT Comments: Sender has elected to use 8-bit data in this message. If problems arise, refer to postmaster at sender's site. Subject: Re: kern/48009: dummynet(4) related machine hangs Cc: bug-followup@freebsd.org, freebsd-ipfw@freebsd.org References: <20030206152157.52736.qmail@unia.3lo.lublin.pl> In-reply-to: <20030206183303.X25010@news1.macomnet.ru> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: <20030210120026Z3132496-961+1@mx1.lublin.pl> Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I've checked if really q->numbytes is getting negative as Mike Hibler described in kern/37573 and I realized this is true. My machine goes into infinite loop in splimp()/splx() sections and that's why it looks as if it was frozen. I've decided the check if the problem exists on other 2 machines (4.7-RELEASE and 4.7-STABLE) and I must confirm, all of them hang is the same way when I frequently modify bandwith parameter. Once again, * Install fresh FreeBSD 4.7-RELEASE * Recompile GENERIC kernel with IPFW2, rebuild ipfw and libalias as described in ipfw(8), reinstall and reboot * Do: ipfw pipe 10 config bw 0 ipfw pipe 20 config bw 0 ipfw add 10 pipe 10 ip from any to any in recv NIC ipfw add 20 pipe 20 ip from any to any out xmit NIC (my NIC was: rl0, fxp0 -- a NIC one is using to connect with LAN) Then connect for example to the fast FTP-server in LAN and GET some big file (hundreds of MB). While this file is downloading, run the following script: #!/bin/sh while [ 1 ] i=1 do echo Test number $i \(`date`\). echo Step 1. ipfw pipe 10 config bw 512kbit/s echo Step 2. ipfw pipe 20 config bw 512kbit/s sleep 1 echo Step 3. ipfw pipe 10 config bw 2Mbit/s echo Step 4. ipfw pipe 20 config bw 2Mbit/s sleep 1 i=`expr $i + 1` done * And look q->numbytes after a while will grow fast up to 2^31-1 and revert into negative causing system hang. What is going on? In ip_dummynet.c, in ready_event() the following line (551) reverts q->numbytes into negative: q->numbytes += ( curr_time - q->sched_time ) * p->bandwidth; causing dummynet() to go into infinite loop with ready_event(). Note, in line 557 we are decreasing q->numbytes preventing it from growing to much: q->numbytes -= len_scaled ; (where len_scaled = pkt->dn_m->m_pkthdr.len * 8 * hz) When we frequently modify bandwith using ipfw pipe config bw xxx, q->numbytes starts growing up to maximum signed integer size. This was easy to observe cause I've added diagnostic printf to config_pipe() showing current q->numbytes value every time config_pipe() was called (every time ipfw pipe config bw xxx was used). It looks, when we are downloading something big (means, we have high traffic on pipe 10 (recv), the q->numbytes associated with pipe 20 (xmit!) grows fast. This patch (work-around) comes from kern/37573 and was changed a bit to cleanly apply on RELENG_4_7 ip_dummynet.c. It works for me preventing machine from hanging. ==================== *** ip_dummynet.c.origThu Jan 23 22:06:45 2003 --- ip_dummynet.cSun Feb 9 23:51:49 2003 *************** *** 549,554 **** --- 549,559 ---- * setting len_scaled = 0 does the job. */ q->numbytes += ( curr_time - q->sched_time ) * p->bandwidth; + if (q->numbytes<0) { + /* This shouldn't happen, I clear q->numbytes in config_pipe() */ + printf("Oops, ready_event has a problem with q->numbytes<0.\n"); + q->numbytes=0 ; + } while ( (pkt = q->head) != NULL ) { int len = pkt->dn_m->m_pkthdr.len; int len_scaled = p->bandwidth ? len*8*hz : 0 ; *************** *** 1515,1521 **** static int config_pipe(struct dn_pipe *p) { ! int s ; struct dn_flow_set *pfs = &(p->fs); /* --- 1520,1526 ---- static int config_pipe(struct dn_pipe *p) { ! int s = 0; struct dn_flow_set *pfs = &(p->fs); /* *************** *** 1549,1561 **** x->idle_heap.size = x->idle_heap.elements = 0 ; x->idle_heap.offset=OFFSET_OF(struct dn_flow_queue, heap_pos); } else x = b; ! x->bandwidth = p->bandwidth ; x->numbytes = 0; /* just in case... */ bcopy(p->if_name, x->if_name, sizeof(p->if_name) ); x->ifp = NULL ; /* reset interface ptr */ ! x->delay = p->delay ; set_fs_parms(&(x->fs), pfs); --- 1554,1579 ---- x->idle_heap.size = x->idle_heap.elements = 0 ; x->idle_heap.offset=OFFSET_OF(struct dn_flow_queue, heap_pos); } else + { struct dn_flow_queue *q; + int i; + x = b; + s = splimp(); /* protect mods to active pipe/flow set */ + + /* Obtained from kern/37573 Audit-Trail */ + /* flush accumulated credit for all queues */ + for (i = 0 ; i <= x->fs.rq_size ; i++ ) + for (q = x->fs.rq[i] ; q ; q = q->next ) { + q->numbytes = 0; + } + } + ! x->bandwidth = p->bandwidth ; x->numbytes = 0; /* just in case... */ bcopy(p->if_name, x->if_name, sizeof(p->if_name) ); x->ifp = NULL ; /* reset interface ptr */ ! x->delay = p->delay ; set_fs_parms(&(x->fs), pfs); *************** *** 1571,1578 **** all_pipes = x ; else a->next = x ; - splx(s); } } else { /* config queue */ struct dn_flow_set *x, *a, *b ; --- 1589,1596 ---- all_pipes = x ; else a->next = x ; } + splx(s); } else { /* config queue */ struct dn_flow_set *x, *a, *b ; *************** *** 1600,1605 **** --- 1618,1624 ---- if (pfs->parent_nr != 0 && b->parent_nr != pfs->parent_nr) return EINVAL ; x = b; + s = splimp(); /* protect mods to active pipe/flow set */ } set_fs_parms(x, pfs); *************** *** 1615,1622 **** all_flow_sets = x; else a->next = x; - splx(s); } } return 0 ; } --- 1634,1641 ---- all_flow_sets = x; else a->next = x; } + splx(0); } return 0 ; } ==================== -- Paweł Małachowski To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Feb 10 8:43:19 2003 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 5ED4037B405; Mon, 10 Feb 2003 08:43:18 -0800 (PST) Received: from mta10.srv.hcvlny.cv.net (mta10.srv.hcvlny.cv.net [167.206.5.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 807C643F85; Mon, 10 Feb 2003 08:43:16 -0800 (PST) (envelope-from agapon@cv-nj.com) Received: from asv10.srv.hcvlny.cv.net (asv10.srv.hcvlny.cv.net [167.206.5.38]) by mta10.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA300H23QG1K1@mta10.srv.hcvlny.cv.net>; Mon, 10 Feb 2003 11:43:16 -0500 (EST) Received: from terminus.foundation.invalid (ool-4355489e.dyn.optonline.net [67.85.72.158]) by asv10.srv.hcvlny.cv.net (8.12.6/8.11.6) with ESMTP id h1AGh566028297; Mon, 10 Feb 2003 11:43:10 -0500 (EST) Received: from edge.foundation.invalid (edge.foundation.invalid [192.168.1.12]) by terminus.foundation.invalid (8.12.6/8.12.3) with ESMTP id h1AGh4Eb038324; Mon, 10 Feb 2003 11:43:04 -0500 (EST envelope-from agapon@cv-nj.com) Received: from localhost (localhost.foundation.invalid [127.0.0.1]) by edge.foundation.invalid (8.12.6/8.12.6) with ESMTP id h1AGh4Wl053498; Mon, 10 Feb 2003 11:43:04 -0500 (EST envelope-from agapon@cv-nj.com) Date: Mon, 10 Feb 2003 11:43:04 -0500 (EST) From: Andriy Gapon Subject: ipsec & ipfw: 4.7-release vs -stable X-X-Sender: avg@edge.foundation.invalid To: freebsd-ipfw@freebsd.org, freebsd-security@freebsd.org Message-id: <20030210114213.P53494@edge.foundation.invalid> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Is there any remedy expected before 4.8 release for the situation with ipsec & ipfw interaction that was created after 'ip_input.c 1.130.2.40, MFC: 1.214' ? The reason I am asking this question with such a big crosspost is that it seems that all previous discussions on this topic resulted in nothing. And this change definetely breaks things for those who use ipsec without extra stuff like gif tunnels. It definetely doesn't look like a kind of change welcomed in -stable branch, not mentioning a potential security vulnaribity for those who can not use gif. I apologize in the case I have missed any latest developments in this area. -- Andriy Gapon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Feb 10 10:47:39 2003 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 33C6837B401 for ; Mon, 10 Feb 2003 10:47:38 -0800 (PST) Received: from mail.agtel.net (babylon.agtel.net [212.111.64.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id A87CB43FB1 for ; Mon, 10 Feb 2003 10:47:36 -0800 (PST) (envelope-from jema@sendmail.ru) Received: from [195.19.9.199] (account ) by mail.agtel.net (CommuniGate Pro WebUser 4.0.3) with HTTP id 24345945 for ; Mon, 10 Feb 2003 21:47:33 +0300 From: "Andy Jema" Subject: ipfw2 bug? To: freebsd-ipfw@freebsd.org X-Mailer: CommuniGate Pro Web Mailer v.4.0.3 Date: Mon, 10 Feb 2003 21:47:33 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I try to use the folowing ruleset: ipfw add check-state ipfw add allow tcp from me to any keep-state out via fxp0 setup ipfw add allow udp from me to any keep-state out via fxp0 ipfw add allow icmp from me to any keep-state out via fxp0 ipfw add 65435 deny log ip from any to any but in attempt of tracerouting of any external host i'm getting the denying message in log Feb 11 21:25:04 nss1 /ns1: ipfw: 65435 Deny ICMP:11.0 in via fxp0 At the same time when i use the common rule like ipfw check-state ipfw add allow ip from me to any keep-state out via fxp0 all works fine What's the deal? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Feb 10 11: 1:31 2003 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 4A34137B401 for ; Mon, 10 Feb 2003 11:01:30 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE96F43F85 for ; Mon, 10 Feb 2003 11:01:29 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id h1AJ1TNS084093 for ; Mon, 10 Feb 2003 11:01:29 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id h1AJ1T3H084075 for ipfw@freebsd.org; Mon, 10 Feb 2003 11:01:29 -0800 (PST) Date: Mon, 10 Feb 2003 11:01:29 -0800 (PST) Message-Id: <200302101901.h1AJ1T3H084075@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2003/01/05] bin/46785 ipfw [patch] add sets information to ipfw2 -h o [2003/01/15] bin/47120 ipfw [patch] Sanity check in ipfw(8) o [2003/01/18] bin/47196 ipfw ipfw won't format correctly output from ' 4 problems total. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Feb 11 4:32:34 2003 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 3673E37B401 for ; Tue, 11 Feb 2003 04:32:33 -0800 (PST) Received: from rumba.wu-wien.ac.at (rumba.wu-wien.ac.at [137.208.3.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38BA543F93 for ; Tue, 11 Feb 2003 04:32:29 -0800 (PST) (envelope-from georg@graf.priv.at) Received: from schurli.wu-wien.ac.at (schurli.wu-wien.ac.at [137.208.16.32]) by rumba.wu-wien.ac.at (8.12.6/8.12.6) with SMTP id h1BCWRck005528 for ; Tue, 11 Feb 2003 13:32:27 +0100 (CET) (envelope-from georg@graf.priv.at) Received: (qmail 29696 invoked by uid 1001); 11 Feb 2003 12:32:26 -0000 Date: Tue, 11 Feb 2003 13:32:26 +0100 From: Georg Graf To: ipfw@FreeBSD.ORG Subject: Re: Static NAT Message-ID: <20030211123226.GA29498@graf.priv.at> References: <3D9865DB.5040902@tcoip.com.br> <20021001055502.GC79303@blossom.cjclark.org> <3D998142.8070005@tcoip.com.br> <20021001174546.GB81932@blossom.cjclark.org> <3D99EEBE.2010403@tcoip.com.br> <20021001195258.GB82099@blossom.cjclark.org> <3D9A00A1.2070809@tcoip.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D9A00A1.2070809@tcoip.com.br> User-Agent: Mutt/1.4i X-WU-uvscan-status: clean v4.1.60/v4246 rumba a686bae9a46a1486ced20ab1b7af0f79 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry for my late reply: On Tue, Oct 01, 2002 at 05:08:01PM -0300, you wrote: [...] > The attack is a Syn Flood. Nothing is affected by the attack except > natd. The symptom with NAT is packet loss (ie, packets enter from one > interface do not exit through the other if they happen to go through > natd). Restarting natd eliminates the symptom immediatly on start (and > then the flood gets to it again). netstat -m shows mbuf clusters peak > equal to maximum, and some hundreds of thousands (maybe more, I don't > recall the exact order, but at least that much) of requests for memory > denied. On syslog, there are messages of packets dropped because of lack > of mbuf clusters. If the synflood comes from the natted network, it is clear that natd is eating up memory. If you use natd "reverse", then you can be dosed by getting synflooded from the internet, because every single syn packet adds an entry in natd's table, at least that's the way I understand this. Were you using reverse nat in October? -- Georg Graf http://georg.graf.priv.at/ PGP Key ID: 0xA5232AD5 Gobergasse 43/2 A-1130 Wien Tel: +43 1 8796723 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Feb 11 4:39: 6 2003 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 2861A37B405 for ; Tue, 11 Feb 2003 04:39:05 -0800 (PST) Received: from host185.dolanmedia.com (host185.dolanmedia.com [209.98.197.185]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EF7143FAF for ; Tue, 11 Feb 2003 04:39:03 -0800 (PST) (envelope-from greg.panula@dolaninformation.com) Received: (qmail 68702 invoked by uid 0); 11 Feb 2003 12:39:02 -0000 Received: from greg.panula@dolaninformation.com by proxy by uid 82 with qmail-scanner-1.15 ( Clear:. Processed in 1.128995 secs); 11 Feb 2003 12:39:02 -0000 X-Qmail-Scanner-Mail-From: greg.panula@dolaninformation.com via proxy X-Qmail-Scanner-Rcpt-To: freebsd-security@freebsd.org,agapon@cv-nj.com,freebsd-ipfw@freebsd.org X-Qmail-Scanner: 1.15 (Clear:. Processed in 1.128995 secs) Received: from unknown (HELO mail.dolanmedia.com) (10.1.1.23) by host185.dolanmedia.com with SMTP; 11 Feb 2003 12:39:01 -0000 Received: from dolaninformation.com (10.1.1.135) by mail.dolanmedia.com (Worldmail 1.3.167); 11 Feb 2003 06:39:01 -0600 Message-ID: <3E48EEE4.AEFC0B4C@dolaninformation.com> Date: Tue, 11 Feb 2003 06:39:00 -0600 From: Greg Panula Reply-To: greg.panula@dolaninformation.com Organization: Dolan Information Center Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Cc: Andriy Gapon , freebsd-ipfw@freebsd.org Subject: Re: ipsec & ipfw: 4.7-release vs -stable References: <20030210114213.P53494@edge.foundation.invalid> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andriy Gapon wrote: > > Is there any remedy expected before 4.8 release for the situation with > ipsec & ipfw interaction that was created after 'ip_input.c 1.130.2.40, > MFC: 1.214' ? > > The reason I am asking this question with such a big crosspost is that it > seems that all previous discussions on this topic resulted in nothing. And > this change definetely breaks things for those who use ipsec without extra > stuff like gif tunnels. It definetely doesn't look like a kind of change > welcomed in -stable branch, not mentioning a potential security > vulnaribity for those who can not use gif. > > I apologize in the case I have missed any latest developments in this > area. > > -- Would it be possible to extend the sysctl variable 'net.inet.ip.fw.one_pass' to include ipsec(esp) traffic? Or maybe create a new similar sysctl variable, e.g. net.inet.ip.fw.ipsec.one_pass? When enabled it would allow ipsec gateways to filter decrypted rfc1918 network traffic on their internal interface(s) and have the all encompassing block rfc1918 traffic on their external interface(s). In the case of non-gateway/single interface boxes using ipsec, the multiple passes thru ipfw behavior could still be used to filter decrypted traffic. Not sure how do-able this is, but it avoids the hassle gif/ipip tunnels(thus keeping interoperability with other non-bsd/linux devices) and also avoids the possible quagmire of a "dedicated" ipsec/esp interface. Just my two bits, greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Feb 11 5:53:49 2003 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 CC1D837B401 for ; Tue, 11 Feb 2003 05:53:46 -0800 (PST) Received: from rumba.wu-wien.ac.at (rumba.wu-wien.ac.at [137.208.3.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B17443FAF for ; Tue, 11 Feb 2003 05:53:45 -0800 (PST) (envelope-from georg-ipfw@graf.priv.at) Received: from schurli.wu-wien.ac.at (schurli.wu-wien.ac.at [137.208.16.32]) by rumba.wu-wien.ac.at (8.12.6/8.12.6) with SMTP id h1BDrhck005827 for ; Tue, 11 Feb 2003 14:53:43 +0100 (CET) (envelope-from georg-ipfw@graf.priv.at) Received: (qmail 30731 invoked by uid 1001); 11 Feb 2003 13:53:43 -0000 Date: Tue, 11 Feb 2003 14:53:43 +0100 From: Georg Graf To: freebsd-ipfw@freebsd.org Subject: IPFW/NATD works (Was: Re: Error in ipfw manpage for stateful rules?) Message-ID: <20030211135343.GD29498@graf.priv.at> Mail-Followup-To: Georg Graf , freebsd-ipfw@freebsd.org References: <200301301630.19610.will@unfoldings.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-WU-uvscan-status: clean v4.1.60/v4246 rumba 11167b3104a53ff539d21518e598895f Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jan 31, 2003 at 12:43:10AM +0000, AMAKAWA Shuhei wrote: [...] > > That keep-state rules do not function correctly in IPFW/NATD. > > not true A proof in 3 lines that it works: ipfw add 20 divert natd log logamount 0 all from any to any via bge0 ipfw add 40 allow log logamount 0 ip from 192.168.77.0/24 to any keep-state ipfw add 50 allow log logamount 0 ip from 137.208.120.10 to any keep-state . . . 65535 deny ip from any to any bge0 ist the world (outside) interface, where natd runs on. 137.208.120.10 is the public IP of the machine. 192.168.77.0/24 is the natted LAN. 137.208.16.32 is just a host on the Internet. The machine is completely invisible to the outside world, but provides full connectivity for the internal LAN and itself! Here are some snapshots what happens within this ruleset: ping from 192.168.77.12 to 137.208.16.32 /kernel: ipfw: 40 Accept ICMP:8.0 192.168.77.12 137.208.16.32 in via vlan998 /kernel: ipfw: 20 Divert 8668 ICMP:8.0 192.168.77.12 137.208.16.32 out via bge0 /kernel: ipfw: 50 Accept ICMP:8.0 137.208.120.10 137.208.16.32 out via bge0 (at this time: dynamic rules:) 00040 0 0 (T 3, slot 208) <-> icmp, 192.168.77.12 0<-> 137.208.16.32 0 00050 0 0 (T 3, slot 214) <-> icmp, 137.208.120.10 0<-> 137.208.16.32 0 reply from 137.208.16.32: /kernel: ipfw: 20 Divert 8668 ICMP:0.0 137.208.16.32 137.208.120.10 in via bge0 /kernel: ipfw: 40 Accept ICMP:0.0 137.208.16.32 192.168.77.12 in via bge0 /kernel: ipfw: 40 Accept ICMP:0.0 137.208.16.32 192.168.77.12 out via vlan998 ping from 137.208.120.10 to 137.208.16.32: /kernel: ipfw: 20 Divert 8668 ICMP:8.0 137.208.120.10 137.208.16.32 out via bge0 /kernel: ipfw: 50 Accept ICMP:8.0 137.208.120.10 137.208.16.32 out via bge0 (at this time: dynamic rules:) ## Dynamic rules: 00050 0 0 (T 2, slot 214) <-> icmp, 137.208.120.10 0<-> 137.208.16.32 0 reply from 137.208.16.32 /kernel: ipfw: 20 Divert 8668 ICMP:0.0 137.208.16.32 137.208.120.10 in via bge0 /kernel: ipfw: 50 Accept ICMP:0.0 137.208.16.32 137.208.120.10 in via bge0 Between 20 and 40 there is space to insert accept rules for other allowed things, like icmp or services the gateway host provides to the Internet or a limited set of "friends" on the Internet or for routing between more than one private subnets. I have to admit that this 3-line set is not the most performance-friendly way to do it. -- Georg Graf http://georg.graf.priv.at/ PGP Key ID: 0xA5232AD5 Gobergasse 43/2 A-1130 Wien Tel: +43 1 8796723 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Feb 11 11:51:19 2003 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 F0EF937B401 for ; Tue, 11 Feb 2003 11:51:17 -0800 (PST) Received: from rumba.wu-wien.ac.at (rumba.wu-wien.ac.at [137.208.3.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C32F43FBF for ; Tue, 11 Feb 2003 11:51:14 -0800 (PST) (envelope-from georg-ipfw@graf.priv.at) Received: from schurli.wu-wien.ac.at (schurli.wu-wien.ac.at [137.208.16.32]) by rumba.wu-wien.ac.at (8.12.6/8.12.6) with SMTP id h1BJpCck007159 for ; Tue, 11 Feb 2003 20:51:12 +0100 (CET) (envelope-from georg-ipfw@graf.priv.at) Received: (qmail 71457 invoked by uid 1001); 11 Feb 2003 19:51:12 -0000 Date: Tue, 11 Feb 2003 20:51:12 +0100 From: Georg Graf To: freebsd-ipfw@freebsd.org Subject: Re: ipfw2 bug? Message-ID: <20030211195112.GA36140@graf.priv.at> Mail-Followup-To: Georg Graf , freebsd-ipfw@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-WU-uvscan-status: clean v4.1.60/v4246 rumba 5487fd9290ca7e2fe236285840849ea3 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 10, 2003 at 09:47:33PM +0300, Andy Jema wrote: > I try to use the folowing ruleset: > > ipfw add check-state > > ipfw add allow tcp from me to any keep-state out via fxp0 > setup > ipfw add allow udp from me to any keep-state out via fxp0 > ipfw add allow icmp from me to any keep-state out via fxp0 > > ipfw add 65435 deny log ip from any to any > > but in attempt of tracerouting of any external host i'm > getting the denying message in log > Feb 11 21:25:04 nss1 /ns1: ipfw: 65435 Deny ICMP:11.0 > in via fxp0 Your setup installs udp dynamic allow rules, but you keep blocking the icmp ttl exceeded messages from the routers resp. the icmp port closed messages from the host you traceroute. > At the same time when i use the common rule like > > ipfw check-state > ipfw add allow ip from me to any keep-state out via fxp0 > > all works fine I dont believe that resp. cannot reproduce it on a 4.7-RELEASE-p4 box. I guess you have an icmp allow rule somewhere left. George -- Georg Graf http://georg.graf.priv.at/ PGP Key ID: 0xA5232AD5 Gobergasse 43/2 A-1130 Wien Tel: +43 1 8796723 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Feb 11 14:14:21 2003 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 DD2D537B401 for ; Tue, 11 Feb 2003 14:14:18 -0800 (PST) Received: from apollo.laserfence.net (apollo.laserfence.net [196.44.69.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2412043F3F for ; Tue, 11 Feb 2003 14:14:17 -0800 (PST) (envelope-from will@unfoldings.net) Received: from localhost ([127.0.0.1]) by apollo.laserfence.net with esmtp (Exim 4.10) id 18iifO-000HUz-00 for freebsd-ipfw@freebsd.org; Wed, 12 Feb 2003 00:14:14 +0200 Received: from prometheus-p0.datel.laserfence.net ([192.168.255.1] helo=prometheus.home.laserfence.net) by apollo.laserfence.net with esmtp (Exim 4.10) id 18iif9-000HUd-00 for freebsd-ipfw@freebsd.org; Wed, 12 Feb 2003 00:14:01 +0200 Received: from phoenix.home.laserfence.net ([192.168.0.2]) by prometheus.home.laserfence.net with esmtp (Exim 4.10) id 18iif6-00043R-00 for freebsd-ipfw@freebsd.org; Wed, 12 Feb 2003 00:13:56 +0200 Received: from will by phoenix.home.laserfence.net with local (Exim 4.10) id 18iif5-0000Kk-00 for freebsd-ipfw@freebsd.org; Wed, 12 Feb 2003 00:13:55 +0200 From: Willie Viljoen To: freebsd-ipfw@freebsd.org Subject: Re: ipfw2 bug? Date: Wed, 12 Feb 2003 00:13:55 +0200 User-Agent: KMail/1.5 References: <20030211195112.GA36140@graf.priv.at> In-Reply-To: <20030211195112.GA36140@graf.priv.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200302120013.55241.will@unfoldings.net> X-Spam-Score: (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *18iif9-000HUd-00*nfZaEHeMSnY* X-Virus-Scanned: by AMaViS snapshot-20020422 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 11 February 2003 21:51, Georg Graf wrote: > On Mon, Feb 10, 2003 at 09:47:33PM +0300, Andy Jema wrote: > > I try to use the folowing ruleset: > > > > ipfw add check-state > > > > ipfw add allow tcp from me to any keep-state out via fxp0 > > setup > > ipfw add allow udp from me to any keep-state out via fxp0 > > ipfw add allow icmp from me to any keep-state out via fxp0 > > > > ipfw add 65435 deny log ip from any to any > > > > but in attempt of tracerouting of any external host i'm > > getting the denying message in log > > Feb 11 21:25:04 nss1 /ns1: ipfw: 65435 Deny ICMP:11.0 > > in via fxp0 > > Your setup installs udp dynamic allow rules, but you keep blocking > the icmp ttl exceeded messages from the routers resp. the icmp port > closed messages from the host you traceroute. > > > At the same time when i use the common rule like > > > > ipfw check-state > > ipfw add allow ip from me to any keep-state out via fxp0 > > > > all works fine > > I dont believe that resp. cannot reproduce it on a 4.7-RELEASE-p4 > box. I guess you have an icmp allow rule somewhere left. > > George You want this rule: ipfw add allow icmp from any to any icmptypes 0,3,4,8,11,12,13,14 You can take out 4 if you do not want source quench (most people don't need it), and you can remove 8 if you do not want your host to be externally pingable, but the rest are absolutely needed, for outgoing traceroutes, ICMP error messages, path MTU discovery, etc. The reason the internet is so slow nowadays is because people block these, and they are *REALLY* needed. For more information, you can read the firewall(7) man page. Will -- Willie Viljoen Freelance IT Consultant 214 Paul Kruger Avenue, Universitas Bloemfontein 9321 South Africa +27 51 522 15 60 +27 51 522 44 36 (after hours) +27 82 404 03 27 (mobile) will@unfoldings.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Feb 14 9:36:36 2003 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 5D54A37B401 for ; Fri, 14 Feb 2003 09:36:34 -0800 (PST) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [199.2.53.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE9CB43FAF for ; Fri, 14 Feb 2003 09:36:33 -0800 (PST) (envelope-from gianluca@sprintlabs.com) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2656.59) id ; Fri, 14 Feb 2003 09:36:33 -0800 Message-ID: <49D9473417F1234C9C86886EE8353FAA0650F8@mailman.sprintlabs.com> From: Gianluca Iannaccone To: "'freebsd-ipfw@freebsd.org'" Subject: FW: Is the RED implementation correct? Date: Fri, 14 Feb 2003 09:36:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG sorry but it seems that this one didn't make it through the first time. -gianluca -----Original Message----- From: Gianluca Iannaccone Sent: Sunday, February 09, 2003 12:37 PM To: 'Peter.Ewert@ewetel.de'; freebsd-ipfw@FreeBSD.ORG Subject: RE: Is the RED implementation correct? peter, > I would have expected something like: > > weight = 1 - w_q; > for (t = (int)(3. / (w_q*lookup_depth)); t > 0; --t) > weight *= (1 - w_q); > pipe.fs.lookup_weight = (int)(weight * (1 << SCALE_RED)); > > which calculates weight as weight=(1-w_q)^(3/(w_q*lookup_depth)). > This would make more sense to me as weight should not depend > on s (ticks for sending medium-sized packet). i don't think that removing the dependency on the ticks needed to send a medium size packet is correct. the idea here is that when the queue becomes empty you need to decide for how long your average queue size is a valid estimator of the congestion on the link. thus, you want to have that slow links have much more "memory" of previous congestion phases when compared to fast links. that's why you need to keep some notion of link speed in the weights. on the other hand, according to the specs the 'weight *= weight' should be as you say 'weight *= (1 - w_q)'. > 2) > The line > s = clock.hz * avg_pkt_size * 8 / pipe.bandwidth; > in ipfw.c/ipfw2.c > should give a "better" accuracy for s using floating point division: > s = clock.hz * avg_pkt_size * 8 / (double)pipe.bandwidth; this part of the RED specs is inherently inaccurate, so i don't think having s more accurate would make any difference. however, i don't see any harm in using floating point division here. > > 3) > In ip_dummynet.c: > I think in > q->avg=(t < fs->lookup_depth) ? > SCALE_MUL(q->avg,fs->w_q_lookup[t]) : 0; > > the 32Bit multiply overflows. Using > SCALE_MUL((int64_t) q->avg, (int64_t)(fs->w_q_lookup[t])) > should solve the problem. yes, SCALE_MUL should always be done on 64bits. indeed in the RED code all the SCALE_MUL operations use 64 bits but this one... thanks, gianluca ---------------------------------------------------------- Gianluca Iannaccone ' gianluca@sprintlabs.com Sprint ATL ' tel +1 (650) 375-4198 1 Adrian Court ' fax +1 (650) 375-4079 Burlingame, CA 94010 ' www.sprintlabs.com/people/gianluca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Feb 15 7: 7:37 2003 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 B304837B401 for ; Sat, 15 Feb 2003 07:07:35 -0800 (PST) Received: from mail1.ewetel.de (mail1.ewetel.de [212.6.122.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46ED943FB1 for ; Sat, 15 Feb 2003 07:07:34 -0800 (PST) (envelope-from Peter.Ewert@ewetel.de) Received: from ewetel.de (dynadsl-080-228-67-233.ewetel.net [80.228.67.233]) by mail1.ewetel.de (8.12.1/8.12.1) with ESMTP id h1FF7TGF024355 for ; Sat, 15 Feb 2003 16:07:30 +0100 (MET) Message-ID: <3E4E57A6.7050403@ewetel.de> Date: Sat, 15 Feb 2003 16:07:18 +0100 From: Peter Ewert Reply-To: Peter.Ewert@ewetel.de User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG Subject: Re: Is the RED implementation correct? References: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com> In-Reply-To: <49D9473417F1234C9C86886EE8353FAA0650E1@mailman.sprintlabs.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-CheckCompat: OK Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Im sorry answering so late. ... >>weight=(1-w_q)^(3/(w_q*lookup_depth)). >>This would make more sense to me as weight should not depend >>on s (ticks for sending medium-sized packet). > > i don't think that removing the dependency on the ticks needed to send > a medium size packet is correct. the idea here is that when the queue > becomes empty you need to decide for how long your average queue size > is a valid estimator of the congestion on the link. > > thus, you want to have that slow links have much more "memory" of > previous congestion phases when compared to fast links. that's why you > need to keep some notion of link speed in the weights. My idea was that the lookuptable always should look the same. It is used this way: new_avg = avg * w_q_lookup[(Nr. of Packets which could have been transfered)] The implementation in ip_dummynet.c: u_int t = (curr_time - q->q_time) / fs->lookup_step; ... if (t < fs->lookup_depth){ q->avg = SCALE_MUL((int64_t) q->avg, (int64_t)(fs->w_q_lookup[t])); } else { q->avg = 0; } The "memory" is always the same in respect to the speed of the link. Its true that it is "bigger" in meanings of ticks but this doesnt matter because the idle time is normalized by the step size (fs->lookup_step). I think this is the dependency you meant. >>2) ... >>3) ... Regards, Peter Ewert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message