<chapter id="X-087-2-ipmasq"><title>IP Masquerade and <?lb>Network Address <?lb>Translation</title>
<indexterm id="chmq.ip.masq" class="startofrange"><primary>IP (Internet Protocol)</primary><secondary>masquerade</secondary></indexterm>

<para>
You don't have to have a good memory to remember a time when only large
organizations could afford to have a number of computers networked together
by a LAN. Today network technology has dropped so much in
price that two things have happened. First, LANs are now
commonplace, even in many household environments. Certainly many Linux
users will have two or more computers connected by some Ethernet. 
Second, network resources, particularly IP addresses, are now
a scarce resource and while they used to be free, they are now being bought 
and sold.
</para>

<para>
Most people with a LAN will probably also want an Internet
connection that every computer on the LAN can use. The IP routing rules
are quite strict in how they deal with this situation. Traditional solutions
to this problem would have involved requesting an IP network address, perhaps
a class C address for small sites, assigning each host on the LAN an
address from this network and using a router to connect the LAN to the
Internet.
</para>

<para>
In a commercialized Internet environment, this is quite an
expensive proposition. First, you'd be required to pay for the network
address that is assigned to you. Second, you'd probably have to pay your
Internet Service Provider for the privilege of having a suitable route
to your network put in place so that the rest of the Internet knows how to
reach you. This might still be practical for companies, but domestic
installations don't usually justify the cost.
</para>

<para>
<indexterm><primary>NAT (Network Address Translation)</primary></indexterm>
Fortunately, Linux provides an answer to this dilemma.
This answer involves a component of a group of advanced networking features
called <emphasis>Network Address Translation</emphasis> (NAT).
NAT describes the process of modifying the network 
addresses contained with datagram headers while they are in transit. This 
might sound odd at first, but we'll show that it is ideal for solving 
the problem we've just described and many have encountered. IP masquerade 
is the name given to one type of network address translation
that allows all of the hosts on a private network to use the Internet at the
price of a single IP address.
</para>

<para>
<indexterm><primary>masquerade</primary><secondary>how it works</secondary></indexterm>
<INDEXTERM><PRIMARY>datagrams</PRIMARY><SECONDARY>masquerading</SECONDARY></INDEXTERM>
IP masquerading allows you to use a private (reserved) IP network
address on your LAN and have your Linux-based router perform some
clever, real-time translation of IP addresses and ports. When it
receives a datagram from a computer on the LAN, it takes note of the
type of datagram it is, &ldquo;TCP,&rdquo; &ldquo;UDP,&rdquo;
&ldquo;ICMP,&rdquo; etc., and modifies the datagram so that it looks
like it was generated by the router machine itself (and remembers that
it has done so). It then transmits the datagram onto the Internet with
its single connected IP address. When the destination host receives
this datagram, it believes the datagram has come from the routing
host and sends any reply datagrams back to that address.  When the
Linux masquerade router receives a datagram from its Internet
connection, it looks in its table of established masqueraded
connections to see if this datagram actually belongs to a computer on
the LAN, and if it does, it reverses the modification it did on the
forward path and transmits the datagram to the LAN computer.
</para>

<para>
A simple example is illustrated in <xref linkend="X-087-2-masquerade.net">.
</para>

<figure id="X-087-2-masquerade.net" float=0>
<title>A typical IP masquerade configuration</title>
<!-- <graphic fileref="lag2_1101.jpg"></graphic> -->
<!-- 2016-01-28; MAB, TLDP -->
<mediaobject> 
  <imageobject>
    <imagedata fileref="images/lag2_1101.jpg" format="jpg">
  </imageobject>
  <imageobject>
    <imagedata fileref="images/lag2_1101.eps" format="eps">
  </imageobject>
</mediaobject>
</figure>

<para>
We have a small Ethernet network using one of the reserved network addresses.
The network has a Linux-based masquerade router providing access to the
Internet. One of the workstations on the network (192.168.1.3) wishes to
establish a connection to the remote host 209.1.106.178 on port 8888. The
workstation routes its datagram to the masquerade router, which identifies
this connection request as requiring masquerade services. It accepts the
datagram and allocates a port number to use (1035), substitutes its own
IP address and port number for those of the originating host, and transmits
the datagram to the destination host. The destination host believes it has
received a connection request from the Linux masquerade host and generates
a reply datagram. The masquerade host, upon receiving this datagram,
finds the association in its masquerade table and reverses the substution
it performed on the outgoing datagram. It then transmits the reply datagram
to the originating host.
</para>

<para>
The local host believes it is speaking directly to the remote host. The
remote host knows nothing about the local host at all and believes it has
received a connection from the Linux masquerade host. The Linux masquerade
host knows these two hosts are speaking to each other, and on what ports,
and performs the address and port translations necessary to allow
communication.
</para>

<para>
This might all seem a little confusing, and it can be, but it works and
is really quite simple to configure. So don't worry if you don't understand 
all the details yet.
</para>

<sect1 id="X-087-2-masq.side.effects"><title>Side Effects and Fringe Benefits</title>
<para>
<INDEXTERM><PRIMARY>masquerade</PRIMARY><SECONDARY>side effects of</SECONDARY></INDEXTERM>
The IP masquerade facility comes with its own set of side effects, some of
which are useful and some of which might become bothersome.
</para>

<para>
<?troff .hw specially>
None of the hosts on the supported network behind the masquerade router
are ever directly seen; consequently, you need only one valid and
routable IP address to allow all hosts to make network connections out
onto the Internet. This has a downside; none of those hosts are
visible from the Internet and you can't directly connect to them from
the Internet; the only host visible on a masqueraded network is the
masquerade machine itself. This is important when you consider
services such as mail or FTP. It helps determine what services should
be provided by the masquerade host and what services it should proxy
or otherwise treat specially.
</para>

<para>
Second, because none of the masqueraded hosts are visible, they are relatively
protected from attacks from outside; this could simplify or even remove
the need for firewall configuration on the masquerade host. You shouldn't rely
too heavily on this, though. Your whole network will be only as safe as
your masquerade host, so you should use firewall to protect it if security is 
a concern.
</para>

<para>
Third, IP masquerade will have some impact on the performance of your
networking. In typical configurations this will probably be barely measurable.
If you have large numbers of active masquerade sessions, though, you may find
that the processing required at the masquerade machine begins to impact 
your network throughput. IP masquerade must do a good deal of work for 
each datagram compared to the process of conventional routing. That
386SX16 machine you have been planning on using as a masquerade machine
supporting a dial-up link to the Internet might be fine, but don't expect
too much if you decide you want to use it as a router in your corporate
network at Ethernet speeds.
</para>

<para>
Last, some network services just won't work through masquerade, or at least
not without a lot of help. Typically, these are services that rely on incoming
sessions to work, such as some types of Direct Communications Channels (DCC), 
features in IRC, or certain types of video and audio multicasting services. 
Some of these services have specially developed kernel modules to provide 
solutions for these, and we'll talk about those in a moment. For others, it 
is possible that you will find no support, so be aware,it won't be suitable 
in all situations.
</para>
</sect1>

<sect1 id="X-087-2-masq.kernel.config"><title>Configuring the Kernel <?lb>for IP Masquerade</title>
<para>
<INDEXTERM><PRIMARY>configuring</PRIMARY><SECONDARY>kernel</SECONDARY><TERTIARY SORTAS="IP masquerade">for IP masquerade</TERTIARY></INDEXTERM>
<indexterm><primary>masquerade</primary><secondary>kernel configuration</secondary></indexterm>
<indexterm><primary>kernels</primary><secondary>configuring for masquerade</secondary></indexterm>

<?troff .hw kernel>
<INDEXTERM><PRIMARY>2.2 kernels</PRIMARY><SECONDARY>IP masquerade</SECONDARY></INDEXTERM>
To use the IP masquerade facility, your kernel must be compiled with masquerade
support. You must select the following options when configuring a 2.2 series
kernel:

<screen>
Networking options  --->
	[*] Network firewalls
	[*] TCP/IP networking
	[*] IP: firewalling
	[*] IP: masquerading
	--- Protocol-specific masquerading support will be built as modules.
	[*] IP: ipautofw masq support
	[*] IP: ICMP masquerading
</screen>

Note that some of the masquerade support is available only as a kernel module.
This means that you must ensure that you
&ldquo;<literal>make modules</literal>&rdquo; in addition to the usual
&ldquo;<literal>make zImage</literal>&rdquo; when building
your kernel.
</para>

<para>
<INDEXTERM><PRIMARY>2.4 kernels</PRIMARY><SECONDARY>IP masquerade</SECONDARY></INDEXTERM>
The 2.4 series kernels no longer offer IP masquerade support as a kernel
compile time option. Instead, you should select the network packet
filtering option:

<screen width=80>
Networking options  --->
    [M] Network packet filtering (replaces ipchains)
</screen>
</para>

<para>
In the 2.2 series kernels, a number of protocol-specific helper
modules are created during kernel compilation. Some protocols begin with
an outgoing request on one port, and then expect an incoming connection on
another. Normally these cannot be masqueraded, as there is no way of associating
the second connection with the first without peering inside the protocols
themselves. The helper modules do just that; they actually look inside the
datagrams and allow masquerading to work for supported protocols that
otherwise would be impossible to masquerade. The supported protocols are:

<informaltable>
<tgroup cols="2">
<thead>
<row>
	<entry>Module</entry>
	<entry>Protocol</entry>
</row>
</thead>
<tbody>
<row>
	<entry>ip_masq_ftp</entry>
	<entry>FTP</entry>
</row>
<row>
	<entry>ip_masq_irc</entry>
	<entry>IRC</entry>
</row>
<row>
	<entry>ip_masq_raudio</entry>
	<entry>RealAudio</entry>
</row>
<row>
	<entry>ip_masq_cuseeme</entry>
	<entry>CU-See-Me</entry>
</row>
<row>
	<entry>ip_masq_vdolive</entry>
	<entry>For VDO Live</entry>
</row>
<row>
	<entry>ip_masq_quake</entry>
	<entry>IdSoftware's Quake</entry>
</row>
</tbody>
</tgroup>
</informaltable>

You must load these modules manually using the <command>insmod</command> 
command to implement them. Note that these modules cannot be loaded using
the <command>kerneld</command> daemon. Each of the modules takes an argument
specifying what ports it will listen on. For the
RealAudio&trade; module you might use:<footnote id="X-087-2-MQ01">
<para>
RealAudio is a trademark of the Progressive Networks Corporation.
</para>
</footnote>
<screen>
# <userinput>insmod ip_masq_raudio.o ports=7070,7071,7072</userinput>           </screen>

The ports you need to specify depend on the protocol. An IP masquerade
mini-HOWTO written by Ambrose Au explains more about the IP masquerade modules
and how to configure them.<footnote id="X-087-2-FNMQ02">
<para>
You can contact Ambrose at
<systemitem role="email">ambrose@writeme.com</systemitem>.
</para>
</footnote>
</para>

<para>
The <emphasis>netfilter</emphasis> package includes modules that perform
similar functions. For example, to provide connection tracking of FTP
sessions, you'd load and use the <filename>ip_conntrack_&thinsp;ftp</filename> and
<filename>ip_nat_&thinsp;ftp.o</filename> modules.
</para>
</sect1>

<sect1 id="X-087-2-masq.configuration"><title>Configuring IP Masquerade</title>
<para>
<indexterm><primary>masquerade</primary><secondary>configuration</secondary></indexterm>
<indexterm><primary>configuring</primary><secondary>IP masquerade</secondary></indexterm>
<INDEXTERM id="ipfwadm.config.masq" class=startofrange><PRIMARY>ipfwadm command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
<INDEXTERM id="ipchains.config.masq" class=startofrange><PRIMARY>ipchains command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
<INDEXTERM id="iptables.config.masq" class=startofrange><PRIMARY>iptables command</PRIMARY><SECONDARY>configuring IP masquerade</SECONDARY></INDEXTERM>
If you've already read the firewall and accounting chapters, it
probably comes as no surprise that the <command>ipfwadm</command>,
<command>ipchains</command>, and <command>iptables</command> commands
are used to configure the IP masquerade rules as well.
</para>

<para>
Masquerade rules are a special class of filtering rule. You can
masquerade only datagrams that are received on one interface that will
be routed to another interface. To configure a masquerade rule you
construct a rule very similar to a firewall forwarding rule, but with
special options that tell the kernel to masquerade the datagram. The
<command>ipfwadm</command> command uses the <emphasis>-m</emphasis>
option, <command>ipchains</command> uses <literal>-j MASQ</literal>, and <command>iptables</command> uses
<literal>-j MASQUERADE</literal> to
indicate that datagrams matching the rule specification should be
masqueraded.
</para>
<?troff .wcon_off>

<para>
Let's look at an example.
A computing science student at Groucho Marx University has a number of
computers at home internetworked onto a small Ethernet-based local area
network. She has chosen to use one of the reserved private Internet network
addresses for her network. She shares her accomodation with other students,
all of whom have an interest in using the Internet. Because student living 
conditions are very frugal, they cannot afford to use a permanent Internet 
connection, so instead they use a simple dial-up PPP Internet connection. 
They would all like to be able
<?troff .ne 10>
to share the connection to chat on IRC, surf 
the Web, and retrieve files by FTP directly to each of their computers&mdash;IP 
masquerade is the answer.
</para>

<para>
The student first configures a Linux machine to support the dial-up link and to
act as a router for the LAN. The IP address she is assigned when she dials up
isn't important. She configures the Linux router with IP masquerade and uses 
one of the private network addresses for her LAN: 
<literal>192.168.1.0</literal>. She ensures that each of the hosts on the 
LAN has a default route pointing at the Linux router.
</para>

<para>
The following <command>ipfwadm</command> commands are all that are required to
make masquerading work in her configuration:

<screen>
# <userinput>ipfwadm -F -p deny</userinput>
# <userinput>ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0/0</userinput>
</screen>

or with <command>ipchains</command>:

<screen>
# <userinput>ipchains -P forward -j deny</userinput>
# <userinput>ipchains -A forward -s 192.168.1.0/24 -d 0/0 -j MASQ</userinput>
</screen>

or with <command>iptables</command>:

<screen>
# <userinput>iptables -t nat -P POSTROUTING DROP</userinput>
# <userinput>iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE</userinput> 
</screen>

Now whenever any of the LAN hosts try to connect to a service on a
remote host, their datagrams will be automatically masqueraded by the
Linux masquerade router. The first rule in each example prevents the
Linux machine from routing any other datagrams and also adds some
security.
</para>

<para>
<indexterm><primary>masquerade</primary><secondary>listing rules</secondary></indexterm>
To list the masquerade rules you have created, use the <literal>-l</literal> 
argument to the <command>ipfwadm</command>
command, as we described in earlier while discussing firewalls.
</para>

<para>
To list the rule we created earlier we use:

<screen>
# <userinput>ipfwadm -F -l -e</userinput>
</screen>

which should display something like:

<screen>
# <userinput>ipfwadm -F -l -e</userinput>
IP firewall forward rules, default policy: accept
 pkts bytes type  prot opt  tosa tosx ifname  ifaddress  &hellip;
    0     0 acc/m all  ---- 0xFF 0x00 any     any        &hellip;
</screen>

The &ldquo;<literal>/m</literal>&rdquo; in the output indicates this is a
masquerade rule.
</para>

<para>
To list the masquerade rules with the <command>ipchains</command> command, 
use the <command>-L</command> argument. If we list the rule
we created earlier with <command>ipchains</command>, the output will look like:

<screen>
<userinput># ipchains -L</userinput>
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target     prot opt     source                destination           ports
MASQ       all  ------  192.168.1.0/24        anywhere              n/a

Chain output (policy ACCEPT):
</screen>
</para>

<para>
Any rules with a target of <literal>MASQ</literal> are masquerade rules.
</para>

<para>
Finally, to list the rules using <command>iptables</command> you need to use:

<screen width=98>
# <userinput>iptables -t nat -L</userinput>
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy DROP)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere           MASQUERADE 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
</screen>

Again, masquerade rules appear with a target of <literal>MASQUERADE</literal>.
</para>

<sect2 id="X-087-2-masq.setting.timing"><title>Setting Timing Parameters for IP Masquerade</title>
<para>
<indexterm><primary>masquerade</primary><secondary>setting timing parameters for</secondary></indexterm>
When each new connection is established, the IP masquerade software
creates an association in memory between each of the hosts involved in
the connection.  You can view these associations at any time by
looking at the <filename>/proc/net/ip_masquerade</filename> file.
These associations will timeout after a period of inactivity, though.
</para>

<para>
<INDEXTERM startref="ipfwadm.config.masq" class=endofrange>
You can set the timeout values using the <command>ipfwadm</command> command.
The general syntax for this is:

<screen>
ipfwadm -M -s &lt;<replaceable>tcp</replaceable>&gt; &lt;<replaceable>tcpfin</replaceable>&gt; &lt;<replaceable>udp</replaceable>&gt;
</screen>
</para>

<para>
<INDEXTERM startref="ipchains.config.masq" class=endofrange>
and for the <command>ipchains</command> command it is:

<screen>
ipchains -M -S &lt;<replaceable>tcp</replaceable>&gt; &lt;<replaceable>tcpfin</replaceable>&gt; &lt;<replaceable>udp</replaceable>&gt;
</screen>
</para>

<para>
The <emphasis>iptables</emphasis> implementation uses much longer default
timers and does not allow you to set them.
</para>

<para>
<?troff .hw meanings>
Each of these values represents a timer used by the IP masquerade software and
are in units of seconds. The following table summarizes the timers and their
meanings:
</para>

<informaltable>
<tgroup cols=2><colspec colnum="2" colwidth="3.57i">
<thead>
<row>
	<entry>Name</entry>
	<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
	<entry>tcp</entry>
	<entry><para>
	TCP session timeout. How long a TCP connection may remain idle before the
	association for it is removed.
	</para></entry>
</row>
<row>
	<entry>tcpfin</entry>
	<entry><para>
        <?troff .hw disconnected>
	TCP timeout after FIN. How long an association will remain
	after a TCP connection has been disconnected.
	</para></entry>
</row>
<row>
	<entry>udp</entry>
	<entry><para>
	UDP session timeout. How long a UDP connection may remain idle before the
	association for it is removed.
	</para></entry>
</row>
</tbody>
</tgroup>
</informaltable>

</sect2>

</sect1>

<sect1 id="X-087-2-masq.namelookups"><title>Handling Name Server Lookups</title>
<para>
<indexterm><primary>masquerade</primary><secondary>name server lookups</secondary></indexterm>
<indexterm><primary>name servers</primary><secondary>for IP masquerade</secondary></indexterm>
Handling domain name server lookups from the hosts on the LAN with IP
masquerading has always presented a problem. There are two ways of
accomodating DNS in a masquerade environment. You can tell each of the
hosts that they use the same DNS that the Linux router machine does,
and let IP masquerade do its magic on their DNS
requests. Alternatively, you can run a caching name server on the
Linux machine and have each of the hosts on the LAN use the Linux
machine as their DNS. Although a more aggressive action, this is
probably the better option because it reduces the volume of DNS
traffic travelling on the Internet link and will be marginally faster
for most requests, since they'll be served from the cache. The downside
to this configuration is that it is more complex. <xref
linkend="X-087-2-resolv.named-cachingonly">,&rdquo; in Chapter 6, describes how to configure
a caching name server.
</para>
</sect1>

<sect1><title>More About Network Address Translation</title>
<para>
<indexterm><primary>NAT (Network Address Translation)</primary></indexterm>
The <emphasis>netfilter</emphasis> software is capable of many different types
of Network Address Translation. IP Masquerade is one simple application of it.
</para>

<para>
It is possible, for example, to build NAT rules that translate only certain
addresses or ranges of addresses and leave all others untouched, or to
translate addresses into pools of addresses rather than just a single address,
as masquerade does. You can in fact use the <command>iptables</command> command
to generate NAT rules that map just about anything, with
combinations of matches using any of the standard attributes, such as source
address, destination address, protocol type, port number, etc.
</para>

<para>
<INDEXTERM startref="iptables.config.masq" class=endofrange>
Translating the Source Address of a datagram is referred to as &ldquo;Source
NAT,&rdquo; or <literal>SNAT</literal>, in the <emphasis>netfilter</emphasis>
documentation. Translating the Destination Address of a datagram is known as
&ldquo;Destination NAT,&rdquo; or <literal>DNAT</literal>. Translating the TCP
or UDP port is known by the term <literal>REDIRECT</literal>. 
<literal>SNAT</literal>, <literal>DNAT</literal>, and
<literal>REDIRECT</literal> are targets that you may use with the
<command>iptables</command> command to build more complex and sophisticated
rules.
</para>

<para>
<indexterm><primary>IPTABLES-HOWTO</primary></indexterm>
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>IPTABLES</SECONDARY></INDEXTERM>
The topic of Network Address Translation and its uses warrants at least a
whole chapter of its own.<footnote><para>
... and perhaps even a whole book!
</para>
</footnote> Unfortunately we don't have the space in this book to cover it in
any greater depth. You should read the IPTABLES-HOWTO for more information, if
you're interested in discovering more about how you might use Network Address 
Translation.
</para>
</sect1>

<indexterm class="endofrange" startref="chmq.ip.masq">
</chapter>
