From owner-freebsd-net@FreeBSD.ORG Fri Oct 24 13:22:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AD96106573D for ; Fri, 24 Oct 2008 13:22:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1C88FC36 for ; Fri, 24 Oct 2008 13:22:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTP id 8224D46B2A; Fri, 24 Oct 2008 09:22:18 -0400 (EDT) Date: Fri, 24 Oct 2008 14:22:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: tap devices ... restricting IP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 13:22:19 -0000 On Wed, 22 Oct 2008, Marc G. Fournier wrote: > Is it possible to assign an IP to a tap device, used by something like QEMU, > such that someone *inside* the QEMU environment can't modify? Or, if they > do modify their own IP, the network inside of QEMU will break, as the > internal IP doesn't match what is attached to tap? > > I'm not seeing anything to that effect in the tap manual, but the part > talking about 'control' seems to indicate that you can do this ... Use a firewall to prevent receiving packets over the interface from any IP other than the one you are willing to accept. Think of a tap interface as simply being a normal ethernet interface hung off a network to the VM and treat it that way in the rules -- for example, dropping IP from addresses other than the designated one when received from the tap interface. Robert N M Watson Computer Laboratory University of Cambridge