Date: Thu, 15 Aug 2002 00:34:22 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed Message-ID: <20020815003422.A24887@iguana.icir.org> In-Reply-To: <3D5B547A.E29F61BA@mindspring.com>; from tlambert2@mindspring.com on Thu, Aug 15, 2002 at 12:12:58AM -0700 References: <20020815000720.B24495@iguana.icir.org> <3D5B547A.E29F61BA@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815003422.A24887>