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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Micheal Patterson 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]>; <[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) 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. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"