ipfw/nated stateful rules example

[fbsd_user]

You do what ever you want.  But typically the private LANS are
considered secure and only the interface facing the public internet
needs stateful processing.  What you are doing is an waste of
resources  and corrupts the stateful table no matter what you think.

But the fact still remains that stateful processing on only the
public facing interface with divert/nated does not work period.

I an finished with this subject. I have made me case  and nobody has
been able to prove otherwise.

Hope the ipfw2 maint team members have been reading this thread and
do something to correct this problem, like copy the ipnat code and
make it their own so it works with ipfw2.

As an side note, I do not use ipfw1 or ipfw 2, I now use IPFILTER
because it does not have this problem and I want an software
solution that provides the MAX  protection which ipfw does not.

-----Original Message-----
From: owner-freebsd-questions at freebsd.org
[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Micheal
Patterson
Sent: Wednesday, January 21, 2004 11:09 AM
To: freebsd-questions at freebsd.org
Subject: Re: ipfw/nated stateful rules example


----- Original Message -----
From: "fbsd_user" <fbsd_user at a1poweruser.com>
To: "Jonathan Chen" <jonc at chen.org.nz>
Cc: "Micheal Patterson" <micheal at tsgincorporated.com>;
<freebsd-questions at freebsd.org>
Sent: Wednesday, January 21, 2004 7:29 AM
Subject: RE: ipfw/nated stateful rules example


> You must have missed reading some parts of the thread. The problem
> is not whether you just do keep-state on the public side or the
> private side, it's with doing keep-state on both sides at the same
> time from within ipfw along with using divert statement.

If you have multiple lans (which in effect you do in my situation)
you
state inspect traffic into and out of each network.

> The stated problem is
> ipfw1 and ipfw2 does not work when keep-state rules are used on an
> single interface along with divert/nated.
> They do work if divert/nated is not used and user ppp nat is used
to
> perform the nat function.

They also work if NAT is used. That's because keep-state monitors
the source
of the packet and relies on that.  So what you're telling me is that
you'd
prefer a masqueraded IP to be the source for all of your stateful
inspections instead of the true tcp source? And you feel that is
more secure
than applying stateful to the true source of the traffic prior to
network
translation?

 > As far as the question of using keep-state rules on both the
private
> and public interfaces this is cross population of the single
> stateful table and returning packets are being matched to entries
in
> the stateful table which do not belong to the interface the
original
> enter was posted from. This is an logic error and invalidates the
> function of the purpose of the whole stateful concept.

It's not cross population of the stateful table. It's how stateful
works
with multiple networks. Regardless if you are running NAT or not, if
you
have 3 /24's behind your firewall, do you expect to secure them all
by
simply having stateful on the firewall's wan port? What keeps them
from
infiltrating each other? Don't make the assumption that all are
welcome
behind the firewall. You treat them as entirely separate networks
unless
otherwise stated. Now, what's going to happen to your stateful table
then?
It's going to be so cross populated with traffic from 762 other
systems
that you'll not see straight.

--

Micheal Patterson
TSG Network Administration
405-917-0600

Confidentiality Notice:  This e-mail message, including any
attachments, is
for the sole use of the intended recipient(s) and may contain
confidential
and privileged information. Any unauthorized review, use, disclosure
or
distribution is prohibited. If you are not the intended recipient,
please
contact the sender by reply e-mail and destroy all copies of the
original
message.

_______________________________________________
freebsd-questions at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribe at freebsd.org"