Troubleshooters.Com and T.C Linux Library Present

IP Forwarding

Copyright (C) 1998, 1999 by Steve Litt, All rights reserved. Material provided as-is, use at your own risk.

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist,  Rapid Learning: Secret Weapon of the Successful Technologist, and Samba Unleashed.

Explanation

In an ideal world, a Windows client should require no knowledge of the network other than where to find its server, or gateway, or whatever. That server or gateway should then be able to route all necessary communications. This is sometimes harder than it would seem.

In the rest of this document, we will be discussing the following configuration:

This information was obtained using the RH5.1 official bluebox Linux distribution:
  
I have the following configuration using RH5.1 official bluebox:
 ______________       ______________    ___________________
|win98         |-----|eth0          |  |eth1               |
|192.168.100.1 |     |192.168.100.3 |--|192.168.200.3      |
|______________|     |______________|  |ip alias           |
                                       |192.168.200.110-149|
                                       |___________________|               

All netmasks are 255.255.255.0
192.168.200.110 thru 149 are used for virtual web hosting -- they represent different websites.

The object here is to allow the Windows 98 machine to access IP addresses 192.168.200.110-149, either through the IP address or through DNS, without the Windows 98 machine knowing details of the network or various subnets.

Preparing Your System to Forward

Assuming there's already a ping'able connection between your Windows machine (192.168.100.1) and your Linux machine's eth0 (192.168.100.3), make sure the following files are edited appropriately:
 

/etc/sysconfig/network-scripts/ifcfg-eth1

This file should contain the following lines:
  
DEVICE="eth1"
IPADDR="192.168.200.3"
NETWORK="192.168.200.0"
NETMASK="255.255.255.0"
BROADCAST=192.168.200.255
ONBOOT="yes" 

I think it's pretty self-explanatory why.

/etc/sysconfig/network-scripts/ifcfg-eth1:0

This is where the alias ip's go, in the form of the following line: 
IPADDR="192.168.200.110-149"  

/etc/sysconfig/network

This defines the network, and is absolutely vital to ip-forwarding. It needs to contain the following:
  
NETWORKING=yes
FORWARD_IPV4="yes"
HOSTNAME="linuxhost.mydomain.cxm"
DOMAINNAME=mydomain.cxm
GATEWAY="192.168.100.254"
GATEWAYDEV="eth0"      

Of course, you'll use your domain name and your host.domain. CAUTION!!!  WARNING!!! Note the 254 on the end of the gateway address. USE IT!!! 254 is a magic number that does the right things. DO NOT user 192.168.100.3 here -- it will appear to work but will cause IP forwarding failure.

CAUTION!!! WARNING!!! Even though you define the gateway in /etc/sysconfig/network as 192.168.100.254, on the Windows machine you must define it as 192.168.100.3. It's the gateway combination of 192.168.100.3 in Windows and 192.168.100.254 that allows IP forwarding. 254 is a magic number.
 

Check IP Forwarding Tables

Here's a command/output combination you should see:
  
[root@linuxhost sysconfig]# /sbin/ipfwadm -F -l
IP firewall forward rules, default policy: accept  
 
[root@linuxhost sysconfig]# /sbin/ipfwadm -A -l
IP accounting rules            
 
[root@linuxhost sysconfig]# /sbin/ipfwadm -M -l
IP masquerading entries  

If you see anything in the output of the commands that seems to preclude any communication to or from 192.168.200, ESPECIALLY a default policy of deny or reject in the IP firewall forward rules, you must add ipfwadm commands to /etc/rc.d/rc.local to enable forwarding to and from that subnet.

NOTE: A default policy of accept is a security risk that's acceptable for tutorial purposes only. For an actual functioning network it's far better to default to deny, then individually enable ip forwarding on a subnet by subnet basis.

False Fixes

A casual reading of documentation might lead you to believe some of these things are issues. They are not:

Arp

You might be tempted to have Windows recognize the eth1 by using a proxy arp. Don't, it's not necessary, and is not the root cause of non-forwarding. Proxy arps are used as workarounds for completely brain dead tcp-ip systems like the one in old dos. Windows does not require proxy arps.

Routing on the Windows Machine

It's possible to cure some "Windows won't ping 192.168.200.3" symptoms by adding subnet 192.168.200 to the Windows machine's routing. DO NOT DO IT!!! That solves the symptom but leaves the root cause (probably the wrong gateway address on one of the machines) intact. The principle of modularity demands that the Windows client requires only knowledge of its gateway, not of the entire network and its routing.

Special Routing Table Tweeks on the Linux Machine

If your eth1 is set up correctly, it has all the routing necessary to achieve ip-forwarding. Verify this by pinging 192.168.200.3 on your Linux machine. If it works, you're probably routed just fine.

Reboot the Linux Box

Once all these configurations have been put in place, reboot the Linux box. You should be able to ping 192.168.200.3 from your Windows machine, as well as any IP in the 192.168.200.110-149 range that you enabled in /etc/sysconfig/network-scripts/ifcfg-eth1:0 file. If you cannot, troubleshoot.

General IP Forwarding Troubleshooting Tips

Quick Checks

Troubleshooting IP forwarding is difficult because of the huge number of variables affecting it. It's easy to try a test which inadvertently creates a problem at a lower level previously working. To prevent that, do these quick checks, in this order, after each change:

Forwarding at a Higher Level

So far we've forwarded at an IP address level. That in itself does not guarantee that virtual hosts set up on the 192.168.200 subnet will appear by name in your browser. To do that naming must be properly achieved. DNS is beyond the scope of this article (click here for DNS tutorial), but we'll assume you had a working DNS server system on the Linux machine before starting. In that case all that's necessary is to configure your DNS files to recognize the 192.168.200 numbers, and to make sure Windows knows where to find authoritative DNS for the 192.168.200 subnet.
 

Telling Windows where DNS is located:

 
  • Host: The name of the Windows machine. Should be the same as the name on the identification tab.
  • Domain: Identifies the domain your computer belongs to.
  • DNS Server Search Order: This must contain a reference to 192.168.100.3 (though not necessarily the first), because that machine is serving as a DNS server with authority over the 192.168.100 and 192.168.200 subnets, and the mydomain.cxm domain in general. 
  • Domain Suffix Search Order: Put a reference to the domain containing the Windows machine, which we'd assume would be the same domain as the Linux machine (192.168.100 subnet, after all).

Configure Your DNS Files

This section contains only ip-forwarding dns info. For a complete tutoral of DNS, click here. We'll assume the following DNS config files:
 
/etc/named.boot Starting point. Must contain a reference for each domain name, telling what file contains its DNS info. As a practical matter, usually all will point to file /var/named/named.forward.
/var/named/named.forward This contains the SOA statement, and other statements that map domain names to ip addresses.
/var/named/named.reverse This is the reverse DNS file. It maps IP addresses to domain names.

/etc/named.boot

Add the following line: 
primary         200.168.192.in-addr.arpa    named.reverse
This tells the system to look in /var/named/named.reverse for any names relating to the 192.168.200 subnet. Obviously if your reverse DNS file is under a different filename, use that filename.

/var/named/named.forward

For each 192.168.200 subnet IP you wish to name, add an IN A statement with a complete (4 byte) IP address. Here's an example: 
troubleshooters.mydomain.cxm.    IN  A            192.168.200.113
Troubleshooters.mydomain.cxm is called the canonical name. You'll probably fit it with a couple aliases using the IN CNAME statements: 
www.troubleshooters.cxm.         IN CNAME         troubleshooters.mydomain.cxm.
troubleshooters.cxm.             IN CNAME         troubleshooters.mydomain.cxm.
You WILL NOT add a new IN SOA statement.

Be sure to increase the serial number (yyyymmdd##) in the IN SOA statement before exiting the editor.

/var/named/named.reverse

Add the following IN SOA statement right below the all information for subnet 192.168.100: 
200.168.192.in-addr.arpa.   IN  SOA linuxhost.mydomain.cxm. hostmaster.mydomain.
cxm. (
            1999010702
            10800
            3600
            604800
            86400
            )

                             IN NS      linuxhost.mydomain.cxm.
This allows everything below it (until the next IN SOA statement) to simply use the least significant IP byte. Note that the SOA is for linuxhost, which is located at 192.168.100.3, rather than on the 192.168.200 subnet. That's perfectly OK. Linuxhost is the DNS server for both subnets.

For each 192.168.200 subnet domain name in named.forward, both canonical and aliased (IN A and IN CNAME), add a line below the 192.168.200 IN SOA. Here are 2 examples: 

113                    IN PTR  troubleshooters.cxm.
113                    IN PTR  troubleshooters.mydomain.cxm.
Once again, be sure to increase the serial number (yyyymmdd##) in every  IN SOA statement in named.reverse before exiting the editor.

Letting DHCP Do Your Windows Client Admin For You

If the Windows client is enabled to use Wins via DHCP, the client need only know its own name in the Identification tab of network setup. All other information can be passed it through its DHCP connection to the DHCP server on the Linux box. Once again, complete DHCP setup is beyond the scope of this document, but there exists a DHCP tutorial.

You must change /etc/dhcpd.conf, adding a dummy entry for the 192.168.200 subnet, and upgrading your existing entry for the 192.168.100 subnet (the one your Windows clients are actually on) to feed them information like default gateway, dns, etc. Here's an example of /etc/dhcpd.conf:
  
subnet 192.168.100.0 netmask 255.255.255.0 {
    range 192.168.100.200 192.168.100.240;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.100.255;
        option routers 192.168.100.3;
        option domain-name-servers 192.168.100.3;
        option domain-name "mydomain.cxm";
        option ip-forwarding on;
        option netbios-node-type 8;
    }

subnet 192.168.200.0 netmask 255.255.255.0 {
    range 192.168.200.200 192.168.200.240;
    }                             

Note that the subnet 192.168.200.0 entry has less information because it's not expected to be used. If it were expected to be used, it would contain the same info as the 192.168.100 entry.

Most contents of the subnet 192.168.100.0 entry are self-explanatory. Note that the option routers is the Windows machine's default gateway (overriding whatever's on Windows' gateway tab, while the option domain-name-servers is the DNS list, overriding or adding to (I'm not sure) the contents of Windows' DNS tab.
 

Note the Magic Here!

With the Linux box properly configured as a dhcp server, you can walk into a site with several Windows computers, connect them via hub to your eth0, tell each Windows box that it gets its WINS resolution via DHCP (on the WINS tab), reboot, and presto: they have access to your DNS, Intranet websites, departmental email, and Samba file service (in Network Neighborhood). Did anyone say "low total cost of ownership"?

Back to Troubleshooters.Com * Back to Linux Library