From owner-freebsd-stable Sun Jul 9 18:24:32 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail2.rdc3.on.home.com (mail2.rdc3.on.home.com [24.2.9.41]) by hub.freebsd.org (Postfix) with ESMTP id D5CA537C49A for ; Sun, 9 Jul 2000 18:24:10 -0700 (PDT) (envelope-from cwass99@home.com) Received: from tristan.net ([24.114.108.234]) by mail2.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000710012408.QIDP1114.mail2.rdc3.on.home.com@tristan.net> for ; Sun, 9 Jul 2000 18:24:08 -0700 Content-Length: 1791 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 09 Jul 2000 21:16:17 -0400 (EDT) From: Colin To: freebsd-stable@FreeBSD.ORG Subject: natd inconsistencies Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just finished setting up FreeBSD 4.0R with ipfw and natd and I've noticed either a discrepency between the actual functionality and the man page or a misunderstanding on my part. The man page recommends putting the divert rule as close to the beginning of the rule set as possible, and the default rule sets seem consistent with this. I noticed, though, that if I didn't put the rule "deny ip from 192.168.0.0/24 to any in recv ed1" before the divert rule nothing from my internal network (which just happens to be 192.168.0.0/24) would get through. I assume the prevent-spoofing rules for private networks rules would have the sam e issue depending on the internal network used. I also noticed several other default rules caused some problems. My first thought was that when natd rebuilt the header with the internal network addresses, it still showed as a packet arriving from the external network (which is why I moved the rule). Then I realized that shouldn't matter, as the source address should have been the external host that sent the packet, which could clearly not be in the 192,168.0.0/24 network (unless there are some serious router issues out there ;) I honestly have no clue why this would be the case. I'm working on a new rule set that seems both secure and reasonable for my type of situation which I assume will become ever more common. A private network running through a firewall and natd via [cable modem|*dsl] to the internet. The simple ruleset was completely unuseable (I couldn't connect doodle to squirt from the internal network) and the open approach was just silly. I'll post it here for comment in a day or two. In the interim, any comments on why natd and ipfw don't work the intuitive way would be appreciated. Cheers, Colin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message