For Windows clients, I use a quick-and-dirty workaround for browsing over
the VPN.  I created a copy of lmhosts which has the machine addresses and
netbios names listed using the #PRE tag, and I distributed this file to each
pc that was going to be used off-site.  Then, when a VPN connection is
established, simply use "nbtstat -R" to reload the lmhosts file and you're
good to go.

Obviously, if you are in a large network, it could be a pain to build a
manual list like that, but most of the time, it is only a handful of
computers that you are trying to browse, and keeping a "master" file around
allows the clients to be updated more easily should you modify it.

Brian

----- Original Message ----- 
From: "Mitch (WebCob)" <mitch at webcob dot com>
To: "Fred Wright" <fw at well dot com>; <m0n0wall at lists dot m0n0 dot ch>
Sent: Sunday, June 27, 2004 9:47 PM
Subject: RE: [m0n0wall] NetBIOS Resolution over IPSEC/PPTP


> 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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>