On Tue, Jun 21, 2005 at 08:23:49PM -0400, Jason Dixon wrote:
> On Jun 21, 2005, at 6:24 PM, Bill Swisher wrote:
> 
> >After reading over the pf-faq.pdf file I have, at this time, one 
> >question.  The home/small office example assumes that the internet 
> >lives off of "ep0".  In my case this is partially true.  What really 
> >is there is a router running on the network 192.168.2.* (my internal 
> >network is the standard 192.168.1.*) and if I use the command "block 
> >drop in quick on $ext if from $priv_nets" and it's corresponding 
> >output block I'd pretty much be sitting deaf and mute, as far as the 
> >rest of the computing world goes near as I can figure.
> >
> >I like that router!  It does the PPoE for me, along with minimal 
> >blocking.  I don't want to toss it.
> >
> >Anyone have a way around this?
> 
> priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 
> !192.168.2.0/24 }"

i'm certainly missing something here, as i am somewhat new-ish to pf
(long time with ipf, though)...

the above macro definition of priv_nets will create the rules:

  block drop in quick on ep0 inet from 127.0.0.0/8 to any
  block drop in quick on ep0 inet from 192.168.0.0/16 to any
  block drop in quick on ep0 inet from 172.16.0.0/12 to any
  block drop in quick on ep0 inet from 10.0.0.0/8 to any
  block drop in quick on ep0 inet from ! 192.168.2.0/24 to any

where the second rule will drop traffic from 192.168.2.0/24, and the
fifth rule will effectively drop all other traffic.

in my experience--lists of networks/IP's that need to be negated always
seem to need to go in a table to work properly.  now i never tried this
before, but i just tested it (on 3.7-release), and it appears to work
(tables *really* kick ass):

  ext_if = "ep0"
  table <private> const \
        { 127/8, 10/8, 172.16/12, 192.168/16, !192.168.2/24 }
  block drop in quick on $ext_if from <private>

with that--traffic from the RFC1918 space plus the loopback net (*) gets
dropped, but 192.168.2.0/24 gets to the next rule.

HTH...

-j

(*) i'm pretty sure that the openbsd routing code drops traffic from
127/8 received "on the wire" before pf ever sees it--so the inclusion of
127/8 in the table is not strictly necessary.

--
"Stewie: Damn you, vile woman, you've impeded my work since the day I
 escaped your wretched womb."
        --Family Guy

Reply via email to