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.
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.
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.
Side Effects and Fringe Benefits
The IP masquerade facility comes with its own set of side effects, some of which are useful and some of which might become bothersome.
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.
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.
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.
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.
Configuring the Kernel for IP Masquerade
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 kerneclass="underline"
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
Note that some of the masquerade support is available only as a kernel module. This means that you must ensure that you " make modules " in addition to the usual " make zImage " when building your kernel.
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:
Networking options --->
[M] Network packet filtering (replaces ipchains)
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:
| Module | Protocol |
|---|---|
| ip_masq_ftp | FTP |
| ip_masq_irc | IRC |
| ip_masq_raudio | RealAudio |
| ip_masq_cuseeme | CU-See-Me |
| ip_masq_vdolive | For VDO Live |
| ip_masq_quake | IdSoftware's Quake |
You must load these modules manually using the insmod command to implement them. Note that these modules cannot be loaded using the kerneld daemon. Each of the modules takes an argument specifying what ports it will listen on. For the RealAudio(TM) module you might use:[66]
# insmod ip_masq_raudio.o ports=7070,7071,7072
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.[67]
The netfilter package includes modules that perform similar functions. For example, to provide connection tracking of FTP sessions, you'd load and use the ip_conntrack_ftp and ip_nat_ftp.o modules.
Configuring IP Masquerade
If you've already read the firewall and accounting chapters, it probably comes as no surprise that the ipfwadm, ipchains, and iptables commands are used to configure the IP masquerade rules as well.
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 ipfwadm command uses the -m option, ipchains uses -j MASQ, and iptables uses -j MASQUERADE to indicate that datagrams matching the rule specification should be masqueraded.