From owner-freebsd-pf@FreeBSD.ORG Mon Jun 19 11:43:29 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96B2D16A479 for ; Mon, 19 Jun 2006 11:43:29 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ws2.infoweapons.com (ws2.infoweapons.com [58.71.34.134]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FBBE43D45 for ; Mon, 19 Jun 2006 11:43:28 +0000 (GMT) (envelope-from rmaglasang@infoweapons.com) Received: from [10.3.1.41] ([10.3.1.41] RDNS failed) by ws2.infoweapons.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 19:43:27 +0800 Message-ID: <44968D8C.5010606@infoweapons.com> Date: Mon, 19 Jun 2006 19:42:04 +0800 From: "Ronnel P. Maglasang" User-Agent: Thunderbird 1.5 (X11/20060613) MIME-Version: 1.0 To: Kian Mohageri References: <44960900.4000406@infoweapons.com> <44963DCA.8030800@infoweapons.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2006 11:43:27.0177 (UTC) FILETIME=[94291B90:01C69395] Cc: freebsd-pf@freebsd.org Subject: Re: outgoing LAN traffic always in "keep state" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 11:43:29 -0000 Kian Mohageri wrote: > On 6/18/06, *Ronnel P. Maglasang* > wrote: > > i have nat function enabled, also tried enabling rdr and > binat. are you > saying the "keep state" functionality depends on these 3? > > > > No, but translation rules create states according to pf.conf(5). > > " Note: nat, binat and rdr rules implicitly create state for > connections." > > Check out the 'state-policy' option (if-bound). I think it's what > you're looking for. i think the implementation and the documentation do not match well on this. i've looked at the PF online documentation in http://www.openbsd.org/faq/pf/nat.html and it says that translated packets still go to the ruleset evaluation. you're correct that nat and translation rules implicitly creates states, i can see the states with the 'pfctl -sa' command. what i'm looking for is the ability to configure PF such that reply packets for packets originated on the LAN or all packets arriving on the external interface go to the ruleset evaluation(for rules on the external interface) and match a rule, even if an state exist. the global run-time 'state-policy' option does not help, i've tried setting all the values. i think this is used on conjunction with the "keep state" enabled on a rule. one note, i observe that reply packets can match a rule(s) on the internal interface. > A few other things to mention. I'm pretty sure you can only have one > loginterface. I'd suggest making it your external one. > You can, instead of passing quick on lo0, just 'set skip on lo0' so pf > doesn't process those packets at all... > thanks for your suggestions on these. > -Kian > > here's my pf config file: > > # > # Aliases > # > loopback = "{ lo0 }" > lan = "{ em0 }" > wan = "{ vr0 }" > > #statistics > set loginterface em0 > set loginterface vr0 > > #optimize packets > set optimization normal > > #normalize outgoing packets IP ID field > scrub log on vr0 all random-id fragment reassemble > > # > # NAT on WAN interface (dont use IF alias for on the fly changes) > # > nat on $wan from 20.0.0.0/8 to any -> (vr0) > > # loopback > pass in quick on lo0 all > pass out quick on lo0 all > > # for ssh from 10.3.1.41 to 10.10.0.161 > > pass in log quick on $wan proto tcp from 10.3.1.41 > to 10.10.0.161 port 22 > pass out log quick on $wan proto tcp from 10.10.0.161 > port 22 to 10.3.1.41 > > # tcp from internal source to external dest > # note: response packet will not be evaluated against incoming wan > rules > pass in log quick on $lan proto tcp from 20.0.0.0/8 > to 10.3.2.19 > pass out log quick on $wan proto tcp from 10.10.0.161 > to 10.3.2.19 > pass in log quick on $wan proto tcp from 10.3.2.19 > to 10.10.0.161 > pass out log quick on $lan proto tcp from 10.3.2.19 > to any > > # > # default block > # > block in log quick all > block out log quick all > > > Kian Mohageri wrote: > > Post your ruleset and people can help you. You're probably using > > nat/rdr/binat which create states. > > > > -Kian > > > > On 6/18/06, *Ronnel P. Maglasang* < rmaglasang@infoweapons.com > > > >> wrote: > > > > I have a minimum PF setup that sits in between my internal > > network(lan) > > and external network(wan). PF by design, bypasses ruleset > > evaluation(on > > external interfaces) for incoming packets on external > interface that > > corresponds > > to an entry in the state table or a response to an internal > generated > > packet. > > I observe this for TCP, UDP and also ICMP packets. Even if the > > matching rule > > in the internal interface do not have a "keep state", still the > > response > > packet > > bypasses the ruleset evaluation. Is there a way (force) to allow > > response > > packets to go thru ruleset evaluation? I just want to have full > > control of > > the incoming packets on the external interface wether they are > > response to > > a LAN traffic or not. I'll be implementing queueing soon and I > > think this > > PF behavior will affect badly. Has anyone experienced this? > > > > Thanks a lot. > > - sho > > _______________________________________________ > > 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 > > > >" > > > > > >