The NetBIOS forwarder

transparent browsing with a masqueraded network

Background

This document explaines the inner working of NBfW. Understanding the inner working of NBfW can be helpful to solve problems.

What does NBfW do?

As explained in the intro, NBfW allows you to connect together two or more anarchistic (read broadcast) netbios networks, like Windows' 'Network Neighbourhood'.

Here's the situation:

     ---------------------------------
    |    campus: 130.89.0.0/16        |
    |                                 |
    |   ---------------------------   |
    |  | topix : 130.89.222.222    |  |
     ---------------------------------
    |  | topix : 192.168.1.1       |  |
    |   ---------------------------   |
    |                                 |
    |   backend: 192.168.1.0/24       |
    |                                 |
    |   ---------------------------   |
    |  | quake : 192.168.1.2       |  |
     ---------------------------------

My computer 'topix' has two ethernetcards and is connected to both LANs. It functions as a masquerading firewall so I can still surf The Internet from 'quake'. Machines on the backend network aren't directly accessible from the campus network, nor from anywhere on the Internet. If you don't understand this, please read RFC 1918.

Using the standard masquerade stuff in the kernel you can use the 'Network Neighbourhood', but you cannot browse it. Why? Well because the actual connetion over which the data is transferred is normal TCP, which is correctly masqueraded.

But browsing relies on broadcasts, which are not forwarded by default. Even worse these broadcasts contain IP-addresses not only in the header, but also in the data. If these packets came from a machine on the backend network we have to change the IP address contained within the packet to the campusnet-IP address of the NBfW machine, in this case 'topix'. This changed packet will only be broadcasted on the campus network. So, any other machines on the backend network will only receive the unchanged packet.

You can now safely browse the netbios network, look at shares or download files etc, contained on the campus network, from 'quake', or any other machine you might have on the backend network.

Now we come to another point. Say a machine 'mwhiskey' on the campus network wants to look at shares on 'quake'. 'mwhiskey' will then open a TCP connection on port 139 with... 130.89.222.222 as this is the IP address it has constantly heard 'quake' say through the masqueraded packets.

So, 'mwhiskey' will open a TCP connection on port 139 of 130.89.222.222 for any backend machine and also of course for the firewall itself. Until version 0.05 you had basically two choices:

• you want shares on your firewall to be reachable.
• you want a backend machine to be reachable.

This worked well, but I wanted my firewall to be master browser and my shares on my backend machine to be reachable. Both are listening to port 139. Well, digging through RFC 1002 I found the solution, Session Retarget Responses:
If a computer connects to port 139 of the firewall it gives a NetBIOS name to which it wants to connect. This name is of course unique and by comparing this name to a list of known backend hosts we can retarget the session request from port 139 to another port on our firewall. This port will be redirected to port 139 of the backend machine. Because Windows95, Windows NT and Samba actually implement the RFC correctly this works great, with little overhead.

Note: this redirecting is done using the kernel patch IPPORTFW (also known as ip-subs). An implementation based on the redir program, will not work correctly because the connection will originate from the firewall, instead of the original host. This causes Windows 95 to detect name conflicts.

Backend with multiple gateways/firewalls

A problem to which a solution has already been implemented into NBfW occurs when you have a backend network with multiple gateways/firewalls to the campus network:

        -- CAMPUS --
       |            |
     topix       yafirewall
       |------------|
     quake       yacompu

ya=yet another

When 'quake' broadcasts its netbios name and IP address, 'topix' will masquerade the packet and broadcast it over the campus network. 'Yafirewall' will hear this packet and broadcast it over the backend network again. 'quake' will then hear his own packet containing the 'topix' IP address and generate a "Name conflict". Also, 'yacompu' will first hear the broadcast packet from 'quake' containing 'quake's backend IP address. Later it will receive the masqueraded packet and generate a "Name conflict" as well. This can for the first half be solved by making 'topix' only broadcast packets from 'quake' on the campus network AND to send packets from the campus network only to 'quake', instead of broadcasting these packets over the backend network. Make 'yafirewall' only broadcast packets from 'yacompu' on the campus network and to send packets from the campus network only to 'yacompu'.

Now at least 'quake' will never receive his masqueraded packets. However! 'yacompu' will first hear 'quake's broadcast on the backend network. It will then receive the masqueraded packet which has traveled from 'topix' to 'yafirewall' and then 'yacompu'. So, the rest of the solution is to make 'yafirewall' ignore all packets it receives from the campus network which were send out by 'topix' and vice versa.

Actually browsing

After NBfW has been properly installed and is running on your firewall(s) you should have no problems browsing the campusnet using Win3.1x, Win95, WinNT or Linux on a backend machine. With Linux it's a bit more tricky.

NBfW listens on ports 137 and 138 and also rebroadcasts over ports 137 and 138. When using smbclient on a Linux machine smbclient will send to ports 137 and 138 but from some variable user ports. It will only of course listen on these user ports as well and thus will not hear the packets from the firewall.

To solve this problem NBfW remembers the senders port for request packets. This way a response can be directed to the correct port.

Access from the outside

Typically an external machine which want to access a backend machine will first do a name query followed by a connection to port 139. Because the response of a backend machine to an external machine will be masqueraded it try to connect to port 139 of your firewall. This connection request has to be forwarded somehow to the backend machine. A simple redir will not work because Windows 95 complains with name conflict errors.

The ipportfw patch makes the connection appear to come directly from the external host instead of the firewall, so this will give no name conflicts. In addition the kernel-based forwarding is much faster. Ipportfw is configured to forward a specific port to a port on the backend machine. Obviously this specific port cannot be port 139, because the smbd of the firewall has that port in use.

Luckily the netbios protocol provides a mechanism to redirect a session request to another host and port. So when an external machine issues a connection request, smbdnbfw checks if the called name is on the backend network and selects an appriorate port to use. It then sends back a 'retarget response'. The external machine will then retry the session request but to another (by ipportfw forwarded) port. Now the request will be handled by the backend machine.