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 following files must be edited:
The configuration of the nbfw is done in the smb.conf. The following parameters are needed for proper operation of nbfw:
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:
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.
The most common configuration is something like this:
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:
On the second gateway the configuration will be something like this:
Note the value of nbfw deny hosts parameter. Also note the nbfw backend hosts parameters MUST contain different IP addresses.
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:
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:
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:
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:
The lmhosts file should contain the names of the backend machines which are reachable from the outside network. This will speed up connections made from the outside to a backend machine.
If we look at the first example above the lmhosts file would be:
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.
If you want your backend machines to be reachable from the outside you must compile a kernel with ipportfw support. For 2.0.3x kernels this great patch can be obtained from http://www.ox.compsoc.org.uk/~steve/portforwarding.html or http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html.
Note the patches for the 2.0.27-29 kernels won't work correctly. It's recommended to use at least a 2.0.33 kernel.
Installation of the nbfw patch is quite simple. Assuming you have the Samba sources in /usr/src/samba-2.2.0/ and extracted the patch to /tmp/nbfw-0.39 do:
Three new files will be created and several will be patched. Now look for *.rej files. If there are none you can go ahead and run the Samba configure script.
Edit the Makefile if necessary and compile Samba. Some extra executables are created: smbdnbfw and nmbdnbfw. The smbd and nmbd executables are just the plain standard executables.
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:
Note the wins forwarding code is virtually untested ...
The configuration of the backend hosts is quite simple: Make sure the backend hosts are in the same workgroup as the firewall and if you use WINS use the same wins-server.
nbfw has been tested with the following operating systems:
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.
Run these to get these features:
The old ones have been fixed at this moment. If you find one, please submit it to email@example.com.