> On Thu, 24 Jun 2004, Mitch (WebCob) wrote:
> > I wonder if that doesn't exist already (nmbd from samba?) or if
> it couldn't
> > be added as a configurable module - SMB Network Browse Master -
> not a samba
> > server, but just the name browser functionality - configured to
> peer with
> > selective vpn endpoints - would solve things wouldn't it?
> Samba's nmbd is sufficient for WINS service but not browsing. The latter
> is based on SMB datagram service, which is provided by smbd, not
> nmbd. And even nmbd isn't exactly tiny.
The notes on openvpn.org indicate that browsing is supported by a wins
server (see faw below) but I don't know, and haven't tried it - I'm not
arguing with you... still, that could de done as well, set up smbd as a
master browser, and link to another at the other side of the tunnel.
> On Sun, 27 Jun 2004, Mitch (WebCob) wrote:
> > This is a problem with netbios broadcast packets not being
> passed over the
> > VPN.
> > There has been some discussion about a module for openvpn,
> which might help,
> > and also running nmbd from samba on both sides of the link and
> > them to communicate somehow?
> I don't see how the type of VPN would affect this, unless OpenVPN *also*
> includes some extra stuff for NetBIOS over and above the VPN capability.
...This allows OpenVPN to route ethernet broadcasts and non-IP protocols
such as Windows NetBios over the VPN. ...
Broadcasts traverse the VPN -- this allows software that depends on LAN
broadcasts such as Windows NetBIOS file sharing and network neighborhood
browsing to work.
Clients must use a WINS server (such as samba) to allow cross-VPN network
browsing to work.
> > Haven't seen a solution.
> > Netgears and Linksys etc do it by allowing netbiod broadcast packets.
> > apparently this can't be done in freebsd.
> Subnet broadcasts can only target one subnet, so routing them between two
> subnets and having them appear as broadcasts on both is just
> plain wrong.
Again, I don't know better and won't argue with you, but it works. That's
what the end user cares about regardless of the semantics of implementation.
> It's legitimate to route a subnet broadcast *to* its destination subnet,
> but it would appear as a link-level unicast in any earlier hops. I do
> recall something about FreeBSD's being unwilling to handle the latter
> case, but I don't know if that can be changed by kernel option or by
> sysctl. I'd rather see them *not* blocked at that level, since one can
> always block them in the filter if desired.
Agreed, but I've heard many say it can't be... on the openvpn site there is
comment of a difference between a tun and a tap device... not sure if that
is the crux of the matter or not.