<!doctype linuxdoc system>

<!-- LinuxDoc file was created by LyX 1.0 (C) 1995-1999 by <pramsey> Thu Jun 22 09:21:23 2000
 -->
 <article>
 <title>
Red Hat Linux 6.X as an Internet Gateway for a Home Network
 </title>
 <author>
Paul Ramsey &lt;pramsey@refractions.net&gt;
 </author>
 <date>
June 22, 2000
 </date>
 <abstract>
A simple tutorial on configuring Red Hat 6 and related variants to operate
 as an internet gateway to a small home or office network. Topics covered include
 masquerading, DNS, DHCP, and basic security.
 </abstract>
 <toc>
 <sect>
Introduction
 <p>
This page contains a simple cookbook for setting up Red Hat 6.X as an internet
 gateway for a home network or small office network. The instructions are very
 simplified: no special cases will be discussed, and some assumptions will be
 made about which network addresses are to be used. The most important assumptions
 are:
 </p>
 <p>
 <itemize>
  <item>
You have a fulltime Cable or ADSL connection to the Internet. 
  <item>
You can successfully install <htmlurl url="http://www.redhat.com" name="Red Hat 6.X"> on at least one of your computers. Note that
 these directions are also valid for Red Hat derivatives, such as <htmlurl url="http://www.linux-mandrake.com" name="Mandrake 6.X"> which is
 distributed by MacMillan Publishing under a variety of labels. 
  <item>
Your Linux computer has two network cards installed in it and both are
 compatible with Linux. 
  <item>
You have an ethernet hub if you are networking more than one computer or
 a cross-over cable if you are only networking one computer. 
  <item>
You know how to edit text files on your Linux machine. 
  <item>
You can log into your machine as <tt>root</tt>. You know how to install RPM packages
 from your Linux CDROM. 
 </itemize>
</p> <p>
If you do not meet any of these assumptions, then this document probably
 isn't for you.
 </p>
 <p>
There is nothing special that you have to do during the installation process.
 Simply choose an installation which makes sense for you and go for it. This
 document gives directions on installing everything to do with networking from
 scratch, to avoid making any assumptions about what was installed or configured
 during installation. To ensure that things work and there is no confusion about
 what information goes where, all the configuration will be done by directly
 editing the system configuration files rather than using the GUI configuration
 tools provided with Red Hat. On the one hand, this might be a little harder
 than it has to be; on the other hand, your knowledge will be a good deal more
 transferable to different distributions and situations (like, what if X doesn't
 work, or you are setting up a headless server).
 </p>
 <sect1>
Versions
 <p>
The latest version of this document should always be available at <htmlurl url="http://www.coastnet.com/~pramsey/linux/homenet.html" name="http://www.coastnet.com/~pramsey/linux/homenet.html"> for
 the HTML version and <htmlurl url="http://www.coastnet.com/~pramsey/linux/homenet.sgml" name="http://www.coastnet.com/~pramsey/linux/homenet.sgml"> for the SGML version.
 </p>
 <p>
 <itemize>
  <item>
December 21, 1999 : First version.
  <item>
January 2, 2000 : Incorporated suggestions from John Mellor on outside
 networking quirks.
  <item>
January 22, 2000 : Minor update about identical network cards and info
 on IP aliasing from Chris Lea.
  <item>
March 16, 2000 : Some information on name server security and on supporting
 Caldera from Nelson Gibbs.
  <item>
June 22, 1000 : Red Hat 6.2 configuration quirk documented. More PPPoE
 info from Kerr First.
 </itemize>
</p> <sect1>
Copyright
 <p>
Copyright © 2000, Paul Ramsey.
 </p>
 <p>
This manual may be reproduced in whole or in part, without fee, subject
 to the following restrictions: 
 </p>
 <p>
 <itemize>
  <item>
The copyright notice above and this permission notice must be preserved
 complete on all complete or partial copies.
  <item>
Any translation or derived work must be approved by the author in writing
 before distribution. 
  <item>
If you distribute this work in part, instructions for obtaining the complete
 version of this manual must be included, and a means for obtaining a complete
 version provided. 
  <item>
Small portions may be reproduced as illustrations for reviews or quotes
 in other works without this permission notice if proper citation is given.
 
 </itemize>
</p> <p>
Exceptions to these rules may be granted for academic purposes: Write to
 the author and ask. These restrictions are here to protect us as authors, not
 to restrict you as learners and educators.
 </p>
 <sect>
Plugging Things In
 <p>
Depending on whether you are using a hub or not, your network topology
 will differ slightly. I am only covering networking with RJ45 cabling (the
 stuff that looks like phone cables on steroids) and not covering thin coax.
 With thin coax you can network multiple machines without requiring a hub, but
 have to be more careful about terminating connections and so on. If you know
 networking already, these instructions will be largely redundant.
 </p>
 <sect1>
With a Hub
 <p>
If you have a hub, your network will look like <url url="http://www.coastnet.com/~pramsey/linux/w_hub.gif" name="this">.
 </p>
 <p>
Connect the <tt>eth0</tt> card on the Linux box to the cable modem or ADSL box using
 the cable supplied by the service provider during their install (or one you
 know works in that configuration. This is important because sometimes cable
 modems like to be connected with a crossover and sometimes they like a straight-through
 through cable: the one the company gives you is the one you want to use.
 </p>
 <p>
Connect the <tt>eth1</tt> card on the Linux box to the hub with a straight-through
 cable. Connect all your other computers to the hub with straight-through cables.
 </p>
 <sect1>
Without a Hub
 <p>
If you do not have a hub, you can still connect one computer to your Linux
 box, using a crossover cable. Your topology will look like <url url="http://www.coastnet.com/~pramsey/linux/wo_hub.gif" name="this">.
 </p>
 <p>
Connect the <tt>eth0</tt> card on the Linux box to the cable modem or ADSL box using
 the cable supplied by the service provider. Connect the <tt>eth1</tt> card on the Linux
 box to the other computer with a crossover cable.
 </p>
 <sect1>
With Only One Network Card
 <p>
This is not a recommended configuration (in this configuration your internal
 and external networks are on the same physical network, and are therefor theoretically
 more susceptible to cracking; in reality, the risk is probably very low), but
 it <em>can</em> be done. Your mileage may vary.
 </p>
 <p>
The Linux kernel includes support for "IP aliasing", which allows an ethernet
 card to service two different IP addresses simultaneously. The stock kernels
 shipped with Red Hat and Mandrake include support for IP aliasing by default.
 To set up your gateway with only one ethernet card, in all the subsequent code
 examples, simply replace <tt>eth1</tt> with <tt>eth0:0</tt>. 
 </p>
 <p>
<em>In a single-card situation, running a DHCP server is </em>not<em> recommended.
</em>
 </p>
 <p>
Plug all your machines and your cable modem or ADSL box into the hub. Cross
 your fingers and continue.
 </p>
 <sect>
Configuring Networking
 <p>
OK, by now you have installed Linux on your gateway computer. You may have
 even configured one of your networking cards, and set up connectivity to the
 Internet. However, we are going to start from scratch and pretend that nothing
 is configured at all.
 </p>
 <p>
Log in as <tt>root</tt>. All the instructions given in this document assume you
 are logged in as root. 
 </p>
 <p>
The Linux kernel refers to your two ethernet cards as <tt>eth0</tt> and <tt>eth1</tt>, so
 that is how I'll be referring to them from now on too. The trouble is, which
 one is which? Here's a &quot;simple&quot; way of figuring out, guaranteed to
 work at least 50&percnt; of the time: lay your computer on the desk with the
 motherboard horizontal and the back panel facing you (as you would if you were
 going to open it and do some work on it). The leftmost card is <tt>eth0</tt> -- you
 might want to label it with some masking tape. Now, write down on a piece of
 paper the make and model of both <tt>eth0</tt> and <tt>eth1</tt>.
 </p>
 <p>
OK, let's see if <tt>eth0</tt> and <tt>eth1</tt> are recognized automatically by the kernel.
 Type <tt>ifconfig eth0</tt> and <tt>ifconfig eth1</tt>. In both cases, if the kernel is recognizing
 your card, you should see something like this (bearing in mind that the numbers
 and whatnot will be different):
 </p>
 <p>
 <verb>
eth0   Link encap: Ethernet   HWaddr 00:60:67:4A:02:0A 
       inet addr:0.0.0.0  Bcast:0.0.0.0  Mask:255.255.255.255
       UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
       RX packets:466 errors:0 dropped:0 overruns:0 frame:0
       TX packets:448 errors:0 dropped:0 overruns:0 carrier:0
       collisions:85 txqueuelen:100 
       Interrupt:10 Base address:0xe400
 </verb>
</p> <p>
If the kernel is not recognizing your network card you will see something
 like this: 
 </p>
 <p>
 <verb>
eth0: error fetching interface information: Device not found.
 </verb>
</p> <sect1>
Configuring a Network Driver
 <p>
If both of your cards were found, skip to the next section. Otherwise,
 read this section.
 </p>
 <p>
OK, so one or both of your cards are not recognized by the kernel. This
 is not a problem, really. What we're going to have to do is tell the kernel
 more explicitly how to find your cards. There are lots of twists and turns
 here, and I'm not going to cover all of them. Remember, when the going gets
 tough, the tough turn to the <htmlurl url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html" name="Ethernet HOWTO">. Here's some summary advice:
 </p>
 <p>
 <itemize>
  <item>
<em>You have a PCI network card.</em> You are probably sitting pretty, assuming
 it is not so new and cutting edge that no drivers exist. You can often find
 out a great deal about your network cards (and other things) by reading through
 <tt>/proc/pci</tt> and noting down makes and models. 
  <item>
<em>You have an ISA network card.</em> It is possible you will have to know the
 IO base address and the IRQ the card is operating on. You have manuals, right?
 Right? If not, this would be a good time to surf to the manufacturer's web
 site and see if they have any online references. Or if you have an old DOS
 configuration diskette, boot to DOS and see if there is a setup program which
 will read and set the address and IRQ. 
  <item>
<em>You have an ISA Plug'n'Play card.</em> You'll have to learn how to configure
 it first -- read the <htmlurl url="http://www.linuxdoc.org/HOWTO/Plug-and-Play-HOWTO.html" name="Plug'n'Play HOWTO">. Fortunately, oncee you've configured your card you will
 know exactly what the IO base and IRQ are. 
 </itemize>
</p> <p>
Now, since you know what the make and model of <tt>eth0</tt> and <tt>eth1</tt> are you can
 go to the <htmlurl url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO-5.html" name="compatibility page"> of the <htmlurl url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html" name="Ethernet HOWTO"> and look up your card. Take note of the recommended driver,
 and any information about special options your card may require. Write it down.
 </p>
 <p>
It's time to edit a configuration file! The file we will be editing is
 <tt>/etc/conf.modules</tt>. Open this file up in the text editor of your choice. Because
 there are so many possibilities and combinations of things which can go in
 this file, I'm going to give my own gateway as an example. I have a PCI 10/100Mb
 card based on the VIA Rhine chip, and a plain-jane 10Mb NE2000 ISA clone. I
 use the 100Mb card for the internal network and the 10Mb card for the external
 connection. My <tt>/etc/conf.modules</tt> file looks like this:
 </p>
 <p>
 <verb>
alias parport_lowlevel parport_pc 
alias eth0 ne 
options ne io=0x300 irq=10 
alias eth1 via-rhine 
 </verb>
</p> <p>
My <tt>conf.modules</tt> file is laid out as follows: 
 </p>
 <p>
 <itemize>
  <item>
The first line is there to configure my parallel port for printing. You
 probably have a similar line. Leave it alone. 
  <item>
The second line (<tt>alias eth0 ne</tt>) tells the kernel to use the ne driver for
 the <tt>eth0</tt> device. 
  <item>
The third line (<tt>options ne io=0x300 irq=10</tt>) tells the ne driver at which
 io address and irq interrupt it will find the ISA card at. If you have ISA
 cards you will probably have to use this kind of directive, just replace the
 driver, io and irq directives with the correct information for your card. 
  <item>
The fourth line (<tt>alias eth1 via-rhine</tt>) tells the kernel to use the via-rhine
 driver for <tt>eth1</tt>. Because my <tt>eth1</tt> card is a PCI card, I do not need to provide
 io or irq information: the PCI subsystem configures the device automatically.
 </itemize>
</p> <p>
You will want to ensure that you have alias entries in <tt>conf.modules</tt> for
 both your cards, and correct options lines for all your ISA cards. You may
 already have lines in <tt>conf.modules</tt> for any ethernet cards you configured during
 installation.
 </p>
 <p>
When you have finished editing <tt>conf.modules</tt>, try <tt>ifconfig eth0</tt> and <tt>ifconfig
 eth1</tt> again. You may have to apply some trial and error if you are messing with
 IO addresses and IRQs without a manufacturers manual.
 </p>
 <sect2>
Two Identical Network Cards
 <p>
So, you were really really smart, bought two identical network cards for
 your Linux gateway, and now you cannot get them to work together? Do not worry,
 getting them to coexist is just a matter of using the correct syntax in <tt>/etc/conf.modules</tt>.
 For this example, the addresses and IRQ numbers are made up, and I will assume
 that you have bought a matched pair of NE2000 clones (a common choice). Your
 <tt>/etc/conf.modules</tt> file should look like this:
 </p>
 <p>
 <verb>
alias eth0 ne
alias eth1 ne
options ne io=0x330,0x360 irq=7,9 
 </verb>
</p> <p>
The addressing options are all given on the same line, and the first number
 for each addressing type is for <tt>eth0</tt>, the second number for <tt>eth1</tt>.
 </p>
 <sect1>
Configuring the Inside Network
 <p>
The &quot;inside network&quot; is the network which all your home/office
 machines will talk on. The &quot;outside network&quot; is the big scary internet
 on the other side of the Linux box. By and large, the inside network will be
 completely insulated from the outside network by the Linux box, which will
 operate as a medium strength firewall.
 </p>
 <sect2>
The Network Device
 <p>
Now that your drivers are working and you can see both <tt>eth0</tt> and <tt>eth1</tt> in
 <tt>ifconfig</tt> it is time to set up the internal home network. I am assuming that
 you are going to put your internal network on <tt>eth1</tt> and your external device
 on <tt>eth0</tt>.
 </p>
 <p>
Your internal network is going to be a private network and will therefor
 be on a special network reserved for internal networking: <tt>192.168.1.0</tt>. This
 is a &quot;private Class C network&quot;, in case you want to impress your
 friends.
 </p>
 <p>
First we need to make sure networking is turned on. Edit the file <tt>/etc/sysconfig/network</tt>
 and make sure the following lines exist:
 </p>
 <p>
 <verb>
NETWORKING=yes 
FORWARD_IPV4=yes
 </verb>
</p> <p>
The first line tells Linux that we want the network devices brought up
 at boot time. The second line tells Linux to enable IP forwarding. This is
 required when we start configuring masquerading in Section 4.
 </p>
 <p>
<em>Redhat 6.2 Note:</em> In order to properly support IP forwarding and masquerading,
 Red Hat 6.2 requires changes to the <tt>/etc/sysctl.conf</tt> file. Make sure the following
 lines exist and are set to the correct values:
 </p>
 <p>
 <verb>
net.ipv4.ip_forward = 1 
net.ipv4.ip_always_defrag = 1 
 </verb>
</p> <p>
All the network interface settings for Red Hat and Red Hat derivatives
 are contained in files in the <tt>/etc/sysconfig/network-scripts</tt> directory. Enter
 that directory, and create a new file <tt>ifcfg-eth1</tt>. Put the following into the
 <tt>ifcfg-eth1</tt> file:
 </p>
 <p>
 <verb>
DEVICE=eth1 
IPADDR=192.168.1.1 
ONBOOT=yes
 </verb>
</p> <p>
This code tells the networking scripts to configure eth1 at boot time and
 to give it a particular IP address. Activate your network with the new settings
 with the following command: <tt>/etc/rc.d/init.d/network restart</tt>
 </p>
 <sect2>
The DHCP Server
 <p>
A DHCP server will automatically configure devices on your internal home
 network with IP addresses. This is very useful for people with laptops: they
 can simply plug their machines in and be immediately properly configured. If
 you do not want a DHCP server on your internal network, just skip to the next
 section.
 </p>
 <p>
First you need to be sure you have the DHCP server installed. Mount your
 Linux CD and install the <tt>dhcp</tt> RPM. Now edit the <tt>/etc/dhcpd.conf</tt> file and put
 the following (and only the following) in it: 
 </p>
 <p>
 <verb>
subnet 192.168.1.0 netmask 255.255.255.0 &lcub;
  range 192.168.1.2 192.168.1.60;
  default-lease-time 86400;
  max-lease-time 86400;
  option routers 192.168.1.1;
  option ip-forwarding off;
  option broadcast-address 192.168.1.255;
  option subnet-mask 255.255.255.0;
&rcub;
 </verb>
</p> <p>
If you are going to set up your Linux box as a caching domain name server,
 insert the following option:
 </p>
 <p>
 <verb>
option domain-name-servers 192.168.1.1;
 </verb>
</p> <p>
If you know your outside DNS addresses and you are <em>not</em> going to use the
 Linux box for DNS, insert the following option, where x.x.x.x and y.y.y.y are
 IP numbers of the DNS servers:
 </p>
 <p>
 <verb>
option domain-name-servers x.x.x.x, y.y.y.y;
 </verb>
</p> <p>
If you are going to run Samba file sharing on the Linux box for your Windows
 computers, add the following options to use the Linux box as the default WINS
 and browsing server:
 </p>
 <p>
 <verb>
option netbios-name-servers 192.168.1.1; 
option netbios-dd-server 192.168.1.1; 
option netbios-node-type 8; 
option netbios-scope &quot;&quot;;
 </verb>
</p> <p>
Configuring Samba and WINS is well beyond the scope of this document. If
 you need some pointers, start with the <htmlurl url="http://www.linuxdoc.org/HOWTO/SMB-HOWTO.html" name="SMB HOWTO"> and go on from there.
 </p>
 <p>
There are still a few more steps. Next, edit the <tt>/etc/rc.d/init.d/dhcpd</tt>
 file and look for the following line:
 </p>
 <p>
 <verb>
/sbin/route add -host 255.255.255.255 dev eth1
 </verb>
</p> <p>
Windows DHCP clients require a particular broadcast address in DHCP responses,
 and this command forces the Linux TCP/IP stack to produce it. If you cannot
 find that line in the file, <em>add it</em>. If you <em>do</em> find a line like that one, make
 sure that the device it references is <tt>eth1</tt>.
 </p>
 <p>
The next step is to alter the <tt>/etc/rc.d/init.d/dhcpd</tt> file to use <tt>eth1</tt> as
 the default device. Replace the line:
 </p>
 <p>
 <verb>
daemon /usr/sbin/dhcpd
 </verb>
</p> <p>
With:
 </p>
 <p>
 <verb>
daemon /usr/sbin/dhcpd eth1
 </verb>
</p> <p>
OK, now we are ready to start up DHCP. First start the DHCP server with
 the command: <tt>/etc/rc.d/init.d/dhcpd start</tt>. 
 </p>
 <p>
Finally, we have to make sure that the DHCP server will start at re-boot
 time. Some RPM packages of the DHCP server do not include directives to ensure
 the server starts every time, so we'll make sure it gets started by invoking
 the command <tt>chkconfig dhcpd on</tt>.
 </p>
 <p>
This command causes RedHat to add the dhcp startup script to the various
 runlevel directories under <tt>/etc/rc.d</tt>. In runlevels 3 and 5 (multiuser console
 and multiuser X) the DHCP server is started. In runlevels 0, 1 and 6 (shutdown,
 single user and reboot) the DHCP server is stopped.
 </p>
 <sect2>
The Client Computers
 <p>
If you have set DHCP up, configuring your client computers is very easy:
 just enable DHCP configuration. For Windows computers, this involves opening
 the &quot;Control Panel&quot; and then the &quot;Networking&quot; option. Find
 the &quot;TCP/IP&quot; protocol and opt to &quot;Configure&quot; it. Check
 the box that says to &quot;Configure TCP/IP address automatically&quot;, apply
 your changes, and reboot.
 </p>
 <p>
Before you reboot, you might want to type the following command: <tt>tail -f
 /var/log/messages</tt>. This will watch the Linux system log continuously. If all
 goes well, when you reboot your Windows computer, you will see it request an
 IP address and see the DHCP server respond. Control-C exits the <tt>tail -f</tt> command.
 </p>
 <p>
If you have not set up DHCP, configuration is still fairly easy. Again,
 open the &quot;Networking&quot; option from the &quot;Control Panel&quot;,
 and choose to configure the TCP/IP protocol. You can assign your client computers
 any address in the 192.168.1.0 network except 192.168.1.0 (the network address),
 192.168.1.255 (the broadcast address) or 192.168.1.1 (your Linux server). Never
 give two computers the same IP address. Set the "Gateway" address to 192.168.1.1,
 so that outgoing traffic is routed through your Linux gateway.
 </p>
 <p>
The <htmlurl url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html" name="IP Masquerading HOWTO"> has very detailed information on client configuration in the <htmlurl url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO-4.html" name="Configuration Section">.
 </p>
 <p>
In general, to configure a client computer, either enable DHCP configuration,
 or manually assign it an address in the 192.168.1.X network with a gateway
 of 192.168.1.1. Let the DNS server be either 192.168.1.1 if you are running
 a caching DNS server (see below) or point the DNS at the addresses assigned
 by your network provider.
 </p>
 <sect2>
The DNS Server
 <p>
Setting up your Linux box as a caching DNS server will (slightly) improve
 your netsurfing speed, because commonly used DNS addresses will get cached
 inside your network and not have to be retrieved from the outside.
 </p>
 <p>
If you are interesting in doing full blown DNS, there is a great deal of
 complexity to be learned. There is a <htmlurl url="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html" name="DNS HOWTO"> available, and the book <htmlurl url="http://www.oreilly.com/catalog/dns3" name="DNS and BIND"> is a good (and
 very comprehensive) paper reference.
 </p>
 <p>
In order for your client machines to take advantage of the caching server,
 they must be configured to use the Linux gateway as their primary DNS server.
 The DHCP directives given in section 3.2.2 are one way to accomplish this.
 If you are configuring your client computers by hand, you can change the DNS
 configurations in the same control tabs you used to set the IP address of the
 machine.
 </p>
 <p>
To install the DNS server, first install the <tt>bind</tt> RPM, then install the
 <tt>caching-nameserver</tt> RPM. At this point, you are almost ready.
 </p>
 <p>
As installed, the caching server will work fine, but if you know the IP
 addresses of the internet providers DNS servers you can improve performance
 slightly by editing the <tt>/etc/named.conf</tt> file and adding the following line
 after the <tt>directory</tt> line (where x.x.x.x and y.y.y.y are the primary and secondary
 DNS servers):
 </p>
 <p>
 <verb>
forwarders &lcub; x.x.x.x; y.y.y.y; &rcub;; 
 </verb>
</p> <p>
This change makes your DNS server first query the ISPs DNS servers before
 traversing the internet in search of a given address. The ISPs servers often
 have a rich cache of DNS information and can provide a much faster answer than
 your server could.
 </p>
 <p>
The <tt>named</tt> daemon has had some security problems over the past 12 months,
 so it is very important that you have the latest version running, and make
 some changes to the default settings to enhance security.
 </p>
 <p>
 <enum>
  <item>
Check your version of <tt>bind</tt> and make sure it is at least 8.2.2. Go to the
 <htmlurl url="ftp://updates.redhat.com" name="Red Hat Updates"> or <htmlurl url="ftp://ftp.linux-mandrake.com/pub/updates" name="Mandrake Updates"> sites to check for the latest version.
  <item>
Restrict access to your name server to just the local network by adding
 the line <tt>allow-query &lcub; 192.168.1/24; 127.0.0.1/32; &rcub;;</tt> to the <tt>/etc/named.conf</tt>
 file after the <tt>forwarders</tt> line.
  <item>
Avoid running your name server as <tt>root</tt>. If your server is running as root,
 an exploit of the server will grant the exploiter root privledges. If you run
 the server as a powerless user, like <tt>nobody</tt>, you can lower the risk of a name
 server exploit. To run your name server as <tt>nobody</tt>, edit the <tt>/etc/rc.d/init.d/named</tt>
 file and change the line <tt>daemon named</tt> to <tt>daemon named -u nobody -g nobody</tt>.
 </enum>
</p> <p>
Make sure your DNS server will start at boot time: <tt>chkconfig named on</tt>.
 Again, this ensures that the server will start in the usual runlevels (3 and
 5) at boot time.
 </p>
 <p>
OK, now you can start your DNS server: <tt>/etc/rc.d/init.d/named start
</tt>
 </p>
 <sect2>
Testing the Inside Network
 <p>
Until we configure the outside network, the DNS service will not work (since
 it has to communicate with other DNS servers on the internet), but we can test
 out the basic internal connectivity with the <tt>ping</tt> program.
 </p>
 <p>
On one of your client computers, open up a terminal (MSDOS) window, and
 type <tt>ping 192.168.1.1</tt>. This will send out packets to your Linux computer at
 regular intervals, and your Linux computer will reflect the packets back. If
 things are working right, you should see a set of packet return times. 
 </p>
 <sect1>
Configuring the Outside Network
 <p>
Now we're ready to configure the outside network. Sometimes this will be
 difficult, depending on how well your internet provider supports Linux. If
 you have difficulty, there is an <htmlurl url="http://www.linuxdoc.org/HOWTO/mini/ADSL.html" name="ADSL mini-HOWTO"> which covers ADSL issues in some detail.
 If I can find a Cable Modem HOWTO, I will link to it also.
 </p>
 <p>
The main problem with most outside connections is <em>getting an IP address</em>.
 Some internet providers hand out static IP addresses to cable or ADSL subscribers,
 and in that case configuration is easy. However, most providers have now moved
 to dynamic configuration via (you guessed it) DHCP. This means that your Linux
 computer will likely be a DHCP <em>server</em> on your <tt>eth1</tt> interface, and a DHCP <em>client</em>
 on your <tt>eth0</tt> interface.
 </p>
 <p>
Additionally, many providers have taken to providing their services in
 specialized non-standard ways which assume their customers will be using Windows.
 Some of those cases will be discussed at the end of section 3.3.2.
 </p>
 <sect2>
With a Static IP
 <p>
If your internet provider has assigned you a static IP address, you are
 sitting pretty. First, create a new interface configuration file, <tt>/etc/sysconfig/network-scripts/ifcfg-eth0</tt>
 and put the following in it:
 </p>
 <p>
 <verb>
DEVICE=eth0
IPADDR=x.x.x.x
NETMASK=y.y.y.y
ONBOOT=yes
 </verb>
</p> <p>
Just fill in x.x.x.x and y.y.y.y with the values given by your internet
 provider. Now edit the <tt>/etc/resolv.conf</tt> file and enter the following information:
 </p>
 <p>
 <verb>
search provider_domain_here
nameserver n.n.n.n
nameserver m.m.m.m
 </verb>
</p> <p>
The provider_domain should be supplied by your internet provider. Also
 enter the primary and secondary DNS servers in the n.n.n.n and m.m.m.m lines.
 If you have set up the Linux box as a DNS server, you can add a line before
 the other nameserver entries: <tt>nameserver 127.0.0.1</tt>. This will make your Linux
 server use the caching server before asking the outside servers for DNS information.
 </p>
 <sect2>
With DHCP
 <p>
If your internet provider uses DHCP configuration, you need to create a
 new interface configuration file, <tt>/etc/sysconfig/network-scripts/ifcfg-eth0
 </tt>and put the following in it:
 </p>
 <p>
 <verb>
DEVICE=eth0 
BOOTPROTO=dhcp 
ONBOOT=yes
 </verb>
</p> <p>
Now make sure that the dhcpcd client daemon is installed on your system.
 Go to your Linux CD and install the <tt>dhcpcd</tt> RPM package.
 </p>
 <p>
It's time to test your new network configuration. Just use the command
 <tt>/etc/rc.d/init.d/network restart</tt>. Now test your outside connection with ping.
 Ping a computer on the internet, like <tt>www.yahoo.com</tt> and see if anything comes
 back.
 </p>
 <sect2>
Quirks and Anomalies
 <p>
Your situation may differ from the very simple situations described above.
 Here are some short remarks on the various difficulties and links to more authoritative
 resources and addressing them. Thanks to John Mellor for supplying the links
 and impetus for adding this section.
 </p>
 <sect3>
PPP Over Ethernet (PPPoE)
 <p>
Several ADSL providers (Bell Atlantic, for example) are now insisting that
 their new customers connect to the service using the &quot;PPP over Ethernet&quot;
 protocol (PPPoE). To this end, they provide a Windows client program: not very
 useful for Linux users. Fortunately, PPPoE is a simple protocol and several
 efforts are underway to support it under Linux.
 </p>
 <p>
 <itemize>
  <item>
The <htmlurl url="http://www.roaringpenguin.com/pppoe.html" name="Roaring Penguin PPPoE Client"> comes highly recommended by reader Kerr First.
  <item>
<htmlurl url="http://www.panix.com/~dfoster/prog/linux/pppoe.html" name="PPPoE on Linux for Bell Sympatico">
  <item>
PPPoE on Linux for Sympatico (<htmlurl url="http://www.carricksolutions.com/pppoe.htm" name="General Info">) (<htmlurl url="http://www.carricksolutions.com/linuxpppoe.htm" name="Linux Info">)
 </itemize>
</p> <sect3>
Stupid DHCP Tricks
 <p>
One of the favorite tricks network providers play is to tie your service
 to a unique hostname, or even a unique network interface card. This is presumably
 to keep you from plugging multiple computers into your ethernet port using
 a hub (of course, by using Linux and Masquerading you're getting the same effect
 with better security and the cable company has no way of knowing!).
 </p>
 <p>
If the provider has given you a hostname and insisted that you set your
 Windows box with that name in order you use their service, then you'll have
 to make sure that your Linux box sends in that hostname when requesting an
 address from the DHCP server.
 </p>
 <p>
The Red Hat DHCP client is called when you set the BOOTPROTO to dhcp in
 the interface configuration file, but it is called without reference to a hostname.
 To call the program with a hostname, in Red Hat 6.1, edit the <tt>/etc/sysconfig/network</tt>
 file, and change the line:
 </p>
 <p>
<tt>HOSTNAME=</tt>
 </p>
 <p>
To read this: 
 </p>
 <p>
<tt>HOSTNAME=your_isp_assigned_name</tt>
 </p>
 <p>
This may not work in some of the Red Hat variants. If it does not work,
 check the <tt>/sbin/ifup</tt> script and see if the call to dhcpcd and pump include
 a -h &dollar;HOSTNAME switch. If they do not, add them, so the calls look like
 <tt>/sbin/dhcpcd -i &dollar;DEVICE -h &dollar;HOSTNAME</tt> and <tt>/sbin/pump -i &dollar;DEVICE
 -h &dollar;HOSTNAME</tt>.
 </p>
 <sect3>
Road Runner
 <p>
The Road Runner cable service has a special login process which must be
 run before the server can be used. Fortunately, a detailed <htmlurl url="http://usmcug.usm.maine.edu/~kpesce/rr" name="Linux Road Runner HOWTO"> is available.
 </p>
 <sect2>
Looking at the Network Entries
 <p>
Now you can admire your work. Type <tt>ifconfig</tt> to see all your configured
 devices. On my gateway computer, it looks like this:
 </p>
 <p>
 <verb>
eth0  Link encap:Ethernet  HWaddr 00:60:67:4A:02:0A 
      inet addr:24.65.182.43  Bcast:24.65.182.255  Mask:255.255.255.0 
      UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1 
      RX packets:487167 errors:0 dropped:0 overruns:0 frame:0 
      TX packets:467064 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:89 txqueuelen:100 
      Interrupt:10 Base address:0xe400
eth1  Link encap:Ethernet  HWaddr 00:80:C8:D3:30:2C 
      inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0 
      UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1 
      RX packets:284112 errors:0 dropped:0 overruns:0 frame:1 
      TX packets:311533 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:37938 txqueuelen:100 
      Interrupt:5 Base address:0xe800
lo    Link encap:Local Loopback 
      inet addr:127.0.0.1  Mask:255.0.0.0 
      UP LOOPBACK RUNNING  MTU:3924  Metric:1 
      RX packets:12598 errors:0 dropped:0 overruns:0 frame:0 
      TX packets:12598 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:0 txqueuelen:0
 </verb>
</p> <p>
Note that the <tt>eth0</tt> interface has a fancy outside IP address, and the <tt>eth1</tt>
 address has a private internal address.
 </p>
 <p>
You can look at the network routes by typing the <tt>route</tt> command. On my gateway
 computer it looks like this:
 </p>
 <p>
 <verb>
  Kernel IP routing table 
  Destination     Gateway      Genmask         Flags Metric Ref Use Iface 
  255.255.255.255 *            255.255.255.255 UH    0      0     0 eth1 
  192.168.1.0     *            255.255.255.0   U     0      0     0 eth1 
  24.65.182.0     *            255.255.255.0   U     0      0     0 eth0 
  127.0.0.0       *            255.0.0.0       U     0      0     0 lo 
  default         24.65.182.1  0.0.0.0         UG    0      0     0 eth0
 </verb>
</p> <p>
Here we can see the outside network is set up, the inside network is set
 up, the local device is set up, the special 255.255.255.255 broadcast address
 is set up, and the default route is set up to point to the internet providers
 gateway. Perfect!
 </p>
 <p>
Now you have the outside, and the inside. All the remains is to open the
 door between the two. First though, we have to make sure no monsters can get
 in from the outside.
 </p>
 <sect1>
Security
 <p>
One of the drawbacks of being permanently connected to the internet via
 ADSL or cable is that your computer is exposed to potential security threats
 24 hours a day, 7 days a week. Using Linux as a gateway reduces the risks,
 because it hides all your other computers: as far as the rest of the internet
 is concerned, only your Linux box is available for connections. This means
 that your network is only as secure as your Linux box, so at this point I'll
 give a few basic tips to make your box more secure.
 </p>
 <p>
First, you need to shut out all the bad guys. To do this, edit the file
 <tt>/etc/hosts.deny</tt> and make sure it looks just like this:
 </p>
 <p>
 <verb>
&num; 
&num; hosts.deny  This file describes the names of the hosts which are 
&num;             *not* allowed to use the local INET services, as decided 
&num;             by the '/usr/sbin/tcpd' server. 
&num; 
&num;            The portmap line is redundant, but it is left to remind you that 
&num;        the new secure portmap uses hosts.deny and hosts.allow. In particular 
&num;             you should know that NFS uses portmap! 
ALL: ALL 
 </verb>
</p> <p>
This tells the &quot;TCP wrappers&quot; -- which control 95&percnt; of
 incoming connections -- to deny all connections from all hosts. That's a pretty
 good rule! But, it will also keep you from connecting to your Linux box from
 inside your home network, which is annoying, so we will make one exception.
 Edit the file <tt>/etc/hosts.allow</tt> and make sure it looks just like this:
 </p>
 <p>
 <verb>
&num; 
&num; hosts.allow  This file describes the names of the hosts which are 
&num;              allowed to use the local INET services, as decided 
&num;              by the '/usr/sbin/tcpd' server. 
&num; 
ALL: 127.0.0.1 
ALL: 192.168.1.
 </verb>
</p> <p>
This tells the &quot;TCP wrappers&quot; that they can allow connections
 to all services from the local device (127.0.0.1) and from your home network
 (192.168.1.).
 </p>
 <p>
You have now locked the monsters outside, with a strong padlock. If you
 want to put up bars and alarm systems, you will have to be alot more sophisticated.
 The <htmlurl url="http://www.linuxdoc.org/HOWTO/Security-HOWTO.html" name="Security HOWTO"> is a good place to start if you want to learn more about securing your
 Linux box.
 </p>
 <sect>
Configuring Masquerading
 <p>
All right! The preliminaries are over, this is where the magic begins.
 IP masquerading is one of the truly magical services Linux provides. There
 are commercial products for Windows which do the same thing, but not nearly
 as efficiently: an ancient 386 can merrily provide IP masquerading services
 to a whole medium sized office, but cannot even run Windows 95, let alone the
 add on masquerading package. (As an addendum, I read in some recent reviews
 that Windows 2000 will support "connection sharing" without addon software. It
 looks like the companies which sold connection sharing software have been "embraced
 and extended" by MicroSoft. However, I wouldn't recommend you try the Windows
 2000 solution on a 386.)
 </p>
 <p>
Linux has an extremely versatile firewalling capability, and we are going
 to be using it in the simplest and crudest possible manner. If you want to
 learn how to do firewalling like an expert, you should read both the <htmlurl url="http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html" name="Firewalling HOWTO"> for an
 understanding of the theory and the <htmlurl url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="IPChains HOWTO"> for instructions on the new <tt>ipchains</tt> firewalling
 tool which ships with the Linux 2.2.X kernel (and by extension Red Hat 6.X).
 There is also now a very good <htmlurl url="http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html" name="IP Masquerading HOWTO"> available which has more details on masquerading
 tweaks.
 </p>
 <p>
Configuring simple masquerading is very very easy once your internal and
 external networking is operational. Edit the <tt>/etc/rc.d/rc.local</tt> file and add
 the following lines to the bottom:
 </p>
 <p>
 <verb>
&num; 1) Flush the rule tables. 
/sbin/ipchains -F input 
/sbin/ipchains -F forward 
/sbin/ipchains -F output 
&num; 2) Set the MASQ timings and allow packets in for DHCP configuration. 
/sbin/ipchains -M -S 7200 10 60 
/sbin/ipchains -A input -j ACCEPT -i eth0 -s 0/0 68 -d 0/0 67 -p udp 
&num; 3) Deny all forwarding packets except those from local network. 
&num;    Masquerage those. 
/sbin/ipchains -P forward DENY 
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ 
&num; 4) Load forwarding modules for special services. 
/sbin/modprobe ip_masq_ftp 
/sbin/modprobe ip_masq_raudio
 </verb>
</p> <p>
The last two lines insert kernel modules which allow FTP and RealAudio
 to work for computers on the inside network. There are other modules for special
 services which you can tack on if you need them:
 </p>
 <p>
 <itemize>
  <item>
CUSeeMe (<tt>/sbin/modprobe ip_masq_cuseeme</tt>) 
  <item>
Internet Relay Chat (<tt>/sbin/modprobe ip_masq_irc</tt>) 
  <item>
Quake (<tt>/sbin/modprobe ip_masq_quake</tt>) 
  <item>
VDOLive (<tt>/sbin/modprobe ip_masq_vdolive</tt>) 
 </itemize>
</p> <p>
Now you're ready to try masquerading! Run the <tt>rc.local</tt> script with the
 command <tt>/etc/rc.d/rc.local</tt> and you are ready to go! Sit down at one of your
 other computers and try some web surfing. With any luck, everything is now
 hunky dory.
 </p>
 <sect>
Problems
 <p>
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 <htmlurl url="mailto:pramsey@refractions.net" name="pramsey@refractions.net">.
 </p>
 <sect1>
ICQ Does Not Work
 <p>
Some portions of ICQ work fine over masquerading. Other portions do not
 work well at all. There is a <htmlurl url="http://members.xoom.com/djsf/masq-icq/" name="beta quality ICQ module"> under development, however, which addresses some
 (but not all) of the deficiencies of running ICQ over masquerading. The <tt>README</tt>
 file in the source code distribution describes how to compile the module. Once
 you have it compiled and installed, invoke <tt>/sbin/modprobe ip_masq_icq</tt>.
 </p>
 <sect1>
I Have Caldera 2.X Not Red Hat 6.X
 <p>
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:
 </p>
 <p>
 <enum>
  <item>
A <tt>GATEWAY=xxx.xxx.xxx.xxx</tt> statement in <tt>/etc/sysconfig/network-scripts/ifcfg-eth0</tt>
 &amp; <tt>eth1</tt> for the interface (local interface uses remote interface IP address
 and remote interface uses service provider's gateway IP).
  <item>
Make sure <tt>/etc/sysconfig/daemons/dhcpd</tt> script lists <tt>ROUTE_DEVICE</tt> as <tt>eth1</tt>
 <em>not</em> <tt>eth0</tt>.
  <item>
<tt>/etc/dhcpd.conf</tt> 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 &lcub; &rcub; 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.
  <item>
Do <em>not</em> add host route <tt>255.255.255.255</tt>, the <tt>/etc/rc.d/init.d/dhcpd</tt> script
 Caldera uses already fixes the problem. <em>DO</em> make sure to change all references
 to <tt>eth0</tt> in the script to <tt>eth1</tt>.
 </enum>
</p> <sect1>
I Want One of My Internal Machines to be my Web Server
 <p>
Piece of cake! However, <em>you need to have a static IP address</em> 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.
 </p>
 <p>
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 <tt>ipmasqadm</tt> utility
 is built to take advantage of that.
 </p>
 <p>
For some reason <tt>ipmasqadm</tt> is not shipped with all the Red Hat and Mandrake
 variants, so will probably have to retrieve it from the maintainer's <htmlurl url="http://juanjox.kernelnotes.org" name="web site"> -- there
 is an <htmlurl url="http://juanjox.kernelnotes.org/ipmasqadm-0.4.2-2.i386.rpm" name="RPM"> available there as well as source code.
 </p>
 <p>
Once you have the RPM, install it, and then add the following lines to
 your <tt>/etc/rc.d/rc.local</tt> file:
 </p>
 <p>
 <verb>
/usr/sbin/ipmasqadm portfw -f 
/usr/sbin/ipmasqadm portfw -a -P tcp -L x.x.x.x 80 -R 192.168.1.x 80 
 </verb>
</p> <p>
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.
 </p>
 <p>
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 <em>external</em> interface.
 </p>


 </article>
