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