|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Adrian Buxton (adrian.buxton
team.ozemail.com.au)Date: Fri Jun 21 2002 - 22:18:05 CDT
> -----Original Message-----
> From: Robert Schwartz [mailto:robert
mrsquirrel.com]
> Sent: Saturday, 22 June 2002 1:19 AM
> To: 'Adrian Buxton'; 'Daniel Hartmeier'
> Cc: misc
openbsd.org
> Subject: Re: PF gateway problems.. return traffic blocked
> (but not if in N AT m ode!)
>
>
> > -----Original Message-----
> > From: owner-misc
openbsd.org [mailto:owner-misc
openbsd.org]
> > On Behalf Of Adrian Buxton
> > Sent: Friday, June 21, 2002 1:35 AM
> > To: 'Daniel Hartmeier'
> > Cc: 'misc
openbsd.org'
> > Subject: Re: PF gateway problems.. return traffic blocked
> > (but not if in N AT m ode!)
> >
> [snip]
> > This also means that the HOWTO document has a bogus
> > demonstration ruleset.
> [snip]
>
> The problem was your "default block" rule as Daniel pointed
> out, not the
> FAQ:
I was not referring to the FAQ on the OpenBSD site. I was referring to
the HOWTO document linked off the pf homepage.
http://www.inebriated.demon.nl/pf-howto/html/node3.html#SECTION000310000
000000000000
> (from your first email)
> # block anything not matching
> block in log quick from any to any
> block out log quick from any to any
>
> (from one of Daniel's responses)
> "> So, this means I have to keep state on the external interface else
> the
> > return traffic is dropped?
> If you have a default block on both interfaces, yes.
> Daniel"
>
> So yes, you'll have to create state on all interfaces you
> want to create
> default block filters on. The default ruleset clearly states:
>
> (from the PF FAQ "putting it all together as per your email)
> "# by default, block all incoming packets, except those explicitly
> # allowed by further rules
> block in on $ExtIF all"
>
> So the example ruleset has a much more conventional block in
> on $ExtIF,
> requiring state to be kept on only one interface, which is a "germain"
> example, not a "bogus" example.
>
Again this refers to a differing document.
> In your example to get the kind of fine-grain control that
> lets you have
> "egress and ingress" filtering, you can block in on $ext and block out
> on $ext. In a 2 nic setup this should work the same as block
> in on $ext
> and block out on $int.
>
Yes. The bit I was missing was that states are interface specific. The
reason it was working for NAT is because of a rule I had to permit
traffic from $ext_if on $ext_it to any keep state, which originally I
setup to allow the f/w gateway to go anywhere.
> If you have more then 2 nics and you have three different security
> policies to enforce then you'll need these bigger state
> tables you were
> talking about, but with only 2 nic's it's fine to move the
> egree filter
> to the external nic as well as the ingress filter.
>
The system will have about 4 nics. I'll have to try and determine what
ruleset will allow me to maintain strict control over what enters the
firewall system, as well allow traffic between all networks. Hopefully
without multiple keep state rules.
Cheers,
Adrian.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]