Hey Fred

> 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
> configuring
> > 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.

From http://openvpn.sourceforge.net/faq.html

...This allows OpenVPN to route ethernet broadcasts and non-IP protocols
such as Windows NetBios over the VPN. ...

Bridging advantages

Broadcasts traverse the VPN -- this allows software that depends on LAN
broadcasts such as Windows NetBIOS file sharing and network neighborhood
browsing to work.

Routing disadvantages

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.

m/