bridging tapX interfaces only

[spambait701 at telus.net]

I have been trying to create an isolated virtual LAN with the following 
configuration. A single FreeBSD v4.10 server with one physical NIC (fxp0) 
is connected to two remote client Windows XP machines via OpenVPN tunnels. 
OpenVPN v1.6 on the server and v2.0 on the clients. There are therefore two 
virtual ethernet devices, tap0 and tap1, active on the server. tap0 is 
assigned an IP address, but tap1 is not. Each client is assigned an IP 
address - all three machines are in the same subnet, which is different 
from any other subnets these machines may be exposed to. I then use 
bridge(4) to bridge tap0 and tap1. Note that I do not include fxp0 in the 
bridge. Neither client Windows machine bridges its tap device to its 
physical NIC. None of the machines enable packet forwarding or routing 
between the virtual LAN and any other LAN. The result is an isolated 
virtual LAN on which there are three hosts: the server and two clients.

The FreeBSD server is running two independent Samba services, one bound to 
the fxp0 interface only and the other bound to the tap0 IP address only. 
The fxp0 Samba serves a local physical LAN and the tap0 Samba serves the 
virtual LAN. Neither the FreeBSD server nor the client machines are 
screening their connections to the virtual LAN with software firewalls.

The result is a fully functional virtual LAN with one nagging problem I 
cannot solve. The two client machines can use the Network Neighborhood to 
browse to each other without problem. The clients' users can also specify 
the hosts by NetBIOS name. The client connected to tap0 can browse to the 
Samba server without problem, or visit by NetBIOS name. The client 
connected to tap1, however, cannot browse to the Samba server, nor access 
it by NetBIOS name. If the tap1 client uses IP addresses to access the 
Samba server, everything works fine, so that makes it an nmbd-related issue.

With the aid of ethereal, tcpdump, netcat, and Samba logs (at high 
verbosity levels) I have done enough experiments to learn the following. 
Both the clients see all broadcast packets sent by any of the three 
machines. The server sees all broadcast packets from the tap0 client. The 
tap1 client sees broadcast packets from the server. But,... although 
tcpdump sniffing either tap0 or tap1 sees broadcast packets from the tap1 
client, Samba's nmbd daemon never sees those packets. I have ruled out 
Samba as the culprit by using netcat to send and receive broadcast packets 
instead, and found that netcat has the same problem as Samba's nmbd daemon. 
Since the nmbd daemon never sees broadcasts, it does not receive name 
queries from the tap1 client which kills NetBIOS browse/name functionality.

If I move the server's virtual LAN IP address from tap0 to tap1, the 
problem is moved from the tap1 client to the tap0 client. Thus, I conclude 
it is not a client issue. Since the two clients can see each other's 
broadcast packets as well as those from the server, I believe this rules 
out OpenVPN as the culprit. It seems to me that this leaves the fault with 
either bridge(4) or the tap device driver. I do not want, nor does it seem 
possible or even useful, to assign an IP address to both tap0 and tap1.

Despite scouring the 'Net as well as FreeBSD, OpenVPN, and Samba mailing 
lists, I have found no references to anyone attempting something like my 
configuration. In the most similar cases, the bridge always includes at 
least one physical NIC with either no IP address in the bridge or with the 
address assigned to the physical NIC.

Can anyone help me with this problem? It smells like a bug, but perhaps 
I've misunderstood something somewhere.

Carl