Date: Mon, 27 Feb 2006 09:53:04 GMT From: Darren Reed <darrenr@FreeBSD.org> To: devteam@donut.ugcs.caltech.edu Cc: freebsd-bugs@FreeBSD.org, spartak@aif.ru, keramida@freebsd.org Subject: Re: kern/79416 Message-ID: <200602270953.k1R9r4rv042059@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
IPFilter now converts a "pass" rule into a block if, during processing the packet, it decides that it has the final matching rule but something else happens that means some sort of assumption about the packet being passed is bad. That "something else" might be a NAT proxy decided it wants the packet to be dropped or adding state fails with a rule that isn't "quick". I believe what was happening here is that in earlier versions of ipfilter 4.1 than 4.1.10, it would see that state couldn't be added (at the end of rule processing) and drop the packet - even with "quick" rules. Now, if "keep state" fails for a packet on a "quick" rule, the failure to add state becomes a reason to treat the packet as not matching the rule and we go to the next filter rule. In FreeBSD prior to IPFilter 4.x, if state failed to be added then the packet would still be allowed through. What is the difference here? If the original packet is allowed through, say it is a TCP SYN packet and no state is created then a SYN-ACK will be received and consequently blocked because there is no state. This can be a bit puzzling and also fails to enforce session limits, like it should, without impacting the system "inside." My real concern with this bug report is that the block ICMP packet should have been matched by state and wasn't. Is that still reproducible with FreeBSD-current ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602270953.k1R9r4rv042059>