Date: Wed, 01 Aug 2007 09:47:39 -0600 From: Brett Glass <brett@lariat.net> To: Julian Elischer <julian@elischer.org> Cc: net@freebsd.org Subject: Re: Creating a "non-bridge" Message-ID: <200708011547.JAA07328@lariat.net> In-Reply-To: <46B02341.9010803@elischer.org> References: <200708010219.UAA24373@lariat.net> <46B02341.9010803@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708011547.JAA07328>