Creating a "non-bridge"

Brett Glass brett at lariat.net
Wed Aug 1 15:47:58 UTC 2007


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



More information about the freebsd-net mailing list