From owner-freebsd-net@FreeBSD.ORG Wed Aug 1 15:47:58 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72A6716A41B for ; Wed, 1 Aug 2007 15:47:58 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.119.58.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0638613C461 for ; Wed, 1 Aug 2007 15:47:57 +0000 (UTC) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id JAA07328; Wed, 1 Aug 2007 09:47:53 -0600 (MDT) Message-Id: <200708011547.JAA07328@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 01 Aug 2007 09:47:39 -0600 To: Julian Elischer From: Brett Glass In-Reply-To: <46B02341.9010803@elischer.org> References: <200708010219.UAA24373@lariat.net> <46B02341.9010803@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Creating a "non-bridge" 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: Wed, 01 Aug 2007 15:47:58 -0000 At 12:08 AM 8/1/2007, Julian Elischer wrote: >possibly you could just bridge them together but use ipfw on the bridge to enforce isolation. Will IPFW block ARP? IPX? Other protocols which may be either demultiplexed or "teed" within the network stack? >OR you could possibly make a netgraph version of that.. Possibly. It could be a mutation of your ng_bridge node, or a configuration option for the existing one. The man page suggests that you can connect the ng_bridge node to the raw Ethernet interfaces and present a pseudo-interface to the BSD TCP/IP stack, which means that it would be none the wiser. The disadvantage of this approach is that the routing table could not be used to figure out which interface each downstream client was on; that overhead would fall to the netgraph node. >you can't really avoid the promiscuous mode part if you use bridging... Ah, but we're not really bridging. We only accept packets that are for us. What we're really doing is giving two interfaces the same IP address and subnet mask and keeping track of which peers are on which interface. We also need to make sure that we can ARP properly. Our ARP broadcasts for that subnet need to go out of both interfaces but we do not want to pass ARP packets between them. There IS an advantage to being able to respond to ARP queries from one interface about IP addresses that are used on the other, though, because it allows OSes like Windows (which ARP their own addresses before using them) to detect conflicts and back off before causing confusion. But none of this requires promiscuous mode, because (again) you are only accepting packets for yourself. So, the hardware can do the work of rejecting packets that aren't for you. >A specific netgraph configuration might be able to do it but it's need some work. You mean, using ng_bpf nodes, ng_tee nodes, and other plumbing? Perhaps, but how would outgoing packets be sorted to the right interface? >Another possibility is to use freebsd 4 and apply the vimage patches to make 3 virtual machines. >(or 7.0 and use the current vimage patches that Marko has brewing up in perforce) Maybe. I am going to try several tactics at once. First, I'm going to try the "PRIVATE" option in bridge(4). If it works, it should be possible to patch the code take the interfaces on which this option is set out of promiscuous mode unless it's needed for tcpdump or a similar network sniffer. (Andrew, would it be possible to look into committing this as a change?) I'm also going to experiment with patches to ng_bridge and see what I can cobble together. (I do not do much with netgraph, so there will be a learning curve.) I'll reserve virtual machines as a last resort due to the overhead. --Brett