Samba nbfw

Installation

Contents

The order of presentation is intentional. Running nbfw badly
configured can and will cause havoc on your (and others') network.
If you have problems getting the normal Samba-distribution to work
don't even try nbfw: It will not work.

The configuration of the nbfw is done in the
smb.conf. The following parameters are needed for proper operation
of nbfw:

nbfw backend hosts
nbfw deny hosts
nbfw netbios names
interfaces

The first three parameters are added by nbfw, the fourth is
needed by Samba (and nbfw) to work with multiple interfaces.

nbfw backend hosts

Specify the IP addresses of the backend hosts you want to
forward for. If you specify a backend broadcast address nbfw will
forward for your backend network. If you want to be able to reach
your backend hosts for the outside you MUST specify the IP
addresses explicitely.

nbfw deny hosts

If you have more than one gateways from your backend network to
the outside you MUST add the other gateway's IP address to the
nbfw deny hosts parameter. Note you MUST use the nbfw deny hosts
parameter on ALL gateways.

nbfw netbios names

Specify the NetBIOS names of the backend hosts you want to
forward for. Note for browsing to work correctly you need to
specify at least the workgroup name and the workstation name. You
can use nmblookup -A <ip> to see which names the backend hosts
have registered.

You SHOULD use this option for 3 reasons:

nbfw will be much more robust.

nbfw will use less CPU-time.

nbfw will not flood your backend network with useless packets.

interfaces

Because your firewall has at least two interfaces you MUST use
the interfaces parameter. Otherwise Samba nor nbfw will work. nbfw
uses this parameter to determine which interface is your backend
interface.

This configuration enables forwarding for hosts 192.168.1.2 and
192.168.1.3 which are in workgroup "MY WORKGROUP" and have
netbiosnames BACKEND-2 and BACKEND-3 respectively. USER-2 and
USER-3 are the user names used on those backend hosts. If you want
to send popup messages to users you have to specify the usernames
here.

Another case is if you have 2 gateways to the outside. The
configuration will look like this on the first gateway:

Note the value of nbfw deny hosts parameter. Also note the nbfw
backend hosts parameters MUST contain different IP addresses.

Other parameters

There're some more parameters in the smb.conf file,
which should be edited in order for nbfw to work properly. If you
want to use the smbdnbfw which enabled full access from the
outside to your backend machines it's recommended you change the
name resolve option to:

name resolve order = lmhosts bcast

Another limitation is the master browser. Backend machines may not be
master browser. If a backend machine is master browser browsing the
workgroup from the outside network will most likely fail and give name
conflicts.

Note the election code in Samba has some problems. In my case both Samba
and NT thought they won the election for master browser... The nbfw patch
provides some workarounds (often called 'hacks' ;) which should make Samba
behave exactly like a NT machine. Using nbfw makes elections even more
complicated.

There are several configuration options to get the elections working.
Which solution you should choose depends on the computers which are in your
workgroup and their configuration.

The ideal situation would be if the firewall is
always master browser of all of its subnets. If this can be
arranged you may want to add the following to your smb.conf:

os level = 40
local master = yes
preferred master = yes

If you have more than one computer with nbfw in your
workgroup only use the above settings on one computer only.
The other computers with nbfw must use the following settings:

os level = 0
local master = no
preferred master = no

In short: Your firewall has to be master browser on every
subnet OR your firewall has to be configured to never
participate in master browser elections at all.

So if your firewall is configured as master browser but it is
not, browsing will fail and you'll have to reconfigure your
firewall.

Some other options which speed up nbfw and/or reduce
network traffic are:

This is only necessary for Linux 2.0.3x kernels. Linux 2.2.x
kernels are capable of port forwarding without patching. NBfW
currently can currently only configure ipportfw and ipchains under
Linux. You can use other programs if you configure them manually.
Start smbdnbfw with debuglevel 2 and it will print the ports it
uses, and that must be forwarded.

nbfw versions 0.27 and above should be able to
forward to wins-servers. If you want to use this feature you must
have your firewall set up as a transparent proxy. Using ipfwadm
you should use something like this to configure your firewall to
redirect packets destined for the wins server to the local
samba:

Just like the normal Samba package nbfw consists of two
daemons: nmbdnbfw and smbdnbfw. The nmbdnbfw and smbdnbfw take the
same command parameters as their original counterparts, nmbd and
smbd respectively. Normally you'll want to run both nmbdnbfw and
smbdnbfw, but depending on your needs you don't have to.

smbdnbfw

Connecting to from the outside to a backend host will be
slower than a normal connection. Sometimes much slower :( But
once a session has been established all forwarding takes place
inside the kernel, which is fast and efficient.

If your NetBIOS implementation sends responses to the IP
address found in the data instead of the header [read: your
NetBIOS implementation is not (totally) RFC compliant] nbfw will
not work.