Multiple Network Interfaces with Samba

Let's assume that we have a server with two network interfaces. Say that one interface, eth0 connects to the company network 10.0.0.0/8, and eth1 connects to 192.168.1.0/24, a small private network within the company. For one reason or another, we want shares exported by Samba to be available on the private network eth1, but not visible to the rest of the organisation via eth0. The machine in question is may be a firewall, gateway or plays some other sensitive role. In other configurations, you might want to avoid SMB connections over your PPP or wireless connection, for performance reasons.

The relevant smb.conf parameters here are both global parameters. They are interfaces and bind interfaces only. From the manual page for smb.conf, we find the following documentation:

(The two parameters kind of overlap a bit, I think. I don't see why it should be necessary to specify bind interfaces only if you have already specified something for the interfaces parameter. One implies the other).

Anyway, if you read the rest of the documentation for these parameters you will discover the gory details about the operation of these two parameters. Some of these details are important, and we'll touch on them later on.

OK let's set some appropriate values for interfaces and bind interfaces only to the smb.conf for our server described above.

[global]
    interfaces = eth1 lo
    bind interfaces only = yes

Don't forget to restart Samba after making these changes. Sending smbd and nmbd a SIGHUP isn't sufficient in this case.

Now since preventing access on particular network interfaces may be a security sensitive configuration, it might be a good idea to test that the configuration changes we have made have had some effect and are working as expected. From the smb.conf documentation, we know that the bind interfaces only parameter causes smbd to restrict which network a TCP port 139 or port 445 connection comes in on, and nmbd to ignore name registration and query requests originating on unspecified interfaces.

Let's start with TCP connections to smbd. Under Unix, it's quite easy to check on which network address a process is listening on by using the netstat command. Here's the relevant output of netstat for our example system:

# netstat -tapn | grep smbd
tcp    0    0    0.0.0.0:139    0.0.0.0:*    LISTEN    24040/smbd
tcp    0    0    0.0.0.0:445    0.0.0.0:*    LISTEN    24040/smbd

Note: if you are running Samba 2.2 you won't see an entry for port 445. It's supported in Samba 3.0 and higher only.

After making the required changes to smb.conf we rerun the netstat command and get some slightly different output:

# netstat -tapn | grep smbd
tcp    0    0    192.168.1.1:139    0.0.0.0:*    LISTEN    26182/smbd
tcp    0    0    127.0.0.1:139      0.0.0.0:*    LISTEN    26182/smbd
tcp    0    0    192.168.1.1:445    0.0.0.0:*    LISTEN    26182/smbd
tcp    0    0    127.0.0.1:445      0.0.0.0:*    LISTEN    26182/smbd

Notice that there is no entry for the "all interfaces" address, 0.0.0.0, but rather a specific line for each entry in the interfaces parameter. This tells us that Samba is only listening on the interfaces we have told it to, and not every one.

If you're still not convinced, you can use smbclient, telnet or any program that can make a TCP connection to port 139 or 445 (let's assume that our server has an IP address of 10.1.1.1 on eth0 and 192.168.1.1 on eth1:

$ smbclient -L //10.1.1.1 -U%
Error connecting to 10.1.1.1 (Connection refused)
Connection to 10.1.1.1 failed

$ smbclient -L //192.168.1.1 -U%
Domain=[EXAMPLE] OS=[Unix] Server=[Samba 3.0.20b-Debian]

        Sharename       Type      Comment
        ---------       ----      -------
...

Now, the other half of the problem is to prevent NetBIOS packets (basically name lookups) from occuring on eth0. Let's look at the output of netstat before fiddling with Samba's configuration:

# netstat -apn | grep nmbd
udp    0    0    10.1.1.1:137       0.0.0.0:*    26245/nmbd
udp    0    0    192.168.1.1:137    0.0.0.0:*    26245/nmbd
udp    0    0    0.0.0.0:137        0.0.0.0:*    26245/nmbd
udp    0    0    10.1.1.1:138       0.0.0.0:*    26245/nmbd
udp    0    0    192.168.1.1:138    0.0.0.0:*    26245/nmbd
udp    0    0    0.0.0.0:138        0.0.0.0:*    26245/nmbd

This output tells us that nmbd is listening on both eth0 and eth1 interfaces on the server. Probably due to the way Samba uses the Unix UDP networking API, there is not just a single wildcard entry for listening to all interfaces, but rather one entry for each interface, plus an entry that can receive broadcast datagrams.

After applying the changes to smb.conf and restarting, netstat says:

# netstat -apn | grep nmbd
udp    0    0    192.168.1.1:137    0.0.0.0:*    26270/nmbd
udp    0    0    0.0.0.0:137        0.0.0.0:*    26270/nmbd
udp    0    0    192.168.1.1:138    0.0.0.0:*    26270/nmbd
udp    0    0    0.0.0.0:138        0.0.0.0:*    26270/nmbd

Notice that we have now lost the entry for eth0 and are only listening on eth1 as well as the broadcast entry.

We can use the nmblookup program that comes with Samba to further test that name lookups are not being processed on the eth0 interface. The -B option can be used to specify the broadcast address to use and thus which network interface the lookup request appears to come from.

Before we change the smb.conf file:

$ nmblookup -B 10.255.255.255 server
querying server on 10.255.255.255
10.1.1.1 server<00>

$ nmblookup -B 192.168.1.255 server
querying server on 192.168.1.255
192.168.1.1 server<00>

Afterwards we can see that our server doesn't respond to NetBIOS name requests on the eth0 interface:

$ nmblookup -B 10.255.255.255 server
querying server on 10.255.255.255
name_query failed to find name server

$ nmblookup -B 192.168.1.255 server
querying server on 192.168.1.255
192.168.1.1 server<00>

The interfaces parameter understands a couple of different ways of specifying network interfaces. You may like to use the IP and mask format way of specifying a network. Instead of of specifying eth1 you can say either 10.1.1.1/8 (bit length format) or 10.1.1.1/255.0.0.0 (netmask format). This may be more readable than just using the interface name.