Date: Wed, 1 Dec 2004 08:23:39 -0500 From: Josh Kayse <josh.kayse@gmail.com> To: yongari@kt-is.co.kr Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD bridge + filtering, BIG problem Message-ID: <7c8f27920412010523730447de@mail.gmail.com> In-Reply-To: <20041201110912.GA9840@kt-is.co.kr> References: <20041201045203.262D443D5C@mx1.FreeBSD.org> <20041201110912.GA9840@kt-is.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 1 Dec 2004 20:09:12 +0900, Pyun YongHyeon <yongari@kt-is.co.kr> wrote: > On Wed, Dec 01, 2004 at 05:51:35AM +0100, Cl?ment MOULIN wrote: > > > > Hi, > > > > I'm afraid about having find a freebsd 5X security issue. > > > > We have recently upgraded one gateway from 4.10 to 5.3... Following network > > used: > > > > [ISP]--xl1--[FW01]-----xl0--em0--[SR01] > > | > > |--fxp0--em0--[SR02] > > > > On fw01, we have one jail. > > > > So fw01 is configured as a bridge on xl1,xl0,fxp0. Services works (before > > and after upgrade). > > On 4.10, we used IPFilter as firewall and for network traffic accounting. > > Since upgrade, INCOMING traffic accounting does not work anymore (OUTGOING > > working fine)... > > > > Thinking this can be a ipfilter issue, and because we are planning to change > > for great OpenBSD pf, we have try to do accounting with pf... but same > > behaviour occurs (tests have be done with big files). > > > > From/to inet fw01 jail sr01 sr02 > > Internet - ok ok KO KO > > Fw01 ok - ok ok ok > > Jail ok ok - ok ok > > Sr01 KO* ok ok - KO > > Sr02 KO* ok ok KO - > > > > * with pf enabled, scp connexion going "stalled" very quickly (stop between > > 100 and 300 Kb of traffic) > > > > > > Worst thing, the "default rule" accounting (any to any) does not report > > "unreported" traffic... feels like rules are not processed. So I deciding to > > make another test with pf. > > > > Adding "block in quick proto tcp from any to [jail_port] port smtp"; > > Testing: works fine. > > But we the same rule with the sr01 as destination host, IT DOESN'T WORK: > > from internet, fw01 or sr02, we can connect to the tcp port > > !!!!!!!!!!!!!!!!! It's not pf related, because, same behaviour occurs with > > IPF!!!!!!!! > > > > > > > > Details > > fw01: running FreeBSD 5.3, GENERIC kernel, with modules = acpi, ipl, bridge, > > nullfs and pf. > > Sr01: FreeBSD 5.2.1, custom kernel > > Sr02: FreeBSD 5.3, GENERIC kernel > > > > ------------------------------------pf.conf > > set loginterface fxp1 > > > > jail=**IP** > > sr01=**IP** > > sr02=**IP** > > > > #block in quick proto tcp from any to $sr01 port smtp > > > > pass quick from any to $jail keep state label 0 > > pass quick from $jail to any keep state label 1 > > pass quick from any to $sr02 keep state label 6 > > pass quick from $sr02 to any keep state label 7 > > pass quick from any to $sr01 keep state label 10 > > pass quick from $sr01 to any keep state label 11 > > > > pass all > > ------------------------------------ > > > > > > Seems to be bridge freebsd 5.3 support related... > > Can someone take a look at this? Thanks! > > > > Both pf and ipf can't create *states* in bridge mode. That restriction > comes from bridge(4). Since pf/ipf couldn't create states it will > drop the packet when it thinks the packet is in out of TCP window. > > If you want to use pf/ipf in bridge mode, don't use stateful inspection. > One more note: filtering works only for inbound traffics in bridge mode. > > -- > Regards, > Pyun YongHyeon > http://www.kr.freebsd.org/~yongari | yongari@freebsd.org > > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > I know it's been touched on in the past, but can you explain why stateful inspection does not work in a bridged mode? And why it only filters for inbound traffic? Does ipfw suffer from the same feature? Thanks. -josh -- Joshua Kayse Computer Engineering
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7c8f27920412010523730447de>