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.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Micheal
Sent: Wednesday, January 21, 2004 11:09 AM
To: [EMAIL PROTECTED]
Subject: Re: ipfw/nated stateful rules example
----- Original Message -----
From: "fbsd_user" <[EMAIL PROTECTED]>
To: "Jonathan Chen" <[EMAIL PROTECTED]>
Cc: "Micheal Patterson" <[EMAIL PROTECTED]>;
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)
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
> perform the nat function.
They also work if NAT is used. That's because keep-state monitors
of the packet and relies on that. So what you're telling me is that
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
than applying stateful to the true source of the traffic prior to
> As far as the question of using keep-state rules on both the
> and public interfaces this is cross population of the single
> stateful table and returning packets are being matched to entries
> the stateful table which do not belong to the interface the
> 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
with multiple networks. Regardless if you are running NAT or not, if
have 3 /24's behind your firewall, do you expect to secure them all
simply having stateful on the firewall's wan port? What keeps them
infiltrating each other? Don't make the assumption that all are
behind the firewall. You treat them as entirely separate networks
otherwise stated. Now, what's going to happen to your stateful table
It's going to be so cross populated with traffic from 762 other
that you'll not see straight.
TSG Network Administration
Confidentiality Notice: This e-mail message, including any
for the sole use of the intended recipient(s) and may contain
and privileged information. Any unauthorized review, use, disclosure
distribution is prohibited. If you are not the intended recipient,
contact the sender by reply e-mail and destroy all copies of the
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"