May 22, 2005
This document describes how to enable the Linux IP Masquerade feature on a given Linux host. IP Masquerade is a form of Network Address Translation or NAT which NAT allows internally connected computers that do not have one or more registered Internet IP addresses to communicate to the Internet via the Linux server's Internet IP address.
This document describes how to enable the Linux IP Masquerade feature on a given Linux host. IP Masquerade, called "IPMASQ" or "MASQ" for short, is a form of Network Address Translation (NAT) which allows internally connected computers that do not have one or more registered Internet IP addresses to communicate to the Internet via the Linux server's Internet IP address. Since IPMASQ is a generic technology, you can connect the Linux server's internal and external to other computers through LAN technologies like Ethernet, TokenRing, and FDDI, as well as dialup connections line PPP or SLIP links. This document primarily uses Ethernet and PPP connections in examples because it is most commonly used with DSL / Cablemodems and dialup connections.
From the original IPMASQ HOWTO author:
This document was originally written by
Please feel free to send any feedback or comments regarding this HOWTO to
This HOWTO is meant to be a fairly comprehensive guide to getting your Linux IP Masquerading system working in the shortest time possible. David only plays a technical writer on T.V. so you might find the information in this document not as general and/or objective as it could be. If you think a section could be clearer, etc.. please let David know. The latest version of the MASQ HOWTO can be found at
The latest version of this document can be found at the following sites which also contains HTML, Postscript, PDF, etc. versions
Also refer to
This document is
The information herein this document is, to the best of David's knowledge, correct. However, the Linux IP Masquerade feature is written by humans and thus, the chance of mistakes, bugs, etc. might occur from time to time.
No person, group, or other body is responsible for any damage on your computer(s) and any other losses by using the information on this document. i.e.
Ok, with all this behind us... On with the show..
IP Masquerade is a networking function in Linux similar to the one-to-many (1:Many) NAT (Network Address Translation) servers found in many commercial firewalls and network routers. For example, if a Linux host is connected to the Internet via PPP, Ethernet, etc., the IP Masquerade feature allows other "internal" computers connected to this Linux box (via PPP, Ethernet, etc.) to also reach the Internet as well. Linux IP Masquerading allows for this functionality even though these internal machines don't have an officially assigned IP address.
MASQ allows a set of machines to invisibly access the Internet via the MASQ gateway. To other machines on the Internet, the outgoing traffic will appear to be from the IP MASQ Linux server itself. In addition to the added functionality, IP Masquerade provides the foundation to create a HEAVILY secured networking environment. With a well built firewall, breaking the security of a well configured masquerading system and internal LAN should be considerably difficult to accomplish.
If you would like to know more on how MASQ (1:Many) differs from 1:1 (true) NAT and Proxy solutions, please see the
IP Masquerade has been in the Linux kernels for several years now and is quite mature as the kernel enters the 2.4.x stage. Kernels since Linux 1.3.x have had MASQ support built-in. Today, many individuals and commercial businesses are using it with excellent results.
2.4.x kernel users:
The 2.4.x kernel hosts an entirely re-written set of NAT code which is both far superior, faster, and more secure than any previous versions written for Linux. Unfortunately, several kernel modules that were written for the 2.2.x kernel to support things like UDP-based RealAudio, etc. have not been ported to 2.4.x yet. Because of this, some people should consider NOT upgrading if these network applications are critical to them. But, at the same time, some of these programs have been updated and now use different, NAT-friendly protocols. Thus special NAT treatment is no longer required. As always, please see the
Common network functionalities like Web browsing, telnet, ssh, ping, traceroute, etc. work well over stock IP Masquerade setups. Other network applications such as ftp, irc, and Real Audio work well with the appropriate additional IP MASQ modules loaded into the kernel as modules. Other network-specific programs like streaming audio (MP3s, True Speech, etc) shouldwork too without any special module. Some users on the mailing list also had good results with video conferencing software.
It should be noted that running IP Masquerade with only ONE network card (NIC) to MASQ between internal and external Ethernet networks is NOT recommended. For more details, please see
Anyways, please refer to
IP Masquerade works well as a server to other 'client machines' running various operating systems and hardware platforms. Here is a sampling of successful reports with internal MASQed systems running :
UNIX: Sun Solaris, [Net,Free,Open,*i]-BSD, Hp-UX, Linux, IBM AIX, Digital UNIX, Ultrix, etc.
Microsoft Windows 2000, NT (3.x and 4.x), 95/98/ME, Windows for Workgroups (with the TCP/IP package)
IBM OS/2
Apple Macintosh MacOS machines running either MacTCP or Open Transport
DOS-based systems with packet drivers and the NCSA Telnet package
VAXen
Compaq/Digital Alpha running Linux and NT
Amiga computers with AmiTCP or AS225-stack.
The list goes on and on but the point is, if your OS platform talks TCP/IP, it should work with Linux's IP Masquerade!
If you have a Linux host connected to the Internet and..
if you have internal computers running TCP/IP connected that are connected tothis Linux box via on a network, and/or
if your Linux host has more than one modem and acts as a PPP or SLIP server connected to other computers, and these machines do not have official or public assigned IP addresses (i.e. addressed with private TCP/IP numbers).
If you want those OTHER machines to communicate to the Internet without spending extra money to acquire additional Public / Official TCP/IP addresses from your ISP, then you should either configure Linux to be a router or purchase an external router.
If your machine is a stand-alone Linux host connected to the Internet (setting up a firewall is a good idea though), or
if you already have multiple assigned public addresses for your OTHER machines, and
if you don't like the idea of a 'free ride' using Linux and feel more comfortable using expensive commercial tools to perform the exact same functionalities.
Based from the original IP Masquerade FAQ by Ken Eves: Here is a drawing of the most simplistic setup:
In the above drawing, a Linux box with IP_MASQUERADING is installed as Linux #1 and is connected to the Internet via PPP, Ethernet, etc. It has an assigned public IP address of 111.222.121.212. It also has another networkinterface (e.g. modem2) connected to allow incoming network traffic be itfrom a PPP connection, Ethernet connection, etc.
The second system (which does not need to be Linux) connects into the Linux #1 box and starts its network traffic to the Internet. This second machine does NOT have a publicly assigned IP address from the Internet, so it uses an
With IP Masquerade and the routing configured properly, this second machine "Anybox" can interact with the Internet as if it was directly connected to the Internet with a few small exceptions [noted later].
Quoting Pauline Middelink (the founder of Linux's IPMASQ):
"Do not forget to mention that the "ANYBOX" machine should have the Linux #1 box configured as its default gateway (whether it be the default route or just a subnet is no matter). If the "ANYBOX" machine is connected via a PPPor SLIP connection, the Linux #1 machine should be configured to support proxy arp for all routed addresses. But, the setup and configuration of proxy arp is beyond the scope of this document. Please see the
The following is an excerpt on how IPMASQ briefly works though this will beexplained in more detail later. This short text is based from a previous post on comp.os.linux.networking which has been edited to match the names used in the above example:
Another IP Masquerading Example:
A typical example is given in the diagram below:
In this example, there are (4) computer systems that we are concerned about. There is also presumably something on the far right that your PPP/ETH connection to the Internet comes through (modem server, DSL DSLAM, Cablemodemrouter, etc.). Out on the Internet, there exists some remote host (very far off to the right of the page) that you are interested in communicating with). The Linux system named
Anyway, the Linux box in the diagram above has the TCP/IP address 192.168.0.1 while the other systems has the addresses:
A-Box: 192.168.0.2
B-Box: 192.168.0.3
C-Box: 192.168.0.4
The three machines,
NOTE: Please see
The differences between NAT, MASQ, and Proxy servers.
How packet firewalls work
The newest 2.4.x kernels are now using both a completely new TCP/IP networkstack as well as a new NAT sub-system called NetFilter. Within this NetFiltersuite of tools, we now have a tool called IPTABLES for the 2.4.x kernels much like there was IPCHAINS for the 2.2.x kernels and IPFWADM for the 2.0.x kernels.The new IPTABLES system is far more powerful (combines several functions into one place like true NAT functionality), offers better security (stateful inspection), and better performance with the new 2.4.x TCP/IP stack. But this new suite of tools can be a bit complicated in comparison to older generation kernels. Hopefully, if you follow along with this HOWTO carefully, setting upIPMASQ won't be too bad. If you find anything unclear, downright wrong, etc. please email David about it.
Unlike the migration to IPCHAINS from IPFWADM, the new NetFilter tool has kernel modules that can actually support older IPCHAINS and IPFWADM rulesets with minimal changes. So re-writing your old MASQ or firewall ruleset scripts is not longer required. BUT.. with the 2.4.x kernels, you cannotuse the old 2.2.x MASQ modules like ip_masq_ftp, ip_masq_irc, etc. AND IPCHAINS is incompatible with the new IPTABLES modules like ip_conntrack_ftp, etc. So, what does this mean?It basically means that if you want to use IPMASQ or PORTFW functionality under a 2.4.x kernel, you shouldn't use IPCHAINS rules but IPTABLES ones instead. Please also keep in mind that there might be several benefits in performing a full ruleset re-write to take advantage of the newer IPTABLES features like stateful tracking, etc. but that is dependant upon how much time you have to migrate your old rulesets. Please see
Some new 2.4.x functionalities include the following:
PROs:
Lots of new protocols modules like: amanda, eggdrop, ipsec, ipv6, portscan, pptp, quota, rsh, talk, and tftp
TRUE 1:1 NAT functionality for those who have TCP/IP addresses and subnets to use (no more iproute2 commands)
Stateful application level (FTP, IRC, etc.) and stateful protocol level (TCP/UDP/ICMP) network traffic inspection
Built-in PORT Forwarding (no more ipmasqadm or ipportfw commands)
The built-in PORTFW'ing support works for both external and internal traffic. This means that users that have PORTFW for external traffic and REDIR for internal port redirection do not need to use two tools any more!
PORT Forwarding of FTP traffic to internal hosts is now completely supportedand is handled in the conn_trak_ftp module
Full Policy-Based routing features (source-based TCP/IP address routing)
Compatibility with Linux's FastRoute feature for significantly faster packet forwarding (a.k.a Linux network switching).
Note that this feature is still not compatible with packet filtering for strong firewall rulesets.
Fully supports TCP/IP v4, v6, and even DECnet (ack!)
Supports wildcard interface names like "ppp*" for serial interfaces like ppp0, ppp1, etc
Supports filtering on both input and output INTERFACES (not just IP addresses)
Source Ethernet MAC filtering
Denial of Service (DoS) packet rate limiting
Packet REJECTs now have user-selectable return ICMP messages
Variable levels of logging (different packets can go to different SYSLOG levels)
Other features like traffic mirroring, securing traffic per login, etc.
CONs:
Netfilter is an entirely new architechure thus most of the older 2.2.x MASQ kernel modules written to make non-NAT friendly network applicationswork through IPMASQ need to be re-written for the 2.4.x kernels. Because of this, if you specifically need functionality from some of these modules(see below), you should stay with a 2.2.x kernel until these modules have been either ported or the application has been updated to use NAT-friendlyprotocols. If you are curious on the porting status of a given module, please email the author of the module and NOT David or Ambrose. We don't code.. we just document. :-)
Here is the status of the known IP Masq kernel modules or patches as found on the
Documentation on how to perform MASQ module porting is available at
If you'd like to read up more on NetFilter and IPTables, please see:
Linux 2.4.x IP Masquerade requirements include:
Any decent computer hardware. See
The 2.4.x kernel source is available from
NOTE: Most modern Linux distributions,
The program "iptables" version 1.2.4 or newer ( 1.2.7a or newer is highly recommended ) archive available from NOTE #1: All versions of IPTABLES less than 1.2.3 have a FTP module issue that can bypass any existing firewall rulesets. ALL IPTABLES users are highly recommended to upgrade to the newest version. The URL is above. NOTE #2: All versions of IPTABLES less than 1.2.2 have a FTP "port" security vulnerability in the ip_conntrack_ftp module. All IPTABLES users are highly recommended to upgrade to the newest version. The URL is above. This tool, much like the older IPCHAINS and IPFWADM tools enables the various Masquerding code, more advanced forms of NAT, packet filtering, etc. It also makes use of additional MASQ modules like the FTP and IRC modules. Additional information on version requirements for the newest IPTABLES howto, etc. is located at the
Loadable kernel modules, preferably 2.1.121 or higher, are available from
A properly configured and running TCP/IP network running on the Linux machineas covered in
Connectivity to the Internet for your Linux host covered in
Know how to configure, compile, and install a new Linux kernel as described in the
Any decent computer hardware. See
The 2.2.x kernel source is available from
NOTE: Most modern Linux distributions,
NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different security vulnerabilities (some were MASQ specific). Kernels less than 2.2.20 have a few local vulnerabilities. Kernel versions less than 2.2.16 have a TCP root exploit vulnerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of these issues, users running a firewall with strong IPCHAINS rulesets are open to possible instrusion. Please upgrade your kernel to a fixed version.
NOTE #2: Some newer
Loadable kernel modules, preferably 2.1.121 or higher, are available from
A properly configured and running TCP/IP network running on the Linuxmachine as covered in
Connectivity to the Internet for your Linux host covered in
IP Chains 1.3.10 or newer are available from
Know how to configure, compile, and install a new Linux kernel as described in the
Other optional patches and tools for 2.2.x kernels
TCP/IP port-forwarding or re-directing:
PORTFW FTP Solutions:
There are 2.2.x and 2.0.x kernel MASQ Module solutions for PORTFWed FTP to a MASQed machine (put an FTP server behind a MASQ server). Please see the Application Page on the
There is a full FTP proxy application from SuSe that will also allow PORTFWed-like functionality to reach an internal FTP server. For more details, please refer to the
IPROUTE2 for True 1:1 NAT, Policy-based (source) routing, and Traffic Shaping:
Documentation can be found at
The
Some source code mirrors are at:
Please see the
Any decent computer hardware. See
The 2.0.x kernel source is available from
NOTE: Most modern Linux
Loadable kernel modules, preferably 2.1.85 or newer is available from
A properly configured and running TCP/IP network running on the Linux machineas covered in
Connectivity to the Internet for your Linux host is covered in
Ipfwadm 2.3.0 or newer is available from
More information on version requirements are on the
If you are interested in running IPCHAINS on a 2.0.x+ kernel, see
Know how to configure, compile, and install a new Linux kernel as described in the
Here is a list of IP Masquerading patches for 2.0.x kernels:
Steven Clarke's
PORTFWed FTP:
If you are going to port forward FTP traffic to an internal FTP server, you might need to download
X-Windows display forwarders:
PPTP (GRE) and SWAN (IPSEC) VPNs tunneling forwarders:
If you plan connecting an internal MASQed PC to a remote PPTP server,you MUST INSTALL the PPTP-Masquerade kernel patch available from the URLsbelow. If you plan on having external PPTP users connect to an internal masqueraded PPTP server, not only do you need the kernel patch installed but you also need PORTFW support enabled in the kernel. Please see the following URLs for the patches and more information:
Game specific patches:
Glenn Lamb's
If your private network contains any vital information, think carefully in terms of SECURITY before implementing IP Masquerade. By default, IP MASQ becomes a GATEWAY for you to get onto the Internet, but it also can allow someone from the Internet to possibly get into your internal network.
Once you have IP MASQ functioning, it is HIGHLY recommended for the user to implement a STRONG IPFWADM/IPCHAINS firewall ruleset. Please see
Almost ALL modern Linux distributions come MASQ-Ready these days but its always good to check your system before you try to set things up. Follow these few steps for your kernel to see if your kernelis MASQ ready.
To see which kernel your system is running, run the following command:
Just for clarity: 2.4.x kernels run IPTABLES :: 2.2.x kernels run IPCHAINS :: 2.0.x kernels run IPFWADM
In general, you must have kernel support for:
IP forwarding
IP masquerading
IP Firewalling
etc.
You will also need to have most MASQ-related modules compiled (most modular kernels will already have all you need already done. Then you will NOT need to re-compile the kernel. If you AREN'T SURE if your Linux distribution is MASQ ready, do the following:
2.4.x kernels (look for most of the following entries out of the much longer list):
Run the command "
To check if IPMASQ was compiled statically into the kernel, run the command "
If you see these /proc entries and there WEREN'T any kernel modules loaded (shown via the "lsmod" command mentioned above), then your kernel has the IPTABLES subsystem statically compiled into it and is ready to go to use IPMASQ on this system.
If your kernel uses IPTABLES via modules, most of the stuff listed above should have been missing (because the modules probably aren't loaded). Run the command " And some optional ones like:
If you see those kernel files, IPTABLES was compiled using modules and things look ready to go to use IPMASQ on this system.
2.2.x kernels (look for most of the following entries out of the much longer list): list):
Run the command "
Other 2.2.x options can be checked by running "ls /proc/net/"
Even more 2.2.x options can be checked by running "ls /proc/net/"
2.0.x kernels (look for most of the following entries out of the much longer list):
Run the command " running "ls /proc/net"
Ultimately, it comes down to the fact if you see /proc files such as "i
So. Do most of the above /proc entries or kernel modules show up for your respective kernel? If so, thats good! If you cannot find any of the above entries or if you aren't sure if your distribution supports IP Masquerading by default, ASSUME IT DOESN'T SUPPORT MASQ. You can do one last check by looking at the
Regardless if your current kernel has MASQ support or not, reading the remainder of this section is still highly recommended as it contains other useful information.
First, you'll need to get some 2.4.x kernel sources (preferably the latest kernel version - NEWER *IS* BETTER IN LINUX LAND)
NOTE #1: As both the 2.4.x kernel train and the iptables program development progresses, the compile configurion options will change over time. As of this version of the IPMASQ howto, this section reflects the settings for IPTABLES 1.2.7a and the 2.4.20 kernel. If you are compiling against a newer or previous kernel or IPTABLES version, the dialogs and even commands might look different. It is recommended that you update to the newest versions of both the kernel and IPTABLES for added capability, performance, and stability of the kernel.
Next, depending on the version of the Linux kernel and IPTABLES archive you downloaded, you might want to apply some IPTABLES "patch-o-matic" patches against the kernel. These OPTIONAL patches might fix some known problems, add additional functionality you might need (H.323 protocol, specific issues with network games), etc. It should be noted that the Patch-O-Matic patches used to come with the IPTABLES archive. This is no longer the case and you have to download them (if any) seperately. You can find the the various URLs for downloading IPTABLES, the Patch-o-matic system, etc.
If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in
NOTE: Please notice that it IS NOT recommended to put the new kernel sources into the /usr/src/linux directory. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of the kernel sources.
For this HOWTO example, create a directory called
BZ2 Note: Some Linux distributions use the "I" option instead of the "y" option to decompress bzip2 archives.
Once uncompressed, I recommend that you rename the directory from the stock "linux" name to "linux-2.4.x" (replace the "x" with the specific version of your newly installed kernel) for clarity. To do this, run the command "
As mentioned above, you might consider applying any appropriate or optional patches to the kernel's MASQ code BEFORE you compile the final kernel. The IP MASQ code found in the stock kernels is already very useful and does not require any specific patching in order for the system to work for NAT-friendly network applications. Many of these patches are only to fix possible known bugs, add new features (some are /very/ cool), etc. Please refer to
Applying IPTABLES and Patch-o-Matic kernel patches
Download the iptables package and optional Patch-O-matics from the
Now, go into the new iptables-x.y.x directory(/usr/src/archive/netfilter/iptables-x.y.z) and run the command
NOTE: this assumes that your 2.4.x kernel sources are in the
NOTE #2: If you append a "/" to the end of the above command line, youwill get an error stating:
Here is an example of compiling IPTABLES v1.2.7a. Your output might lookdifferent depending on what version you are trying to use.
Ok, hopefully the IPTABLES program compiled up for you. Now, you need toinstall it. To do this, directory and run the command
Here is an example of installing IPTABLES v1.2.7a. Your output might lookdifferent depending on what version you are trying to use.
Next, if you are interested in applying a Patch-O-Matic patch set, go into the
NOTE #1: The use of the "pending" batch is the most common for IPMASQfunctionality but there are several others. See below.
NOTE #2: this assumes that your 2.4.x kernel sources are in the
NOTE #3: If you append a "/" to the end of the command line, youwill get an error stating:
Here is an example of the Patch-O-Matic prompts you might receive for a 2.4.20 kernel with the "20030107" Patch-O-Matic set. You can also run the "runme" program in a batch mode to speed things up, add experimental patches,etc. if you'd like. To better understand your options, simply run the "
If everything patches fine, you should see something like the text
towards the bottom of the screen. Beyond that, you don't have to install anything at this point. The next step is to compile the new PATCHED kernel.
Ok, now the new kernel is ready to be compiled but you should make sure that you also have the proper matching
and make sure its installed on the machine (the default place is in
Now that the kernel sources are patched up, you need to configure it to know what kinds of features you need (HD support, Networking support, MASQ support, etc.). Here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to configure and compile a kernel (modules vs static). The main difference from this example vs. an example given by a different MASQ guide is that some people might wish to compile kernel components either as modules OR monolithically into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use for things you aren't / won't use and modules also allow for drop-in software upgrades [usually no need to reboot the machine]). On the flip side, kernel modules add more complexity to your configuration and sometimes the kernel auto-loader might make mistakes (not that I've ever seen this happen). Compiling things directly into the kernel makes things simpler BUT you loose a huge level of flexibility. The following kernel configuration example is a mixture of both a selection of kernel modules and building them in monolithically (you probably will ALWAYS need MASQ functionality ready to go).
Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as USB printers, Ethernet network interfaces, SCSI and IDE HD controllers, etc. as well. Please refer to the
You will need to answer either YES, NO, or MODULE to the following program. Not all options will be available without the proper kernel patches described later in this HOWTO. Thisshouldn't be an issue as most 3rd party patches are only needed for a very select group of users.
Run the following commands to configure your kernel:
Please note the following kernel prompts reflect a 2.4.14 kernel (with some ofthe optional Patch-O-Matic additions. Please read the following carefully forrecommendations:
NOTE: These are just the kernel components you need for IP Masquerade networkingsupport. You will need to select whatever other options needed for your specific setup. If you want more information on what each one of these kernel modules does, please see the FAQ section of this HOWTO for details.
Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTOif you have problems compiling your kernel. Please see
You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs mentioned above in this section.
Please see
First of all, you need the kernel source for 2.2.x (preferably the latest kernel version)
NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different
NOTE #2: As the 2.2.x train progressed, the compile-time options keep on changing. As of this version, this section reflects the settings for a 2.2.20 kernel.
If you are running either a newer or older kernel version, the dialogs will look different. It is recommended that you update to the newest kernel for added capability and stability of the system.
If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in
NOTE: Please notice that it isn't recommended to put the new kernel sources into /usr/src/linux. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of your kernel sources.
For this HOWTO example, create a directory called
NOTE: Some Linux distributions use the "I" option instead of the "y" option to decompress bzip2 archives.
Once uncompressed, I recommend that you rename the directory from "linux" to "linux-2.2.x" for clarity. To do this, run the command
Apply any appropriate or optional patches to the kernel source code. By default, stock Linux kernels do not require any specific patching in order for the system to work. Features like PPTP/IPSEC masqurading are already built-in in the newest kernels but other tools like Xwindows forwarders are optional. Please refer to
Now that the kernel is patched up (if required), here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to compile a kernel. The main difference from this method vs. a different one is some people wish to compile things either as modules OR monolithically right into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use and allow for drop-in upgrades [no need to reboot]) BUT they add more complexity to your configuration. On the flip side, compiling things directly into the kernel makes things simpler BUT you loose a level of flexibility. The following example is a mixture of both built-in AND modules.
Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as network interfaces, optional SCSI controllers, etc. as well. Please refer to the
Please note the YES or NO ANSWERS to the following. Not all options will be available without the proper kernel patches described later in this HOWTO.
Run the following commands to configure your kernel:
The following kernel prompts reflect a 2.2.20 kernel:
NOTE: These are just the components you need for IP Masquerade. You will need to select whatever other options needed for your specific setup.
Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTO if you have problems compiling your kernel. Please see
You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs above in this section.
Please see
First of all, you need the kernel source for 2.0.x (preferably the latest kernel version)
As the 2.0.x train progress, the compile-time options keep on changing. As of this version, this section reflects the settings for a 2.0.39 kernel.
If this is your first time compiling the kernel, don't be scared. In fact, it's rather easy and it's covered in several URLs found in
NOTE: Please notice that it isn't recommended to put the new kernel sources into /usr/src/linux. You should leave the original kernel sources that came with your Linux distribution in /usr/src/linux. For more details on this topic, please read the "README" file in the top level directory of your kernel sources.
For this HOWTO example, create a directory called
Once uncompressed, I recommend that you rename the directory from "linux" to "linux-2.0.x" for clarity. To do this, run the command
Apply any appropriate or optional patches to the kernel source code. By default, stock Linux kernels do not require any specific patching in order for the system to work. Features like IPPORTFW, PPTP, and Xwindows forwarders are optional but very useful. Please refer to
Now that the kernel is patched up (if required), here are the MINIMUM kernel configuration options required to enable IP Masquerade functionality. Please understand that this HOWTO illustrates just ONE way to compile a kernel. The main difference from this method vs. a different one is some people wish to compile things either as modules OR monolithically right into the kernel. Basically, compiling things as modules gives you added flexibility to what is or isn't installed into the kernel (reduces unneeded memory use and allow for drop-in upgrades [no need to reboot]) BUT they add more complexity to your configuration. On the flip side, compiling things directly into the kernel makes things simpler BUT you loose a level of flexibility. The following example is a mixture of both built-in AND modules.
Side Note: It is assumed that you will also configure the kernel to use your other installed hardware such as network interfaces, optional SCSI controllers, etc. as well. Please refer to the
Please note the YES or NO ANSWERS to the following options. Not all options will be available without the proper kernel patches described later in this HOWTO:
Run the following commands to configure your kernel:
The following kernel prompts reflect a 2.0.39 kernel:
So go ahead and "exit" and you should be prompted to save your config.
NOTE: These are only components for IP Masquerade functionality. You may need to also select additional options to match your specific network and hardware setup.
Now compile the kernel (make dep; make clean; make bzImage; make modules; make modules_install) , etc. Again, it is beyond the scope of this HOWTO if you have problems compiling your kernel. Please see
You will then have move over the kernel binary, update your bootloader (LILO, Grub, etc.), and reboot. If you have questions about kernel compiling, I highly recommend to consult some of the URLs above in this section.
Since all INTERNAL MASQed machines should NOT have official Internet assigned addressees, there must be a specific and accepted way to allocate addresses to those machines without conflicting with anyone else's Internet address.
From the original IP Masquerade FAQ:
For the record, my preference is to use the 192.168.0.0 network with a 255.255.255.0 Class-C subnet mask and thus this HOWTO reflects this. Any of the above private networks are valid, but just be SURE to use the correct subnet-mask.
So, if you're using a Class-C network, you should number your TCP/IP enabled machines as 192.168.0.1, 192.168.0.2, 192.168.0.3, .., 192.168.0.x
192.168.0.1 is usually set as the internal gateway or Linux MASQ machine which reaches the external network. Please note that 192.168.0.0 and 192.168.0.255 are the Network and Broadcast address respectively (these addresses are RESERVED). Avoid using these addresses on your machines or your network will not function properly.
At this point, you should have your kernel and other required packages installed. All network IP addresses, gateway, and DNS addresses should be configured on your Linux MASQ server. If you don't know how to configure your Linux network cards, please consult the HOWTOs listed in either the 2.4.x
Now, the only thing left to do is to configure the IP firewalling tools to both FORWARD and MASQUERADE the appropriate packets to the correct machine.
** This section ONLY provides the user with the bare minimum firewall ruleset to get IP Masquerading working.
Once IP MASQ has been successfully tested (as described later in this HOWTO), please refer to the Stronger IPTABLES ruleset for 2.4.x kernels in
Instead of manually typing one of these files by hand, I recommend to simply
Please note that IPCHAINS is no longer the primary firewall configuration tool for the 2.6.x and 2.4.x kernels. The new kernels now use the IPTABLES toolkit though the new 2.4.x kernels CAN still run most old IPCHAINS or IPFWADM rulesets via a compatiblity module. It should be noted that when in this mode, NO IPTABLES modules can be loaded. It should also be noted that none of the 2.2.x IPMASQmodules are compatible with 2.4.x kernels. For a more detailed reason for these changes, please see the
Ok, as mentioned before, the
Anyway, create the file /etc/rc.d/rc.firewall-iptables with the following initial SIMPLE ruleset:
<rc.firewall-iptables START>
Once you are finished with editing the /etc/rc.d/rc.firewall ruleset, make itexecutable by typing in
Now that the firewall ruleset is ready, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below:
1. Redhat and Redhat-derived distros:
There are two ways to automatically load things in Redhat: /etc/rc.d/rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest. All you have to do is add the line:
to the end of the /etc/rc.d/rc.local file and thats it (as described earlierin the HOWTO).
The problem with this approach is that the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory:
<firewall-iptables START>
With this script in place, all you need to do now is make it executable andthen make it load upon reboot. First, make it executable by running:
2. Slackware:
There are two ways to load things in Slackware: /etc/rc.d/rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest. All you have to do is add the line:
Notes on how users might want to change the above firewall ruleset:
You could also have IP Masquerading enabled on a PER MACHINE basis instead of the above method, which is enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall ruleset.
Common mistakes:
It appears that a common mistake with new IP Masq users is to make the first command simply the following:
Do NOT make your default policy MASQUERADING. Otherwise, someone can manipulate their routing tables to tunnel straight back through your gateway, using it to masquerade their OWN identity!
Again, you can add these lines to the
Please see
Please note that IPFWADM is no longer the firewall tool for manipulating IP Masquerading rules for both the 2.1.x and 2.2.x kernels. These new kernels now use the IPCHAINS toolkit. For a more detailed reason for this change, please see
Create the file /etc/rc.d/rc.firewall-ipchains with the following initial SIMPLE ruleset:
<rc.firewall-ipchains START>
Once you are finished with editing the /etc/rc.d/rc.firewall ruleset, make itexecutable by typing in
Now that the firewall ruleset is ready, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below:
1. Redhat and Redhat-derived distros:
There are two ways to automatically load things in Redhat: /etc/rc.d/rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest. All you have to do is add the line:
to the end of the /etc/rc.d/rc.local file and thats it (as described earlierin the HOWTO).
The problem with this approach is that the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory:
<firewall-ipchains START>
With this script in place, all you need to do now is make it executable andthen make it load upon reboot. First, make it executable by running:
2. Slackware:
There are two ways to load things in Slackware: /etc/rc.d/rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest. All you have to do is add the line:
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do so using /etc/rc.d/rc.local. If you want a stronger system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
Notes on how users might want to change the above firewall ruleset:
You could also have IP Masquerading enabled on a PER MACHINE basis instead of the above method, which is enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall ruleset.
Common mistakes:
What appears to be a common mistake with new IP MASQ users is to make the first command:
Do NOT make your default policy MASQUERADING. Otherwise, someone can manipulate their routing tables to tunnel straight back through your gateway, using it to masquerade their OWN identity!
Again, you can add these lines to the
Please see
Create the file /etc/rc.d/rc.firewall with the following initial SIMPLE ruleset:<rc.firewall-ipfwadm START>
Once you are finished with editing the /etc/rc.d/rc.firewall ruleset, make itexecutable by typing in "
Now that the firewall ruleset is ready to go, you need to let it run after every reboot. You could either do this by running it by hand everytime (such a pain) or add it to the boot scripts. We have covered two methods below:
Redhat and Redhat-derived distros:
There are two ways to automatically load things in Redhat: /etc/rc.d/rc.local or a init script in /etc/rc.d/init.d/. The first method is the easiest. All you have to do is add the line:
The problem with this approach is that the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. To do this, copy the following file into the /etc/rc.d/init.d directory:
<firewall-ipfwadm START>
With this script in place, all you need to do now is make it executable andthen make it load upon reboot. First, make it executable by running:
Slackware:
There are two ways to automatically load things in Slackware: /etc/rc.d/rc.local or editing the /etc/rc.d/rc.inet2 file. The first method is the easiest. All you have to do is add the line:
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn' t executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do so using /etc/rc.d/rc.local. If you want the strong er system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
Notes on how users might want to change the above firewall ruleset:
You could have also enabled IP Masquerading on a PER MACHINE basis instead of the above method enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall ruleset.
Common mistakes:
What appears to be a common mistake with new IP Masq users is to make the first command:
Do NOT make your default policy MASQUERADING. Otherwise, someone who has the ability to manipulate their routing tables will be able to tunnel straight back through your gateway, using it to masquerade their OWN identity!
Again, you can add these lines to the
Please see
Besides setting the appropriate IP address for each internal MASQed machine(either statically or though DHCP), you should also set each internal machine with the appropriate gateway IP address of the Linux MASQ server and required DNS servers. In general, this is rather straight forward. You simply enter the address of your Linux host (192.168.0.1 is used throughout this HOWTO) as the machine's gateway address.
For the Domain Name Service (DNS), you add in any DNS servers that are available to you to use. The most apparent one(s) should be the DNS servers that your Linux server uses. You can optionally add any "domain search" suffix as well for quicker connections, etc.
After you have properly reconfigured the internal MASQed machines, remember to restart their appropriate network services or reboot them if need be.
The following configuration instructions assume that you are using a Class C network with 192.168.0.1 as your Linux MASQ server's address. Please note that 192.168.0.0 and 192.168.0.255 are reserved TCP/IP address per RFC1918 for usesjust like enabling IP Masquerade services.
As it stands, the following Platforms have been tested as internal MASQed machines. This is only an EXAMPLE of all compatible OSes out there:
Apple Macintosh OS and OS-X (with MacTCP or Open Transport or the BSD TCP/IP stack)
AT&T Unix (Caldera)
*BSD systems including Free/Net/Open/BSDi/386/etc.
Commodore Amiga (with AmiTCP or AS225-stack)
Digital VAX Stations 3520 and 3100 with UCX (TCP/IP stack for VMS)
Digital Ultrix, Digital Unix (Compaq Tru/64)
HP HP/UX
IBM AIX running on RS/6000, PowerPC, etc.
IBM OS/2 (including Warp v3)
IBM OS400 running on a AS/400
Linux distributions from vendors like Caldera, Corel, Debian, Mandrake, Redhat, Slackware, SuSe, etc. running various kernels like 1.2.x, 1.3.x, 2.0.x, 2.1.x, 2.2.x, 2.3.x, 2.4.x, etc.
Microsoft DOS (with NCSA Telnet package, DOS Trumpet works partially)
Microsoft Windows 3.1 (with the Netmanage or FTP packages)
Microsoft Windows For Workgroup 3.11 (with a TCP/IP package)
Microsoft Windows 95, OSR2, 98, 98se, Me
Microsoft Windows NT 3.51, 4.0, 2000, XP - (both workstation (professional) and server versions)
Novell Netware 4.01, 5.x, etc. with the TCP/IP service
SCO Openserver (v3.2.4.2 and 5) and UnixWare (AT&T Unix)
Sun Solaris 2.51, 2.6, 7, 8
heheh.. what else am I missing?
** Please note that some prompts might be different based upon the buildversion of Windows95 you are running **
If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this step is beyond the scope of this document andthough it is fairly simple, if you haven't done this before, please seekassitance.
Go to the 'Control Panel' --> 'Network'.
Click on Add --> Protocol --> Manufacture: Microsoft --> Protocol: 'TCP/IP protocol' if you don't already have it installed.
Highlight the TCP/IP item bound to your correct Windows95 network card e.g. (TCP/IP --> Intel EtherExpress Pro/100+) and select 'Properties'. Here, you have twooptions: configure a static address or use DHCP. Static addresses are simplebut require that you NEVER configure duplication IPs on different machines.The alternative is DHCP which automatically configures all DHCP-enabled workstations things like IP addresses, DNS servers, etc. from a central server (typically the Linux MASQ server).
DHCP enabled:
To use DHCP, simply click on the "Use DHCP to assign addresses" button.Please note that configuring a DHCP server is beyond the scope of this HOWTO but it is fully covered in TrinityOS and other Linux HOWTOs.
Static Addresses:
Now goto the 'IP Address' tab and set IP Address to 192.168.0.x, (1 < x < 255), and set the Subnet Mask to 255.255.255.0
Now select the "Gateway" tab and add 192.168.0.1 as your gateway under 'Gateway' and hit "Add".
Under the 'DNS Configuration' tab, make sure to put enter in a name for this machine and specify your official domain name. If you don't have your own domain, enter in the domain of your ISP. Next, you need to specify the DNS servers you plan on using.
DHCP: No entries are required as this is configured dynamically via DHCP.
STATIC: Add all of the DNS servers that your Linux MASQ server uses (usually found in
Optionally, you can add any appropriate domain search suffixes as well. Thisallows users to simply type in the hostname of the destination computer insteadof the fully qualified domain name (FQDN). This is similar to the PATH functionfor finding common Unix commands.
Leave all of the other settings alone as they are unless (even dangerous) if you don't know what you're doing.
Click 'OK' in all dialog boxes and restart your system.
As an initial test,
You can optionally create a
If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document.
Go to 'Control Panel' --> 'Network' --> Protocols
Add the TCP/IP Protocol and related Components from the 'Add Software' menu if you don't have TCP/IP service installed already.
Under 'Network Software and Adapter Cards' section, highlight the 'TCP/IP Protocol' in the 'Installed Network Software' selection box.
In 'TCP/IP Configuration', select the appropriate adapter, e.g.
Do not enable any of the following options (unless you know what you are doing):
'Automatic DHCP Configuration' : Unless you have a DHCP server running on your network.
Put anything in the 'WINS Server' input areas : Unless you have setup one or more WINS servers.
Enable IP Forwardings : Unless you are routing on your NT machine and really -REALLY- know EXACTLY what you're doing.
Click 'DNS', fill in the appropriate information that your Linux host uses (usually found in /etc/resolv.conf) and then click 'OK' when you're done.
Click 'Advanced', be sure to DISABLE 'DNS for Windows Name Resolution' and 'Enable LMHOSTS lookup' unless you known what these options do. If you want to use a LMHOSTS file, it is stored in C:\winnt\system32\drivers\etc.
Click 'OK' on all dialog boxes and restart the system.
If you haven't installed your network card and adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document.
Install the TCP/IP 32b package if you haven't already.
In 'Main'/'Windows Setup'/'Network Setup', click on 'Drivers'.
Highlight 'Microsoft TCP/IP-32 3.11b' in the 'Network Drivers' section, click 'Setup'.
Set the IP Address to 192.168.0.x (1 < x < 255), then set the Subnet Mask to 255.255.255.0 and Default Gateway to 192.168.0.1
Do not enable any of the following options (unless you know what you are doing):
'Automatic DHCP Configuration' : Unless you have a DHCP server running on your network.
Put anything in the 'WINS Server' input areas : Unless you have setup one or more WINS servers.
Click 'DNS', fill in the appropriate information your Linux host uses (usually found in /etc/resolv.conf). Then click 'OK' when you're done with it.
Click 'Advanced', check 'Enable DNS for Windows Name Resolution' and 'Enable LMHOSTS lookup' found in c:\windows.
Click 'OK' in all dialog boxes and restart the system.
As an initial test,
If you haven't installed your network card and either re-configured the networksubsystem or recompiled your kernel with the appropriate adapter driver, do so now. Descriptions to perform this task is beyond the scope of this document but are covered in the Networking HOWTO.
Install TCP/IP networking, such as the net-tools package, if you don't have it already.
Set IPADDR to 192.168.0.x (1 < x < 255), then set NETMASK to 255.255.255.0, GATEWAY to 192.168.0.1, and BROADCAST to 192.168.0.255.
Redhat (Mandrake / TurboLinux / etc): You can edit the
Slackware: You need to edit the /etc/rc.d/rc.inet1 file to configure the network subsystem.
To Add: Debian, Suse, Caldera, etc. Please email dranch@trinnet.netif you can tell me what distro uses what files to configure the networkingsubsystem.
Beyond this, most Linux distributions use significantly different networkconfiguration mechanisms let alone other UNIXes such as SunOS, BSDi, Solaris, AIX, TruUnix, FreeBSD, etc.). Please refer to your specific UNIX documentation for more details.
Add your domain name service (DNS) and domain search suffix in
You may also want to update your
Restart the appropriate services, or simply restart your system.
As an initial test, run the
If you haven't installed your network card, do so now. Descriptions to perform this task is beyond the scope of this document.
Load the appropriate packet driver. For example: an NE2000 Ethernet card set for I/O port 300 and IRQ 10, would need to be issued
Make a new directory, and then unpack the NCSA Telnet package:
Use a text editor to open the
Set
In this example, you should set
You should have at least one individual machine specified as the gateway, i.e. the Linux host:
Have another specified as a domain name service:
Note: substitute the appropriate information about the DNS according what your Linux host uses
Save your
As an initial test,
If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document.
Open the MacTCP control panel. Select the appropriate network driver (Ethernet, NOT EtherTalk) and click on the 'More...' button.
Under 'Obtain Address:', click 'Manually'.
Under 'IP Address:', select class C from the popup menu. Ignore the rest of the dialog box sections.
Fill in the appropriate information under 'Domain Name Server Information:'.
Under 'Gateway Address:', enter 192.168.0.1
Click 'OK' to save the settings. In the main window of the MacTCP control panel, enter the IP address of your Mac (192.168.0.x, 1 < x < 255) in the 'IP Address:' box.
Close the MacTCP control panel. If a dialog box pops up, notifying you to do so, then restart the system.
You may optionally ping the Linux box to test the network connection. If you have the freeware program MacTCP Watcher, click on the 'Ping' button, and enter the address of your Linux box (192.168.0.1) in the dialog window that pops up. (This is only an INTERNAL LAN connection test, you can't ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
You can optionally create a
If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document.
Open the TCP/IP Control Panel and choose 'User Mode ...' from the Edit menu. Make sure the user mode is set to at least 'Advanced' and click the 'OK' button.
Choose 'Configurations...' from the File menu. Select your 'Default' configuration and click the 'Duplicate...' button. Enter 'IP Masq' (or something to let you know that this is a special configuration) in the 'Duplicate Configuration' dialog, it will probably say something like 'Default copy'. Then click the 'OK' button, and the 'Make Active' button
Select 'Ethernet' from the 'Connect via:' pop-up.
Select the appropriate item from the 'Configure:' pop-up. If you don't know which option to choose, you probably should re-select your 'Default' configuration and quit. I use 'Manually'.
Enter the IP address of your Mac (192.168.0.x, 1 < x < 255) in the 'IP Address:' box.
Enter 255.255.255.0 in the 'Subnet mask:' box.
Enter 192.168.0.1 in the 'Router address:' box.
Enter the IP addresses of your domain name servers in the 'Name server addr.:' box.
Enter the name of your Internet domain (e.g. 'microsoft.com') in the 'Starting domain name' box under 'Implicit Search Path:'.
The following procedures are optional. Incorrect values may cause erratic behavior. If you're not sure, it's probably better to leave them blank, unchecked and/or un-selected. Remove any information from those fields, if necessary. As far as I know, there is no way to use the TCP/IP dialogs to tell the system not to use a previously selected alternate "Hosts" file. If you know, I would be interested.
Check the '802.3' if your network requires 802.3 frame types.
Click the 'Options...' button to make sure that the TCP/IP is active. I use the 'Load only when needed' option. If you continuously run and quit TCP/IP applications without rebooting your machine, you may find that unchecking the 'Load only when needed' option will prevent/reduce the effects on your machine's memory management. With the item unchecked, the TCP/IP protocol stacks are always loaded and available for use. If checked, the TCP/IP stacks are automatically loaded when needed and un-loaded when not. It's the loading and unloading process that can cause your machine's memory to become fragmented.
You may ping the Linux box to test the network connection. If you have the freeware program MacTCP Watcher, click on the 'Ping' button, and enter the address of your Linux box (192.168.0.1) in the dialog box that pops up. (This is only an INTERNAL LAN connection test, you can't ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
You can optionally create a
Click the close box or choose 'Close' or 'Quit' from the File menu, and then click the 'Save' button to save the changes you have made.
The changes take effect immediately, but rebooting the system won't hurt.
If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document.
Downloaded tcpip16.exe from
Now edit the above "NAMESERVER" entries and replace them with the correct IP addresses for your local DNS server.
Issue a
If you haven't installed the appropriate driver software for your Ethernet adapter, do so now. Descriptions to perform this task is beyond the scope of this document.
Install the TCP/IP protocol if you don't have it already.
Go to Programs/TCP/IP (LAN) / TCP/IP Settings
In 'Network', add your TCP/IP Address (192.168.0.x) and set your netmask (255.255.255.0)
Under 'Routing', press 'Add'. Set the Type to 'default' and type the IP Address of your Linux Box in the Field 'Router Address'. (192.168.0.1).
Set the same DNS (Nameserver) Address that your Linux host uses in 'Hosts'.
Close the TCP/IP control panel. Say yes to the following question(s).
Reboot your system
You may ping the Linux box to test the network configuration. Type
The descriptions to configure TCP/IP on OS/400 version V4R1M0 running on a AS/400 is beyond the scope of this document.
1) To perform any communications configuration tasks on your AS/400, you must have the special authority of *IOSYSCFG (I/O System Configuration) defined in your user profile. You can check the characteristics of your user profile with the DSPUSRPRF command.
2) Type GO CFGTCP command th reach the Configure TCP/IP menu.
3) Select Option 2 - Work with TCP/IP Routes.
4) Enter a 1 on the Opt field to add a route.* In Route Destination type *DFTROUTE* In Subnet Mask type *NONE* In Type of Service type *NORMAL* In Nex Hop type the address of your gataway (the Linux box)
The same logic should apply to setting up other platforms. Consult the sections above. If you're interested in writing about any of systems that have not been covered yet, please send a detail setup instruction to
Finally, it's time to give IP Masquerading an official try after all this hard work. If you haven't already rebooted your Linux box, do so to make sure the machines boots ok, executes the /etc/rc.d/rc.firewall ruleset, etc. Next, make sure that both the internal LAN connection and connection of your Linux hosts to the Internet is okay.
Follow these -11- tests to make sure all aspects of your MASQ setup isrunning properly:
Step One: run the command "/etc/rc.d/rc.firewall".
Does it load with some strange errors? Here are some exmaples and help to fixthem:
Problem #1:
Run the command "/sbin/lsmod" and make sure the module "ipchains.o" is NOT installed. If it is installed, your machine (most likely Redhat-7.x based) is probably trying to load an IPCHAINS ruleset which is incompatible with IPTABLES.
To disable this from happening in the future, run the command:
To remove the "ipchains" module without rebooting, run the command:
Problem #2:
Your version of IPTABLES it too old. You need to upgrade it with a newer version via an updated RPM, DEB, or via compiling up the source. You can get an updated version from your Linux distribution manufacturer or from the NetFilter WWW site. This is all covered in the
Problem #3:
Did you copy this rc.firewall file from a DOS machine? Load the rc.firewall file in a binary editor such as ViM (vim -b /etc/rc.d/rc.firewall) and make sure that every line is NOT finished with a ^M.
Step Two: Testing internal MASQ client PC connectivity
From an internal MASQed computer, try pinging its local IP address (i.e. ping 192.168.0.10 ). This will verify that TCP/IP is correctly working on the local machine. Almost ALL modern operating systems have built-in support for the "ping" command. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed PC as described earlier in
Step Three: Testing internal MASQ client to MASQ server connectivity
Next, from the same internal MASQed computer, try pinging the the IP address of the Linux MASQ server's INTERNAL interface (i.e. ping 192.168.0.1 ). This will verify that TCP/IP is correctly working on both the local and Linux MASQ machine. Almost ALL modern operating systems have built-in support for the "ping" command. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements sectionfor your 2.4.x kernel in
If the ping failed, check the network connection between the MASQ server and the PC. If it's a DIRECT Ethernet connection (no hub or switch), you MUST have a "Ethernet cross-over cable". These cables are common and can befound at any computer store. Without this cable, the NICs (network cards) will not give you a "LINK" light. If you are using a hub or switch, make sure the ports connected to the MASQ server and MASQed client machine have a LINK light. If they do and the pings STILL don't work or there is a lot ofpacket loss, try different ports on the hub/switch (it not all that uncommon to have hub/switch ports die). Finally, if things still don't work perfectly, try replacing each of the NICs in the machines. You would be surprised howmany people I've helped have found that their NIC cards were going bad andcaused them all kinds of grief.
Step Four: Testing internal MASQ server connectivity
On the MASQ server, ping the internal IP address of the MASQ server's network interface card (i.e. ping 192.168.0.1). If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements section for your2.4.x kernel in
Step Five: Testing internal MASQ server to MASQ clientconnectivity
Next from MASQed server, try pinging the IP address of one of the internalMASQ client computers (i.e. ping 192.168.0.10 ). This will verify that TCP/IP is correctly working on both the local server machine and on the MASQ client machine. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed PC as described earlier in
Step Six: Testing external MASQ server to Internet connectivity
From the MASQ server, ping the external IP address of the MASQ server's EXTERNAL network interface that is connected to the Internet. This address might be a Ethernet interface, a PPP interface, etc. connection to your ISP. If you don't know what this external IP address is, run the Linux command "/sbin/ifconfig" on the MASQ server itself to get the Internet address. The output should look something like the following (we are looking for the IP address of eth0):
As you can see from the above, the external IP address is "12.13.14.15" forthis example. So, now that you have your IP address after running the "ipconfig" command, ping your external IP address. This will confirm that the MASQ server has full network connectivity. The output should look something like the following (hit Control-C to abort the ping):
If either of these tests doesn't work, you need to go back and double check your network cabling and verify that the two network interfaces on the MASQ server are seen in "dmesg". An example of this output would be the following towards the END of the "dmesg" command:
Also be sure that the cabling is correct (Ethernet: the NICs connecting theexternal MASQ server to your ISP has the "link" light lit up). Finally, makesure that TCP/IP is correctly configured on the MASQed Server as described by the various Network HOWTOs (URLs can be found in the requirements section for your2.4.x kernel in
Step Seven: Testing internal MASQ client to external MASQ server connectivity
From an internal MASQed computer, ping the IP address of the MASQ server's EXTERNAL TCP/IP address obtained in Step FIVE above. This address could be from your Ethernet, PPP, etc. interface which is ultimately the address connected to your ISP. This ping test will prove that Linux masquerading (ICMP Masquerading specifically) and IP forwarding is working.
If everthing thing is working correctly, the output should look something like the following (hit Control-C to abort the ping):
If this test doesn't work, first make sure that the "Default Gateway" on the MASQed PC is pointing to the IP address on the MASQ -SERVERs- INTERNAL NIC. Also double check that the /etc/rc.d/rc.firewall script was run without any errors. Just as a test, try re-running the /etc/rc.d/rc.firewall script now to see if it runs OK. Also, though most kernels support it by default, make sure that you enabled "ICMP Masquerading" in the kernel comfiguration and "IP Forwarding" in your /etc/rc.d/rc.firewall script.
If you still can't get things to work, take a look at the output from the following commands run on the Linux MASQ SERVER:
"ifconfig" : Make sure the interface for your Internet connection (be it ppp0, eth0, etc.) is UP and you have the correct IP address for the Internet connection. An example of this output is shown in STEP FIVE above.
"netstat -rn" : Make sure your default gateway (the column with an IP address in the Gateway column) is set. An example of this output might look like:
"cat /proc/sys/net/ipv4/ip_forward" : Make sure it says "1" so that Linux forwarding is enabled
Run the command "/sbin/ipchains -n -L" for 2.2.x users or "/sbin/ipfwadm -F -l" for 2.0.x users. Specifically, look for the FORWARDing section to make sure you have MASQ enabled. An example of an IPCHAINS output might look like for users using the Simple rc.firewall ruleset:
Step Eight: Testing external MASQ ICMP forwarding
From an internal MASQed computer, ping a static TCP/IP address (NOT a machine by DNS name) out on the Internet (i.e. ping 152.2.210.80 (this technically the DNS name "metalab.unc.edu" whichis home of MetaLabs' Linux Archive). If this works, it should look somethinglike the result below and this ultimately shows that ICMP Masquerading is working properly. (hit Control-C to abort the ping):
If this didn't work, again check your Internet connection. Make sure thatthe MASQ server itself can ping this address. If this works from the MASQ server, make sure you are using the simple rc.firewall ruleset and that you have ICMP Masqurading compiled into the Linux kernel.
Finally, make sure that the ruleset which enables IP MASQ is pointing to the correct EXTERNAL interface. PPPoE users should use the MASQ servers'slogical PPP interface such as "ppp0" and /NOT/ the physical external interface like "eth0".
Step Nine: Testing MASQ functionality without DNS
Now try TELNETing to a remote IP address (i.e. telnet 152.2.210.81 ( this is technically the DNS name "metalab.unc.edu").It might take a few seconds to get a login prompt since this is a VERY busy server. Did you get a login prompt like shown below? If so, it means that TCP Masquerading is running OK. If not, try TELNETing to some other hosts you think will support TELNET like 198.182.196.55 (www.linux.org). If this still doesn't work, make sure you are using the simple rc.firewall ruleset for this test. An example of this output might look like (hit Control-D to exit out of the TELNET):
Step Ten: Testing MASQ functionality with DNSresolution
Now try TELNETing to a remote machine by DNS name (i.e. "telnet metalab.unc.edu" (IP address 152.2.210.81). If this works, the output should look like something below. With this test,this shows that UDP-based DNS is working fine.
If this did not work, but Step EIGHT did work, make sure that you have one or more valid DNS servers configured on each of the MASQ CLIENT computer(s) as shown in
Step Eleven: Testing more MASQ functionality with DNS
As a last test, try browsing some 'INTERNET' WWW sites on one of your MASQ Client machines, and see if you can reach them. For example, access the Linux Documentation Project site at
If you see The Linux Documentation Project homepage, then CONGRATULATIONS! It's working! If the WWW site comes up correctly, then all other standard network tools such as PING, TELNET, SSH, and with their related IP MASQ modules loaded: FTP, Real Audio, IRC DCCs, Quake I/II/III, CuSeeme, VDOLive, etc. should work fine too! If FTP, IRC, RealAudio, Quake I/II/III, etc. aren't working or are performing poorly, verify that their associated Masquerading modules are loaded by running "lsmod" and also be sure you are loading the module with any non-default server ports. If you don't see your needed module, make sure your /etc/rc.d/rc.firewall script is loading them (i.e. remove the # character for a given IP MASQ module).
Step Twelve: Any remaining functional, performance, etc. issues...
If your system passes all of the above tests, but functionality tests like WWW browsing, FTP, and other types of traffic aren't reliable or are slow, I recommend that you read the FAQ section of this HOWTO.. specifically the
Some TCP/IP application protocols will not currently work with Linux IP Masquerading because they either assume things about port numbers or encode TCP/IP addresses and/or port numbers in their data stream. These latter protocols need specific proxies or IP MASQ modules built into the masquerading code to make them work.
By default, Linux IP Masquerading cannot handle incoming services at all but there are a few ways that would allow this.
If you do not require high levels of security, then you can simply forward or redirect IP ports. There are various ways to perform this, though the most stable method is to use IPPORTFW. For more information, please see
If you wish to have some level of authorization on incoming connections, then you will need to either configure TCP-wrappers or Xinetd to allow only specific IP addresses to pass. The TIS Firewall Toolkit is a good place to look for tools and information.
More details on incoming security can be found in the
Generally, any application that uses standard TCP and UDP should work. If you have any suggestion, hints, etc., please see the
General Clients:
all supported platforms, file searching client (not all archie clients are supported)
all supported platforms, with the ip_masq_ftp.o kernel module for active FTP connections.
all supported platforms
all supported platforms, WWW surfing
all IRC clients on various supported platforms, DCC is supported via the ip_masq_irc.o module
all supported platforms, USENET news client
all platforms, with ICMP Masquerading kernel option
all supported platforms, email clients
all supported platforms, Secure TELNET/FTP clients
all supported platforms, email servers like Sendmail, Qmail, PostFix, etc.
all supported platforms, remote session
UNIX and Windows based platforms, some variations may not work
Windows(possibly all supported platforms), virtual reality surfing
all supported platforms
Multimedia and Communication Clients:
- MS Netmeeting, Intel Internet Phone Beta , and other H.323 applications - There are now two solutions to accomplish this through IPMASQed connections:
There is a stable BETA 2.2.x kernel module available on the
Another commercial solution is the
Windows, Client-Server 3D chat program
all supported platforms, with the ip_masq_cuseeme module loaded, please see
all supported clients. Requires the Linux kernel to be either compiled with PORTFW support, have the ip_masq_icq module (2.2.x and 2.0.x only), or havea SOCKS proxy running. A full description of this configuration is in
Windows, Peer-to-peer audio communications, users can reach you only if you initiate the call, but those users cannot call you without a specific port forwarding setup. See
Windows, network streaming audio
Windows, Peer-to-peer Text audio whiteboard communications, users can reach you only if you initiate the call, but those users cannot call you without a specific port forwarding setup. See
Windows, network streaming audio, higher quality available with the ip_masq_raudio UDP module
Windows, network streaming audio
Windows, with the ip_masq_vdolive patch
Windows, Client-Server 3D chat program
Games - See
Works but requires TCP ports 116, 118 and UDP port 6112 IPPORTFWed to the client game machine. See
Works with LooseUDP patch and new NAT-friendly -- email
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. Newer versions of Diablo use only TCP port 6112 and UDP port 6112. See
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See
Works right out of the box but requires the ip_masq_quake module if there are more than one Quake I/II/III player behind a MASQ box. Also, this module only supports Quake I and QuakeWorld by default. If you need to support Quake II or non-default server ports, please see the module install section of
Works with the LooseUDP patch, IPPORTFWing TCP, and UDP ports 6112 to the internal MASQed game machine. See
Works with LooseUDP patch
Other Clients:
Linux, network administration-account package
DOS, a suite containing telnet, ftp, ping, etc.
MS-Windows remotely controls a PC over TCP/IP, but only works if it is a client, but not a host without a specific port forwarding setup. See
uses NTP - network time protocol
Cannot connect to server
Cannot connect to opposite side
Cannot work at present (it makes invalid assumptions about addresses).
<rc.firewall-iptables-stronger START>
To automatically start this stronger firewall ruleset at the proper time,please see the end of the
This section provides a more in-depth guide to using the 2.2.x firewall tool, IPCHAINS. See above sections for IPFWADM rulesets.
This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :-). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. A nything not explicitly allowed is FORBIDDEN (well.. rejected actually). If your IP MASQ box breaks after implementing this rc.firewall script, be sure that you edit it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOGfile for any firewall errors.
For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see
NOTE #1: --- UPDATE YOUR KERNEL --- Linux 2.2.x kernels less than version 2.2.20 contain several different
NOTE #2: If you get a dynamically assigned TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon booting. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this for PPP users, carefully read and un-comment out the proper lines in the "Dynamic PPP IP fetch" section below. You can also find more details in the
Please also be aware that there are several GUI Firewall creation tools available as well. Please see
Lastly, if you are using a STATIC PPP IP address, change the "EXTIF="your.static.PPP.address"" line to reflect your address.
----------------------------------------------------------------
<rc.firewall-ipchains-stronger START>
To automatically start this stronger firewall ruleset at the proper time,please see the end of the
With IPCHAINS, you can block traffic to a particular site using the "input", "output", and/or "forward" rules. Remember that the set of rules are scanned from top to bottom and "-A" tells IPCHIANS to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come before any global rules. For example:
Using "input" rules:
Probably the fastest and most efficient method to block traffic, but this method only stops the MASQed machines and NOT the firewall machine itself. Of course, you might want to allow that combination.
Anyway, to block 204.50.10.13:
Using "output" rules:
This is the slower method to block traffic because the packets must go through masquerading before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site.
... start of "output" rules ...# reject and log outgoing to 204.50.10.13#ipchains -A output -s $ppp_ip/32 -d 204.50.10.13/32 -l -j REJECT# anything else outgoing on remote interface is valid#ipchains -A output -s $ppp_ip/32 -d 0.0.0.0/0 -l -j ACCEPT... end of "output" rules ...
Using "forward" rules:
Probably slower than "input" rules for blocking traffic, this only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s).
... start of "forward" rules ...# Reject and log from local net on PPP interface to 204.50.10.13.#ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT# Masquerade from local net on local interface to anywhere.#ipchains -A forward -i ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j MASQ... end of "forward" rules ...
No need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule.
NOTE: Unlike IPFWADM, IPCHIANS has only one way of coding the interfaces name. IPCHAINS uses the "-i eth0" option where as IPFWADM had both "-W" for the interface name and "-V" for the interface's IP address.
This section provides a more in-depth guide on using the 2.0.x firewall tool, IPFWADM. See below for IPCHAINS rulesets
This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. Anything not explicitly allowed is FORBIDDEN (well.. rejected, actually). If your IP MASQ box breaks after implementing this rc.firewall script, be sure that you edit it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors.
For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see
NOTE: If you get a dynamically assigned TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon boot. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this for PPP users, carefully read and un-comment out the proper lines in the "Dynamic PPP IP fetch" section below. You can also find more details on Strong rulesets and Dynamic IP addresses in the
Please also be aware that there are several GUI Firewall creation tools available as well. Please see
Lastly, if you are using a STATIC PPP IP address, change the "ppp_ip="your.static.PPP.address"" line to reflect your address.
----------------------------------------------------------------
<rc.firewall-ipfwadm-stronger START>
To automatically start this stronger firewall ruleset at the proper time,please see the end of the
With IPFWADM, you can block traffic to a particular site using the -I, -O or -F rules. Remember that the set of rules are scanned top to bottom and "-a" tells IPFWADM to "append" this new rule to the existing set of rules. So with this in mind, any specific restrictions need to come before global rules. For example:
Using -I (input ) rules:
Probably the fastest and most efficient method to block traffic but it only stops the MASQed machines, and NOT the the firewall machine itself. Of course, you might want to allow that combination.
Anyway, to block 204.50.10.13:
In the /etc/rc.d/rc.firewall ruleset:... start of -I rules ...# reject and log local interface, local machines going to 204.50.10.13#/sbin/ipfwadm -I -a reject -V 192.168.0.1 -S 192.168.0.0/24 -D 204.50.10.13/32 -o# local interface, local machines, going anywhere is valid#/sbin/ipfwadm -I -a accept -V 192.168.0.1 -S 192.168.0.0/24 -D 0.0.0.0/0... end of -I rules ...
Using -O (output) rules:
This is the slower method to block traffic because the packets go through masquerading first before they are dropped. Yet, this rule even stops the firewall machine from accessing the forbidden site.
... start of -O rules ...# reject and log outgoing to 204.50.10.13#/sbin/ipfwadm -O -a reject -V $ppp_ip -S $ppp_ip/32 -D 204.50.10.13/32 -o# anything else outgoing on remote interface is valid#/sbin/ipfwadm -O -a accept -V $ppp_ip -S $ppp_ip/32 -D 0.0.0.0/0... end of -O rules ...
Using -F (forward) rules:
Probably slower than -I (input) rules for blocking traffic, this still only stops masqueraded machines (e.g. internal machines). The firewall machine can still reach forbidden site(s).
... start of -F rules ...# Reject and log from local net on PPP interface to 204.50.10.13.#/sbin/ipfwadm -F -a reject -W ppp0 -S 192.168.0.0/24 -D 204.50.10.13/32 -o# Masquerade from local net on local interface to anywhere.#/sbin/ipfwadm -F -a masquerade -W ppp0 -S 192.168.0.0/24 -D 0.0.0.0/0... end of -F rules ...
There is no need for a special rule to allow machines on the 192.168.0.0/24 network to go to 204.50.11.0. Why? It is already covered by the global MASQ rule.
NOTE: There is more than one way of coding the interfaces in the above rules. For example instead of "-V 192.168.255.1" you can code "-W eth0", instead of "-V $ppp_ip" , you can use "-W ppp0". The "-V" method was phased out with the imgration to IPCHAINS, but for IPFWADM users, its more of a personal choice and documentation.
Masquerading more than one internal network is fairly simple. You need to first make sure that all of your networks are running correctly (both internal and external). You then need to enable traffic to pass to both the other internal interfaces and to be MASQed to the Internet.
Next, you need to enable Masquerading on the INTERNAL interfaces. This example uses a total of THREE interfaces: EXTIF stands for the eth0 interface which is the EXTERNAL connection to the Internet. INTIF stands for the eth1 interfaceand is the 192.168.0.0 network. Finally, INTIF2 stands for the eth2 interface and is the 192.168.1.0 network. Both INTIF and INTIF2 will be MASQed out of interface eth0 or EXTIF. In your rc.firewall ruleset next to the existing MASQ at the very end of the ruleset, add the following:
Please note that it is CORRECT to have "eth0" specified multiple times for theexmples shown above. The reason for this is the Linux kernel needs to knowwhich interface is used for OUTGOING traffic. Since eth0 in the above examplesis the Internet connection, it is listed for each internal interface.
If you would like to setup your network to automatically dial up the Internet, either the Diald demand dial-up or new versions of the PPPd packages will be of great utility. Both Diald and PPPd are very powerful in their configurationflexibility.
To setup PPPd for Dial-on-Demand, pease check out the
To setup Diald, please check out the
Once Dial on Demand and IP Masq have been setup properly, any MASQed client machines that initiate a web, telnet or ftp session will make the Linux box dynamically bring up its Internet link.
There is a timeout that will occur with the first connection. This is inevitable if you are using analog modems. The time taken to establish the modem link and the PPP connections may cause your client program (WWW browser, etc.) to stop. This isn't common though. If this does happen, just retry that Internet traffic request (say a WWW page) again and it should come up fine. You can also try setting echo "1" > /proc/sys/net/ipv4/ip_dynaddr kernel option to help with this initial setup.
IPPORTFW, IPAUTOFW, REDIR, UDPRED, and other programs are generic TCP and/or UDP port forwarding tools for Linux IP Masquerade (for < 2.4 kernels). These tools are typically used with or as a replacement for specific IP MASQ modules to get a specific network traffic through the MASQ server.
With port forwarders, you can redirect data connections from the Internet to an internal, privately addressed machine behind your IP MASQ server. This forwarding ability includes network protocols such as TELNET, WWW, SMTP, FTP (with a special patch - see below), ICQ, and many others.
NOTE: If you are just looking to do simple port forwarding but you don't need Masquerading support, you don't have any choice. You will STILL NEED to enable IP Masquerading support in the kernel AND either run a IPTABLES, IPCHAINS, or IPFWADM ruleset to be able to use Linux's port forwarding tools.
So why all the different choices? MARK (MFW), IPMASQADM (PORTFW or AUTOFW), IPPORTFW, IPAUTOFW, REDIR, and UDPRED (all URLs are in
In recent 2.2.x kernels, the IPMASQADM tool combined the IPAUTOFW and IPPORTFW 2.0.x kernel tools into one binary. Both the IPMASQADM tool and IPTABLES also supports a new mechanism called "MARK" or MFW. The MARK system works where a specific IPTABLES or IPCHAINS ruleset would match a given packet sequence.Once matched, the tool would "mark" these packets. Later, the IPMASQADM tool or a specific IPTABLE "table" could be instructed to change these packets as needed and forward them off to their desired destination. Currently, this HOWTO doesn't cover the MARK solution but it will in the near future.
Anyway, because of the availablity of the newer tools, it is *HIGHLY DISCOURAGED* to use the old tools such as IPAUTOFW (even AUTOFW in IPMASQADM) and REDIR because they don't properly notify the Linux kernel of their presence and can ultimately CRASH your Linux server with extreme use.
NOTE #2: With enabling PORTFW functionality in ANY 2.2/2.0 Linux kernel (not 2.4.x), internal machines typically CANNOT use the same "external" PORTFWed IP address to access a given internal" machine. To put it another way, PORTFW was only intended to be used with "external" computers on the Internet. If this is an issue for you, you can also implement the REDIR tool for 2.2.x and 2.0.x kernels to let internal machines get redirected to the internal servers too. The 2.4.x kernels running IPTABLES solves this issue once and for all and is covered in a FAQ entry in
NOTE #3: The forwarding of FTP server traffic to an internal MASQed FTP server, known as PORTFW FTP, is now fully supported in the 2.4.x kernels as well as in the 2.2.x kernels via a BETA version FTP kernel module (does NOT come with the stock Linus kernels). It should also be noted that you can also PORTFW FTP traffic using an external FTP proxy program (not covered in this HOWTO). It should be noted that the Beta 2.2.x FTP kernel module code is still experimental and some people get better results simply using ACTIVE FTP sessions compared to PASSIVE connections. Interestingly enough, other people have seen the exact opposite behavior. Please let us know what your results are like. More about this is covered below in both the 2.2.x and 2.0.x sections as the solutions requirethe use of different patches.
WARNING! Before jumping right into installing ANY of these tools, it needs to be mentioned that network security can be an issue with ANY PORT FORWARD tool. The reason for this is because these tools basically create a hole in strong packet firewalls for the required TCP/UDP ports. Though this doesn't pose any threat to your Linux machine, it might be an issue to the PORTFW'ed internal machine(s). No worries though, this is what Steven Clarke (the author of IPPORTFW) had to say about that:
What that means in English is that if you have a strong packet firewallrunning, PORTFW doesn't directly bypass any of that security. You will still be able to allow or deny specific IPs and/or domains to this new PORTFW'ed resource if you so wish.
With this said, it's important to have a strong firewall ruleset. Please see
2.4.x kernels users should be ready to go for PORTFW functionality. 2.2.x and2.0.x kernel kernel users will need to re-compile the Linux kernel to support PORTFW. It should be noted that some Linux distribution kernels might have this already done for you.
Modern 2.2.x kernel users will already have the PORTFW kernel option available to them via the normal kernel "make" procedures.
2.0.x users will need to apply a simple kernel option patch to have access tothen enable this via the normal kernel "make" procedures.
Unlike ALL previous Linux kernels, the 2.4.x series now allows for fullPORTFW, PORTFW FTP, and PORTFW REDIR functionality within the "iptables" tool itself.
NOTE: Once you enable a port forwarder on say port 80 (forward WWW traffic through the MASQ server to an internal WWWserver), that port will no longer be used by the Linux IP Masquerade serveritself. To be more specific, if you have a WWW server already running on the MASQ server, enabling PORTFW will now give all Internet users acces to the WWW pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server.
To enable port forwarding on a 2.4.x kernel:
Edit the /etc/rc.d/rc.firewall-iptables ruleset and place the lines shown below just ABOVE the "
NOTE: Unlike the 2.2.x and 2.0.x kernels, PORTFWed traffic does *not* traverse the INPUT or OUTPUT rules. It only traverses the FORWARD rule.
NOTE: If you use get a DYNAMIC TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you will NEED to make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this, please see
/etc/rc.d/rc.firewall
That's it! Just re-run your /etc/rc.d/rc.firewall-iptables ruleset and test it out!
--------------------------------------------------------------------------
Running the rc.firewall-iptables-stronger ruleset? Good for you! To get PORTFWrunning with this ruleset, it's very easy. The following example is for HTTP (WWW) traffic to be PORTFWed to the IP address indicated by the $PORTFWIP variable:
Take the ruleset lines shown above (for the generic rc.firewall ruleset) and place them just after the "
PORTFW FTP: If you have the "ip_conntrack_ftp" and "ip_nat_ftp" kernel modules loaded into kernel space (as already done in the rc.firewall-iptables script), the simple PREROUTING command like the one shown above changed for for port "21" should do the trick. This is much easier than the configuration for the old 2.2.x / 2.0.x kernels!
Please note, if you setup PORTFW to an internal FTP server that is running on a NON-standard FTP port, say port 8021, you MUST tell the "ip_conntrack_ftp" module about the new FTP port. The reason for this is that FTP is not a NAT-friendly protocol. By telling the NAT module about this new non-standard FTP port, the NAT module and do it's job again. To do this, edit your rc.firewall file and change the loading of the FTP module to look something like this:
PORTFW Redirection of Internal requests:
In the past, if users PORTFWed port 80 on their EXTERNAL IP address to some internal machine, only machines out on the Internet would properly reachthis internal WWW server. If you tried to contact this internal WWW servervia the MASQ server's EXTERNAL address, it would fail. Fortunately, there is a workaround for 2.2.x and 2.0.x kernels using the REDIR tool. Even better, the use of the REDIR tool is NOT required for the 2.4.x kernels. To support redirection like this from an internal host, add a rule like the one shownbelow ABOVE the "Catch all" FORWARDing rule in the rc.firewall file. The following example will REDIRECT internal WWW traffic to the 192.168.0.2 internal machine (please change the IP address to reflect your configuration):
First, make sure you have the newest 2.2.x kernel uncompressed into /usr/src/kernel/linux. If you haven't already done this, please see
Next, you'll need to compile the 2.2.x kernel as shown in
Now, compile and install the IPMASQADM tool:
Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to be forwarded to the internal Masqueraded machine at IP address 192.168.0.10.
PORTFW FTP: As mentioned above, there are two solutions for forwarding FTP server traffic to an internal MASQed PC. The first solution *IS* a BETA level IP_MASQ_FTP module for 2.2.x kernels to PORT Forward FTP connections to an internal MASQed FTP server. The other method is using a FTP proxy program (the URL is in
NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server, a port forward will now give all Internet users the WWW pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server.
Anyway, to enable port forwarding for HTTPd:
Edit the /etc/rc.d/rc.firewall ruleset and ENABLE the "Optional" "HTTP" sections in both the INPUT and OUTPUT subsections.
Add the following lines shown below JUST BELOW the "
NOTE: If you use get a DYNAMIC TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you will NEED to make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this, please see
/etc/rc.d/rc.firewall
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out!
If you get the error message "ipchains: setsockopt failed: Protocol not available", you AREN'T running your new IPPORTFW enabled kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again. If you are sure you are running your new kernel, run the command "ls /proc/net/ip_masq" and make sure the "portfw" file exists. If it doesn't, you must have made an error when configuring your kernel. Try again.
For those who want to understand why PORTFW cannot redirect traffic for bothexternal and internal interfaces (the REDIR situation), here is an email from Juanjo that better explains it:
First, make sure you have the newest 2.0.x kernel uncompressed into /usr/src/kernel. If you haven't already done this, please see
NOTE: Please replace the "x" in the "subs-patch-x.gz" file name with the most current version available on the site.
Next, if you plan on port forwarding FTP traffic to an internal server, you will have to apply an additional NEW IP_MASQ_FTP module patch found in
Now, copy the IPPORTFW patch (subs-patch-x.gz) into the Linux directory
Next, apply the kernel patch to create the IPPORTFW kernel option:
Ok, time to compile the kernel as shown in
Now with a newly compiled kernel, please compile and install the actual "IPPORTFW" program
Now, for this example, we are going to allow ALL WWW Internet traffic (port 80) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10.
NOTE: Once you enable a port forwarder on port 80, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have a WWW server already running on the MASQ server and then you port forward port 80 to an internal MASQed computer, ALL internet users will see the WWW pages pages from the -INTERNAL- WWW server and not the pages on your IP MASQ server. This only performs a port forward to some other port, say 8080, to your internal MASQ machine. Though this will work, all Internet users will have to append :8080 to the URL to then contact the internal MASQed WWW server.
Anyway, to enable port forwarding, edit the /etc/rc.d/rc.firewall ruleset. Add the follow lines but be sure to replace the word "$extip" with your Internet IP address.
NOTE: If you use get a DYNAMIC TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you will NEED to make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this, please see
/etc/rc.d/rc.firewall
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out!
If you get the error message "ipfwadm: setsockopt failed: Protocol not available", you AREN'T running your new kernel. Make sure that you moved the new kernel over, re-run LILO, and then reboot again.
Port Forwarding FTP servers:
If you plan on port forwarding FTP to an internal machine, things get more complicated. The reason for this is because the standard IP_MASQ_FTP kernel module wasn't written for this though some users report that it works without any problems. Personally, without the patch, I've heard that extended file transfers in excess of 30 minutes will fail without the patch while other users swear that it works flawlessly. Anyway, I recommend that you try the following PORTFW instruction with the STOCK ip_masq_ftp module and see if it works for you. If it doesn't, try using the modified ip_masq_ftp module.
For those who need the module, Fred Viles wrote a modified IP_MASQ_FTP module to make things work. If you are curious what EXACTLY are the issues, download the following archive since Fred documents it quite well. Also understand that this patch is somewhat experimental and should be treated as such. It should be noted that this patch is ONLY available for the 2.0.x kernels though there is a different patch available for 2.2.x kernels.
So, to get the 2.0.x patch working, you need to:
FIRST, apply the IPPORTFW kernel patch as shown earlier in this section.
Download the "msqsrv-patch-36" from Fred Viles's FTP server in
Patch the kernel with this new code by running "cat msqsrv-patch-36 | patch -p1"
Next, replace the original "ip_masq_ftp.c" kernel module with the new one
mv /usr/src/linux/net/ipv4/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c.orig
mv /usr/src/linux/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c
Lastly, build and install the kernel with this new code in place.
Once this is complete, edit the /etc/rc.d/rc.firewall ruleset and add the following lines, but be sure to replace the word "$extip" with your Internet IP address.
This example, like the one above, will allow ALL FTP Internet traffic (port 21) hitting your Internet TCP/IP address to then be forwarded to the internal Masqueraded machine at IP address 192.168.0.10.
NOTE: Once you enable a port forwarder on port 21, that port can no longer be used by the Linux IP Masquerade server. To be more specific, if you have an FTP server already running on the MASQ server, a port forward will now give all Internet users the FTP files from the -INTERNAL- FTP server and not the files on your IP MASQ server.
/etc/rc.d/rc.firewall
That's it! Just re-run your /etc/rc.d/rc.firewall ruleset and test it out!
Linux IP Masquerade supports CuSeeme via the "ip_masq_cuseeme" kernel module. This kernel modules should be loaded in the /etc/rc.d/rc.firewall script. Once the "ip_masq_cuseeme" module is installed, you should be able to both initiate and receive CuSeeme connections to remote reflectors and/or users.
NOTE: It is recommended to use the IPPORTFW tool instead of the old IPAUTOFW tool for running CuSeeme.
If you need more explicit information on configuring CuSeeme, see
ICQ, the instant messaging client now owned by AOL, has changed over theyears. All modern ICQ clients are NAT friendly and thus DON'T requireany special NAT modules, PORTFW tricks, etc.
IF, for some reason, you want to run an OLD ICQ client, you can read thissection. If not, just IGNORE all this info. I am leaving this in theHOWTO demonstrate large a LARGE PORTFW example.
There are three methods of getting ICQ to work behind a Linux MASQ server. These solutions include the use the ICQ Masq module (for 2.2.x and 2.0.x kernels), using IPPORTFW for basic ICQ functionality, or setting up a SOCKS proxy server.
MODULE: The ICQ module was written for the older generation of ICQ clientsfor both the 2.2.x and 2.0.x kernels. This module allows for the simple setup of multiple ICQ users behind a MASQ server. It also doesn't require any special changes to the ICQ client(s). Recently, AOL changed the protocol andports used for ICQ. Because of this, many users might find that theip_masq_icq module will no longer help them. For users of the older ICQ clients, the 2.2.x version of the module supports file transfer and read-time chat. The 2.0.x kernel module doesn't support file transfers and there is no module available for the 2.4.x kernels.
PORTFW: Your next option is to use port forwarding. With port forwarding, basic ICQ chat will work but file transfers might not be very reliable. Please see below for an example of how to configure ICQ PORTFW.
SOCKS: Finally, your last and possibly best option is to setup a SOCKS proxy server on your Linux machine. This service can happily co-exist with the MASQ service and ICQ should be fully functional regardless of what Linux kernel version you are running. The use of a SOCKS server will require ALL ICQclients to be reconfigured to use it and the installation and configurationof a SOCKS server has nothing to do with IP Masquerade. Because of this,SOCKS is not covered in this HOWTO.
If you are interested in Andrew Deryabin's
To use port forwarding (PORFW)for ICQ, you will have to make some changes on both Linux and ICQ clients but all ICQ messaging, URLs, chat, and some file transfers should work.
First, you need to be running a Linux kernel with IPPPORTFW enabled. Please see
Next, you need to add the following lines to your /etc/rc.d/rc.firewall file. This example assumes that 10.1.2.3 is your external Internet IP address and your internal MASQed ICQ machine is 192.168.0.10:
The following example is for a 2.2.x kernel with IPCHAINS:
I have included two examples here for the user: Either one would work fine:
Example #1
The following example is for a 2.0.x kernel with IPFWADM:
I have included two examples here for the user: Either one would work fine:
Example #1
Example #2
Once your new rc.firewall is ready, reload the ruleset to make sure things are OK by simply typing in "/etc/rc.d/rc.firewall". If you get any errors, you either don't have IPPORTFW support in the kernel or you made a typo in the rc.firewall file.
Now, in ICQ's Preferences-->Connection, configure it to be "Behind a LAN" and "Behind a firewall or Proxy". Now, click on "Firewall Settings" and configure it to be "I don't use a SOCK5 proxy". Also note that it was previously recommended to change ICQ's "Firewall session timeouts" to "30" seconds BUT many users have found that ICQ becomes unreliable. It has been found that ICQ is more reliable with its stock timeout setting (don't enable that ICQ option) and simply change MASQ's timeout to 160 seconds. You can see how to change this timeout in
Now ICQ will tell you that you will have to restart ICQ for the changes to take effect. To be honest, I had to REBOOT the Windows9x machine in order for things to work right but some users might say otherwise. So.. try it both ways.
A user once told me that by simply portforwarding port 4000 to his ICQ machine, it worked perfectly. He reported that EVERYTHING worked fine (even chat, file transfers, etc) WITHOUT re-configuring ICQ from its default settings. Your mileage might vary on this topic but I thought you might like to hear about this alternative configuration.
The LooseUDP patch allows semi-NAT-friendly games that usually use UDP connections to both WORK behind a Linux IP Masquerade server.
What the LooseUDP patch does is allow ALL UDP packets to be NATed through the MASQ box without any checks or expiration. This liberal forwarding method is considered insecure by many and is disabled in modern2.2.x kernels. The 2.4.x kernels with it's IPTABLES stateful UDP inspection only allows incoming UDP packets into the machine (and thus MASQ) if there was already an outbound UDP packet to that same host in it's stateful table. Ifthe MASQ host hasn't sent a UDP packet to the remote host within ~30 seconds,the return UDP table entry is deleted. Because of this, IPTABLES removes most of the need for the LooseUDP patch as it does it in a more secure fashion.
Currently, LooseUDP is available as a patch for 2.0.36+ kernels and it is already built into 2.2.3+ kernels though it is now DISABLED by DEFAULT in 2.2.16+ (please see the example rc.firewal ruleset comments for details).
To get LooseUDP running on a 2.0.x kernel, follow the following steps:
Have the newest 2.0.x kernel sources uncompressed in the /usr/src/linux directory
ABSOLUTELY REQUIRED for v2.0.x: Download and install the IPPORTFW patch from
Download the LooseUDP patch from
Now, put the LooseUDP patch in the /usr/src/linux directory. Once this is done, type in:
Now, depending on the version of your "patch", You will then see the following text:
If you see the text "Hunk FAILED" only ONCE and ONLY ONCE at the very beginning of the patching, don't be alarmed. You probably have an old patch file (this has been fixed) but it still works. If it fails completely, make sure you have applied the IPPORTFW kernel patch FIRST.
Once the patch is installed, re-configure the kernel as shown in
To get LooseUDP running on a 2.2.x kernel, follow the following steps:
In the /etc/rc.d/rc.firewall script, goto the BOTTOM of the file and find the LooseUDP section. Change the "0" in the line:
NOTE: The LooseUDP code is /not/ available (?required?) for the 2.4.x kernels
See the begining of this section for all the details. Basically, the old 2.0.x / 2.2.x LooseUDP code was considered a security issue. Because of this, it was removed from the kernel. Fortunately, some games that used to require the LooseUDP code on the 2.2.x IPCHAINS system might work just final under the 2.4.x IPTABLES kernels. If the games don't work, I'm not aware of a solution for you. Sorry.
Once you are running the new LooseUDP enabled kernel, you should be good to go for most NAT-friendly games. Some URLs have been given for patches to make games like BattleZone and others NAT friendly. Please see
If you can think of any useful FAQ suggestions, please send it to
If your Linux distribution doesn't support IP MASQ out of the box, don't worry. All you have to do is to re-compile the kernel as shown above in this HOWTO.
NOTE: If you can help us fill out this table, please email
Caldera < v1.2 : NO - ?
Caldera v1.3 : YES - 2.0.35 based
Caldera v2.2 : YES - 2.2.5 based
Caldera eServer v2.3 : YES - ? based
Debian v1.3 : NO - ?
Debian v2.0 : NO - ?
Debian v2.1 : YES - 2.2.1 based
Debian v2.2 : YES - 2.2.15 based
Debian v3.0 : YES - 2.4.18 based
DLX Linux v? : ? - ?
DOS Linux v? : ? - ?
FloppyFW v1.0.2 : ? - ?
Gentoo v1.4 : YES - ? Based
Hal91 Linux v? : ? - ?
Linux PPC vR4 : NO - ?
Linux Pro v? : ? - ?
LinuxWare v? : ? - ?
Mandrake v5.3 : YES - ?
Mandrake v6.0 : YES - 2.2.5
Mandrake v6.1 : YES - ?
Mandrake v7.0 : YES - 2.2.14
Mandrake v7.1 : YES - 2.2.15
Mandrake v7.2 : YES - 2.2.17
Mandrake v8.0 : YES - ?
Mandrake v8.1 : YES - 2.4.8
Mandrake v8.2 : YES - ?
Mandrake v9.0 : YES - ?
Mandrake v9.1 : YES - 2.4.21-pre
MkLinux v? : ? - ?
MuLinux v3rl : YES - ?
Redhat < v4.x : NO - ?
Redhat v5.0 : YES - ?
Redhat v5.1 : YES - 2.0.34 based
Redhat v5.2 : YES - 2.0.36 based
Redhat v6.0 : YES - 2.2.5 based
Redhat v6.1 : YES - 2.2.12 based
Redhat v6.2 : YES - 2.2.14 based
Redhat v7.0 : YES - 2.2.16 based
Redhat v7.2 : YES - 2.4.7 based
Redhat v7.3 : YES - 2.4.? based
Redhat v8.0 : YES - 2.4.18? based
Redhat v9.0 : YES - 2.4.20 based
Slackware v3.0 : ? - ?
Slackware v3.1 : ? - ?
Slackware v3.2 : ? - ?
Slackware v3.3 : ? - 2.0.34 based
Slackware v3.4 : ? - ?
Slackware v3.5 : ? - ?
Slackware v3.6 : ? - ?
Slackware v3.9 : ? - 2.0.37pre10 based
Slackware v4.0 : YES - 2.2.6 based
Slackware v7.0 : YES - 2.2.13 based
Slackware v7.1 : YES - 2.2.16 based
Slackware v8.0 : YES - 2.4.17 based
Slackware v8.1 : YES - ? based
Stampede Linux v? : ? - ?
SuSE v5.2 : YES - 2.0.32 base
SuSE v5.3 : YES - ?
SuSE v6.0 : YES - 2.0.36 based
SuSE v6.1 : YES - 2.2.5 based
SuSE v6.3 : YES - 2.2.13 based
Tomsrbt Linux v? : ? - ?
TurboLinux Lite v4.0 : YES - ?
TurboLinux v6.0 : YES - 2.2.12 based
TriLinux v? : ? - ?
Yggdrasil Linux v? : ? - ?
A 486/66 box with 16MB of RAM was more than sufficient to fill a 1.54Mb/s T1 100%! MASQ has also been known to run quite well on 386SX-16s with 8MB of RAM. Yet, it should be noted that Linux IP Masquerade starts thrashing the system with more than 500 MASQ entries.
The only application that I know which can temporarily break Linux IP Masquerade, is GameSpy. Why? When it refreshes its lists, it creates 10,000s of quick connections in a VERY short period of time. Until these sessions timeout, the MASQ tables become "FULL". See
While we are at it:
There is a hard limit of 4096 concurrent connections each for TCP & UDP. This limit can be changed by fiddling the values in /usr/src/linux/net/ipv4/ip_masq.h - a maximum limit of 32000 should by OK. If you want to change the limit - you need to change the PORT_MASQ_BEGIN & PORT_MASQ_END values to get an appropriately sized range above 32K and below 64K.
How did you put the rc.firewall onto your machine? Did you cut&paste it into a TELNET window, FTP it from a Windows/DOS machine, etc? Try this.. log into your Linux box and run "vim -b /etc/rc.d/rc.firewall" and see if all your lines end in a ^M. If they do, delete all the ^M and try again.
Stay calm. Get yourself a cup of tea, coffee, soda, etc., and have a rest. Once your mind is clear, try the suggestions mentioned below. Setting up Linux IP Masquerading is NOT hard but there are several concepts that will be new to you.
Again, go through all the steps in
Check the
Check out the
Make sure that you aren't running ROUTED or GATED. To verify, run "ps aux | grep -e routed -e gated"
Post your question to the IP Masquerade Mailing List (see next the FAQ section for details). Please only use this if you cannot find the answer from the IP Masquerading Archive. Be sure to include all the information requested in
Post your question to a related Linux NNTP newsgroup.
Send email to
Check your configurations again :-)
There are two ways to join the two Linux IP Masquerading mailing lists. The first way is to send an email to
Subscribe via email: Now put the word "subscribe" in either the subject or body of the e-mail message. If you want to only subscribe to the Digest version of either the main MASQ or MASQ-DEV list (all e-mails on the given list during the week are sent to you in one big email), put the words "subscribe digest" in either the subject or body of the e-mail message.
Once the server receives your request, it will subscribe you to your requested list and give you a PASSWORD. Save this password as you will need it to later unsubscribe from the list or change your options.
The second method is to use a WWW browser and subscribe via a form at
Once subscribed, you will get emails from your subscribed list. It should be also noted that both subscribed and NON-subscribed users can access the two list's archives. To do this, please see the above two WWW URLs for more details.
Lastly, please note that you can only post to the MASQ list from the original account/address you used to subscribe.
If you have any problems regarding the mailing list or the mailing list archive, please contact