5. Problems

There are lots and lots of things which can go wrong using a simple document like this, because there are plenty of special cases. The majority of possible problems adhere to the configuration of the internal and external network devices. I will try and respond to people with problems, figure out what went wrong and add links down here so that people with special case problems can track down help. Feel free to contact me at pramsey@refractions.net.

5.1 ICQ Does Not Work

Some portions of ICQ work fine over masquerading. Other portions do not work well at all. There is a beta quality ICQ module under development, however, which addresses some (but not all) of the deficiencies of running ICQ over masquerading. The README file in the source code distribution describes how to compile the module. Once you have it compiled and installed, invoke /sbin/modprobe ip_masq_icq.

5.2 I Have Caldera 2.X Not Red Hat 6.X

Well, firstly congratulations for bucking the trend! Secondly, Nelson Gibbs (ngibbs@pacbell.net) sends good news, because most of these instructions will work for you. There are some important changes to note however:

1. A GATEWAY=xxx.xxx.xxx.xxx statement in /etc/sysconfig/network-scripts/ifcfg-eth0 & eth1 for the interface (local interface uses remote interface IP address and remote interface uses service provider's gateway IP).
2. Make sure /etc/sysconfig/daemons/dhcpd script lists ROUTE_DEVICE as eth1 not eth0.
3. /etc/dhcpd.conf requires a subnet statement for both interfaces (I'm not entirely sure why as I made my second statement : subnet 216.102.154.201 netmask 255.255.255.255 { } with no other options and the DHCP server listens and sends on eth0 and eth1 as well as the fallback). The DHCP server errors out if only one subnet is listed.
4. Do not add host route 255.255.255.255, the /etc/rc.d/init.d/dhcpd script Caldera uses already fixes the problem. DO make sure to change all references to eth0 in the script to eth1.

5.3 I Want One of My Internal Machines to be my Web Server

Piece of cake! However, you need to have a static IP address for this easy set of directions to work. If you have a dynamic IP address, you will need some additional scripting to ensure that your IP address gets updated in the port forwarding commands when the address changes.

Bear in mind, forwarding an external port to an inside machine makes your "internal" machine less "internal" than before, but it can be done very transparently and with little or no performance degredation. One of the side effects of the IP masquerading code in the Linux kernel is the ability to do some pretty funky stuff with packets as they hit the network layer, and the ipmasqadm utility is built to take advantage of that.

For some reason ipmasqadm is not shipped with all the Red Hat and Mandrake variants, so will probably have to retrieve it from the maintainer's web site -- there is an RPM available there as well as source code.

Once you have the RPM, install it, and then add the following lines to your /etc/rc.d/rc.local file:

/usr/sbin/ipmasqadm portfw -f 
/usr/sbin/ipmasqadm portfw -a -P tcp -L x.x.x.x 80 -R 192.168.1.x 80 
 

The first command flushes the port forwarding rules and the second command adds a forward from port 80 on the external interface to port 80 on the internal machine. Note that the external static IP address goes in the x.x.x.x space and the internal machine IP address goes in the 192.168.1.x space.

Now external requests for port 80 will be transparently sent to port 80 of the internal machine. Note that you cannot test this by telnetting or connecting to your gateway's port 80 from one of your inside machine: the port forwarder only honors requests coming in on the external interface.