So you have a small network running at home, you use Linux, and you want to be able to share a single ISP with all of your machines. How do you do it? Ladies and gentlemen, I give you IP Masquerading!
There are many sources to guide the novice through the fundamentals of IP Masquerading. Unfortunately, all of these sources vary to a great degree in both difficulty and accuracy. From the how-tos to the URLs, each source will guide you through a different process. Some of these sources are out of date and some of them are a bit too technical. This one, however, hopes to lead the average user towards that pinnacle of geekdom known as IP Masquerading.
According to the Mini How-to:
"IP Masquerade is a networking function in Linux. If a Linux host is connected to the Internet with IP Masquerade enabled, then computers connecting to it (either on the same LAN or connected with modems) can reach the Internet as well, even though they have no official, assigned IP addresses."
At first, you may think this is somewhat criminal. A user typically pays the ISP for a single IP address. (Unless you're on a cable modem using a static IP address, you'll be assigned a dynamic IP each time you log on.) IP Masquerading "fakes" your machines into thinking that each has it's own IP, thereby robbing the ISP of income. Although that could be one way to think of this activity, as long as you aren't taking up too much bandwidth, there's no problem.
Beyond the obvious advantages, IP Masquerading is also a solid method of protection for critical files and data. Breaking the security of a well-set-up masquerading system should be considerably more difficult than breaking a good packet filter-based firewall. IP Masquerading allows the average home user to benefit from Linux's scalability and security and can be set up simply and rather quickly by gently hacking a few short scripts.
The process
The first step (refer to my previous Daily Drill Down, "The Linux network: A simple solution to a mind-boggling problem," for the details) is to get your network running properly with the proper (private) IP addresses. (In the aforementioned Daily Drill Down, we used the 172.22.1.x range of IP.) It's very important that private IP addresses are utilised for security issues.
Once your network is up and running (and you have the ability to ping each machine by both IP and host name), you're ready to begin the setup of IP Masquerading.
In "The Linux network: A simple solution to a mind-boggling problem," we labeled the machines "local" and "remote." For the purposes of this Daily Drill Down, we'll term the first machine (the machine with the modem to be used) the GATEWAY (or SERVER) and the machine without the modem will be the CLIENT.
The first step in setting this little marvel up is to see if the kernels (on both GATEWAY and CLIENT) support IP Masquerading. This is much easier than it sounds. The first method of determining if IPM is enabled is to find out what kernel you're running in your Linux box. Should you be running a standard (out of the box) 2.2.x kernel, IPM should be enabled by default. Anything earlier than 2.2.x will probably entail a kernel re-compilation. If you still aren't sure whether IPM is enabled, run this command at a console:
ls /proc/net
You should receive results similar to this:
Arp
igmp
ip_masquerade
route
sockstat
unix
Dev
ip_fwchains
netlink
rpc
tcp
wireless
dev_mcast
ip_masq
netstat
rt_cache
tr_rif
dev_stat
ip_fwnames
raw
snmp
udp
The entry in bold is the entry you need to look for. Should ip_masquerade not be part of the output of ls /proc/net, you will have to recompile your kernel to include IPM.
Now that you're sure IPM is enabled in your kernel, you must enable IPV4 (IP version 4) forward (on both GATEWAY and CLIENT) after booting. There are two ways to do this: manually and "The Red Hat way." To enable IPV4 manually, run this command:
echo "1" > /proc/sys/net/ipv4/ip_forward
The ip_forward file may be saved under the name ip_forwarding. (check this by running ls /proc.sys/net/ipv4 ip_forward*. If the output to this command is ip_forward, then use the above command. Should the output of the ls be ip_forwarding, you will need to alter the command like this:
echo "1" > /proc/sys/net/ipv4/ip_fowarding
To enable IPV4 "The Red Hat way," simply edit the /etc/sysconfig/network script (as root) with this change:
FORWARD_IPV4="no" ----> changes to ----> FORWARD_IPV4="yes"
At boot time, Red Hat checks this file (network) and performs the manual configuration. If you've had to make one of the above changes, you'll want to reboot both machines to make sure the changes take effect.
Now that IPv4 has been enabled, it's time to work specifically on the GATEWAY. Now we'll set up a few firewall rules to give our network a semblance of security.
The file you want to call up (as root) is: /etc/rc.d/rc.local. This file looks like:
#!/bin/sh
# This script will be executed *after* all the other init scripts.
# You can put your own initialisation stuff in here if you don't
# want to do the full Sys V style init stuff.
if [ -f /etc/redhat-release ]; then
R=$(cat /etc/redhat-release)
arch=$(uname -m)
a="a"
case "_$arch" in
_a*) a="an";;
_i*) a="an";;
esac
# This will overwrite /etc/issue at every boot. So, make any changes you
# want to make to /etc/issue here or you will lose them when you reboot.
echo "" > /etc/issue
echo "$R" >> /etc/issue
echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue
cp -f /etc/issue /etc/issue.net
echo >> /etc/issue
fi
It's very important to use caution when working with this particular script. The rc.local script is imperative to the boot process (after all, init processes have run). In this script, you can enter all personal initialisation calls; and the following will set up the necessary routines to enable a very basic firewall.
#
# Enable IP Masquerading
#
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 172.22.1.0/255.255.0.0 -j MASQ
Here is where one of the problems lies in many of the how-tos and walkthroughs. Many of these papers were written circa Red Hat 5.1 or 5.2 and some of the directories are different. Most notably, in this instance, is the ipchains file. Most manuals instruct you to add the lines:
ipchains -P forward Deny
ipchains -A forward -s 172.22.1.0/255.255.0.0 -j MASQ
However, in Red Hat 6.0 this won't work. Red Hat 6.0 locates ipchains in the sbin directory—therefore you must follow suite when enabling the basic firewall rules. A quick way to test the accuracy of this newly edited file is to restart the rc.local file with:
/etc/rc.d/rc.local
If you aren't greeted with any errors, then your file is written correctly and your firewall rules are set up.
Notice the IP addresses in the above file. Here you want to make sure to enter the IP addresses you've used for your own network. We're telling the system to allow IP addresses of 172.22.1.x (where x=0) starting with 0 and a submask of 255.255.0.0. This should take into account all CLIENTS you have configured on your network.
Finally, you'll want to configure all of your CLIENT machines' gateway addresses to the IP address of the SERVER machine. This configuration is done quickly through linuxconf. In the linuxconf application, open the Defaults section that lies directly under the Routing And Gateways heading. In this section, there's only one text area, and it's where you will enter the IP of the SERVER machine. In our example, we have 172.22.1.2 as a CLIENT and 172.22.1.1 as a SERVER; therefore the 172.22.1.1 IP will be entered as the default gateway. Also in this section, you'll want to click Enable Routing. This will allow the CLIENT to route its packets from the server machine.
Let's run a simple test. First, see if you can access the machines (on your private network) using only the IP addresses. If this works, you're almost finished. The next step in the final phase is to attempt to get out into the wild. Go to the SERVER box and dial up your connection. Once you are connected to your ISP, go back to the CLIENT and try to ping a service. Let's be geeks and ping the Linux Documentation Project, shall we?
Ping 152.19.254.81
You should be returned with output similar to this:
64 bytes from 152.19.254.81: icmp_seq=0 ttl=245 time 237.7 ms
64 bytes from 152.19.254.81: icmp_seq=1 ttl=245 time 237.7 ms
64 bytes from 152.19.254.81: icmp_seq=2 ttl=245 time 237.7 ms
64 bytes from 152.19.254.81: icmp_seq=3 ttl=245 time 237.7 ms
And so on... until you end the connection by pressing [Ctrl][C]. If you managed to ping the connection, let's take this test to its final stage and attempt to tread the waters of the ocean called the Internet.
Jump on the CLIENT machine, open Netscape, and try to log on to www.techrepublic.com. If you're greeted with our index page, congratulations! You've managed to install IP Masquerading on your Simple Home Linux Network (or SHLN).
If the CLIENT doesn't seem to want to use the SERVER correctly, move back to the SERVER, open linuxconf, and make sure the SERVER's enable routing is checked (see above—same as CLIENT). Make sure you do not enter an IP address in the default text area.
Other possible errors could be that ip_forwarding was not properly set up or that the firewall rules are not correct.
These instructions offer a simple solution to a complex problem. With IP Masquerading enabled on a simple network, costs are cut, and security is enhanced—a combination no business or home can do without.
Jack Wallen, Jr. is the author of "Get Jack'd" and proud to be working on his third degree in the University of Louisville's Computer Information Systems program. Jack is an expert on the many flavors of Linux, as well as other prominent operating systems. His columns offer up a weekly dose of the "attitude" so familiar with Linux, and he plumbs the deeper depths of technology by drilling down into the heart of the applications and systems.
And, much to everyone's surprise, Jack is not permanently connected to his computer.
Editorial Disclaimer
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
6%
1%
