From owner-freebsd-questions Fri May 28 16: 1:31 1999 Delivered-To: freebsd-questions@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id AD170150B1 for ; Fri, 28 May 1999 16:01:16 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.8/8.8.8) with ESMTP id QAA18448; Fri, 28 May 1999 16:01:08 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Fri, 28 May 1999 16:01:07 -0700 (PDT) From: Doug White To: Konstantinos.DRYLLERAKIS@DG21.cec.be Cc: freebsd-questions@FreeBSD.ORG Subject: Re: ipfw/natd limitation: controlling access of an unregistered net to the internet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ack. Please wrap your lines, thanks! On Fri, 28 May 1999 Konstantinos.DRYLLERAKIS@DG21.cec.be wrote: > The problem is that of connecting _and_ controlling a company net with > unregistered IP address to the Internet via a multi-homed FreeBSD box > using ipfw/natd. According to my understanding, all packets going > through the outer interface of the mutli-homed machine should be > diverted to natd as soon as possible. The problem appears to be that > outgoing packets (through the firewall) are first translated to the > firewall's IP address and _then_ further constrained by the firewall > rules. This gives ALL internal machines the same "access privileges" > to the internet as the firewall machine. For incoming packets this is > simpler since they are first translated back to the real target and > then passed through the firewall so you can control them by target IP > address. I should write something up on this. It is totally unnecessary to use any sort of packet filtering with NAT and still have a secure network. The reason is that natd will not permit traffic from the outside world into the private network unless it is associated with an existing data stream. This makes for a very, very effective firewall. If you're creative with your 'via', 'in', and 'out' keywords you can control this, but for most circumstances you do not need firewall rules beyond the defaults provided by rc.conf. Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message