With the World Wide Web now a mainstream phenomenon and computer prices dropping by the minute, there are more machines than ever connected to the Internet. All of this activity has created a bit of a real estate problem for the classic TCP/IPv4 addressing system and those of us who are beholden to it. Assigning a TCP/ IP address to each and every machine on your network today can be tricky -- either because of the cost, or because your network has simply run out of addresses. But don't despair, Linux IP Masquerade is ready and able to come to your rescue.
With the World Wide Web now a mainstream phenomenon and computer prices dropping by the minute, there are more machines than ever connected to the Internet. All of this activity has created a bit of a real estate problem for the classic TCP/IPv4 addressing system and those of us who are beholden to it. Assigning a TCP/ IP address to each and every machine on your network today can be tricky — either because of the cost, or because your network has simply run out of addresses. But don’t despair, Linux IP Masquerade is ready and able to come to your rescue.
|Figure 1: Ready for IP Masq — typical network topology.|
Linux IP Masquerade or “IP Masq” is a Linux kernel feature that’s been available since the old 1.2.x kernel days. It allows a single Linux machine to act as a translator between a single IP address and an entire internal network. In technical terms this is called 1:Many (read as “One to Many”) NAT (Network Address Translation). This means “1″ TCP/IP address is translated into “Many” internal hosts. The internal network you use with IP Masq can include any assortment of TCP/ IP-enabled machines using an entirely different addressing scheme, and running over a totally different LAN infrastructure like Ethernet and FDDI. IP Masq lets you do all of this without purchasing additional IP addresses or expensive network routers. It supports a number of Internet protocols including SMTP, HTTP, FTP, IRC, RealAudio, and even gaming protocols.
So how does IP Masq work? What happens is this: IP Masq takes a TCP/ IP packet from the internal network and analyzes it against its own tables. Linux determines whether or not the packet is bound for the Internet, and IP Masq records where this packet originated and where it’s heading. It then re-writes the packet’s original source IP address, giving it the Linux server’s own — external — IP address, and forwards it out to the Internet. When the remote server receives the packet and replies, the Linux IP Masqserver is able to recognize this Masqed packet and re-route it.
One of the benefits of IP Masquerade is that it lets you implement a secure TCP/IP packet firewall using the stan-dard Linux ipfwadm or ipchains tools.
Both ipfwadm and ipchains can be used to configure the Linux IP Masquerade kernel code. Since the user has to use a simple script to turn on IP Masq anyway, why not use a strong firewall ruleset instead? There are many examples of strong rulesets, including ones in the IP-MASQ-HOWTO and even stronger ones in the TrinityOS document. None of these rulesets are the end-all be all for firewall security, but they make a great start.
These firewalling mechanisms also provide extensive logging facilities so that administrators can find out when external intruders are trying to break into their machines.
Another powerful IP Masq feature, called IP port forwarding, lets you forward external Internet traffic into your internal LAN, giving remote Internet users access to internal computers.
|Figure 2: IP Masq at work — a Masq Telnet session.|
There aren’t a lot of drawbacks to IP Masq, but a few limitations are worth mentioning. Once Linux IP Masq is functioning, the majority of network applications will work fine but some applications need special help. To aid these difficult applications, Linux IP Masquerade utilizes special kernel modules. As of today, Linux modules have been written for the most common applications — CuSeeMe (video conferencing), FTP (file transfer), IRC (for DCC file transfers), Quake (for multiple internal game players), Real Audio (video/ sound streaming), and IRCVdoLive (video conferencing) — there is not a long list of modules, but very few applications need a special module. For a number of other network applications out there, configuring TCP/IP port forwarders for your network application’s TCP/UDP ports, will get things running without a hitch.
Modules are lacking for a very few network applications that won’t work with IP port forwards. For example, Microsoft’s NetMeeting video conferencing program uses the industry standard H.323 protocol, but until a kernel module is written, NetMeeting won’t work properly.
So who doesn’t need IP Masq? Well,if you don’t have LAN, you don’t needit. Also, if you’re lucky enough to haveyour very own TCP/IP subnet (a group of TCP/IP addresses), you’re probably okay too. If you should happen to belong to this latter class of privileged users, you can simply setup TCP/IP routing using your plenitude of addresses and be done with it.
There are a number of alternatives to IP Masq. On the Microsoft Windows 9x/NT front, you can use programs like Wingate, WinRoute, NAT32, and several others. On the DOS front, there is IProute, and on the network router side, almost all router vendors provide similar services. Now, almost all of these solutions cost money; and they may not do everything you want. It is important to note that some of these are proxy servers, while others, like IP Masq, are NAT servers.
Proxy servers are essentially stopping points for network traffic. In somerespects, proxy servers provide greater security than conventional servers since internal traffic doesn’t pass directly to an outside machine. Instead, packets are terminated locally and then re-created on the proxy server which sends them to the final destination.
One of the great benefits of proxies is that you can use them for caching. For example, imagine that you have several internal users going to the same Web sites. A caching proxy server will take the first downloads of the more popular Web pages and store them on its hard drive. When other internal computers try to load that same page, the caching proxy server will realize that it has this information and serve the pages from its local hard drive. This system can both reduce the load on the external Internet connection and speed up Web access.
But proxy servers aren’t perfect. To use them, all of your internal hosts must be “proxy savvy.” This means that all of the network applications on all of your internal machines must be reconfigured to use the proxy server.
A NAT, or Network Address Translation server, is more of a packet re-writing and routing service than a stopping point for network traffic. A NAT server will examine packets from the internal network and route them to the Internet if need be. To do this, the NAT server edits each TCP/IP packet, changing the source TCP/IP addresses and port numbers. As it does this, it records this “translation” in a table so that when the packets return, it knows where to redirect them. Though it’s commonly believed that NAT serving is a bandwidth-intensive process, the truth of the matter is that the slowest 486-class machines can saturate a 1.54 Mb/s T1 connection.
Typically, a NAT server maps one external IP address for one internal IP address providing 1:1 NAT. With NAT, you’ll need sev-eral external TCP/IP addresses for several internal hosts. As I mentioned earlier, IP Masq is 1:Many NAT, which means that it needs only one external IP address, no matter how many internal machines it happens to be hosting.
One problem with commercial solutions is that they tend to sacrifice security for ease of use. Many of these solutions will expose your internal machines to packets from the Internet. Older versions of WinGate, for example, had some bad default settings, designed tomake it easier to use. But they let spammers use WinGate’s SMTP proxy server as a spam relay. This default relaying mode has since been fixed.
Another issue is application support. While most of these solutions support basic services like FTP, POP3, and FTP, some of them don’t work with games or provide external access to internal servers. I’ve found that this last issue is the most critical for first-time NAT or proxy users. Unless it works for them, they won’t have much interest in the solution.
Believe it or not, it’s easy to run 25 to 50 hosts behind a 66 MHz 486 Linux IP Masq server with as little as 16 MB of RAM. I even have a buddy who runs a small Masqed LAN behind a 40 MHz 486 with 8MB of RAM. And his network is connected via a 5Mb/s cable modem. Did I also mention that it’s running a number of other services including DHCP, SMTP, DNS, POP-3, SMB, and NFS? So really, you should be fine with a decent 486-class or better machine.
With IP-Masq, you can connect your Linux box to the Internet any way you want. Internet connectivity options include PPP for modem users, Ethernet for xDSL and cable modem users, FDDI for corporate users, even packet radio for HAM users. Once connected, you just need to connect your internal network to the Linux box and you’re ready to set up IP Masquerading.
Setting Up Linux IP Masquerade
Setting up Linux IP Masq really isn’t that difficult. Modern Linux distributions, such as Redhat 5.0, SuSE 6.0, and many others support Linux IP Masquerade out of the box. My instructions make a few assumptions:
* You are running a 2.2.x Linux kernel that supports IP Masquerading by default. If your system isn’t running a 2.2.x kernel or if you need to re-compile your kernel to support IP Masquerade, please consult the IP-MASQ-HOWTO (the URL for the HOWTO and other useful resources can be found on pg. 52). It has complete instructions on how to install IP Masq on the 2.0.x kernel and on how to re-compile your kernel to support IP Masquerade.
* You already have a working Internet connection to your Linux box. This also includes a working DNS lookup. For example, you need to be able to run the command ping www.yahoo. com on your Linux server and get ping replies. If you don’t have either of these configured, please consult some of the excellent HOWTOs at the Linux Documentation Project homepage or the TrinityOS document.
* You already have a working internal network, which uses the 192.168.0.x addressing space (RFC-1918 – http:// www.cis.ohiostate.edu/htbin/rfc/ rfc1918.html). This RFC defines several TCP/IP address ranges that any person or organization can use on an internal network. These addresses (10.x.x.x, 172.16-31.x.x, 192.168.x.x) are the recommended ranges that any person or entity should use behind a NAT or Proxy server. You can also use any other internal addressing scheme but understand that you will have to make some minor changes to this guide to get things working.
* All of the internal machines use your Linux server as their default gateway (for this example, I used 192.168. 0.1). If you are unsure how to do this, the IP-MASQ-HOWTO covers this in detail for over ten different operating systems.
* All of your internal machines are configured to use your ISP’s DNS servers or to use your Linux server as their DNS server.
Seven Steps to IP Masquerade
Step #1: Confirm that IP Masq is enabled on your machine.
Run the command ls /proc/net and make sure that the entry ip_ masquerade exists. If it doesn’t, you will need to compile a new kernel. Instructions on how to do this can be found in the IP-Masq-HOWTO.
Step #2: Confirm that the ipchains firewall tool exists.
Run the command ls -la /sbin/ ipchains and make sure the file exists. If it doesn’t exist, you will need to download ipchains as explained in the IP-Masq-HOWTO.
Step #3: Create the rc.firewall ruleset.
Create the file /etc/rc.d/rc. firewall and enter the minimal ruleset listed in Listing One.
Step #4: Make the /etc/rc.d/rc. firewall ruleset executable only by the root user.
Run the command chmod700 /etc/rc.d/rc.firewall.
Step #5: If you plan on having IP Masquerade run after each reboot of your Linux machine, add it to your Linux startup scripts.
Append the line /etc/rc.d/rc. firewall to the end of the /etc/ rc.d/rc. local file
Step #6: Enable IP Masquerade.
Run the command /etc/rc.d/ rc.firewall. Make sure that the script runs without any errors. If you do receive errors, check again to make sure that you passed all of the assumption tests at the beginning of this section.
Step #7: Test IP Masquerade.
Make sure that you can ping the Linux server’s internal IP address:
You should see output similar to Figure 3. Hit “Ctrl-C” to stop the ping. Make sure you can ping the Masq Linux server’s external IP address (e.g.ping 188.8.131.52 — you will need to substitute your own Internet TCP/IP address for this one). You can find your IP address by running the command /sbin/ifconfig tool and look for the TCP/IP address on your external interface.
Figure 3: IP Masquerade Test
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=1.5 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.6 ms
— 192.168.0.1 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.6/1.0/1.5 ms
Make sure you can ping the IP address of an external server. For connections to the Internet, see if you can ping the TCP/IP address of the Linux Documentation Project (LDP) server by typing ping 184.108.40.206.
If that doesn’t work, try other TCP/ IP addresses. Sometimes the Internet breaks and you won’t always be able to reach all servers. So try ping-ing a different IP address such as Yahoo’s (220.127.116.11).
Make sure you can ping the name of an external server. For connections to the Internet, see if you can ping the TCP/IP address of the LDP server:
Running tests with the raw TCP/IP address and then later with the full Internet address isolates any problems you might have with DNS name resolution.
Make sure you can telnet to an external server. For connections to the Internet, see if you can telnet to the LDP server by typing telnet metalab.unc.edu.
If you receive a login: prompt, IP Masq is working! Don’t bother with trying to log into this machine since you don’t have a username or password on it. Please note that the LDP server can be very slow at times so don’t take the response speed of this test as indicative of the performance of your Masq connection.
Finally, load a Web browser on a Masqed PC and see if you can browse the Internet. You should also find out if you can use other networked programs like FTP, RealAudio, or IRC.
Listing One: IP-Masq Minimal Ruleset.
# rc.firewall – Initial SIMPLE IP Masquerade test for 2.1.x and 2.2.x kernels using IPCHAINS
#Initialize the IP Masquerade kernel modules
#Load the kernel modules
# NOTE: Only enable the modules you need and leave the rest “#”ed out
# Supports the proper masquerading of FTP file transfers using the PORT
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
# Supports the masquerading of IRC DCC file transfers
# Supports the masquerading of Quake I, II, III and QuakeWorld by default.
# This modules is for multiple users behind the Linux IP-Masq server.
/sbin/modprobe ip_masq_quake ports=26000,27000,27910
# Supports the masquerading of the CuSeeme video conferencing software
#Supports the masquerading of the VDO-live video conferencing software
# Dynamic IP users:
#If you get your Internet IP address dynamically from SLIP, PPP, or DHCP, enable this
#echo “1″ > /proc/sys/net/ipv4/ip_dynaddr
#Enable IP Forwarding in the Linux kernel. A requirement to later enable
echo “1″ > /proc/sys/net/ipv4/ip_forward
# Enable MASQ timeouts
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP “FIN” packet is received
# 60 sec timeout for UDP traffic
ipchains -M -S 7200 10 160
# Enable simple IP Masquerading for the internal 192.168.0.x network
ipchains -P forward DENY
ipchains -A forward -s 192.168.0.0/24 -j MASQ
echo “/etc/rc.d/rc.firewall done.”