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.

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.

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.

-----Original Message-----
From: Jonathan Chen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 21, 2004 12:20 AM
To: fbsd_user
Cc: Micheal Patterson; [EMAIL PROTECTED]
Subject: Re: ipfw/nated stateful rules example

On Tue, Jan 20, 2004 at 09:18:27PM -0500, fbsd_user wrote:
> Yes you are making it work, but not work
> correctly. In the true security sense, this is un-secure and
> invalidates the whole purpose of using keep-state rules at all.
> would never be allowed by an real firewall security professional.

I'm curious as to why you'd consider it insecure. How would applying
the keep-state rules on the public IP be anymore secure that using
on the internal IP? The mechanism works the same regardless. You
haven't provided an case as to why you think it is unsecure.
Jonathan Chen <[EMAIL PROTECTED]>
                                Don't worry about avoiding
                            as you grow older, it starts avoiding

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to