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.

1. Configuration
2. Installation of the ipportfw patch
3. Installation of the nbfw patch
4. WINS and nbfw
5. Configuration of backend hosts
6. Running nbfw
7. Verify if nbfw is working correctly
8. Known limitations
9. Known bugs

1 - Configuration

The following files must be edited:

1. /usr/local/samba/lib/smb.conf
2. /usr/local/samba/lib/lmhosts

1.1 - smb.conf

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:

1. nbfw will be much more robust.
2. nbfw will use less CPU-time.
3. 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.

Example

The most common configuration is something like this:

interfaces = x.y.123.123/16 192.168.1.1/24
nbfw backend hosts = 192.168.1.2 192.168.1.3
nbfw deny hosts =
nbfw netbios names = MY-WORKGROUP BACKEND-2 "BACKEND 3" "USER 2" USER-3


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:

interfaces = x.y.123.123/16 192.168.1.1/24
nbfw backend hosts = 192.168.1.2 192.168.1.3
nbfw deny hosts = x.y.123.234
nbfw netbios names = MY-WORKGROUP BACKEND-2 "BACKEND 3" "USER 2" USER-3


On the second gateway the configuration will be something like this:

interfaces = x.y.123.234/16 192.168.1.21/24
nbfw backend hosts = 192.168.1.22
nbfw deny hosts = x.y.123.123
nbfw netbios names = MY-WORKGROUP BACKEND-22 USER-22


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:

lm announce = false
lm interval = 0
domain master = no
wins support = no
wins proxy = no
dns proxy = no


1.2 - lmhosts

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:

192.168.1.2 BACKEND-2
192.168.1.3 BACKEND-3


2 - Installation of the port forwarding patch

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.

3 - Installation of the nbfw patch

Installation of the nbfw patch is quite simple. Assuming you have the Samba sources in /usr/src/samba-2.0.4/ and extracted the patch to /tmp/nbfw-0.28 do:

cd /usr/src/samba-2.0.4/source/
patch -p0 < /tmp/nbfw-0.28/nbfw.diff


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.

4 - WINS and nbfw

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:

/sbin/ipfwadm -I -a accept -P udp -S <backend-subnet> \
  -D <wins-server-ip> 137 138 -r 0


Note the wins forwarding code is virtually untested ...

5 - Configuration of backend hosts

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:

• Windows NT 4.0.
  All the backend hosts of the people who are testing nbfw are running Windows NT, so NT should definitely work with nbfw.
• Windows 95 and Windows 98
  Windows 9x should work fine. My Windows 95 (a.k.a. Games) works ok.
• Linux
  Smbclient and nmblookup should work fine.

6 - Running nbfw

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:

7 - Verify if nbfw is working correctly

nmbdnbfw

1. Look up an outside host from your backend (nmblookup <host> or net view <host> or nbtstat -a <host>)
2. Lookup up your backend host from the outside. If you see a backend IP address, than it's not good. It should be the same as the IP address of your firewall.

smbdnbfw

1. Check with ipportfw -L if the redirections are correctly configured.
2. Connect to your backend host from the outside and connect to your firewall from the outside.

8 - Known limitations

• 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.
• NetBIOS aliases of the firewall are not supported at this moment.

9 - Known bugs

The old ones have been fixed at this moment. If you find one, please submit it to nbfw@malt-whisky.student.utwente.nl.