"Linux Gazette...making Linux just a little more fun!"

Copyright © 1998, 1999 by Ron Jenkins. This work is provided on an "as is" basis. The author provides no warranty whatsoever, either express or implied, regarding the work, including warranties with respect to its merchantability or fitness for any particular purpose.

The author welcomes corrections and suggestions. I can be reached by electronic mail at , or at my personal homepage: http://www.qni.com/~rjenkins/.
Corrections, as well as updated versions of all of the author's scribbles may be found at the URL listed above.

NOTE: As you can see, I am moving to a new ISP. Please bear with me as I get everything in working order. The e-mail address is functional; the web site will be operational hopefully around mid January or early February.

SPECIAL NOTE: Due to the quantity of correspondence I receive, if you are submitting a question or request for problem resolution, please see my homepage listed above for suggestions on information to provide.

Operating Systems Covered/Supported:
Slackware version 3.6
RedHat version 5.1
Windows NT Server version 4.0
Windows NT Workstation version 4.0

I only test my columns on the operating systems specified. I don't have access to a MAC, I don't use Windows 95, and have no plans to use Windows 98. If someone would care to provide equivalent instructions for any of the above operating systems, I will be happy to include them in my documents.

Part Six: Building an Internet Gateway
After much rewriting and testing, we will hook our home network up to the Internet, using a Linux machine as an Internet gateway/proxy server.

The Linux machine will automatically connect to your ISP at boot time, configure itself, and re-establish the PPP link automatically in the event of a line failure. I will NOT be covering a dial-on-demand (diald) setup in this column, that will be covered next month in the advanced configuration and performance tuning column.

At the conclusion of this installment, you should be able to access the internet from any machine on your network, send and receive e-mail, (subject to the restrictions of the type of ISP account you possess) surf the web, and most any other darn thing you might want to do.

As with each installment of this series, there will be some operations required by each distribution that may or may not be different in another. I will diverge from the generalized information when necessary, as always.

In this installment, I will cover the following topics:
* Some background information on Internet gateway services.
* Advantages and disadvantages.
* Required hardware and software.
* Pre-installation planning.
* Setting up the PPP Interface.
* Setting up the NIC.
* Monolithic vs. modular approach to gateway services.
* Recompiling the kernel for gateway services.
* Testing the gateway machine.
* Configuration of the client machines.
* Testing the client machines.
* Troubleshooting the installation.
* Some notes and tips on particular services.
* Example rc.local scripts.
* References.
* Resources for further information.
* About the Author.

Quick Review of previous material and assumptions relevant to this column:
Briefly, at this point, we have a three node network, all configured with reserved 192.168.1.x IP addresses, using a common hosts files for name resolution.

The gateway machine will be called gateway01.home.net, and will have the IP address of 192.168.1.1.

It is assumed that the gateway machine has a standard, non Plug and Pray modem (or has the capability to disable the PNP features and manually set the COM port and IRQ values,) installed either internally or externally.

NOTE: I have received many requests for the inclusion of 56K V.90 modems, ISDN modems, and cable modems in this document.

The ISDN modem's line provisioning and setup are beyond the scope of the document. However, if it connects using a serial port or network interface, there is no reason you should not be able to make it work. I have an Ascend Pipeline 50 myself, and have always had great success with it.

Concerning 56K V.90 internal modems, it is my understanding that these are at best a telco interface and impedance matching device, with the bulk of the work performed by software and your CPU. As far as I know these will not work with Linux.

If you have an external 56K V.90 modem, and it will accept the Hayes command set, give it a try. I would be interested to hear from you concerning your experiences with the external models.

Finally, concerning cable modems, I don't have access to one, so I don't know much about them. See the Cable Modem MINI HOW-TO. One bright note is that since these devices connect to your computer via a NIC, your configuration process will be much simpler than what we will be doing here.

It is assumed you know the relevant information for your particular ISP. At a minimum, you should have the following:

Access phone number
Fully Qualified Domain Name (FQDN) of your mail and news servers.
The IP addresses of your Primary and Secondary DNS servers.
Your subnet mask (usually 255.255.255.0.)

For more information on this subject, see my November column, or the ISP Hookup and Connectivity HOW-TO's.

Some background information on Internet gateway services:
People always say "You can't get something for nothing." Well, in a sense, that's exactly what we are going to do this time. We are going to use a standard, non-dedicated, and inexpensive dial up account to provide Internet access for our entire network.

To accomplish this, we will be using the IP Masquerading software in conjunction with a firewall application (ipfwadm), as well as a NIC, modem, and what I call PFM - Pure Freakin' Magic.

Simply put, our machine will be performing two major functions. It will be acting as an Internet gateway, while simultaneously masquerading local IP addresses from the outside world.

The gateway function is fairly straightforward. A gateway does nothing more than connect two disparate networks, and make sure that all the traffic passed through the gateway reaches the proper destination.

The masquerading function, sometimes called Network Address Translation (NAT,) is a bit more complicated.

Basically, it is a programmable liar. What a masquerade program does is take the requests from all the machines on our local (home) network, and lie to the rest of the world, about the source of the requests, making it appear that they all originate from the gateway machine.

Conversely, when requests from the outside world come in, the little stinker grabs the requests and lies some more, then delivers the request to the proper user on the local net.

There is a lot more to it than that, but for the purposes of this project we will proceed with this explanation.

Advantages and disadvantages:
Advantages:
* You get to hookup up your whole network to the Internet for $18.00 per month, as opposed to as much as $300.00 for a dedicated ISDN connection.

* You do not need to purchase a domain name, configure name servers, and all the other administrivia that goes with a commercial installation (although much of what you will learn and do here will be applicable to such an installation.)

* Indeed, our configuration and installation in this project will, in many ways, be more intricate than a simple commercial installation. This will give you not only a home network for a reasonable price, but a marketable skill.
* If there are only two or three people on it doing e mail, web surfing or telnet, it should provide acceptable performance.

Disadvantages:
* Some ISP's are less than thrilled if you set up something like this. Although you are still using just the one dial up connection, they , like most corporate people I approach about telecommuting from home, think there's just something wrong with it. It is possible you could be asked to get a business type dedicated account, or your account may be canceled.
* Depending on the type of account you have with your ISP, you most likely have only one e mail address. This means only you can receive e mail with this setup. Some ISP's are beginning to offer "family accounts" with extra e mail addresses available for a small extra monthly charge.
* While everyone on the network can surf the WWW, perform FTP, Telnet, and many other applications, there are some things you will not be able to do. See the IP_Masq document mentioned below for a complete listing of supported and unsupported services and applications.
* Depending on the type of connection you use for your PPP link, performance can be really poor. Although there are some things you can do to improve performance and speed things up on a slow link, (More on this next time,) after a week or so of a 28.8 or 33.6 modem connection, you will be dreaming of an ISDN or Cable Modem connection.
* This sort of setup does NOT do outbound services well at all. Since you are most likely using Dynamic IP Addressing, where you are assigned a different IP each time you connect, it's very difficult and not very practical to try to provide outbound services. You would be better served with a dedicated connection, or some co-hosted web space on your ISP's server if you plan to do any business with this setup.

Required hardware and software:
RedHat - Accept the defaults, and additionally select Dialup Workstation, Networked Workstation, and C Development tools and libraries.

You may also want to consider adding Mail/WWW/News Tools, DOS/Windows Connectivity, NFS Server, SMB (Samba) Connectivity, Anonymous FTP Server, or anything else you require for your particular installation.

As below, skip APACHE, INN, and BIND. When prompted, go ahead and set your local network information. Leave your nameserver and gateway prompts BLANK.

You don't really get a choice of kernels here, so accept the default, and when prompted, be sure to make a bootdisk.

Finally, install LILO on the first superblock of the install partition, DO NOT INSTALL LILO IN THE BOOT SECTOR AT THIS TIME!

Reboot, and you should be connected to your home.net. Copy the common hosts file onto the gateway machine, as well as the other files specified last month.

Slackware - Install the A, AP, D, and N series. Chose the menu selection method of installation. Do NOT install APACHE , INN, or BIND. When prompted, go ahead and set your local network information. Leave your nameserver and gateway prompts BLANK. Finally, choose the proper vmlinuz kernel for your system.

When asked if you want to make a bootdisk, answer yes. Make several simple vmlinuz bootdisks. Do not install LILO at this time.

Reboot, and don't worry when it freaks out about not being able to find the network. Jump down to the setting up the NIC section and follow the instructions there, and reboot again.

Pre-installation planning:
Make sure you have the aforementioned ISP info handy.

If possible, try to get someone else involved in the project.

It is much easier to diagnose, test, and troubleshoot with someone else at the workstation and you at the gateway.

Make sure the ipfwadm software is installed on the gateway machine. This is not a problem in Slackware, but depending on what you choose when you install, it may not get installed in RedHat. If necessary, install it using glint or by hand:

rpm -ivh <nameofipfwadm.rpm>

Setting up the PPP interface:
RedHat - In text mode, you can either use the linuxconf utility, or configure it manually. Under X, use the Control Panel/Networking/Network Configurator utility.

Slackware - Here you have to do it manually. The down side is it's a bit more difficult, but the up side is in case of a problem, you will have a lot better idea of where to look to fix it.

Regardless of which flavor of Linux you are using, the following things will need to be done on either machine:

* Add your ISP's Primary and Secondary DNS servers IP addresses to you /etc/resolv.conf file. This is identical for both distributions.
* Add and configure the ppp0 interface, activate it at boot time, make it your default gateway device, and have it set your defaultroute. Finally, you will need to configure the ppp0 interface to automatically redial on link failure.

RedHat - Open Network Configurator, click on the Interfaces tab, select Add, then follow the prompts of the Network Configurator to set the above options.

Additionally, select the Routing tab, and check the Network Packet Forwarding option. To finish up, make sure the Default Gateway: is empty, and the Default Gateway Device: is ppp0. Select Save, then Quit.

Slackware - You have two options here - you may use the pppsetup utility that comes with Slackware 3.6, or you can script it yourself as described in the troubleshooting section.

I can only recommend the "script it yourself" method, as my experience with the pppsetup method met with mixed results. When used as an end user program, (after login and initiated by hand, it worked well.) When used at boot time, called from the rc.local file, sometimes it would connect, sometimes not.

To use the recommended scripting method, proceed to the troubleshooting section, create and test the scripts, then edit your rc.local file to call the unicom BEFORE the ipfwadm stuff.

If you do use the pppsetup method, be sure to read the docs and insert the line ppp-go in your /etc/rc.d/rc.local file BEFORE the ipfwadm stuff.

Concerning auto redial - there is a great little program for this, called pppupd, available at:

ftp://metalab.unc.edu/pub/Linux/system/network/serial/ppp/pppupd-0.23.tar.gz

Unpack it: gunzip -dc pppupd-0.23.tar.gz | tar xvf -

Look at the README file for complete compilation instructions, but in a nutshell, copy, then edit the pppupd.cf.template file to match your system.

You will have to provide the path to the pppsetup scripts, or the script described in the troubleshooting section, the time interval between pings, as well as a hostname for the program to ping.

Next, simply open the Makefile and look for the line:

CONFIGFILE=

And set it to the path of the pppupd.cf file you created earlier.

Finally, enter the command "make" at the command line and you will end up with the pppupd binary. Copy it to your /sbin or /usr/sbin directory.

You can start this at boot time if you desire by adding the line :

pppupd > /dev/null to your rc.local file, but I would be cautious, as during testing, this intermittently caused some freaky things to happen. I recommend starting it by hand at first, then if all goes well put it in your rc.local file at some point after the ipfwadm stuff.

* Enable IP Forwarding in the kernel at boot time. This should already be activated on the Slackware box. To make sure, issue the following command - cat /proc/sys/net/ipv4/ip_forwarding. This should be set to the number one (1.) On the RedHat box, edit /etc/sysconfig/network, and change the line : FORWARD_IPV4=no to yes.
* Edit your /etc/rc.d/rc.local file to instruct the machine to masquerade for the rest of the network. Again this is the same for either distribution. There are probably many better ways to do this, but here's what works for me:
* Open /etc/rc.d/rc.local, and uncomment or add the following lines (as necessary,) in the following order:

1. ipfwadm -F -p deny #deny everyone not listed below
2. ipfwadm -F -a masquerade -W ppp0 -S 192.168.1.0/24 -D 0.0.0.0

The previous line, number two (2), activates masquerading, and specifies the ppp0 interface as the default gateway for the home network.

Setting up the NIC:
RedHat - This should have been done during the installation of the software. If not, in text mode, you can edit /etc/config.modules, or use the linuxconf utility. If you have X up and running, You can use the Control Panel/Networking/Network Configurator you used before for the PPP interface.

Slackware - Provided you have a supported NIC (you have been listening to me haven't you?) to setup the NIC, Change directory to /etc/rc.d/rc.modules, and uncomment the appropriate line for your NIC by removing the pound (#) sign at the beginning of the line. You may or may not have to pass some configuration information here such as the IO port and/or IRQ of the NIC.

In either case, be sure to leave the NAMESERVER and DEFAULT GATEWAY dialogs blank.

Monolithic vs. modular approach to gateway services:
You have two options for providing gateway services on a UNIX box - a monolithic kernel (one with all the drivers and required support compiled as part of the kernel itself,) or a modular approach (in this method you use your standard kernel, and load or unload the required drivers and services as needed.)

There has been about as many wars over this issue as the emacs vs. vi debate, so here's my two cent's worth - I use the modular approach, mostly because it makes for a smaller, leaner kernel, and most importantly, I'm lazy ;-)

Since the new kernels already have support for ip_masquerade, ip_forward, and ipfwadm built in, why go to all the extra trouble to compile a new kernel?

Sure, some of us get off on tweaking and tuning our installations continuously, the purpose of this series is to get you up and running with a minimum of fuss.

Recompiling the kernel for gateway services:
This is not necessary if you are using Slackware 3.6, RedHat 5.1 or above.

If you are a masochist, kernel compilation instructions can be found in the Kernel HOWTO, and the required parameters for gateway services are specified in the IP_Masq MINI HOW-TO.

Testing the gateway machine:
The RedHat box should fire right up upon reboot. Proceed to the following tests.

For Slackware, should fire up on reboot as well. Proceed to the following tests.

If you fail to connect, or any of the following tests fail, go to the troubleshooting section for some ideas on how to resolve the problem.

Testing the interfaces - Simply issue the command ifconfig, and it should return three (3) interfaces: lo, or the loopback adapter, eth0, your NIC, and ppp0, the connection to your ISP.

Testing the PPP interface - kill the pppd daemon a few times. Unplug the phone line from the modem. Make sure it redials properly.

Testing physical connectivity - ping the outside world by IP address (Use one of your ISP's DNS numbers you obtained,) then ping one of your local machines.

Testing name resolution - ping the outside world by hostname, for instance - ping ftp.foobar.com, then ping something local - ping filserver01.

Testing routing and gateway functions - issue the command netstat -r to examine your routing table. There should be four entries :

1. <your ISP assigned IP>, with no Gateway, a Genmask of 255.255.255.255, Flags set to UH, MSS of 1500, Window of 0, irtt of 0, and an Iface (Interface) of ppp0.
2. 192.x (or localnet), no Gateway, Genmask 255.255.255.0, Flags U, MSS, Window, and irtt identical to the above, Iface of eth0.
3. 127.x (or localhost), no Gateway, Genmask 255.0.0.0, Flags U, MSS 3584, Window and irtt same, Iface of lo.
4. Default, <the same IP as number one (1,)>, Gateway <your ISP's machine at the other end of the PPP link>, Genmask 0.0.0.0, Flags UG, MSS 1500, Window and irtt same, Iface ppp0.

Configuration of the client machines:
UNIX Clients -
RedHat - Using either linuxconf or the Network Configurator, set the default gateway of your client machine to 192.168.1.1.

Slackware - Using netconfig, set your default gateway as above.

NT Clients - Open Control Panel/Network/Protocols/Properties/IP Address, and set your default gateway as above.

NOTE: For services other than http, smtp/pop3, icmp, and telnet, see the notes and tips section below.

Testing the client machines:
If everything has gone well, you should be able to fire up your browser and be off and running with access to your mail server, access to the web, and telnet access to the net.

If any of the above services does not work, see the troubleshooting section below.

If you need other services, such as ftp, real audio/video, cuseeme, and so on, consult the notes and tips section below.

Troubleshooting the installation:
Gateway Machine -
Make sure all three interfaces are being recognized. If not, reconfigure the one that is missing.

Check your scripts and routing tables. If necessary, review the gateway machine's PPP and NIC setup for accuracy.

Finally, if you are having no success with the RedHat or Slackware whizbang PPP connection thingie, you can do it with the tried and true scripting method using the following technique:

Again, there are probably many better ways to do this, but this is what I came up with. You will have to create two scripts, one to dial up your ISP and login using chat and to configure your PPP daemon, pppd, and one to pass the chat program the proper information about your modem and tell it what username/password to send to the ISP's machine when prompted.

In my case, my ISP expects a Username and Password to be entered, using clear text. Then, the ISP's PPP daemon starts up automatically. The following examples are for this sort of configuration only. Depending on your ISP you may or may not have to modify them. See the References section of this column for information on other configurations.

In my case, I created two scripts, one named unicom (the script that dials the ISP and starts pppd, and one named unicom.chat, which contains the modem information and the expect/send pairs.

Using your favorite editor, create the scripts, save them, and them make them executable by issuing the following command - chmod +x <name of script>

Contents of the script unicom:

#!/bin/sh
pppd connect \
'chat -v -f /sbin/unicom.chat' -detach crtscts modem defaultroute \
/dev/modem/ 115200 &

Contents of the script unicom.chat:

TIMEOUT 5
"" ATZ
OK ATDT2213005
ABORT "NO CARRIER"
ABORT BUSY
ABORT "NO DIALTONE"
ABORT WAITING
TIMEOUT 45
CONNECT ""
TIMEOUT 5
"name:" your username
"word:" your password

When you are done, place unicom, and unicom.chat in the /sbin directory. run the unicom script from the command line. If all goes well with the following tests, then call the unicom script from rc.local, placing it ABOVE the ipfwadm lines you created earlier.

UNIX Clients -
Double check that your workstation has the gateway machine's NIC set as it's default gateway (192.168.1.1 in this example.)

Ping 127.0.0.1, then the machine's IP address. If this fails, your networking setup is incorrect, or your NIC is malfunctioning.

If this goes well, ping the gateway box by IP address. If this fails, check your cabling.

Ping the outside world. If this fails, the problem lies in the gateway, not the client.

Now repeat the above steps, using hostnames instead of IP addresses. If it fails at any point, you have a name resolution problem. Check your DNS settings in resolv.conf, your hosts.conf file for the line - order hosts, bind, and your hosts file for accuracy.

NT Clients -
Double check that your workstation has the gateway machine's NIC set as it's default gateway (192.168.1.1 in this example.)

Ping 127.0.0.1, then the machine's IP address. If this fails, your networking setup is incorrect, or your NIC is malfunctioning.

If this goes well, ping the gateway box by IP address. If this fails, check your cabling.

Ping the outside world. If this fails, the problem lies in the gateway, not the client.

Now repeat the above steps, using hostnames instead of IP addresses. If it fails at any point, you have a name resolution problem.

Check your Control Panel/Network/Protocols/Properties,DNS settings, making sure neither enable lmhosts for lookup or enable dns for lookup is checked in your networking setup, that your hostname and domain are correct, and finally, check your hosts file for accuracy.

Some notes and tips on particular services:
As described here, the gateway should support ICMP requests, Web Surfing, SMTP/POP3, and telnet.

For additional services, particularly ones that assume things about certain ports, you may or may not need to load some additional modules at boot time.

For a complete listing of the supported applications, see the IP_Masq HOW-TO.

At a minimum, you will probably want to load the ftp module, and the real audio module.

Change directory to the /etc/rc.d/rc.local file mentioned previously, and add these lines BEFORE the ipfwadm rules you put in here earlier.

/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio

NOTE ON MODULES: There are many more modules available, these are simply the two I use most. To add additional modules, just add them using the above lines as a guide.

Example rc.local scripts:
RedHat -
>snip of lots of stuff<
cp -f /etc/issue /etc/issue.net
echo >> /etc/issue
# Now, the stuff you add -
echo "Loading Masquerade Modules .."
/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
echo "Done..."
echo "Loading Masquerade and Routing Rules.."
ipfwadm -F -p deny
ipfwadm -F -a masquerade -W ppp0 -S 192.168.1.0/24 0.0.0.0/0
echo "Done.."
# if configured properly, no pppupd required

Slackware (with my script)
>snip gpm stuff<
# Now, the stuff you add -
/usr/sbin/unicom
echo "Loading Masquerade Modules .."
/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
echo "Done..."
echo "Loading Masquerade and Routing Rules.."
ipfwadm -F -p deny
ipfwadm -F -a masquerade -W ppp0 -S 192.168.1.0/24 0.0.0.0/0
echo "Done.."
pppupd > /dev/null

Slackware (with pppsetup script NOT RECOMMENDED)
>snip gpm stuff<
# Now, the stuff you add -
ppp-go -q
echo "Loading Masquerade Modules .."
/sbin/depmod -a
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio
echo "Done..."
echo "Loading Masquerade and Routing Rules.."
ipfwadm -F -p deny
ipfwadm -F -a masquerade -W ppp0 -S 192.168.1.0/24 0.0.0.0/0
echo "Done.."
pppupd > /dev/null
 

References:
Previous Columns:
November, December, and January columns

Other:
IP_Masq mini HOW-TO
Ethernet HOW-TO
Net-3 HOW-TO
Network Administrator's Guide
Mastering Windows NT Server 4 (3rd Edition)
ISP Hookup HOW-TO
ISP Connectivity HOW-TO

Resources for further information:
Web Resources:
http://ipmasq.cjb.net/
http://www.redhat.com/
http://www.linuxgazette.com
http://www.linuxjournal.com/
http://www.cdrom.com/

Newsgroups:
alt.unix.wizards
comp.security.unix
comp.unix.admin
alt.os.linux.slackware
comp.os.linux.networking
comp.os.linux.hardware
linux.redhat.misc

Print Materials:
Linux - Installation, Configuration, and Use (Michael Kofler)
RedHat Linux Installation Guide - versions 4.2, 5.0, 5.1 (Red Hat Software, Inc.)
Linux Gazette - (SSC Inc.)
Linux Journal - (SSC Inc.)
Linux - The Complete Reference (Walnut Creek CDROM Books)

Next month, installing a caching web and nameserver, some tips and tricks for advanced configuration, and some secrets to improve performance!

Linux Installation Primer #1, September 1998
Linux Installation Primer #2, October 1998
Linux Installation Primer #3, November 1998
Linux Installation Primer #4, December 1998
Linux Installation Primer #5, January 1999