IP Masquerading Code Follow-up
Over a year ago this magazine graciously allowed me to write a couple of articles for them. One of them concerned the topic of IP Masquerading (July 1996, Issue 27) as supported by the Linux kernel. Since that time a number of changes have occurred during the ongoing development of Linux. I'd like to bring the Linux Journal readers up to date on what changes have taken place, explain a few of the technical details and take some guesses at where things are going in the future. Many of the technical details of functionality will not be revisited because overall the functionality hasn't changed. The previous article still applies in that area.
IP Masquerading is a way of performing address hiding. It may be that a company does not have enough registered IP addresses to connect all of its computers to the Internet or, if you're like me, you have one address through a local dial-up account, but three computers. Each of these circumstances can be solved by using masquerading to allow the “internal” computers access via the one external connection point. The external connection point will use masquerading to hide addresses. Figure 1 is a diagram of the local network I have as my setup.
Using masquerading is still as easy as ever. I have one network where I want all of my hosts to have access to the Internet. Since they are on 192.168.1.0 (the network), I can masquerade the entire class C address space. You'll notice, being the good administrator that I am, I'm using a private address as defined by RFC 1918.
To start masquerading, I defined an rc.masq file in my /etc/rc.d/ directory and added it to execute in /etc/rc.d/rc.local. The rc.masq file looks like this:
#!/bin/sh # PATH=/usr/local/bin; export PATH
# # setup system forwarding policy ipfwadm -F -p deny # # masquerading rules ipfwadm -F a m -S 192.168.1.0/24 -D 0.0.0.0/0 # # list out the current ruleset ipfwadm -F -l -n,
First, you'll notice the command to set up masquerading is the ipfwadm (version 2.3.0) command. This is noticeably different from the previous article when only the ipfw command could be used. Since kernels 1.3.66 ipfwadm is the only command to manipulate masquerading rules and is available from http://www.xos.nl/linux/ipfwadm/.
There are really just two statements given. The first one:
ipfwadm -F -p deny
defines the forwarding policy (-F) of this machine—deathstar from Figure 1. It sets the policy to deny all packets to be forwarded by deathstar. Forwarding is the situation where a packet has a source address and destination address different from any of deathstar's interfaces and is to be routed through.
The second statement:
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
added a masquerading rule for the source (-S) network 192.168.1.0. We can tell it is for the entire network by the 24-bit netmask associated with it. 24 bits equates to 255.255.255.0 to indicate the network versus the host portion of an IP address. The destination (-D) address is the all encompassing 0.0.0.0 network, which is used to identify any network. That's it.
The last command allows me to look at the rules set for deathstar. The output looks like this:
IP firewall forward rules, default policy: deny type prot source destination ports acc/m all 192.168.1.0/24 0.0.0.0/0 n/a
Briefly, the output indicates that it will masquerade for all protocols from source 192.168.1.* to anywhere for all source and destination ports.
The ipfwadm program is primarily used to set the rules for the firewalling code in the Linux 2.x kernels.
Masquerading takes a small amount of effort to get configured. Before kernel 2.0.30 the masquerading code was still considered experimental. As such, many pieces of the code were not included with the full distribution, but only included as patches. If you are running a 2.0.x kernel where is x is 29 or lower, see the “Code Maturity Level” sidebar for patching the kernel to include masquerading. My kernel is set up running version 2.0.30 with masquerading included. The configuration options related to masquerading are shown in Listing 1.
You'll notice that parts of the masquerading code can only be included as kernel modules. These are for specific protocols or applications; examples include FTP, VDOLive and Real Audio.
Currently, IP Masquerading has support for TCP and UDP, FTP, Real Audio, IRC, ICMP (configuration option), VDOLive, CUSeeMe and Quake. Normal TCP and UDP applications like TELNET or DNS are supported directly in the kernel masquerading code. The abnormal (i.e. pathological) protocols such as FTP and IRC (which have IP addresses as a part of the message stream) and Real Audio (because the control protocol needs to know where you are) are supported via kernel modules. VDOLive, CUSeeME and Quake are also kernel modules.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- New Products
- Trying to Tame the Tablet
- What's the tweeting protocol?
- Dart: a New Web Programming Experience
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.





3 hours 14 min ago
5 hours 36 min ago
22 hours 25 min ago
1 day 57 min ago
1 day 2 hours ago
1 day 2 hours ago
1 day 3 hours ago
1 day 8 hours ago
1 day 8 hours ago
1 day 10 hours ago