On Wed, Feb 25, 2009 at 04:39:08PM -0800, patrick keshishian wrote: > On Wed, Feb 25, 2009 at 4:07 PM, ropers <rop...@gmail.com> wrote: > > 2009/2/25 patrick keshishian <pkesh...@gmail.com>: > >> On Tue, Feb 24, 2009 at 9:48 PM, Hilco Wijbenga > >> <hilco.wijbe...@gmail.com> wrote: > >>> 2009/2/23 Jason Dixon <ja...@dixongroup.net>: > >>>> ########################################################## > >>>> 00 ext_if = "sk0" > >>>> 01 int_if = "sk1" > >>>> 02 > >>>> 03 set skip on lo > >>>> 04 > >>>> 05 scrub in > >>>> 06 > >>>> 07 nat on $ext_if from $int_if:network to any -> ($ext_if:0) > >>>> 08 > >>>> 09 block in log all > >>>> 10 pass in on $int_if inet keep state > >> > >> # I think you are missing a pass out on $ext_if rule > >> 11 pass out on $ext_if > >> > >> w/o 11 all inbound packets are blocked by 09. > > > > Please correct me it I'm wrong, but my understanding is that Jason's > > line 09 is only blocking packets that traverse interfaces in the > > *inward* direction (i.e. from the attached networks (WAN and LAN) > > *in*to the OpenBSD box). And I think that's why a "pass out" rule > > would be unnecessary, as the default is to pass packets. Again, take > > this with truckloads of salt; I could be wrong, but I trust Jason. > > You need states created for traffic passing through the pf firewall, > specifically through the $ext_if to allow packets flowing back in, > otherwise line 09 blocks those packets. I don't see where states would > get created for outbound traffic with Jason's rule-set.
Using floating states (the default), line 10 should suffice. But I forgot to account for outbound DNS requests from the firewall itself. Here is the same ruleset with the one extra rule. It shouldn't be necessary for outbound traffic originating from $int_if:network, but it won't hurt either. 00 ext_if = "sk0" 01 int_if = "sk1" 02 03 set skip on lo 04 05 scrub in 06 07 nat on $ext_if from $int_if:network to any -> ($ext_if:0) 08 09 block in log all 10 pass out 11 pass in on $int_if inet keep state P.S. Sorry for the late response, I hadn't noticed the additional replies. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
