Samba nbfw

Background

nbfw

background

Overview

If you have a masquerading firewall, like this one below and you want to be able to browse the public LAN's 'Windows Network' from the private LAN, you can use nbfw to make that possible.

Typical masquerading firewall setup:

 ________________                  ____________
/                \                /            \
|   public LAN   |   +--------+   |            |
|                |---| router |---|  Internet  |
| 130.89.0.0/16  |   +--------+   |            |
\________________/                \____________/

        |
        |
+----------------+
| 130.89.222.201 |
+================+
|     Jupiter    |
+================+
|   192.168.1.1  |
+----------------+
        |
        +-----------+
                    |
             ________________
            /                \
            |  private LAN   |
            |                |
            | 192.168.1.0/24 |
            \________________/

                    |
        +-----------+
        |
 +-------------+
 | 192.168.1.2 |
 +=============+
 |  Callisto   |
 +=============+

Problem

Normally when you have a masquerading firewall, like the setup below, you loose the ability to browse the public LAN from your private LAN. With nbfw it is possible to use the 'Windows Network' from hosts on a private LAN as if they where on the public LAN.

The 'Windows Network' does support cross-subnet browsing, if you use WINS and domain master browsers. However if you use a masquerading firewall this will not work, because the hosts on the private LAN will register their private ip-addresses with the WINS server, which is of course not good. If you do not administer the public LAN and it does not have a WINS server, cross-subnetbrowsing is very problematic.

FYI: On our campus LAN there is no WINS server. There are about 1600 hosts, each with their own administrator, happily using broadcasts. Amazingly it works.

The root cause is the use of ip-address inside the body of an ip-packet. The masquerading software only rewrites the ip-addresses in the header of the packet, leaving the ip-addresses in the body untouched. A special kernel module could solve this, but the NetBIOS protocol and its 'extensions' are not simple. Especially browsing is tricky, even more when the firewall runs Samba itself.

Solution

Write a program that masquerades all ip-addresses in the packet of course! Actually the very first versions did just that: using a binary search and replace.

Writing this program as a patch for Samba has some benefits:

All packets are processed by Samba anyhow.
You can still use Samba on the firewall.
Less code to be written.

Implementation

Using RFC 1001 and 1002 I have written the patch for Samba which enables cross-subnetbrowsing with a masquerading firewall.

Generally the patch does the following:

Let Samba do error checking and stuff like that.
Check if the source ip-address and the netbios names make the packet eligible for forwarding.
Check if packet must be forwarded to all interfaces (minus the source interface of course), or it must be directed to a specific interface.
Determine from the source and destination interface if the packet must be masqueraded.
Determine packet type. Only the types which contain ip-addresses will be masqueraded if needed. The rest goes through unchanged.
Send the processed packet.
If the packet must be forwarded to all interfaces, repeat step 4 to 6 for each interface.
Let Samba continue normal processing of the packet.

Filtering

Step filters the incoming packets using ip-addresses and NetBIOS names. With a large 'Windows Network' this can reduce traffic on the private LAN with more than 95%, especially if you're stuck with broadcasts.

In addition it provides a means to detect several configuration errors, which can disrupt the 'Windows Network' very effectively.

Selecting an interface

Generally broadcast requests, which are received on an interface, must be forwarded to all other interfaces. Their responses should only be send back host which initiated a query. Nbfw keeps a list of outstanding requests so it can send a response back to the correct host and port.

Masquerading the ip-addresses

All packets travelling from the private LAN to the public LAN are masqueraded. Packets travelling the opposite direction must not be masquaraded. However in some cases, f.i. election packets, must be masqueraded in order to make them as if they come from the firewall.

Special cases

Interesting problems occur when you have a network configuration as seen below:

 ________________                  ____________
/                \                /            \
|   public LAN   |   +--------+   |            |
|                |---| router |---|  Internet  |
| 130.89.0.0/16  |   +--------+   |            |
\________________/                \____________/

        |
        +-----------------------+
        |                       |
+----------------+     +----------------+
| 130.89.222.201 |     | 130.89.222.211 |
+================+     +================+
|     Jupiter    |     |     Saturn     |
+================+     +================+
|   192.168.1.1  |     |  192.168.1.11  |
+----------------+     +----------------+
        |                       |
        +-----------+-----------+
                    |
             ________________
            /                \
            |  private LAN   |
            |                |
            | 192.168.1.0/24 |
            \________________/

                    |
        +-----------------------+
        |                       |
 +-------------+         +--------------+
 | 192.168.1.2 |         | 192.168.1.12 |
 +=============+         +==============+
 |  Callisto   |         |     Titan    |
 +=============+         +==============+

The first problem occurs when Callisto makes a broadcast. If both firewall are configured to forward all NetBIOS traffic from the private LAN to the public LAN, the packet Callisto sends will appear on public LAN two times and worse with different ip-addresses causes name conflicts.

So it's important for nbfw to know which hosts it should forward for and which it should ignore. You can control that with the nbfw backend hosts parameter.

But in order to eliminate name conflict we need to do more. Suppose Jupiter forwards for Callisto and Saturn forwards for Titan. Now if Callisto sends a broadcast on the private LAN, it will be re-broadcasted on the public LAN by Jupiter. Saturn will receive this broadcast and will send it to Titan. However Titan did already receive this packet, because it's also on the private LAN. Titan will receive to packets from Callisto, one with ip-address 192.168.1.2 and one with ip-address 130.89.222.201, causing a name conflict.

To prevent such loops you can use the nbfw deny hosts parameter. If your firewall can connect to another host via two or more different interfaces, you must use this parameter to block packets send to the public LAN from that host. In the above case Jupiter should deny NetBIOS packets from 130.89.222.211 and Saturn from 130.89.222.201.

Also note the 'interesting' situation which exists if both Jupiter and Saturn forward to and from the whole private LAN. That will flood your network pretty fast.

Accessing the private LAN

If you want to share data on the hosts on the private LAN with hosts on the public LAN there is another problem: all connections are made on tcp port 139, which is in use by Samba. So if you want a host on the public LAN to access a host on the private LAN you must redirect its request.

Luckily the SMB protocol provides a very elegant way to accomplish this: the retarget response. Suppose host Uranus, on the public LAN, wants to connect to Callisto. It first send a query to obtain the ip-address of Callisto. Uranus will find this ip-address to be 130.89.222.201, the public ip-address of Jupiter, which masquerades for Callisto. Uranus will now connect to host Callisto using the ip-address of Jupiter on port 139. Jupiter knows Callisto is a host on the private LAN and will send a retarget response back to Uranus. This response instructs Uranus to try again using the ip-address of Jupiter but a different port. And this port on Jupiter is forwarded to port 139 on Callisto. So the second time Uranus connects to Callisto it will connect trough Jupiter to Callisto.