From owner-freebsd-ipfw Tue Aug 13 0:30:47 2002 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 9968E37B400; Tue, 13 Aug 2002 00:30:44 -0700 (PDT) Received: from addr-mx02.addr.com (addr-mx02.addr.com [209.249.147.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1022F43E8A; Tue, 13 Aug 2002 00:30:29 -0700 (PDT) (envelope-from torvalds@addr.com) Received: from proxy1.addr.com (proxy1.addr.com [209.249.147.28]) by addr-mx02.addr.com (8.12.5/8.12.2) with ESMTP id g7D7USjG003330; Tue, 13 Aug 2002 00:30:28 -0700 (PDT) Received: from TS22 ([202.71.153.170]) by proxy1.addr.com (8.11.6/8.9.1) with ESMTP id g7D7UOx03910; Tue, 13 Aug 2002 00:30:24 -0700 (PDT) (envelope-from torvalds@addr.com)(envelope-to ) Message-ID: <003f01c2429b$356daf20$9600a8c0@blraddrcom> From: "Naga Suresh B" To: Cc: Subject: Problem in port forwarding Date: Tue, 13 Aug 2002 12:59:47 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) 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 Hai, I am having a Gateway configured with two network cards one with external and another with internal ip. On this gateway I am having ipfw rules enabled. I am doing portforwarding for the following ports 5800 5500 5900 using natd I redirected the ports, by using external ip from my internal network I am not able to access that application But externally I am able to access that application by using external IP. Please give me some solution for this problem. Please tell me whether I have to change anything on my firewall scripts. Waiting for u r reply, Suresh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 0: 7:25 2002 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 9AB1D37B400; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6740E43E4A; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7F77Lr24724; Thu, 15 Aug 2002 00:07:21 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 00:07:21 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Subject: RFC: new mbuf flag bit needed Message-ID: <20020815000720.B24495@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 [Bcc to -arch in case they have some comments] Hi, we have the following problem: both ipfw and ipfw2 can sometimes generate new packets (e.g. in response to an "unreach" or "reset" action, or simply keepalives) which in turn get reinjected in the stack and the firewall itself, starting from the beginning. This has the potential of causing loops, unless we break them in some way. ipfw does this using two specific hacks: + ICMP packets will not generate a response even on "unreach" rules; + TCP packets with the RST bit set will not generate a response on "unreach" rules) ipfw2 has a harder time because keepalives have nothing very distinguishable in them (except sequence numbers which refer to old data; but to detect them requests a lookup of the stateful entry). So my proposal is to use a different method, and use one of the m_pkthdr.flags bits as a marker that the packet should bypass the firewall. I can restrict the change to just ip_fw2.c so no other parts of the system will need to be modified, except sys/mbuf.h for the definition of the new bit if we want to give it a meaningful name. sys/mbuf.h contains definitions for M_PROTO1..M_PROTO5; the first one is used to mark that rcvif is valid on vlan packets (btw should we rename it to indicate its real use ?). The others are used in the KAME code in netinet6/ -- i guess that leaves me with using one of the two unused bits, 0x4000 and 0x8000 ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 0:26:15 2002 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 2321D37B400 for ; Thu, 15 Aug 2002 00:26:14 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1EA443E6A for ; Thu, 15 Aug 2002 00:26:13 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0107.cvx40-bradley.dialup.earthlink.net ([216.244.42.107] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fF1I-00054f-00; Thu, 15 Aug 2002 00:26:12 -0700 Message-ID: <3D5B547A.E29F61BA@mindspring.com> Date: Thu, 15 Aug 2002 00:12:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: ipfw@freebsd.org Subject: Re: RFC: new mbuf flag bit needed References: <20020815000720.B24495@iguana.icir.org> 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 Luigi Rizzo wrote: > ipfw does this using two specific hacks: > + ICMP packets will not generate a response even on "unreach" rules; > + TCP packets with the RST bit set will not generate a response > on "unreach" rules) > > ipfw2 has a harder time because keepalives have nothing very > distinguishable in them (except sequence numbers which refer to old > data; but to detect them requests a lookup of the stateful entry). Why does ipfw2 not do it exactly the way ipfw does it? I don't understand why it has a harder time, since it has all the same information. > So my proposal is to use a different method, and use one of the > m_pkthdr.flags bits as a marker that the packet should bypass the > firewall. I can restrict the change to just ip_fw2.c so no other > parts of the system will need to be modified, except sys/mbuf.h for > the definition of the new bit if we want to give it a meaningful name. Ugh. So all you have to really do is figure a way to force this bit to get set in data, and you can bypass the firewall with all you hack packets? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 0:34:26 2002 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 D135D37B400 for ; Thu, 15 Aug 2002 00:34:23 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D64E43E42 for ; Thu, 15 Aug 2002 00:34:23 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7F7YMW24922; Thu, 15 Aug 2002 00:34:22 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 00:34:22 -0700 From: Luigi Rizzo To: Terry Lambert Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815003422.A24887@iguana.icir.org> References: <20020815000720.B24495@iguana.icir.org> <3D5B547A.E29F61BA@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5B547A.E29F61BA@mindspring.com>; from tlambert2@mindspring.com on Thu, Aug 15, 2002 at 12:12:58AM -0700 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 ipfw2 does the same hacks as ipfw for ICMP and TCP reset, but should invent a new hack for keepalives (which ipfw does not generate), so i'd rather use a simpler (3 lines) solution which would be: + at the beginning of ip_fw_chk: if (m->m_pkthdr.flags & M_NOFIREWALL) return 0; /* accept */ + in send_pkt, right before the call to ip_output(): m->m_pkthdr.flags |= M_NOFIREWALL; this is all. The only issue is finding what value for M_NOFIREWALL will not conflict with other things (consider that ipfw2 will eventually be used for ipv6 and non-ip protocols as well...) cheers luigi On Thu, Aug 15, 2002 at 12:12:58AM -0700, Terry Lambert wrote: > Luigi Rizzo wrote: > > ipfw does this using two specific hacks: > > + ICMP packets will not generate a response even on "unreach" rules; > > + TCP packets with the RST bit set will not generate a response > > on "unreach" rules) > > > > ipfw2 has a harder time because keepalives have nothing very > > distinguishable in them (except sequence numbers which refer to old > > data; but to detect them requests a lookup of the stateful entry). > > Why does ipfw2 not do it exactly the way ipfw does it? I don't > understand why it has a harder time, since it has all the same > information. > > > > So my proposal is to use a different method, and use one of the > > m_pkthdr.flags bits as a marker that the packet should bypass the > > firewall. I can restrict the change to just ip_fw2.c so no other > > parts of the system will need to be modified, except sys/mbuf.h for > > the definition of the new bit if we want to give it a meaningful name. > > Ugh. So all you have to really do is figure a way to force > this bit to get set in data, and you can bypass the firewall > with all you hack packets? > > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 7:15:41 2002 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 6F31637B409 for ; Thu, 15 Aug 2002 07:15:34 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4589243E6E for ; Thu, 15 Aug 2002 07:15:33 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g7FEF5x08352; Thu, 15 Aug 2002 10:15:05 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Thu, 15 Aug 2002 10:15:05 -0400 From: Bosko Milekic To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815101505.A8332@unixdaemons.com> References: <20020815000720.B24495@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020815000720.B24495@iguana.icir.org>; from rizzo@icir.org on Thu, Aug 15, 2002 at 12:07:21AM -0700 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 Thu, Aug 15, 2002 at 12:07:21AM -0700, Luigi Rizzo wrote: > [Bcc to -arch in case they have some comments] > > Hi, > we have the following problem: both ipfw and ipfw2 can sometimes > generate new packets (e.g. in response to an "unreach" or "reset" > action, or simply keepalives) which in turn get reinjected in the > stack and the firewall itself, starting from the beginning. This > has the potential of causing loops, unless we break them in some > way. > > ipfw does this using two specific hacks: > + ICMP packets will not generate a response even on "unreach" rules; > + TCP packets with the RST bit set will not generate a response > on "unreach" rules) > > ipfw2 has a harder time because keepalives have nothing very > distinguishable in them (except sequence numbers which refer to old > data; but to detect them requests a lookup of the stateful entry). > > So my proposal is to use a different method, and use one of the > m_pkthdr.flags bits as a marker that the packet should bypass the > firewall. I can restrict the change to just ip_fw2.c so no other > parts of the system will need to be modified, except sys/mbuf.h for > the definition of the new bit if we want to give it a meaningful name. This sounds like it could warrant its own flag in sys/mbuf.h, say M_BYPASS_IPFW, instead of using one of the M_PROTO flags. I just made m_flags an int instead of a short so you should have plenty of available bits now. You can do the same in RELENG_4. > sys/mbuf.h contains definitions for M_PROTO1..M_PROTO5; the first > one is used to mark that rcvif is valid on vlan packets (btw should > we rename it to indicate its real use ?). It's safe to use one of the M_PROTO flags only if you know that the other layers the mbuf chain will pass through will not use it. What I mean is that it's only ok if you know that, say, "there is no way that the packet I am looking at can be vlan, I am using M_PROTO1 just for internal things." In general, I think that for your case, where the packet is re-inserted into the stack, you have a good enough reason to define your own flag in sys/mbuf.h > The others are used in the KAME code in netinet6/ -- i guess that > leaves me with using one of the two unused bits, 0x4000 and 0x8000 ? > > cheers > luigi Cheers, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 7:22: 3 2002 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 846A937B400 for ; Thu, 15 Aug 2002 07:22:01 -0700 (PDT) Received: from rshb.com.ru (rshb.com.ru [195.162.58.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F379543E7B for ; Thu, 15 Aug 2002 07:22:00 -0700 (PDT) (envelope-from admin@rshb.com.ru) Received: by rshb.com.ru (Sendmail for UK-NC RT11-SJ, from userid 426) id A4CC520F13; Thu, 15 Aug 2002 21:21:59 +0700 (OMSST) Received: from rshb.com.ru (vampiro.rsb.local [192.168.1.111]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Evgueni V. Gavrilov", Issuer "RSHB Omsk branch CA" (verified OK)) by rshb.com.ru (Sendmail for UK-NC RT11-SJ) with ESMTP id 796A820F0D for ; Thu, 15 Aug 2002 21:21:59 +0700 (OMSST) Message-ID: <3D5BB907.2070609@rshb.com.ru> Date: Thu, 15 Aug 2002 21:21:59 +0700 From: "Evgueni V. Gavrilov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020813 X-Accept-Language: ru, en MIME-Version: 1.0 To: ipfw@FreeBSD.ORG Subject: IPFW2 segfaults Content-Type: text/plain; charset=KOI8-R; format=flowed 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 hi I tried to take a look at IPFW2 but all I got is segfault *8-) here are my IPFW definitions from kernel: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFW2 any advises appreciated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 9:28:39 2002 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 2DF6137B400 for ; Thu, 15 Aug 2002 09:28:37 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5299E43E42 for ; Thu, 15 Aug 2002 09:28:36 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7FGSPQ29728; Thu, 15 Aug 2002 09:28:26 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 09:28:25 -0700 From: Luigi Rizzo To: "Evgueni V. Gavrilov" Cc: ipfw@FreeBSD.ORG Subject: Re: IPFW2 segfaults Message-ID: <20020815092825.A29716@iguana.icir.org> References: <3D5BB907.2070609@rshb.com.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D5BB907.2070609@rshb.com.ru>; from admin@rshb.com.ru on Thu, Aug 15, 2002 at 09:21:59PM +0700 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 are you sure you recompiled /sbin/ipfw and /usr/lib/libalias with -DIFPW2 ? cheers luigi On Thu, Aug 15, 2002 at 09:21:59PM +0700, Evgueni V. Gavrilov wrote: > hi > > I tried to take a look at IPFW2 but all I got is segfault *8-) > here are my IPFW definitions from kernel: > > options IPFIREWALL > > options IPFIREWALL_VERBOSE > > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options IPFW2 > > > any advises appreciated > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 9:30:34 2002 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 1CA7737B400 for ; Thu, 15 Aug 2002 09:30:33 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDB8F43E65 for ; Thu, 15 Aug 2002 09:30:32 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7FGUSI29762; Thu, 15 Aug 2002 09:30:28 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 09:30:28 -0700 From: Luigi Rizzo To: Bosko Milekic Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815093028.B29716@iguana.icir.org> References: <20020815000720.B24495@iguana.icir.org> <20020815101505.A8332@unixdaemons.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020815101505.A8332@unixdaemons.com>; from bmilekic@unixdaemons.com on Thu, Aug 15, 2002 at 10:15:05AM -0400 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 Thu, Aug 15, 2002 at 10:15:05AM -0400, Bosko Milekic wrote: ... > M_BYPASS_IPFW, instead of using one of the M_PROTO flags. I just made > m_flags an int instead of a short so you should have plenty of > available bits now. You can do the same in RELENG_4. i hear julian screaming in the background :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 11: 0:25 2002 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 45C5A37B400 for ; Thu, 15 Aug 2002 11:00:23 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C825243E70 for ; Thu, 15 Aug 2002 11:00:22 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815180022.PWXA1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 18:00:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA27493; Thu, 15 Aug 2002 10:49:22 -0700 (PDT) Date: Thu, 15 Aug 2002 10:49:22 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: ipfw@freebsd.org Subject: Re: RFC: new mbuf flag bit needed In-Reply-To: <20020815000720.B24495@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 15 Aug 2002, Luigi Rizzo wrote: > [Bcc to -arch in case they have some comments] > > Hi, > we have the following problem: both ipfw and ipfw2 can sometimes > generate new packets (e.g. in response to an "unreach" or "reset" > action, or simply keepalives) which in turn get reinjected in the > stack and the firewall itself, starting from the beginning. This > has the potential of causing loops, unless we break them in some > way. A bit to force non testing in a firewall might be useful in other places.. I'd however like to float an idea that maybe there should be more specific bits for input and output processing. for example a 'fwd' packet that has been forwarded out from thi input filter needs to bypass the output filter.. your bit could be used for that. I am just wondering if a separate 'input' and 'output' filtering bit may be a worthwhile aim.. anyhow these are IP specific items so what I suggest is instead, that we define 4 or so "protocol family specific" bits that are reserved for protocol use. and allow each protocol family to define their own use for them. you could then define bits for input-filter bypass, output filter bypass, input-from-divert etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 11:38:29 2002 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 A7BCA37B400 for ; Thu, 15 Aug 2002 11:38:26 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C3043E65 for ; Thu, 15 Aug 2002 11:38:26 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7FIcPu30659; Thu, 15 Aug 2002 11:38:25 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 11:38:25 -0700 From: Luigi Rizzo To: Julian Elischer Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815113824.B30190@iguana.icir.org> References: <20020815000720.B24495@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Thu, Aug 15, 2002 at 10:49:22AM -0700 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 Thu, Aug 15, 2002 at 10:49:22AM -0700, Julian Elischer wrote: ... > A bit to force non testing in a firewall might be useful in other places.. > I'd however like to float an idea that maybe there should be more > specific bits for input and output processing. unfortunately bits are a scarce resource in struct m_hdr which we do not want to change in RELENG_4. Plus, many of the cases you are mentioning are already taken care of with m_tag/annotations because you need additional information: e.g. in the "fwd" you need the fwd address anyways, same for divert (you need the 'next rule'), and dummynet when you want multiple passes. The problem with protocol-specific bits is that you'll end up overloading them, and once you pass the packets to a multi-protocol module (such as netgraph, or ipfw2) you are in trouble. E.g. M_PROTO1 has been overloaded by device drivers to report some vlan-related info. The other M_PROTO* are all taken by the KAME code. cheers luigi > > > for example a 'fwd' packet that has been forwarded out from thi input > filter needs to bypass the output filter.. your bit could be used for > that. I am just wondering if a separate > 'input' and 'output' filtering bit may be a worthwhile aim.. > anyhow these are IP specific items so what I suggest is instead, that we > define 4 or so "protocol family specific" bits > that are reserved for protocol use. and allow each protocol family to > define their own use for them. > > you could then define bits for > input-filter bypass, > output filter bypass, > input-from-divert > > > etc. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 12: 0:23 2002 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 DA1F537B401 for ; Thu, 15 Aug 2002 12:00:19 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD8943E3B for ; Thu, 15 Aug 2002 12:00:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815190018.UEHR1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 19:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA27732; Thu, 15 Aug 2002 11:49:43 -0700 (PDT) Date: Thu, 15 Aug 2002 11:49:41 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed In-Reply-To: <20020815113824.B30190@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 15 Aug 2002, Luigi Rizzo wrote: > On Thu, Aug 15, 2002 at 10:49:22AM -0700, Julian Elischer wrote: > ... > > A bit to force non testing in a firewall might be useful in other places.. > > I'd however like to float an idea that maybe there should be more > > specific bits for input and output processing. > > unfortunately bits are a scarce resource in struct m_hdr which we > do not want to change in RELENG_4. Plus, many of the cases you are > mentioning are already taken care of with m_tag/annotations because > you need additional information: e.g. in the "fwd" you need the > fwd address anyways, same for divert (you need the 'next rule'), > and dummynet when you want multiple passes. > > The problem with protocol-specific bits is that you'll end up > overloading them, and once you pass the packets to a multi-protocol > module (such as netgraph, or ipfw2) you are in trouble. > E.g. M_PROTO1 has been overloaded by device drivers to report > some vlan-related info. The other M_PROTO* are all taken by > the KAME code. > > cheers > luigi > protocols should not expect to store flags there on packets that cross a protocol boundary. it would be for passing state around within a single protocol family.. such as you suggest. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 12:10: 8 2002 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 3224D37B401 for ; Thu, 15 Aug 2002 12:10:04 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E287143E3B for ; Thu, 15 Aug 2002 12:10:03 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7FJA2m30919; Thu, 15 Aug 2002 12:10:02 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 12:10:02 -0700 From: Luigi Rizzo To: Julian Elischer Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815121002.D30190@iguana.icir.org> References: <20020815113824.B30190@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Thu, Aug 15, 2002 at 11:49:41AM -0700 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 Thu, Aug 15, 2002 at 11:49:41AM -0700, Julian Elischer wrote: ... > > The problem with protocol-specific bits is that you'll end up > > overloading them, and once you pass the packets to a multi-protocol > > module (such as netgraph, or ipfw2) you are in trouble. ... > protocols should not expect to store flags there on packets that cross a > protocol boundary. yesh but then you rely on those protocols cleaning up the flags after they are done with it. Which does not always happen in real life, e.g. one of the comments to motivate the use of M_PROTO1 is that "somewhere mbuf headers are not properly initialized and rcvif might contain junk" > it would be for passing state around within a single protocol family.. > such as you suggest. So, i do _not_ want a protocol-specific bit because the info i need is not protocol-specific and goes to a non-protocol-specific module. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 14:39:33 2002 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 7BF3737B409 for ; Thu, 15 Aug 2002 14:39:17 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7800943F75 for ; Thu, 15 Aug 2002 14:22:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815212007.POZQ11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 21:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA28310; Thu, 15 Aug 2002 14:03:46 -0700 (PDT) Date: Thu, 15 Aug 2002 14:03:45 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed In-Reply-To: <20020815121002.D30190@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thu, 15 Aug 2002, Luigi Rizzo wrote: > On Thu, Aug 15, 2002 at 11:49:41AM -0700, Julian Elischer wrote: > ... > > > The problem with protocol-specific bits is that you'll end up > > > overloading them, and once you pass the packets to a multi-protocol > > > module (such as netgraph, or ipfw2) you are in trouble. > ... > > protocols should not expect to store flags there on packets that cross a > > protocol boundary. > > yesh but then you rely on those protocols cleaning up the flags > after they are done with it. Which does not always happen in real > life, e.g. one of the comments to motivate the use of M_PROTO1 > is that "somewhere mbuf headers are not properly initialized and > rcvif might contain junk" > > > it would be for passing state around within a single protocol family.. > > such as you suggest. > > So, i do _not_ want a protocol-specific bit because the info i need > is not protocol-specific and goes to a non-protocol-specific module. how does ipfw2 connect with appletalk? it really IS a protocol specific hack.. > > cheers > luigi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 14:40:33 2002 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 32CB337B744 for ; Thu, 15 Aug 2002 14:39:48 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id E21C5442EF for ; Thu, 15 Aug 2002 14:31:43 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g7FLUuK31932; Thu, 15 Aug 2002 14:30:56 -0700 (PDT) (envelope-from rizzo) Date: Thu, 15 Aug 2002 14:30:56 -0700 From: Luigi Rizzo To: Julian Elischer Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815143056.A31621@iguana.icir.org> References: <20020815121002.D30190@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Thu, Aug 15, 2002 at 02:03:45PM -0700 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 Thu, Aug 15, 2002 at 02:03:45PM -0700, Julian Elischer wrote: ... > > So, i do _not_ want a protocol-specific bit because the info i need > > is not protocol-specific and goes to a non-protocol-specific module. > > how does ipfw2 connect with appletalk? > it really IS a protocol specific hack.. yes it does. From the manpage: ipfw can be invoked from multiple places in the protocol stack, under control of several system parameters, and it is important to understand when this occurs in order to design a proper ruleset. The places where ipfw is invoked are listed below, together with the sysctl variables which control its invocation. ^ to upper layers V | | +----------->-----------+ ^ V [ip_input] [ip_output] net.inet.ip.fw.enable=1 | | ^ V [ether_demux] [ether_output_frame] net.link.ether.ipfw=1 | | +-->--[bdg_forward]-->--+ net.link.ether.bridge_ipfw=1 ^ V | to devices | and also The general rule body format is one of the following: proto from src to dst [options] MAC dst-mac src-mac [mac-type] [from src to dst] [options] where fields have the following meaning: Mostly, ipfw2 is designed so that you can add protocol-specific checks. MAC header filtering is only the first one after IPv4; i suppose soon we will have ipv6, and then maybe pppoe. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 15 19:10:16 2002 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 DD7E537B400 for ; Thu, 15 Aug 2002 19:10:15 -0700 (PDT) Received: from rshb.com.ru (rshb.com.ru [195.162.58.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5494A43E4A for ; Thu, 15 Aug 2002 19:10:15 -0700 (PDT) (envelope-from admin@rshb.com.ru) Received: by rshb.com.ru (Sendmail for UK-NC RT11-SJ, from userid 426) id 9875821147; Fri, 16 Aug 2002 09:10:13 +0700 (OMSST) Received: from rshb.com.ru (vampiro.rsb.local [192.168.1.111]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Evgueni V. Gavrilov", Issuer "RSHB Omsk branch CA" (verified OK)) by rshb.com.ru (Sendmail for UK-NC RT11-SJ) with ESMTP id 7E0C021144 for ; Fri, 16 Aug 2002 09:10:13 +0700 (OMSST) Message-ID: <3D5C5F04.9080504@rshb.com.ru> Date: Fri, 16 Aug 2002 09:10:12 +0700 From: "Evgueni V. Gavrilov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020813 X-Accept-Language: ru, en MIME-Version: 1.0 To: ipfw@FreeBSD.ORG Subject: Re: IPFW2 segfaults References: <3D5BB907.2070609@rshb.com.ru> <20020815092825.A29716@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Luigi Rizzo wrote: > are you sure you recompiled /sbin/ipfw and /usr/lib/libalias with > -DIFPW2 ? Sorry, I forgot to do that. *8-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message