>    Andrew> i'll grant you that, but it's still much harder to break a proxy so
>    Andrew> that it accidentally forwards every connection attempt.  packet
>    Andrew> filters can be easily broken (by clueless personnel) such that they
>    Andrew> *do* forward too much.
>
>  Yes, I agree completely. However, they promote NAT (BlackHole was the
>first proxy based firewall that gave you option not to do NAT), and they
>totally kill IPsec. I've repented, since I like IPsec more than I like
>proxies :-)

maybe i'm not understanding your position...but you seem to advocating
proxied services.  with proxied services, nat is not necessary; with
filtered forwarding, it may be (for, eg, load balancing ala local
director).

as for nat, i *don't* promote nat.  it breaks *anything* that expects
to be able to look at the remote (or even local in some cases) address
and use it in the protocol (eg, ftp, dcc, and in another way, dnssec).

>    Andrew> your rules are supposed to distinguish between what needs to local and
>    Andrew> what needs to be forwarded.  i thought that was the idea...
>
>  Yes, they do. it is a pain.
>
>  I want to write a rule for inbound and outbound connections (at the UDP/TCP
>layer... they already have all the state that they need), and seperate
>stateful rules for each possible forwarding direction. 

what i've done in the past is write separate rules for inbound
connection attempts (and udp transactions) all with "keep state" and
then then a rule that allows tcp (and udp) out with "keep state",
thereby keeping everything flowing nicely, but keeping out (and
tracking) anything i don't want.

then again...i've only been using ipf for about two weeks.  if i'm
wrong in my assumptions, please correct me.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."