Browsing / nmbd issue with subnetting for VPN

Benjamin Carter bcarter at umr.edu
Sat Jul 29 20:37:48 GMT 2000


On Fri, Jul 28, 2000 at 04:48:15PM -0500, Christopher R. Hertel wrote:
> Right.  PPTP is a point-to-point protocol.  It's the conceptual equivalent
> to setting up a dial-up link.  As such, the "LAN" consists of two nodes: 
> the client and the server.  I believe that if you look at the routing
> table once you've set up a tunnel, the netmask will be something like
> FF.FF.FF.FC.  I don't know what happens if you change this.  More
> particularly, I don't know if the server will actually repeat NetBIOS
> broadcasts to other PPTP-connected nodes. 

I get a netmask of FF.FF.FF.00 on the Windows (client) side.  The only
other option for their VPN client is to set up a default route to the
other side (which I definitely do not want.)  I assume this is getting
picked up from the fact that it is a class-C network.

As far as the Linux machine is concerned, the netmask is FF.FF.FF.FF (it
recognizes it as a point-to-point link and the routing entry signifies
that it is for a single host rather than a network.)

> Also, note that you may need to do some tweaking to get NetBIOS to work.  
> The best bet is to bind NetBIOS to the PPTP interface *only*.  If you are 
> also doing sharing within your home or dorm, you'll suddently find that 
> you have a duel-homed host.  NetBIOS, and Windows in general, has been 
> known to have trouble in duel homed situations.

I do not think this will be a problem except in a case of namespace
collision, which is easy enough to rectify.

> As a member of the Networking Staff at a (different) University, make sure
> you check the Acceptable Use Policy before offering such services from a
> dorm room.  You can get in someone in big trouble (and there really is
> some rational thinking behind some of those policies).  (No, Really!)

Well, the individual in question is already running a web/ftp server
from his room, so I don't think an additional service that should peak
at 20-odd connections will be a big deal, he just has to consent to
another machine in his room.  :)  But that is a separate issue.

> Which server software are you using?

I am using the poptop server (it appears to be the only pptp server for
Linux, other than a modified version of Ananian's pptp client to act as
a server.)  I do not have any problems with the VPN portion (other than
messy logging; the server does not figure out that a link has been
terminated until it tries to write to it.)  I need to support Windows
clients, so the only other option would be third-party software on the
windows side to support IPSec or some other protocol.  Windows supports
PPTP natively [more or less].

> > with the
> > propagation delays, and the local netbios caches, I have to wait quite
> > some time before I know if my configuration changes even had any effect.
> >
> > However, I do know that browsing is my only problem; if I specify
> > \\computer-name in any of the connected clients, they can find that
> > machine.  Pings to the other servers work [the machine is configured to
> > forward packets between hosts on the vpn subnet], they register their
> > names with the WINS server, and all is well on that front.
> 
> I'm really curious to know if you can send broadcast messages at all.  If 
> you can, then this should work.  If not, then try the "Remote Announce" 
> option in smb.conf.  It's a kludge, but you might be able to get it to 
> send announcements to each of the other participants.
> 
> If you can't broadcast across the VLAN, then that's clearly why browsing
> doesn't work.  Browsing relies on broadcast.  If this guess is right, then
> each participating node will elect itself as Local Master Browser.  On 
> their own subnet (which, again, is probably a /30) they are.

Broadcast messages cannot go over a point-to-point link.  I believe [not
100% certain] that Windows figures this out; when I connect to the VPN
and pick up the WINS server, the client changes from B-node to H-node.
(see http://support.microsoft.com/support/kb/articles/Q119/4/93.asp)
Even though the routing on the client allows 192.168.2.255 as a
broadcast address, it will only end up talking to the other end of the
PPP link.

> Digging my hole of assumptions deeper, I mentioned the multi-homed host
> problems.  If I'm right about broadcasts, and if any of these nodes is
> also on a local Ethernet LAN and is doing NetBIOS there, well...  What 
> might happen is this:
> 
>   - The host may send a request for a Local Master Browser on the PPTP
>     interface.
>   - Finding none, the host will call for an election.
>   - The election request goes out all vLANAs (virtual LAN Adapters--an old
>     IBM term from the days of native NetBIOS).
>   - A syste on your local ethernet LAN, other than the host that called 
>     for the electon, wins the election.
>   - Kewl.  Now we can talk to an LMB, right?  So send a request for an 
>     LMB on the PPTP interface.  No reply because, of course, the LMB is 
>     out the *other* interface.
>   - So the host calls for another election.
> 
> This problem can also be seen if some hosts on a network have NetBIOS
> bound to more than one underlying protocol (NetBEUI, IP, IPX, whatever).

Hmm.  I had not considered that the clients might call for an election
over the VPN link.  However, as they _are_ broadcast-isolated (even if
they do not think so) I want them all to be treated as being on
different subnets; they can be LMBs if they desire, and then register
their list with the DMB (found via workgroup<1b> on the WINS server),
even if their list contains only themself.

Ideally, the windows clients should have a netmask of FF.FF.FF.FF
(unicast); but I believe if that were the case they would not correctly
route to other hosts on the VPN.  Part of the problem is that I do not
know how to control what Windows does to its routing table (or even if
it is possible to do so.)

> > But the problem I have is that I cannot figure out how to get nmbd to
> > consistently register itself as the DMB for this subnet without getting
> > into fights over browse mastering.  If I set 'bind interfaces only =
> > true', nmbd _still_ binds to IPADDR_ANY:netbios-ns, and I see in the
> > logs '192.168.112.180 thinks it is a master browser for workgroup
> > MY_WORGROUP, forcing election' [in this case 192.168.112.* is the subnet
> > I masquerade from and .180 is one of the hosts I am connecting to the
> > VPN with.]
> 
> Bingo!  "master browser" doesn't mean "Domain master browser".  Two
> different things. 

I understand the difference, but correct me if I am wrong - is it
possible to be DMB without also being a LMB?  I was under the impression
that this was not the case.  If it is possible to do so, that is
essentially what I want - I need the browse list collection, but I
cannot address the VPN through broadcast, so there is _no_ valid subnet
that I want nmbd to be the LMB for.  Essentially, it needs to be the
master of a dummy subnet containing just itself.

As far as the above is concerned, I was trying to make nmbd the LMB on
its own subnet.  The Linux box has multiple interfaces, going to
separate subnets.  I do not want any samba services present on the
interface to the masqeraded subnet.  I thought that the 'bind interfaces
only' option was supposed to address this, but it does not seem to be
working.  I ended up manually blocking the relevant ports with ipchains
firewall rules.

I will double-check on this, though - I think nmbd is supposed to bind
to 0.0.0.0:137 and 0.0.0.0:138 even with 'bind interfaces only = true',
and just ignore packets that do not match the 'interfaces =' line.
Perhaps it was a side effect of matching against the bcast/netmask that
were computed (see below).  It seems to me that the correct behaviour in
the situation above would be to recognize 192.168.112.180 as being the
LMB for a separate subnet (one that samba does not participate in
elections, although it does happen to have an interface on that
subnet.)

> > I also have problems with the interfaces line; nmbd seems to disbelieve
> > my subnet settings.  If I set interfaces=192.168.2.254/32, it tells me
> > 'bcast addr = 255.255.255.255, netmask=0.0.0.0' - this is obviously
> > incorrect.
> 
> Um, no.  /32 *is* bcast addr = 255.255.255.255, netmask=0.0.0.0  You 
> probably want /30.

Technically, shouldn't /32 imply a unicast address?  And it should be an
alias for a netmask of 255.255.255.255 (which is definitely NOT 0.0.0.0)
regardless of what is an appropriate broadcast address.

> > If I set interfaces=192.168.2.254/24, it tries to do a
> > broadcast for that subnet [which obviously cannot work - all the hosts
> > for that subnet are over point-to-point links and therefore unicast
> > only.]
> 
> Right, that's what I was thinking.  Now to the "COOL IDEA".
> 
> I've considered for a while what it would take to code up a "virtual 
> switch".  Basically, you'd have to modify the PPTP server code so that it 
> could handle broadcasts.

This would be one way of going about it.  Perhaps it would even be
appropriate for what I am trying to do.  The problem here is that the
PPTP server does not handle broadcasts - it just does handshaking and
encapsulation of the traffic.  The IP protocol layer is talking to the
PPP daemon on the other end, so that is what would need to be modified.

> > If I set it to 192.168.2.254/31, it still fights with the clients at
> > 192.168.2.1 over who is browse master for their subnet.
> 
> /31 won't work because that's only two addresses.  You need four.  Yes, 
> really.  You need:
> 
> - 192.168.2.0 = the network address.
> - 192.168.2.1 = the client address.
> - 192.168.2.2 = the server's PPTP interface.
> - 192.168.2.3 = the broadcast address.
> 
> Both ends of the connection should have an IP address so, even if the
> server's address is 192.168.2.254, each virtual interface on the server
> side should have its own address.  I don't know where to check this to
> see. 

I have all the virtual interfaces on the server side set to the same
address (192.168.2.254).  This address is not on any non-ppp interface.
I could use a different address for each instance of PPP, but I do not
see any advantage to doing so.

> > One other thing - I only want to run the WINS server, and collect browse
> > lists with this process, I am not interested in serving any files.  Is
> > there some way to convince nmbd not to register "netbios-name<20>", or
> > is simply not starting smbd sufficient to achieve this?
> 
> Simply not starting smbd.  You also want to set your machine up to be the 
> Domain Master Browser.  The DMB registers its name in WINS.  LMBs then 
> look up that name (they must all be in the same workgroup/domain) and 
> send updates to the DMB.  The DMB collects the lists and sends them back 
> to the LMBs.

I understand that not starting smbd prevents the file sharing - but I
was unsure whether smbd or nmbd was the process that registered the
server IP under "netbios-name<20>" which corresponds to the file and
print sharing service and has the effect of causing the computer name to
show up in the browse list.

In any case, the server string (comment) will not be found as IPC$ is
not being served if smbd is not running - this _probably_ prevents the
name from showing even if name<20> is registered.

> > One other note: when I configured 'dummy' to 192.168.200.254/24, and
> > told nmbd that was its subnet, things _almost_ worked... while the
> > workgroup<1b> name was still registered to 192.168.2.254.  The VPN
> > clients only get a route to 192.168.2.0/24, so they can't find the
> > domain master at 192.168.200.254.  (It appears I _have_ to put the nmbd
> > on 192.168.2.0 subnet, as I can't control the routes the VPN clients
> > get.)
> 
> The WINS server/DMB doesn't need to be on the same subnet.  Try getting 
> the DMB/LMB setup straightened out first.  Then see what problems remain.

No, but if it is located at 192.168.200.254, the VPN clients do not know
to route over the PPP link to get to the DMB.  I have to serve back an
address on 192.168.2.* or the clients will never be able to talk to the
DMB even if they have a link directly to one of its other IP addresses.

I realize that this is as much a routing issue as an issue with samba.
Routing table from the above-mentioned client, before connecting to the
VPN:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.112.254  192.168.112.180       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
    192.168.112.0    255.255.255.0  192.168.112.180  192.168.112.180       1
  192.168.112.180  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.112.255  255.255.255.255  192.168.112.180  192.168.112.180       1
        224.0.0.0        224.0.0.0  192.168.112.180  192.168.112.180       1
  255.255.255.255  255.255.255.255  192.168.112.180  192.168.112.180       1

After connecting:

  Network Address          Netmask  Gateway Address        Interface  Metric
          0.0.0.0          0.0.0.0  192.168.112.254  192.168.112.180       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
      192.168.2.0    255.255.255.0      192.168.2.2      192.168.2.2       1
      192.168.2.2  255.255.255.255        127.0.0.1        127.0.0.1       1
    192.168.112.0    255.255.255.0  192.168.112.180  192.168.112.180       1
  192.168.112.180  255.255.255.255        127.0.0.1        127.0.0.1       1
  192.168.112.254  255.255.255.255  192.168.112.180  192.168.112.180       1
  192.168.112.255  255.255.255.255  192.168.112.180  192.168.112.180       1
        224.0.0.0        224.0.0.0      192.168.2.2      192.168.2.2       1
        224.0.0.0        224.0.0.0  192.168.112.180  192.168.112.180       1
  255.255.255.255  255.255.255.255  192.168.112.180  192.168.112.180       1

-- 
-Ben Carter
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so. - Douglas Adams, "Last Chance to See" 




More information about the samba-technical mailing list