LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/IP-Masquerade-HOWTO.sgml

17634 lines
516 KiB
Plaintext
Raw Permalink Blame History

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<Book id="ipmasq-toc">
<!-- Search for Blah for markers : verify that all the SGML escaping works -->
<BookInfo>
<Title>Linux IP Masquerade HOWTO</Title>
<AUTHOR>
<FirstName>David</Firstname>
<othername role="mi">A.</othername>
<surname>Ranch</surname>
<affiliation>
<address><email>dranch@trinnet.net</email></address>
</affiliation>
</AUTHOR>
<pubdate>
November 13, 2005
</pubdate>
<Abstract>
<para>
November 13, 2005
</para>
<para>
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.
</para>
</Abstract>
</BookInfo>
<Chapter id="ipmasq-intro1.0">
<Title>Introduction</Title>
<Sect1 id="ipmasq-intro1.1">
<Title>Introduction to IP Masquerading or IP MASQ</Title>
<para>
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.
</para>
<para>
<quote>
<Emphasis role="strong">
This document is intended for systems running stable Linux kernels like 2.4.x,
2.2.x, and 2.0.x preferably on an IBM-compatible PC. IP Masquerade
does work on other Linux-supported platforms like Sparc, Alpha, PowerPC, etc.
but this HOWTO doesn't cover them in as much detail. Beta kernels
such as 2.5.x, 2.3.x, 2.1.x, and ANY kernels less than 2.0.x are NOT covered
in this document. The primary reason for this is because many of the older
kernels are considered broken. If you are using an older kernel version, it
is highly advisable to upgrade to one of the stable Linux kernels before using
IP Masquerading.
</Emphasis>
</quote>
</para>
</Sect1>
<Sect1 id="ipmasq-intro1.2">
<Title>Foreword, Feedback &amp; Credits</Title>
<para>
<emphasis>
From the original IPMASQ HOWTO author:
</emphasis>
</para>
<para>
<quote>
As a new user, I found it very confusing to setup IP masquerade on the Linux
kernel, (back then, its was a 1.2.x kernel). Although there was a FAQ and a
mailing list, there was no documentation dedicated to this. There was also
some requests on the mailing list for a HOWTO manual. So, I decided to write
this HOWTO as a starting point for new users and possibly create a building
block for other knowledgeable users. If you, the reader, have any additional
ideas, corrections, or questions about this document, please feel free to
contact us.
</quote>
</para>
<para>
This document was originally written by <ULink
URL="mailto:ambrose@writeme.com">Ambrose Au</Ulink> back in August, 1996,
based on the 1.x kernel IPMASQ FAQ written by Ken Eves and numerous helpful
messages from the original IP Masquerade mailing list. In particular, a
mailing list message from Matthew Driver inspired Ambrose to set up IP
Masquerade and eventually write version 0.80 of this HOWTO. In April 1997,
Ambrose created the Linux IP Masquerade Resource Web site at
<Ulink URL="http://ipmasq.webhop.net">http://ipmasq.webhop.net</Ulink> which has
provided up-to-date information on Linux IP Masquerading ever since. In
February 1999, <ULink URL="dranch@trinnet.net">David Ranch</ULink> took over
maintenance of the HOWTO. David then re-wrote the HOWTO and added a
substantial number of sections to the document. Today, the HOWTO is still
maintained by David where he constantly updates it and fixes any reported bugs,
etc.
</para>
<para>
Please feel free to send any feedback or comments regarding this HOWTO to
<ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink> if you have
any corrections or if any information/URLs/etc. is missing. Your invaluable
feedback will certainly influence the future of this HOWTO!
</para>
<para>
<Emphasis>
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
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#ipmasq">
Dranch's Linux Page</Ulink>. Additional news, mirrors of the HOWTO, and
information regarding IPMASQ can be found at the
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resource</ULink> web page.
If you have any technical questions on IP Masquerade, please join the
<ULink URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade Mailing List</ULink>
instead of sending email to David or Ambrose. Most MASQ problems are -common-
for ALL MASQ users and can be easily solved by users on the list. In addition
to this, the response time of the IP MASQ email list will be much faster than
a reply from either David or Ambrose.
</Emphasis>
</para>
<para>
The latest version of this document can be found at the following sites which
also contains HTML, Postscript, PDF, etc. versions
</para>
<ItemizedList>
<listitem>
<para>
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#ipmasq">
Dranch's Linux page</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/">http://ipmasq.webhop.net/: The IP
Masquerade Resources</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq2.webhop.net/">http://ipmasq2.webhop.net/: The IP
Masquerade Resources MIRROR</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.tldp.org">The Linux Documentation Project</ULink>
</para>
</listitem>
<listitem>
<para>
Also refer to <ULink URL="http://ipmasq.webhop.net/index.html#mirror">IP
Masquerade Resource Mirror Sites Listing
</ULink> for other local mirrored sites.
</para>
</listitem>
</ItemizedList>
</Sect1>
<Sect1 id="ipmasq-intro1.3">
<Title>Copyright &amp; Disclaimer</Title>
<para>
This document is <Literal remap="tt">copyrighted(c) 2003,2002,2001,2000 for
David A. Ranch </Literal> and it is a FREE document. You may redistribute it
under the terms of the GNU General Public License (GPL).
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
<quote><Emphasis>THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY
DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS
DOCUMENT.</Emphasis>
</quote>
</para>
<para>
Ok, with all this behind us... On with the show..
</para>
</Sect1>
</Chapter>
<Chapter id="ipmasq-background2.0">
<Title>Background Knowledge</Title>
<Sect1 id="ipmasq-background2.1">
<Title>What is IP Masquerade?</Title>
<para>
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
<Emphasis role="strong">an officially assigned IP address</Emphasis>.
</para>
<para>
MASQ allows a set of machines to <Emphasis role="strong">invisibly</Emphasis>
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.
</para>
<para>
If you would like to know more on how MASQ (1:Many) differs from 1:1 (true) NAT
and Proxy solutions, please see the <XRef LinkEnd="what-is-masq"> FAQ entry.
</para>
</Sect1>
<Sect1 id="ipmasq-background2.2">
<Title>Current Status</Title>
<para>
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.
</para>
<para>
2.4.x kernel users:
<ItemizedList>
<listitem>
<para>
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
<ULink URL="http://ipmasq.webhop.net/">http://ipmasq.webhop.net/: The IP
Masquerade Resources</ULink> site for updated news, etc.
</para>
</listitem>
</itemizedlist>
</para>
<para>
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) should
work too without any special module. Some users on the mailing list also had
good results with video conferencing software.
</para>
<para>
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 <XRef LinkEnd="aliasing"> FAQ section.
</para>
<para>
Anyways, please refer to <XRef LinkEnd="Supported-Client-Software"> for a more
complete listing of software supported by IP Maquerade all kernel versions.
</para>
<para>
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 :
</para>
<para>
<ItemizedList>
<listitem>
<para>
UNIX: Sun Solaris, [Net,Free,Open,*i]-BSD, Hp-UX, Linux, IBM AIX, Digital UNIX, Ultrix, etc.
</para>
</listitem>
<listitem>
<para>
Microsoft Windows 2000, NT (3.x and 4.x), 95/98/ME, Windows for Workgroups
(with the TCP/IP package)
</para>
</listitem>
<listitem>
<para>
IBM OS/2
</para>
</listitem>
<listitem>
<para>
Apple Macintosh MacOS machines running either MacTCP or Open Transport
</para>
</listitem>
<listitem>
<para>
DOS-based systems with packet drivers and the NCSA Telnet package
</para>
</listitem>
<listitem>
<para>
VAXen
</para>
</listitem>
<listitem>
<para>
Compaq/Digital Alpha running Linux and NT
</para>
</listitem>
<listitem>
<para>
Amiga computers with AmiTCP or AS225-stack.
</para>
</listitem>
</ItemizedList>
</para>
<para>
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!
</para>
</Sect1>
<Sect1 id="ipmasq-background2.3">
<Title>Who Can Benefit From IP Masquerade?</Title>
<para>
<ItemizedList>
<listitem>
<para>
If you have a Linux host connected to the Internet and..
</para>
</listitem>
<listitem>
<para>
if you have internal computers running TCP/IP connected that are connected to
this Linux box via on a network, and/or
</para>
</listitem>
<listitem>
<para>
if your Linux host has more than one modem and acts as a PPP or SLIP server
connected to <Emphasis >other</Emphasis> computers, and these machines do not
have official or public assigned IP addresses (i.e. addressed with private
TCP/IP numbers).
</para>
</listitem>
<listitem>
<para>
If you want those <Emphasis >OTHER</Emphasis> 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.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="ipmasq-background2.4">
<Title>Who Doesn't Need IP Masquerade?</Title>
<para>
<ItemizedList>
<listitem>
<para>
If your machine is a stand-alone Linux host connected to the Internet (setting
up a firewall is a good idea though), or
</para>
</listitem>
<listitem>
<para>
if you already have multiple assigned public addresses for your <Emphasis>
OTHER</Emphasis> machines, and
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="ipmasq-background2.5">
<Title>How does IP Masquerade Work?</Title>
<para>
Based from the original IP Masquerade FAQ by Ken Eves:
Here is a drawing of the most simplistic setup:
</para>
<screen>
PPP/ETH/etc. +------------+ +-------------+
to ISP provider | Linux #1 | PPP/ETH/etc. | Anybox |
| | | |
<---------- modem1| |modem2 ----------- modem3| |
| | | |
111.222.121.212 | | 192.168.0.100 | |
+------------+ +-------------+
</screen>
<para>
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 network
interface (e.g. modem2) connected to allow incoming network traffic be it
from a PPP connection, Ethernet connection, etc.
</para>
<para>
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
<ULink URL="http://www.ietf.org/rfc/rfc1918.txt?number=1918">
RFC1918 private address</ULink>, say 192.168.0.100. (see below for more info)
</para>
<para>
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].
</para>
<para>
Quoting Pauline Middelink (the founder of Linux's IPMASQ):
</para>
<para>
"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 PPP
or 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 <ULink
URL="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html">PPP-HOWTO</ULink>
for more details."
</para>
<para>
The following is an excerpt on how IPMASQ briefly works though this will be
explained 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:
</para>
<screen>
o I tell machine ANYBOX that my PPP or Ethernet connected Linux box is its
gateway.
o When a packet comes into the Linux box from ANYBOX, it will assign the
packet to a new TCP/IP source port number and insert its own IP address
inside the packet header, saving the originals. The MASQ server will
then send the modified packet over the PPP/ETH interface onto the
Internet.
o When a packet returns from the Internet into the Linux box, Linux
examines if the port number is one of those ports that was assigned
above. If so, the MASQ server will then take the original port and
IP address, put them back in the returned packet header, and send
the packet to ANYBOX.
o The host that sent the packet will never know the difference.
</screen>
<para>
<Emphasis >Another IP Masquerading Example:</Emphasis>
</para>
<para>
A typical example is given in the diagram below:
</para>
<screen>
Ethernet
192.168.0.x
+----------+
| |
| A-box |::::::
| |.2 :
+----------+ :
: +----------+ PPP/ETH
+----------+ : .1 | Linux | link
| | :::::::| Masq-Gate|:::::::::::::::::::>> Internet
| B-box |:::::: | | 111.222.121.212
| |.3 : +----------+
+----------+ :
:
+----------+ :
| | :
| C-box |::::::
| |.4
+----------+
| | | >
| <-Internal Network--> | | <- External Network ----> >
| connected via an | | Connected from the >
| Ethernet hub or | | Linux server to your >
| switch | | Internet connection >
</screen>
<para>
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, Cablemodem
router, 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 <Emphasis><Literal>Masq-Gate</Literal></Emphasis> is
the IP Masquerading gateway for ALL internal networked machines. In this
example, the machines <Emphasis><Literal>A-box</Literal></Emphasis>, <Emphasis>
<Literal>B-box</Literal></Emphasis>, and <Emphasis><Literal>C-box</Literal>
</Emphasis> would have to go through the Masq-Gate to reach the Internet. The
internal network uses one of several
<ULink URL="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1918.html">
RFC-1918 assigned private network addresses</ULink>, where in this case, would
be the Class-C network 192.168.0.0. If you aren't familiar with RFC1918, it
is encouraged to read the first few chapters of the RFC but the jist of it is
that the TCP/IP addresses 10.0.0.0/8, 172.16-31.0.0/12, and 192.168.0.0/16
are reserved. When we say "reserved", we mean that anyone can use these
addresses as long as they aren't routed over the Internet. ISPs are even
allowed to use this private addressing space as long as they keep these
addresses within their own networks and NOT advertise them to other ISPs.
Unfortunately, this isn't always the case but thats beyond the scope of
this HOWTO.
</para>
<para>
Anyway, the Linux box in the diagram above has the TCP/IP address 192.168.0.1
while the other systems has the addresses:
</para>
<para>
<ItemizedList>
<listitem>
<para>
A-Box: 192.168.0.2
</para>
</listitem>
<listitem>
<para>
B-Box: 192.168.0.3
</para>
</listitem>
<listitem>
<para>
C-Box: 192.168.0.4
</para>
</listitem>
</ItemizedList>
</para>
<para>
The three machines, <Literal>A-box</Literal>, <Literal>B-box</Literal> and
<Literal>C-box</Literal>, can have any one of several operating systems, just
as long as they can speak TCP/IP. Some such as <Emphasis >Windows
95</Emphasis>, <Emphasis >Macintosh MacTCP or OpenTransport </Emphasis>, or
even another <Emphasis >Linux box</Emphasis> have the ability to connect to
other machines on the Internet. When running the IP Masquerade, the
masquerading system or <Literal>MASQ-gate</Literal> converts all of these
internal connections so that they appear to originate from the
<Literal>masq-gate</Literal> itself. MASQ then arranges so that the data
coming back to a masqueraded connection is relayed to the proper originating
system. Therefore, the systems on the internal network are only able to see
a direct route to the internet and are unaware that their data is being
masqueraded. This is called a "Transparent" connection.
</para>
<para>
NOTE: Please see <XRef LinkEnd="FAQ"> for more details on topics such as:
</para>
<para>
<ItemizedList>
<listitem>
<para>
The differences between NAT, MASQ, and Proxy servers.
</para>
</listitem>
<listitem>
<para>
How packet firewalls work
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="kernel-2.4.x-Requirements">
<Title>Requirements for IP Masquerade on Linux 2.4.x</Title>
<para>
<quote> <Emphasis >** Please refer to <ULink URL="http://ipmasq.webhop.net/">IP
Masquerade Resource</ULink> for the latest information. **</Emphasis>
</quote>
</para>
<ItemizedList>
<listitem>
<para>
The newest 2.4.x kernels are now using both a completely new TCP/IP network
stack as well as a new NAT sub-system called NetFilter. Within this NetFilter
suite 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 up
IPMASQ won't be too bad. If you find anything unclear, downright wrong, etc.
please email David about it.
</para>
<para>
<Emphasis role="strong">Unlike</Emphasis> 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.
<Emphasis role="strong">BUT..</Emphasis> with the 2.4.x kernels, you cannot
use the old 2.2.x MASQ modules like ip_masq_ftp, ip_masq_irc, etc.
<Emphasis role="strong">AND</Emphasis> 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 <XRef LinkEnd="ipchains-on-2.4.x"> for
additional details.
</para>
</listitem>
</ItemizedList>
<para>
Some new 2.4.x functionalities include the following:
</para>
<para>
<Emphasis role="strong">PROs:</Emphasis>
<ItemizedList>
<listitem>
<para>
Lots of new protocols modules like: amanda, eggdrop, ipsec, ipv6, portscan,
pptp, quota, rsh, talk, and tftp
</para>
</listitem>
<listitem>
<para>
TRUE 1:1 NAT functionality for those who have TCP/IP addresses and subnets
to use (no more iproute2 commands)
</para>
</listitem>
<listitem>
<para>
Stateful application level (FTP, IRC, etc.) and stateful protocol level
(TCP/UDP/ICMP) network traffic inspection
</para>
</listitem>
<listitem>
<para>
Built-in PORT Forwarding (no more ipmasqadm or ipportfw commands)
</para>
</listitem>
<listitem>
<para>
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!
</para>
</listitem>
<listitem>
<para>
PORT Forwarding of FTP traffic to internal hosts is now completely supported
and is handled in the conn_trak_ftp module
</para>
</listitem>
<listitem>
<para>
Full Policy-Based routing features (source-based TCP/IP address routing)
</para>
</listitem>
<listitem>
<para>
Compatibility with Linux's FastRoute feature for significantly faster packet
forwarding (a.k.a Linux network switching).</para>
<para>Note that this feature is still not compatible with packet filtering
for strong firewall rulesets.
</para>
</listitem>
<listitem>
<para>
Fully supports TCP/IP v4, v6, and even DECnet (ack!)
</para>
</listitem>
<listitem>
<para>
Supports wildcard interface names like "ppp*" for serial interfaces like
ppp0, ppp1, etc
</para>
</listitem>
<listitem>
<para>
Supports filtering on both input and output INTERFACES (not just IP addresses)
</para>
</listitem>
<listitem>
<para>
Source Ethernet MAC filtering
</para>
</listitem>
<listitem>
<para>
Denial of Service (DoS) packet rate limiting
</para>
</listitem>
<listitem>
<para>
Packet REJECTs now have user-selectable return ICMP messages
</para>
</listitem>
<listitem>
<para>
Variable levels of logging (different packets can go to different SYSLOG
levels)
</para>
</listitem>
<listitem>
<para>
Other features like traffic mirroring, securing traffic per login, etc.
</para>
</listitem>
</ItemizedList>
</para>
<para>
<Emphasis role="strong">CONs:</Emphasis>
<ItemizedList>
<listitem>
<para>
Netfilter is an entirely new architechure thus most of the older 2.2.x
MASQ kernel modules written to make non-NAT friendly network applications
work 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-friendly
protocols. 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. :-)
</para>
<para>
Here is the status of the known IP Masq kernel modules or patches as found
on the <ULink URL="http://ipmasq.webhop.net">IPMASQ WWW site's Application
Support Matrix</ULink>. In addition, you should also setup out the
<ULink URL="http://www.netfilter.org/documentation/pomlist/pom-summary.html">
Netfilter Patch-o-Matic</ULink> URL as well. If you have the time and
knowledge to help in the porting of code, your efforts would be highly
appreciated:
</para>
<screen>
Status = Module name = Description and notes
--------- ----------- ----------------------------------
Ported CuSeeme Used for Video conferencing
NotPorted DirectPlay Used for online Microsoft-based games
Ported FTP Used for file transfers
- NOTEs: Built into the kernel and
fully supports PORTFWed FTP
ReWritten H.323 Used for Video conferencing
NotPorted ICQ Used for Instant messaging
* No longer required for modern ICQ clients
Ported Irc Used for Online chat rooms
Ported Quake Used for online Quake games
Ported PPTP Allow for multiple clients to the same server
NotPorted Real Audio Used for Streaming video / audio
* No longer required for modern RealVideo clients
NotPorted VDO Live Used for Streaming audio?
</screen>
<para>
Documentation on how to perform MASQ module porting is available at
<ULink URL="http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html">
http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO.html
</ULink>. If you have the time and knowledge, your talent would highly be
appreciated in porting these modules.
</para>
</listitem>
</ItemizedList>
</para>
<para>
If you'd like to read up more on NetFilter and IPTables, please see:
<ULink URL="http://www.netfilter.org/documentation/index.html#HOWTO">
http://www.netfilter.org/documentation/index.html#HOWTO</ULink>
and more specifically <ULink
URL="http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO.html">
http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO.html</ULink>
</para>
<para>
<Emphasis role="strong">Linux 2.4.x IP Masquerade requirements include:
</Emphasis>
</para>
<ItemizedList>
<listitem>
<para>
Any decent computer hardware. See <XRef LinkEnd="FAQ-Hardware"> for more
details.
</para>
</listitem>
<listitem>
<para>
The 2.4.x kernel source is available from <ULink URL="http://www.kernel.org/">
http://www.kernel.org/</ULink>.
</para>
<para>
NOTE: Most modern Linux distributions,
<XRef LinkEnd="MASQ-supported-Distributions">, that
natively come with 2.4.x kernels are typically modular kernels and have
all the IP Masquerade functionality already included. In such cases,
there is no need to compile a new Linux kernel. If you are UPGRADING your
kernel, you should be aware of other programs that might be required and/or
need to be upgraded as well (mentioned later in this HOWTO).
</para>
</listitem>
<listitem>
<para>
The program "iptables" version 1.2.4 or newer ( 1.2.7a or newer is highly
recommended ) archive available from
<ULink URL="http://www.netfilter.org/">
http://www.netfilter.org/</ULink>
<ItemizedList>
<listitem>
<para>
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.
</para>
<para>
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.
</para>
</listitem>
<listitem>
<para>
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
<ULink URL="http://www.netfilter.org/">Unreliable IPTABLES HOWTOs</Ulink>
page.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Loadable kernel modules, preferably 2.1.121 or higher, are available from
<ULink URL="http://home.pi.se/blox/modutils/index.html">
http://home.pi.se/blox/modutils/index.html </ULink> or
<ULink URL="ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils
">ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils</ULink>
</para>
</listitem>
<listitem>
<para>
A properly configured and running TCP/IP network running on the Linux machine
as covered in
<ULink URL="http://www.tldp.org/HOWTO/Net-HOWTO/index.html">
Linux NET HOWTO</ULink> and the
<ULink URL="http://www.tldp.org/LDP/nag2/index.html">
Network Administrator's Guide</ULink> . Also check out the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink> document which is also authored by David Ranch. TrinityOS is a
very comprehensive guide for Linux networking. Some topics include IP MASQ, security,
DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, and performance sections,
to name a few. There are over Fifty sections in all!
</para>
</listitem>
<listitem>
<para>
Connectivity to the Internet for your Linux host covered in
<ULink URL="http://www.tldp.org/HOWTO/ISP-Hookup-HOWTO.html">
Linux ISP
Hookup HOWTO</ULink>, <ULink URL="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html">
Linux PPP HOWTO</ULink>, and
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink>. Other helpful HOWTOs could include:
<ULink URL="http://www.tldp.org/HOWTO/mini/DHCP/index.html">Linux DHCP
mini-HOWTO</ULink>,
<ULink URL="http://www.tldp.org/HOWTO/Cable-Modem/index.html">
Linux Cable Modem mini-HOWTO</ULink> and
<ULink URL="http://www.tldp.org/HOWTO/DSL-HOWTO/index.html">
http://www.tldp.org/HOWTO/DSL-HOWTO/index.html</ULink>
</para>
</listitem>
<listitem>
<para>
Know how to configure, compile, and install a new Linux kernel as described in
the <ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">Linux Kernel
HOWTO</ULink>. This HOWTO does cover kernel compiling but only for IP
Masquerade related options.
</para>
</listitem>
</ItemizedList>
</Sect1>
<Sect1 id="kernel-2.2.x-Requirements">
<Title>Requirements for IP Masquerade on Linux 2.2.x </Title>
<para>
<quote> <Emphasis >** Please refer to <ULink URL="http://ipmasq.webhop.net/">IP
Masquerade Resource</ULink> for the latest information. **</Emphasis>
</quote>
</para>
<para>
<ItemizedList>
<listitem>
<para>
Any decent computer hardware. See <XRef LinkEnd="FAQ-Hardware"> for more
details.
</para>
</listitem>
<listitem>
<para>
The 2.2.x kernel source is available from <ULink URL="http://www.kernel.org/">
http://www.kernel.org/</ULink>.
</para>
<para>
NOTE: Most modern Linux distributions,
<XRef LinkEnd="MASQ-supported-Distributions">, that
natively come with 2.2.x kernels are typically modular kernels and have
all the IP Masquerade functionality already included. In such cases,
there is no need to compile a new Linux kernel. If you are UPGRADING your
kernel, you should be aware of other programs that might be required and/or
need to be upgraded as well (mentioned later in this HOWTO).
</para>
<ItemizedList>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</listitem>
<listitem>
<para>
NOTE #2: Some newer <XRef LinkEnd="MASQ-supported-Distributions"> such as
Redhat 5.2 might not be Linux 2.2.x ready (upgradable). Tools
like DHCP, NetUtils, etc. will need to be upgraded. More details
can be found later in the HOWTO.
</para>
</listitem>
<listitem>
<para>
Loadable kernel modules, preferably 2.1.121 or higher, are available from
<ULink URL="http://home.pi.se/blox/modutils/index.html">
http://home.pi.se/blox/modutils/index.html</ULink> or
<ULink URL="ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils
">ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils</ULink>
</para>
</listitem>
<listitem>
<para>
A properly configured and running TCP/IP network running on the Linux
machine as covered in
<ULink URL="http://www.tldp.org/HOWTO/Net-HOWTO/index.html">
Linux NET HOWTO</ULink> and the
<ULink URL="http://www.tldp.org/LDP/nag2/index.html">
Network Administrator's Guide</ULink> . Also check out the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink> document which is also authored by David Ranch. TrinityOS is
a very comprehensive guide for Linux networking. Some topics include IP MASQ,
security, DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, and
performance sections, to name a few. There are over Fifty sections in all!
</para>
</listitem>
<listitem>
<para>
Connectivity to the Internet for your Linux host covered in
<ULink URL="http://www.tldp.org/HOWTO/ISP-Hookup-HOWTO.html">
Linux ISP
Hookup HOWTO</ULink>, <ULink URL="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html">
Linux PPP HOWTO</ULink>, and
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink>. Other helpful HOWTOs could include:
<ULink URL="http://www.tldp.org/HOWTO/mini/DHCP/index.html">Linux DHCP
mini-HOWTO</ULink>,
<ULink URL="http://www.tldp.org/HOWTO/Cable-Modem/index.html">
Linux Cable Modem mini-HOWTO</ULink> and
<ULink URL="http://www.tldp.org/HOWTO/DSL-HOWTO/index.html">
http://www.tldp.org/HOWTO/DSL-HOWTO/index.html</ULink>
</para>
</listitem>
<listitem>
<para>
IP Chains 1.3.10 or newer are available from
<ULink URL="http://www.netfilter.org/ipchains/">
http://www.netfilter.org/ipchains/</ULink>.
Additional information on
version requirements for the newest IPCHAINS HOWTO, etc is located at the
<ULink URL="http://www.netfilter.org/ipchains/"> Linux IP Chains
page</ULink> <ULink URL="http://www.netfilter.org/ipchains"> (mirror at
Samba.org)</ULink>
</para>
</listitem>
<listitem>
<para>
Know how to configure, compile, and install a new Linux kernel as described in
the <ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">Linux Kernel
HOWTO</ULink>. This HOWTO does cover kernel compiling but only for IP
Masquerade related options.
</para>
</listitem>
</ItemizedList>
</para>
<para>
<Emphasis role="strong">
Other optional patches and tools for 2.2.x kernels</Emphasis>
<itemizedlist>
<listitem>
<para>
TCP/IP port-forwarding or re-directing:
<ItemizedList>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/juanjox/">IP PortForwarding (IPMASQADM)
- RECOMMENDED - mirror</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
PORTFW FTP Solutions:
<ItemizedList>
<listitem>
<para>
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 <ULink URL="http://ipmasq.webhop.net">
IPMASQ WWW site </ULink> for full details. Please note that this is not
required for 2.4.x kernels.
</para>
<para>
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
<ULink URL="http://www.suse.de/en/whitepapers/proxy_suite/">SuSe Proxy
URL</ULink>.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
IPROUTE2 for True 1:1 NAT, Policy-based (source) routing, and Traffic
Shaping:
<ItemizedList>
<listitem>
<para>
<ULink URL="ftp://ftp.inr.ac.ru/ip-routing/">ftp://ftp.inr.ac.ru/ip-routing
</ULink>
</para>
</listitem>
<listitem>
<para>
Documentation can be found at
<ULink URL="http://www.compendium.com.ar/policy-routing.txt">
http://www.compendium.com.ar/policy-routing.txt</ULink>
</para>
</listitem>
<listitem>
<para>
The <ULink URL="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/index.html">
Advanced Routing HOWTO</ULink>
</para>
</listitem>
<listitem>
<para>
Some source code mirrors are at:
</para>
<para>
<ULink URL="ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/">
ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/ (STM1 to USA)</ULink>
---
<ULink URL="ftp://sunsite.icm.edu.pl/pub/Linux/iproute/">
ftp://sunsite.icm.edu.pl/pub/Linux/iproute/</ULink>
</para>
<para>
<ULink URL="ftp://ftp.sunet.se/pub/Linux/ip-routing/">
ftp://ftp.sunet.se/pub/Linux/ip-routing/</ULink> ---
<ULink URL="ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/">
ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/</ULink>
</para>
<para>
<ULink URL="ftp://ftp.crc.ca/pub/systems/linux/ip-routing/">
ftp://ftp.crc.ca/pub/systems/linux/ip-routing/</ULink> ---
<ULink URL="ftp://ftp.paname.org">ftp://ftp.paname.org (France)</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Please see the <ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resource
</ULink> page for more information available on these patches and possibly
others as well.
</para>
</Sect1>
<Sect1 id="kernel-2.0.x-Requirements">
<Title>Requirements for IP Masquerade on Linux 2.0.x</Title>
<para>
<quote> <Emphasis >** Please refer to <ULink URL="http://ipmasq.webhop.net/">IP
Masquerade Resource</ULink> for the latest information. **</Emphasis>
</quote>
</para>
<ItemizedList>
<listitem>
<para>
Any decent computer hardware. See <XRef LinkEnd="FAQ-Hardware"> for more
details.
</para>
</listitem>
<listitem>
<para>
The 2.0.x kernel source is available from <ULink URL="http://www.kernel.org/">
http://www.kernel.org/</ULink>.
</para>
<para>
NOTE: Most modern Linux <XRef LinkEnd="MASQ-supported-Distributions"> that
natively come with 2.0.x kernels are typically modular kernels and have
all the IP Masquerade functionality already included. In such cases,
there is no need to compile a new Linux kernel. If you are UPGRADING your
kernel, you should be aware of other programs that might be required and/or
need to be upgraded as well (mentioned later in this HOWTO).
</para>
</listitem>
<listitem>
<para>
Loadable kernel modules, preferably 2.1.85 or newer is available from
<ULink URL="http://home.pi.se/blox/modutils/index.html">
http://home.pi.se/blox/modutils/index.html </ULink> or
<ULink URL="ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils
">ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils</ULink>
(modules-1.3.57 is the minimal requirement)
</para>
</listitem>
<listitem>
<para>
A properly configured and running TCP/IP network running on the Linux machine
as covered in <ULink URL="http://www.tldp.org/HOWTO/Net-HOWTO/index.html">
Linux
NET HOWTO </ULink> and the <ULink URL="http://www.tldp.org/LDP/nag2/index.html">
Network Administrator's Guide</ULink>Also check out the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink> document which is also authored by David Ranch. TrinityOS is
a very comprehensive guide to Linux networking. Topics include IP MASQ,
security, DNS, DHCP, Sendmail, PPP, Diald, NFS, IPSEC-based VPNs, performance
issues, and many more. There exists over fifty sections in all!
</para>
</listitem>
<listitem>
<para>
Connectivity to the Internet for your Linux host is covered in
<ULink URL="http://www.tldp.org/HOWTO/ISP-Hookup-HOWTO.html">
Linux ISP
Hookup HOWTO</ULink>, <ULink URL="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html">
Linux PPP HOWTO</ULink>, and
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink>. Other helpful HOWTOs could include:
<ULink URL="http://www.tldp.org/HOWTO/mini/DHCP/index.html"> Linux DHCP
mini-HOWTO</ULink>,
<ULink URL="http://www.tldp.org/HOWTO/Cable-Modem/index.html">
Linux Cable Modem mini-HOWTO</ULink> and
<ULink URL="http://www.tldp.org/HOWTO/DSL-HOWTO/index.html">Linux DSL HOWTO
</ULink>
</para>
</listitem>
<listitem>
<para>
Ipfwadm 2.3.0 or newer is available from
<ULink URL="http://www.xos.nl/linux/ipfwadm/download.html">
http://www.xos.nl/linux/ipfwadm/download.html
</ULink>
</para>
</listitem>
<listitem>
<para>
More information on version requirements are on the
<ULink URL="http://www.xos.nl/linux/ipfwadm/">Linux IPFWADM page</ULink>
</para>
</listitem>
<listitem>
<para>
If you are interested in running IPCHAINS on a 2.0.x+ kernel, see
<ULink URL="http://miaif.lip6.fr/~tarreau/pub/linux-patches/">
Willy Tarreau's
IPCHAINS enabler for 2.0.36+</ULink> or
<ULink URL="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"> Rusty's
IPCHAINS for 2.0.x kernels</ULink>. Please note that these patches are NOT
compatible with the IPPORTFW patches for the 2.0.x kernels. Unfortunately,
its an either/or deal.
</para>
</listitem>
<listitem>
<para>
Know how to configure, compile, and install a new Linux kernel as described in
the <ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">
Linux Kernel HOWTO</ULink>. This HOWTO does cover kernel compiling but only
for IP Masquerade related options.
</para>
</listitem>
</ItemizedList>
<para>
<Emphasis role="strong">Here is a list of IP Masquerading patches for 2.0.x kernels:</Emphasis>
</para>
<ItemizedList>
<listitem>
<para>
Steven Clarke's
<ULink URL="http://www.ox.compsoc.org.uk/~steve/portforwarding.html">IP
PortForwarding (IPPORTFW)</ULink> - <Emphasis >RECOMMENDED</Emphasis>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/ipautofw.tar.gz">IP AutoForward</ULink>
- <ULink URL="http://ipmasq.webhop.net/tcpdeath.html">NOT
Recommended</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/redir_0.7.orig.tar.gz">REDIR</ULink> for TCP
(REDIR) - NOT Recommended unless required for internal PORTFW
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/udpred.c.gz">UDP redirector</ULink>
(UDPRED) - NOT Recommended
</para>
</listitem>
<listitem>
<para>
PORTFWed FTP:
<ItemizedList>
<listitem>
<para>
If you are going to port forward FTP traffic to an internal FTP server, you
might need to download <ULink URL="http://ipmasq.webhop.net/files22/ip_masq-v0.27-for_2.2.18pre9.patch.gz">
Fred Viles's FTP server patch</ULink>
The reason for "might" is that some
users have had success without the use of these pathches, while others need it.
Explicit details on this topic can be found in <XRef LinkEnd="Forwarders"> of
this HOWTO.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
X-Windows display forwarders:
<ItemizedList>
<listitem>
<para>
<ULink URL="ftp://sunsite.unc.edu/pub/Linux/X11/compress/dxpc-3.7.0.tar.gz">
X-windows forwarding (DXCP)</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
PPTP (GRE) and SWAN (IPSEC) VPNs tunneling forwarders:
<ItemizedList>
<listitem>
<para>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:
</para>
<para>
<ULink URL="http://www.impsec.org/linux/masquerade/ip_masq_vpn.html">
John Hardin's VPN Masquerade forwarders</ULink> or the old patch for just
<ULink URL="http://ipmasq.webhop.net/ip_masq_pptp.patch.gz">PPTP Support</ULink>.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Game specific patches:
<ItemizedList>
<listitem>
<para>
Glenn Lamb's
<ULink URL="http://ipmasq.webhop.net/files20/loose-udp-2.0.36.patch.gz">
LooseUDP for 2.0.36+</ULink> patch.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</Sect1>
</Chapter>
<Chapter>
<Title>Setting Up IP Masquerade</Title>
<Sect1 id="ipmasq-compiling3.0">
<Title>Compiling a new kernel if needed</Title>
<para>
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.
</para>
<para>
<emphasis role="strong">
Once you have IP MASQ functioning, it is HIGHLY recommended for the user to
implement a STRONG IPFWADM/IPCHAINS firewall ruleset. Please see
<XRef LinkEnd="rc.firewall-iptables-stronger">,
<XRef LinkEnd="rc.firewall-ipchains-stronger"> and
<XRef LinkEnd="rc.firewall-ipfwadm-stronger"> located below for more details.
</emphasis>
</para>
</Sect1>
<Sect1 id="ipmasq-compiling3.1">
<Title>Checking your existing kernel for MASQ functionality</Title>
<para>
<Emphasis role="strong">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 kernel
is MASQ ready.
</Emphasis>
</para>
<para>
To see which kernel your system is running, run the following command:
<Screen>
uname -a
</Screen>
</para>
<para>
<ItemizedList> <!-- Start general check list -->
<listitem>
<para>
Just for clarity: 2.4.x kernels run IPTABLES :: 2.2.x kernels run IPCHAINS ::
2.0.x kernels run IPFWADM
</para>
</listitem>
<listitem>
<para>
In general, you must have kernel support for:
<Itemizedlist>
<listitem>
<para>
IP forwarding
</para>
</listitem>
<listitem>
<para>
IP masquerading
</para>
</listitem>
<listitem>
<para>
IP Firewalling
</para>
</listitem>
<listitem>
<para>
etc.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList> <!-- end general check list -->
</para>
<para>
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:
<ItemizedList> <!-- start specific check list -->
<listitem> <!-- 2.4.x -->
<para>
<Emphasis role="strong">2.4.x kernels</Emphasis> (look for most of the
following entries out of the much longer list):
<Itemizedlist> <!-- 2.4.x sub 1 -->
<listitem>
<para>
Run the command "<Literal>ls /proc/sys/net/ipv4</Literal>" while logged
into the Linux box. These items are required and should be present
regardless if your kernel built IPMASQ as modules or statically.
<ItemizedList> <!-- 2.4.x sub 2 -->
<listitem>
<para>
<Literal>ip_dynaddr</Literal>
</para>
<para>
<Literal>ip_forward</Literal>
</para>
</listitem
</Itemizedlist> <!-- 2.4.x sub 2 -->
</para>
</listitem>
<listitem>
<para>
To check if IPMASQ was compiled statically into the kernel, run the
command "<Literal>/sbin/lsmod</Literal>" and see if and modules like
the ones shown below for the MODULE section are loaded. No? Ok,
now run the command "<Literal>ls /proc/net/</Literal>" and see if you
see additional /proc files such as:
<ItemizedList> <!-- 2.4.x sub 3 -->
<listitem>
<para>
<Literal>ip_masquerade</Literal>
</para>
<para>
<Literal>ip_conntrack</Literal>
</para>
<para>
<Literal>ip_tables_names</Literal>
</para>
</listitem
</Itemizedlist> <!-- 2.4.x sub 3 -->
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.
</para>
</listitem>
<listitem>
<para>
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 "<Literal>ls
/lib/modules/`uname -r`/kernel/net/ipv4/netfilter/</Literal>" where you should
see files like:
<ItemizedList> <!-- 2.4.x sub 4 -->
<listitem>
<para>
<Literal>ip_conntrack.o, ip_conntrack_ftp.o, ip_conntrack_irc.o,
ip_nat_ftp.o, ip_nat_irc.o</Literal>
</para>
<para>
<Literal>ip_tables.o, ipt_MASQUERADE.o, iptable_nat.o,
iptable_mangle.o, iptable_filter.o</Literal>
</para>
<para>
And some optional ones like: <Literal>ipchains.o, ipt_REJECT.o,
and ipt_tcpmss.o</Literal>
</para>
</listitem
</Itemizedlist> <!-- 2.4.x sub 4 -->
If you see those kernel files, IPTABLES was compiled using modules and
things look ready to go to use IPMASQ on this system.
</para>
</listitem>
</Itemizedlist> <!-- 2.4.x sub 1 -->
</para>
</listitem> <!-- 2.4.x -->
<listitem> <!-- 2.2.x -->
<para>
<Emphasis role="strong">2.2.x kernels</Emphasis> (look for most of the
following entries out of the much longer list): list):
<Itemizedlist> <!-- 2.2.x sub 1 -->
<listitem>
<para>
Run the command "<Literal>ls /proc/sys/net/ipv4</Literal>" while logged
into the Linux box. These items are required and should be present
regardless if your kernel built IPMASQ as modules or statically.
<ItemizedList> <!-- 2.2.x sub 2 -->
<listitem>
<para>
<Literal>ip_always_defrag</Literal>
</para>
<para>
<Literal>ip_dynaddr</Literal>
</para>
<para>
<Literal>ip_forward</Literal>
</para>
<para>
<Literal>ip_masq_debug</Literal>
</para>
<para>
<Literal>ip_masq_udp_dloose</Literal> (some distros don't support
this -- ignore it for now
</para>
<para>
<Emphasis role="strong">Other 2.2.x options</Emphasis> can be checked
by running "ls /proc/net/"
<Itemizedlist> <!-- 2.2.x sub 2a -->
<listitem>
<para>
<Literal>ip_fwchains</Literal>
</para>
<para>
<Literal>ip_fwnames</Literal>
</para>
<para>
<Literal>ip_masquerade</Literal>
</para>
</listitem>
</Itemizedlist> <!-- 2.2.x sub 2a -->
</para>
<para>
<Emphasis role="strong">Even more 2.2.x options</Emphasis> can be
checked by running "ls /proc/net/"
<Itemizedlist> <!-- 2.2.x sub 2b -->
<listitem>
<para>
<Literal>app</Literal>
</para>
<para>
<Literal>icmp</Literal>
</para>
<para>
<Literal>icq</Literal>
</para>
<para>
<Literal>mfw</Literal>
</para>
<para>
<Literal>portfw</Literal>
</para>
<para>
<Literal>tcp</Literal>
</para>
<para>
<Literal>udp/</Literal>
</para>
</listitem>
</Itemizedlist> <!-- 2.2.x sub 2b -->
</para>
</listitem>
</Itemizedlist> <!-- 2.2.x sub 2 -->
</para>
</listitem>
</ItemizedList> <!-- 2.2.x sub 1 -->
</para>
</listitem> <!-- 2.2.x -->
<listitem> <!-- 2.0.x -->
<para>
<Emphasis role="strong">2.0.x kernels</Emphasis> (look for most of the
following entries out of the much longer list):
<Itemizedlist> <!-- 2.0.x sub 1 -->
<listitem>
<para>
Run the command "<Literal>ls /proc/sys/net/ipv4</Literal>" while logged
into the Linux box. These items are required and should be present
regardless if your kernel built IPMASQ as modules or statically.
<ItemizedList> <!-- 2.0.x sub 2 -->
<listitem>
<para>
<Literal>ip_dynaddr</Literal>
</para>
<para>
<Literal>ip_forward</Literal>
</para>
<para>
running "ls /proc/net"
<Itemizedlist> <!-- 2.0.x sub 3 -->
<listitem>
<para>
<Literal>ip_forward</Literal>
</para>
<para>
<Literal>ip_masq_app</Literal>
</para>
<para>
<Literal>ip_masquerade</Literal>
</para>
<para>
<Literal>ip_portfw</Literal>
</para>
</listitem
</Itemizedlist> <!-- 2.0.x sub 3 -->
</para>
</listitem>
</Itemizedlist> <!-- 2.0.x sub 2 -->
</para>
</listitem>
</Itemizedlist> <!-- 2.0.x sub 1 -->
</para>
</listitem> <!-- 2.0.x -->
</ItemizedList> <!-- specific check list -->
</para>
<para>
Ultimately, it comes down to the fact if you see /proc files such as
"i<Literal>ip_forward</Literal>", "<Literal>ip_masq_debug</Literal>",
"<Literal>ip_masq_udp_dloose</Literal>"(optional), and "<Literal>
ip_always_defrag</Literal>" (optional) exist.
</para>
<para>
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 <XRef LinkEnd="MASQ-supported-Distributions"> section and see if your
Linux Distribution is listed. Still not there? Sounds like you'll need to
compile a kernel but don't worry.. it isn't hard.
</para>
<para>
<Emphasis role="strong">Regardless if your current kernel has MASQ support or
not</Emphasis>, reading the remainder of this section is still highly
recommended as it contains other useful information.
</para>
<Sect2 id=ipmasq-compiling3.1.1>
<Title>Compiling Linux 2.4.x Kernels</Title>
<ItemizedList>
<listitem>
<para>
First, you'll need to get some 2.4.x kernel sources (preferably the latest
kernel version - NEWER *IS* BETTER IN LINUX LAND)
</para>
<Itemizedlist>
<listitem>
<para>
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.
</para>
</listitem>
</Itemizedlist>
</listitem>
<listitem>
<para>
Next, depending on the version of the Linux kernel and IPTABLES archive you
downloaded, you <Emphasis role="strong">might </Emphasis>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 various URLs for downloading IPTABLES, the
Patch-o-matic system, etc. <XRef LinkEnd="kernel-2.4.x-Requirements">.
</para>
</listitem>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.4.x-Requirements">. Please note that the instructions
included here is just one way to do build a kernel. Please see the Kernel
HOWTO for full details.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>Please notice that it <Emphasis
role="strong">IS NOT </Emphasis> 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.
</para>
</listitem>
<listitem>
<para>For this HOWTO example, create a directory called <Literal>/usr/src/kernel</Literal>.
Next, "cd" into this directory and download the newest 2.4.x kernel sources
into it. Once downloaded, issue the following command (if the file ends in a .tar.gz):
<Literal>tar xvzf linux-2.4.x.tar.gz</Literal> or (if the file ends in a
.tar.bzip2): <Literal>tar xyvf linux-2.4.x.tar.bz2</Literal>. Please
substitute the "x" in the 2.4.x filename with the Linux 2.4 kernel version you
downloaded.
</para>
<para>
BZ2 Note: Some Linux distributions use the "I" option instead of the "y"
option to decompress bzip2 archives.
</para>
<para>
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
"<Literal>mv linux linux-2.4.x</Literal>". Next, make sure there is a
directory or symbolic link pointing to
"<Literal>/usr/src/kernel/linux</Literal>" ie. run the command:
<screen>ln -s /usr/src/kernel/linux-2.4.x /usr/src/kernel/linux</screen>
again subsituting the "x" for your proper kernel version.
</para>
</listitem>
<listitem>
<para>
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 <XRef LinkEnd="kernel-2.4.x-Requirements"> for URLs and the
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resources</ULink> for
up-to-date information and patch URLs.
</para>
</listitem>
<listitem>
<para>
<Emphasis role="strong">Applying IPTABLES and Patch-o-Matic kernel patches
</Emphasis>
</para>
<para>
Download the iptables package and optional Patch-O-matics from the
<XRef LinkEnd="kernel-2.4.x-Requirements"> and put it into a directory, say
"<Literal>/usr/src/archive/netfilter</Literal>". Next, go into this new
netfilter directory and uncompress the iptables archive with the command:
</para>
<para>
<screen>
<Literal>tar xyvf iptables-x.y.z.tar.bz2</Literal>
<Literal>tar xyvf patch-o-matic-x.tar.bz2</Literal>
</screen>
</para>
<para>
Now, go into the new iptables-x.y.x directory
(/usr/src/archive/netfilter/iptables-x.y.z) and run the command
</para>
<para>
<screen>
<Literal>#For iptables v1.2.7a:</Literal>
<Literal>make KERNEL_DIR=/usr/src/kernel/linux</Literal>
<Literal> </Literal>
<Literal>#For iptables v1.2.4 (when Patch-o-matic was built-in):</Literal>
<Literal>make pending-patches KERNEL_DIR=/usr/src/kernel/linux</Literal>
<Literal> </Literal>
</screen>
</para>
<para>
NOTE: this assumes that your 2.4.x kernel sources are in the
<Literal>/usr/src/kernel/linux</Literal> directory.
</para>
<para>
NOTE #2: If you append a "/" to the end of the above command line, you
will get an error stating:
<screen>
"make: *** [/usr/src/kernel/linux/include/asm/socket.h] Error 1".
</screen>
Remove the trailing "/" and try again.
</para>
<para>
Here is an example of compiling IPTABLES v1.2.7a. Your output might look
different depending on what version you are trying to use.
</para>
</listitem>
<listitem>
<para>
<screen>
# make KERNEL_DIR=/usr/src/kernel/linux
Extensions found:
cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/
-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_ah_sh.o -c
extensions/libipt_ah.c
ld -shared -o extensions/libipt_ah.so extensions/libipt_ah_sh.o
cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/
-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_conntrack_sh.o -c
extensions/libipt_conntrack.c
ld -shared -o extensions/libipt_conntrack.so extensions/libipt_conntrack_sh.o
cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/
-DIPTABLES_VERSION=\"1.2.7a\" -fPIC -o extensions/libipt_dscp_sh.o -c
extensions/libipt_dscp.c
extensions/libipt_dscp_helper.c:69: warning: `dscp_to_name' defined but not
used
ld -shared -o extensions/libipt_dscp.so extensions/libipt_dscp_sh.o
.
.
.
cc -O2 -Wall -Wunused -I/usr/src/kernel/linux/include -Iinclude/
-DIPTABLES_VERSION=\"1.2.7a\" -c -o libipulog/libipulog.o
libipulog/libipulog.c
ar rv libipulog/libipulog.a libipulog/libipulog.o
a - libipulog/libipulog.o
rm libiptc/libip6tc.o libiptc/libip4tc.o libipulog/libipulog.o libipq/libipq.o
</screen>
</para>
</listitem>
<listitem>
<para>
Ok, hopefully the IPTABLES program compiled up for you. Now, you need to
install it. To do this, directory and run the command
</para>
<para>
<screen>
<Literal>make install KERNEL_DIR=/usr/src/kernel/linux</Literal>
</screen>
</para>
</listitem>
<listitem>
<para>
Here is an example of installing IPTABLES v1.2.7a. Your output might look
different depending on what version you are trying to use.
</para>
</listitem>
<listitem>
<para>
<screen>
# make install KERNEL_DIR=/usr/src/kernel/linux
cp iptables /usr/local/sbin/iptables
cp iptables-save /usr/local/sbin/iptables-save
cp iptables-restore /usr/local/sbin/iptables-restore
cp ip6tables /usr/local/sbin/ip6tables
cp extensions/libipt_ah.so /usr/local/lib/iptables/libipt_ah.so
cp extensions/libipt_conntrack.so /usr/local/lib/iptables/libipt_conntrack.so
cp extensions/libipt_dscp.so /usr/local/lib/iptables/libipt_dscp.so
cp extensions/libipt_ecn.so /usr/local/lib/iptables/libipt_ecn.so
cp extensions/libipt_esp.so /usr/local/lib/iptables/libipt_esp.so
cp extensions/libipt_helper.so /usr/local/lib/iptables/libipt_helper.so
.
.
.
cp extensions/libip6t_udp.so /usr/local/lib/iptables/libip6t_udp.so
cp extensions/libip6t_LOG.so /usr/local/lib/iptables/libip6t_LOG.so
cp extensions/libip6t_MARK.so /usr/local/lib/iptables/libip6t_MARK.so
</screen>
</para>
</listitem>
</ItemizedList>
<para>
Next, if you are interested in applying a Patch-O-Matic patch set, go into the
<Literal>patch-o-matic-X </Literal>directory
(/usr/src/archive/netfilter/patch-o-matic-X) and run the command
</para>
<ItemizedList>
<listitem>
<para>
<screen>
<Literal>#For Patch-O-Matic later than the release of iptables v1.2.7a:</Literal>
<Literal>KERNEL_DIR=/usr/src/kernel/linux</Literal>
<Literal>./runme pending</Literal>
<Literal> </Literal>
</screen>
</para>
<para>
NOTE #1: The use of the "pending" batch is the most common for IPMASQ
functionality but there are several others. See below.
</para>
<para>
NOTE #2: this assumes that your 2.4.x kernel sources are in the
<Literal>/usr/src/kernel/linux</Literal> directory.
</para>
<para>
NOTE #3: If you append a "/" to the end of the command line, you
will get an error stating:
<screen>
"make: *** [/usr/src/kernel/linux/include/asm/socket.h] Error 1".
Remove the trailing "/" and try again.
</screen>
</para>
<para>
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 "<Literal>./runme</Literal>" command
by itself. Please note that these prompts WILL CHANGE over time.
</para>
</listitem>
<listitem>
<para>
<screen>
Welcome to Rusty's Patch-o-matic!
Each patch is a new feature: many have minimal impact, some do not.
Almost every one has bugs, so I don't recommend applying them all!
-------------------------------------------------------
Already applied: submitted/01_2.4.19
submitted/02_2.4.20
submitted/ipt_ULOG-mac_len-fix
submitted/ipt_multiport-invfix
pending/01_ip_conntrack_proto_tcp-lockfix
pending/02_newnat-udp-helper
pending/03_REJECT-fwspotting-phrack60-fix
pending/04_ftp-conntrack-msg-fix
Testing... 05_ECN-tcpchecksum-littleendian-fix.patch NOT APPLIED (1 rejects out
of 1 hunks)
The pending/05_ECN-tcpchecksum-littleendian-fix patch:
Author: Patrick McHardy
Status: Pending for kernel inclusion
The 2.4.20 kernel included the new iptables 'ECN' target, enabling a
selective
ECN disable mechanism. Unfortunately there was a bug in the incremental
TCP
checksum update, resulting in broken TCP checksums on little endian
machines.
This patch fixes the Bug.
Testing patch pending/05_ECN-tcpchecksum-littleendian-fix.patch...
Patch pending/05_ECN-tcpchecksum-littleendian-fix.patch applied cleanly.
Applying patch pending/05_ECN-tcpchecksum-littleendian-fix.patch...
Patch pending/05_ECN-tcpchecksum-littleendian-fix.patch applied cleanly.
Excellent! Kernel is now ready for compilation.
</screen>
</para>
</listitem>
<listitem>
<para>
If everything patches fine, you should see something like the text
</para>
<para>
<screen>Excellent! Kernel is now ready for compilation.</screen>
</para>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Ok, now the new kernel is ready to be compiled but you should make sure
that you also have the proper matching <literal>iptables</literal> program
on your machine too (just to make sure). Run the command:
<Itemizedlist>
<listitem>
<para>
<screen>whereis iptables</screen>
</para>
</listitem>
</Itemizedlist>
and make sure its installed on the machine (the default place is in
<literal>/usr/local/sbin/iptables</literal>. If you cannot find it
or patched up your kernel sources as shown above, I recommend you just
re-compile it up as shown above.
</para>
</listitem>
</ItemizedList>
<para>
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 <Emphasis role="strong">modules OR monolithically</Emphasis> 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).
</para>
<ItemizedList>
<listitem>
<para>
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
<ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">
Linux Kernel HOWTO</ULink> and the kernel source's "<Literal>README</Literal>"
file and "<Literal>Documentation/</Literal>" directory for detailed help on
compiling a kernel.
</para>
</listitem>
</ItemizedList>
<para>
You will need to answer either <Emphasis role="strong">YES, NO, or MODULE
</Emphasis> to the following program. Not all options will be available
without the proper kernel patches described later in this HOWTO. This
shouldn't be an issue as most 3rd party patches are only needed for a very
select group of users.
</para>
<para>
Run the following commands to configure your kernel:
</para>
<para>
<Itemizedlist>
<listitem>
<para>
<literal>cd /usr/src/kernel/linux</literal>
</para>
</listitem
<listitem>
<para>
<literal>make menuconfig</literal>
</para>
</listitem>
</Itemizedlist>
</para>
<para>
Please note the following kernel prompts reflect a 2.4.14 kernel (with some of
the optional Patch-O-Matic additions. Please read the following carefully for
recommendations:
</para>
<para>
<Screen>
[ Code maturity level options ]
* Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
- YES: though not required for IP MASQ, this option allows the kernel to create
the MASQ modules and enable the option for port forwarding
* Enable loadable module support (CONFIG_MODULES) [Y/n/?]
- YES: allows you to load kernel IP MASQ modules
* Set version information on all module symbols (CONFIG_MODVERSIONS) [Y/n/?]
- YES: allows newer kernels to load older modules if possible
* Kernel module loader (CONFIG_KMOD) [Y/n/?]
- OPTIONAL: Recommended : allows the kernel to load various kernel modules as it needs them
== Non-MASQ options skipped
== (CPU type, memory, SMP, FPU, specific stuff)
[ General setup ]
* Networking support (CONFIG_NET) [Y/n/?]
- YES: Enables the network subsystem
== Non-MASQ options skipped
== (specific hardware, PCI, kernel binaries, PCMCIA, etc.)
* Sysctl support (CONFIG_SYSCTL) [Y/n/?]
- YES: Enables the ability to enable disable options such as forwarding,
dynamic IPs, etc. via the /proc interface
[ Block devices ]
== Non-MASQ options skipped
== (kernel binaries, power management, PnP, RAID, etc.)
== Don't forget to compile in support for hardware that you might need:
== IDE controllers, HDs, CDROMs, etc.
[ Networking options ]
* Packet socket (CONFIG_PACKET) [Y/m/n/?]
- YES: Though this is OPTIONAL, this recommended feature will allow you
to use TCPDUMP to debug any problems with IP MASQ
* Packet socket: mmapped IO (CONFIG_PACKET_MMAP) [N/y/?] y
- YES: Speed up the packet protocol
* Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?]
- OPTIONAL: Recommended : this feature will allow the logging of
advanced firewall issues such as routing messages, etc
* Routing messages (CONFIG_RTNETLINK) [N/y/?] (NEW) y
- OPTIONAL: Allows for support of advanced kernel routing messages
if you enabled the CONFIG_NETLINK option
* Netlink device emulation (CONFIG_NETLINK_DEV) [N/y/m/?] (NEW)
- NO: This option does not have anything to do with packet firewall
logging
* Network packet filtering (replaces ipchains) (CONFIG_NETFILTER) [N/y/?] y
- YES: Enable this option to let IPTABLES configure the TCP/IP subsection
of the kernel. By enabling this, then you can turn on advanced
routing mechanisms like IP Masq, packet filtering, etc.
* Network packet filtering debugging (CONFIG_NETFILTER_DEBUG) [N/y/?] (NEW) n
- NO: Not required for Masquerading functionality though it may help
for troubleshooting. There might be a performance penalty when
enabling this.
* Socket Filtering (CONFIG_FILTER) [Y/n/?]
- OPTIONAL: Recommended : Though this doesn't have anything do with IPMASQ,
if you plan on implimenting a DHCP server on the internal network, you WILL
need to enable this option.
* Unix domain sockets (CONFIG_UNIX) [Y/m/n/?]
- YES: This enables the UNIX TCP/IP sockets mechanisms
* TCP/IP networking (CONFIG_INET) [Y/n/?]
- YES: Enables the TCP/IP protocol
* IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?]
- OPTIONAL: You can enable this if you want to be able to receive
Multicast traffic. Please note that your ISP must
support Multicast as well for this all to work at all
* IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?]
- OPTIONAL: Though there is nothing in this section mandatory for
Masquerade, some specific options might be useful
== Non-MASQ options skipped
== ( autoconf, tunneling )
* IP: multicast routing (CONFIG_IP_MROUTE) [N/y/?] n
- OPTIONAL: Though not needed for IPMASQ, enabling this feature will
let you route multicast traffic through your Linux box.
Please note that this requires that your ISP be multicast
enabled as well.
== Non-MASQ options skipped
== (ARPd)
* IP: TCP Explicit Congestion Notification support (CONFIG_INET_ECN) [N/y/?] n
- NO: Though enabling this option would be great, there are many Internet
sites out there that will block this. Hit the "?" when configuring
the kernel to learn more about it but it is recommended to say NO for
now.
* IP: TCP syncookie support (disabled per default) (CONFIG_SYN_COOKIES) [Y/n/?]
- YES: Recommended : for basic TCP/IP network security
[ Networking options --> IP: Netfilter Configuration ]
* Connection tracking (required for masq/NAT) (CONFIG_IP_NF_CONNTRACK) [N/y/m/?] (NEW) m
- YES: (Module) This enables the kernel to track various network connections.
This option is required for Masquerading support as well as to enable
Stateful tracking for various filewall mechanisms. Please note that
if you compile this directly into the kernel, you cannot enable
the legacy IPCHAINS or IPFWADM compatibility modules.
* FTP protocol support (CONFIG_IP_NF_FTP) [M/n/?] (NEW) m
- YES: (Module) This enables the proper Masquerading of FTP connections if
CONFIG_IP_NF_CONNTRACK was enabled above
* IRC protocol support (CONFIG_IP_NF_IRC) [M/n/?] (NEW) m
- YES: (Module) This enables the proper Masquerading of IRC connections if
CONFIG_IP_NF_CONNTRACK was enabled above
* Userspace queueing via NETLINK (EXPERIMENTAL) (CONFIG_IP_NF_QUEUE) [N/y/m/?] (NEW) m
- OPTIONAL: Though this is OPTIONAL, this feature will allow IPTABLES to
copy specific packets to UserSpace tools for additional checks
* IP tables support (required for filtering/masq/NAT) (CONFIG_IP_NF_IPTABLES) [N/y/m/?] (NEW) m
- YES: (Module) Enables IPTABLES support
* limit match support (CONFIG_IP_NF_MATCH_LIMIT) [N/y/m/?] (NEW) y
- OPTIONAL: (Module) Recommended : Though not required, this option can used to
enable rate limiting of both traffic and loggin messages help slow down denial
of service (DoS) attacks.
* MAC address match support (CONFIG_IP_NF_MATCH_MAC) [N/y/m/?] (NEW) m
- OPTIONAL: Though not required, the option can allow you to
filter traffic based upon the SOURCE Ethernet MAC address.
* netfilter MARK match support (CONFIG_IP_NF_MATCH_MARK) [N/y/m/?] (NEW) y
- YES: (Module) Recommended : This enables IPTABLES to take action upon marked packets.
This mechanism can allow for PORTFW functionality, TOS marking, etc.
* Multiple port match support (CONFIG_IP_NF_MATCH_MULTIPORT) [N/y/m/?] (NEW) y
- YES: (Module) Recommended : This enables IPTABLES to accept mutliple SRC/DST port
ranges (non-contiguous) instead of one port range per IPTABLES
statement.
* TOS match support (CONFIG_IP_NF_MATCH_TOS) [Y/m/n/?] n
- OPTIONAL: This allows IPTABLES to match packets based upon their
DIFFSERV settings.
* LENGTH match support (CONFIG_IP_NF_MATCH_LENGTH) [N/m/?] (NEW) n
- OPTIONAL: This allows IPTABLES to match packets based upon their
packet length.
* TTL match support (CONFIG_IP_NF_MATCH_TTL) [N/m/?] (NEW) ? n
- OPTIONAL: This allows IPTABLES to match packets based upon their
TTL settings.
* tcpmss match support (CONFIG_IP_NF_MATCH_TCPMSS) [N/y/m/?] m
- OPTIONAL: (Module) Recommended : This option allows users to examine the MSS value in
TCP SYN packets. This is an advanced knob but can be very valuable in
troubleshooting MTU problems.
* Connection state match support (CONFIG_IP_NF_MATCH_STATE) [M/n/?] m
- YES: (Module) Recommended : This option allows for Stateful tracking of network
connections.
* Unclean match support (EXPERIMENTAL) (CONFIG_IP_NF_MATCH_UNCLEAN) [N/y/m/?] y
- YES: (Module) Recommended : This option allows for connection tracking on odd packets.
It cal also help in the detection of possibly malicious packets.
This can be a valuable tool in tracking hostile people on the network.
* Owner match support (EXPERIMENTAL) (CONFIG_IP_NF_MATCH_OWNER) [N/y/m/?] n
- OPTIONAL: This option allows IPTABLES to match traffic based upon the
user login, group, etc. who created the traffic.
* Packet filtering (CONFIG_IP_NF_FILTER) [N/y/m/?] ? y
- YES: (Module) This option allows for the kernel to be able filter traffic at
the INPUT, FORWARDING, and OUTPUT traffic points.
* REJECT target support (CONFIG_IP_NF_TARGET_REJECT) [N/y/m/?] (NEW) y
- YES: (Module) With this option, a packet firewall can send an ICMP Reject packet
back to the originator when a packet is blocked.
* MIRROR target support (EXPERIMENTAL) (CONFIG_IP_NF_TARGET_MIRROR) [N/y/m/?] (NEW) n
- OPTIONAL: This option allows the packet firewall to mirror the exact same
network packet back to the originator when it is supposed to be
blocked. This is similar to the REJECT option above but it actually
sends the original packet back to the originator. i.e. a
hostile user could actually portscan themselves.
* Full NAT (CONFIG_IP_NF_NAT) [M/n/?] m
- YES: (Module) This option enables the future menus to enable Masquerading,
PORTFWing, Full (1:1) NAT, etc.
* MASQUERADE target support (CONFIG_IP_NF_TARGET_MASQUERADE) [M/n/?] (NEW) m
- YES: (Module) This option specifically enables Masquerade into the
kernel
* REDIRECT target support (CONFIG_IP_NF_TARGET_REDIRECT) [N/y/m/?] n
- OPTIONAL: Not needed for normal MASQ functionality though people who
want to do transparent proxy via Squid will want this.
* Basic SNMP-ALG support (EXPERIMENTAL) (CONFIG_IP_NF_NAT_SNMP_BASIC) [N/m/?] n
- OPTIONAL: This enables IPTABLES to properly NAT internal SNMP packets so
that machines with duplicate addressing ranges can be properly
managed.
* Packet mangling (CONFIG_IP_NF_MANGLE) [N/y/m/?] y
- YES: (Module) This option allows for advanced IPTABLES packet manipulation
options.
* TOS target support (CONFIG_IP_NF_TARGET_TOS) [N/y/m/?] (NEW) n
- OPTIONAL: Enables the kernel to modify the TOS field in a packet
before routing it on
* MARK target support (CONFIG_IP_NF_TARGET_MARK) [N/y/m/?] (NEW) m
- OPTIONAL: (Module) Recommended : This enables the kernel to manipulate
packets based upon the MARK field. This can be used for PORTFW
as well as many other things.
* LOG target support (CONFIG_IP_NF_TARGET_LOG) [N/y/m/?] m
- YES: (Module) This allows for the logging of packets before they are accepted,
denied, rejected, etc.
* TCPMSS target support (CONFIG_IP_NF_TARGET_TCPMSS) [N/y/m/?] ? m
- YES: (Module) This option help some people with MTU problems. Typically,
most users have to set their Internet connection's MTU to
1500 as well as ALL internal machines to 1500. With this
option, this whole MTU issue might be finally solved.
* ipchains (2.2-style) support (CONFIG_IP_NF_COMPAT_IPCHAINS) [N/y/m/?] m
- OPTIONAL: (Module) Recommended : If you have an existing IPCHAINS ruleset
(2.2.x kernels) and enable this option, you can continue to use the
IPCHAINS program and the majority of your old ruleset except for the
use of any 2.2.x kernel-specific modules. Please note that if this
IPCHAINS module is loaded, ALL IPTABLES modules will be non-
operational. This is an either/or deal only intended for legacy
rulesets.
* ipfwadm (2.0-style) support (CONFIG_IP_NF_COMPAT_IPFWADM) [N/y/m/?] n
- OPTIONAL: If you have an existing IPFWADM ruleset (2.0.x kernels) and
enable this option, you can continue to use the IPFWADM program and
the majority of your old ruleset except for the use of any 2.0.x
kernel-specific modules. Please note that if this IPFWADM module
is loaded, ALL IPTABLES modules will be non operational. This is
an either/or deal only intended to support legacy rulesets.
== Non-MASQ options skipped
== (IPv6, khttpd, ATM, IPX, AppleTalk, etc.) --
* Fast switching (read help!) (CONFIG_NET_FASTROUTE) [N/y/?] n
- NO: This performance optimization is NOT compatible with IP MASQ and/or
packet filtering
== Non-MASQ options skipped
== (QoS, Telephony, IDE, SCSI, 1394FW, I2O, etc)
== Don't forget to compile in support for hardware that you might need:
== IDE: HDs, CDROMs, etc.
== SCSI: HDs, CDROMs, etc.
[ Network device support ]
* Network device support (CONFIG_NETDEVICES) [Y/n/?]
- YES: Enables the Linux Network device sublayer
== Non-MASQ options skipped
== (Arcnet)
* Dummy net driver support (CONFIG_DUMMY) [M/n/y/?]
- YES: Though OPTIONAL, this option can help when debugging problems
== Non-MASQ options skipped
== (EQL, etc..)
== Don't forget to compile in support for hardware that you might need:
== NICs: eth, tr, etc.
== MODEMs: ppp (ppp async) and/or slip
== WANs: T1, T3, ISDN, etc.
== ISDN: for internal ISDN modems
== Non-MASQ options skipped
== (Amateur Radio, IrDA, ISDN, USB, etc.)
[ Character devices ]
== Don't forget to compile in serial port support if you are a modem user
== Don't forget to compile in mouse support
== Non-MASQ options skipped
== (I2C, Watchdog cards, Ftape, Video for Linux, etc. )
[ File systems ]
== Non-MASQ options skipped
== (Quota, ISO9660, NTFS, etc )
* /proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
- YES: Required to dynamically configure the Linux forwarding
and NATing systems
== Non-MASQ options skipped
== (Console drivers, Sound, USB, Kernel Hacking)
</screen>
So go ahead and select "exit" and you should be prompted to save your config.
</para>
<para>
NOTE: These are just the kernel components you need for IP Masquerade networking
support. 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.
<!-- Blah . add FAQ URL -->
</para>
<ItemizedList>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.4.x-Requirements"> for URLs to the KERNEL howto, etc.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</Sect2>
<Sect2 id=ipmasq-compiling3.1.2>
<Title>Compiling Linux 2.2.x Kernels</Title>
<para>
<Emphasis role="strong">Please see <XRef LinkEnd="kernel-2.2.x-Requirements"> for
any required software, patches, etc.</Emphasis>
</para>
<ItemizedList>
<listitem>
<para>
First of all, you need the kernel source for 2.2.x (preferably the latest
kernel version)
</para>
<Itemizedlist>
<listitem>
<para>
NOTE #1: --- UPDATE YOUR KERNEL ---
Linux 2.2.x kernels less than version 2.2.20 contain several different
<ULink URL="http://www.linux.org.uk/VERSION/">security
vulnerabilities</Ulink> (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.
</para>
</listitem>
<listitem>
<para>
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.
</para>
<para>
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.
</para>
</listitem>
</Itemizedlist>
</listitem>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.2.x-Requirements">. Please note that the instructions
included here is just one way to do build a kernel. Please see the Kernel
HOWTO for full details.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>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.
</para>
</listitem>
<listitem>
<para>
For this HOWTO example, create a directory called <Literal>/usr/src/kernel</Literal>.
Next, "cd" into this directory and download the newest 2.2.x kernel sources
into it. Once downloaded, issue the following command (if the file ends in a .tar.gz):
<Literal>tar xvzf linux-2.2.x.tar.gz</Literal> or (if the file ends in a
.tar.bzip2): <Literal>tar xyvf linux-2.2.x.tar.bz2</Literal>. Please
substitute the "x" in the 2.2.x filename with the Linux 2.2 kernel version you
downloaded.
</para>
<para>
NOTE: Some Linux distributions use the "I" option instead of the "y" option to
decompress bzip2 archives.
</para>
<para>
Once uncompressed, I recommend that you rename the directory from "linux" to
"linux-2.2.x" for clarity. To do this, run the command <Literal>mv linux
linux-2.2.x</Literal>. Next, make sure there is a directory or symbolic
link pointing to <Literal>/usr/src/kernel/linux</Literal> ie. run the
command: <Literal>ln -s /usr/src/kernel/linux-2.2.x /usr/src/kernel/linux</Literal>o
again subsituting the "x" for your proper kernel version.
</para>
</listitem>
<listitem>
<para>
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 <XRef LinkEnd="kernel-2.2.x-Requirements"> for
URLs and the <ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resources</ULink>
for up-to-date information and patch URLs.
</para>
</listitem>
<listitem>
<para>
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.
</para>
<para>
<Emphasis role="strong">Side Note:</Emphasis>
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
<ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">
Linux Kernel
HOWTO</ULink> and the kernel source's README file and Documentation/ directory
for detailed help on compiling a kernel.
</para>
</listitem>
</ItemizedList>
<para>
Please note the <Emphasis role="strong">YES or NO ANSWERS</Emphasis> to the
following. Not all options will be available without the proper kernel
patches described later in this HOWTO.
</para>
<para>
Run the following commands to configure your kernel:
<Itemizedlist>
<listitem>
<para>
<literal>cd /usr/src/kernel/linux</literal>
</para>
</listitem
<listitem>
<para>
<literal>make menuconfig</literal>
</para>
</listitem>
</Itemizedlist>
</para>
<para>
The following kernel prompts reflect a 2.2.20 kernel:
</para>
<para>
<Screen>
[ Code maturity level options ]
* Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
- YES: though not entirely required for IP MASQ, this option allows the kernel
to create possible additional MASQ modules such as PORTFW, etc.
== Non-MASQ options skipped
== (CPU, memory, MTRR, SMP, etc.)
[ Loadable module support ]
* Enable loadable module support (CONFIG_MODULES) [Y/n/?] y
- YES: allows you to load kernel IP MASQ modules
* Set version information on all symbols for modules (CONFIG_MODVERSIONS) [N/y/?] y
- YES: allows newer kernels to load older modules if possible
* Kernel module loader (CONFIG_KMOD) [Y/n/?] y
- OPTIONAL: Recommended : allows the kernel to load various kernel modules as
it needs them
[ General setup ]
* Networking support (CONFIG_NET) [Y/n/?]
- YES: This enables the network subsystem
== Non-MASQ options skipped
== (PCI, kernel binaries, specific hardware options, etc.)
* Sysctl support (CONFIG_SYSCTL) [Y/n/?]
- YES: Enables the ability to enable disable options such as forwarding,
dynamic IPs, etc. via the /proc interface
[ Block devices ]
== Non-MASQ options skipped
== (kernel binaries, power management, PnP, IDE, SCSI, etc.)
== Don't forget to compile in support for hardware that you might need:
== IDE controllers, HDs, CDROMs, etc.
[ Networking options ]
* Packet socket (CONFIG_PACKET) [Y/m/n/?] y
- YES: Though this is OPTIONAL, this recommended feature will allow you
to use TCPDUMP to debug any problems with IP MASQ
* Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?] y
- OPTIONAL: Recommended : This feature will allow the logging of
advanced firewall issues such as routing messages, etc
* Routing messages (CONFIG_RTNETLINK) [Y/n/?] y
- OPTIONAL: If you enabled the CONFIG_NETLINK option above, this option
will send routing messages and other information to SYSLOG.
* Netlink device emulation (CONFIG_NETLINK_DEV) [N/y/m/?] (NEW) n
- NO: This option does not have anything to do with packet firewall
logging
* Network firewalls (CONFIG_FIREWALL) [Y/n/?] y
- YES: Enables the kernel to be comfigured by the IPCHAINS firewall tool
* Socket Filtering (CONFIG_FILTER) [Y/n/?] y
- OPTIONAL: Though this doesn't have anything do with IPMASQ, if you
plan on implimenting a DHCP server on the internal network, you
WILL need this option.
* Unix domain sockets (CONFIG_UNIX) [Y/m/n/?] y
- YES: This enables the UNIX TCP/IP sockets mechanisms
* TCP/IP networking (CONFIG_INET) [Y/n/?] y
- YES: Enables the TCP/IP protocol
* IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?] y
- OPTIONAL: You can enable this if you want to be able to receive
Multicast traffic. Please note that your ISP must
support Multicast as well for this all to work
* IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?] n
- OPTIONAL: Though there is nothing in this section mandatory for
Masquerade, some specific options might be useful
* IP: kernel level autoconfiguration (CONFIG_IP_PNP) [N/y/?] ?
- NO: Not needed for normal MASQ functionality
* IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?] y
- YES: This enables the kernel to support packet filtering, NAT, etc.
* IP: firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) [Y/n/?] n
- OPTIONAL: Though this is OPTIONAL, this feature will allow IPCHAINS to
copy some packets to UserSpace tools for additional checks
* IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) [N/y/?] n
- OPTIONAL: Not needed for normal MASQ functionality though people who
want to do transparent proxy via Squid will want this. Please note
that there is a PERFORMANCE PENALTY enabling this feature.
* IP: masquerading (CONFIG_IP_MASQUERADE) [Y/n/?] y
- YES: Enable IP Masquerade to re-address specific internal to external
TCP/IP packets
* IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) [Y/n/?] y
- YES: Enable support for masquerading ICMP ping packets (ICMP error
codes will be MASQed regardless). This is an important feature
for troubleshooting connections.
* IP: masquerading special modules support (CONFIG_IP_MASQUERADE_MOD) [Y/n/?] y
- YES: Though OPTIONAL, this enables the option to later enable other
modules like the PORTFW to give external computers a directly
connection to specified internal MASQed machines.
* IP: ipautofw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [N/y/m/?] n
- NO: NOT recommended : IPautofw is a legacy method of port forwarding. It
is mainly old code and has been found to have some issues.
* IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/m/n/?] y
- OPTIONAL: Recommended : This enables PORTFW which allows external computers
on the Internet to directly communicate to specified internal MASQed
machines. This feature is typically used to allow access to internal
SMTP, TELNET, and WWW servers. Please note that FTP port forwarding
needs an additional patch, as described in the FAQ section of the MASQ
HOWTO. Please see the this FAQ section in the HOWTO for additional
information.
* IP: ip fwmark masq-forwarding support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_MFW) [Y/m/n/?] y
- OPTIONAL: This is a NEW method of performing PORTFW-like functionality which is
similar to how the new 2.4.x kernels do things. With this option, IPCHAINS
can mark packets that should have additional work done upon it. Using a
UserSpace tool, much like IPMASQADM or IPPORFW, IPCHAINS would then
do things like re-address the packets, change their TOS value, etc.
Currently, this code is less tested than PORTFW but it looks promising.
For now, this HOWTO recommends to use IPMASQADM and IPPORTFW. If you
have specific thoughts or comments on MFW, please email dranch.
* IP: optimize as a router not host (CONFIG_IP_ROUTER) [Y/n/?] y
- YES: This optimizes the kernel for the network subsystem, though it
isn't well known if this makes a siginificant performance difference
or not.
== Non-MASQ options skipped
== ( autoconf, tunneling, GRE )
* IP: multicast routing (CONFIG_IP_MROUTE) [N/y/?] n
- OPTIONAL: Though not needed for IPMASQ, enabling this feature will
let you route multicast traffic through your Linux box.
Please note that this requires that your ISP be multicast
enabled as well.
== Non-MASQ options skipped
== (Aliasing, ARPd)
* IP: TCP syncookie support (disabled per default) (CONFIG_SYN_COOKIES) [Y/n/?]
- YES: Recommended : for basic TCP/IP network security
* IP: GRE tunnels over IP (CONFIG_NET_IPGRE) [N/y/m/?]
- NO: This OPTIONAL selection is to enable PPTP and GRE tunnels through
the IP MASQ box
== Non-MASQ options skipped
== (aliasing, ARPd)
* IP: TCP syncookie support (not enabled per default) (CONFIG_SYN_COOKIES) [Y/n/?]
- YES: HIGHLY recommended for basic TCP/IP network security
== Non-MASQ options skipped
== (RARP)
* IP: Allow large windows (not recommended if <16Mb of memory) * (CONFIG_SKB_LARGE) [Y/n/?]
- YES: This is recommended to optimize Linux's TCP window
== Non-MASQ options skipped
== (IPv6, IPX, WAN router, etc.)
* Fast switching (read help!) (CONFIG_NET_FASTROUTE) [N/y/?] n
- NO: This performance optimization is NOT compatible with IP MASQ and/or
packet filtering
== Non-MASQ options skipped
== (Slow CPU, Telephony, SCSI, I2O, etc. )
== Don't forget to compile in support for hardware that you might need:
== SCSI: HDs, CDROMs, etc.
[ Network device support ]
* Network device support (CONFIG_NETDEVICES) [Y/n/?]
- YES: Enables the Linux Network device sublayer
== Non-MASQ options skipped
== (Arcnet)
* Dummy net driver support (CONFIG_DUMMY) [M/n/y/?]
- YES: Though OPTIONAL, this option can help when debugging problems
== Non-MASQ options skipped
== (EQL, NICs, Wireless, IrDA, ISDN, etc..)
== Don't forget to compile in support for hardware that you might need:
== NICs: eth, tr, etc.
== MODEMs: ppp and/or slip
== WANs: T1, T3, ISDN, etc.
== ISDN: for internal ISDN modems
[ Character devices ]
== Don't forget to compile in serial port support for modem users
== Don't forget to compile in mouse support
== Non-MASQ options skipped
== (I2C, Watchdog cards, Ftape, Video for Linux, USB, etc. )
[ File systems ]
== Non-MASQ options skipped
== (Quota, ISO9660, NTFS, etc )
* /proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
- YES: Required to dynamically configure the Linux forwarding
and NATing systems
== Non-MASQ options skipped
== (network fs, NLS, video section, sound, kernel hacking)
</Screen>
So go ahead and "exit" and you should be prompted to save your config.
</para>
<para>
NOTE: These are just the components you need for IP Masquerade. You will need
to select whatever other options needed for your specific setup.
</para>
<ItemizedList>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.2.x-Requirements"> for URLs to the KERNEL howto, etc.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</Sect2>
<Sect2 id="ipmasq-compiling3.1.3">
<Title>Compiling Linux 2.0.x Kernels</Title>
<para>
<Emphasis role="strong">Please see <XRef LinkEnd="kernel-2.0.x-Requirements"> for any
required software, patches, etc.</Emphasis>
</para>
<ItemizedList>
<listitem>
<para>
First of all, you need the kernel source for 2.0.x (preferably the latest
kernel version)
<Itemizedlist>
<listitem>
<para>
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.
</para>
</listitem>
</Itemizedlist>
</para>
</listitem>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.0.x-Requirements">. Please note that the instructions
included here is just one way to do build a kernel. Please see the Kernel
HOWTO for full details.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>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.
</para>
</listitem>
<listitem>
<para>
For this HOWTO example, create a directory called <Literal>/usr/src/kernel</Literal>.
Next, "cd" into this directory and download the newest 2.0.x kernel sources
into it. Once downloaded, issue the following command:
<Literal>tar xvzf linux-2.0.x.tar.gz</Literal> . Please substitute the "x"
in the 2.0.x filename with the Linux 2.0 kernel version you downloaded.
</para>
<para>
Once uncompressed, I recommend that you rename the directory from "linux" to
"linux-2.0.x" for clarity. To do this, run the command <Literal>mv linux
linux-2.0.x</Literal>. Next, make sure there is a directory or symbolic
link pointing to <Literal>/usr/src/kernel/linux</Literal> ie. run the
command: <Literal>ln -s /usr/src/kernel/linux-2.0.x /usr/src/kernel/linux</Literal>o
again subsituting the "x" for your proper kernel version.
</para>
</listitem>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.0.x-Requirements"> for URLs and the
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resources</ULink>
for up-to-date information and patch URLs.
</para>
</listitem>
<listitem>
<para>
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.
</para>
<para>
<Emphasis role="strong">Side Note:</Emphasis>
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
<ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">
Linux Kernel
HOWTO</ULink> and the kernel source's "<Literal>README</Literal>" file and
"<Literal>Documentation/</Literal>" directory for detailed help on compiling a kernel.
</para>
</listitem>
</Itemizedlist>
<para>
Please note the <Emphasis role="strong">YES or NO ANSWERS</Emphasis> to the
following options. Not all options will be available without the proper
kernel patches described later in this HOWTO:
</para>
<para>
Run the following commands to configure your kernel:
<Itemizedlist>
<listitem>
<para>
<literal>cd /usr/src/kernel/linux</literal>
</para>
</listitem
<listitem>
<para>
<literal>make menuconfig</literal>
</para>
</listitem>
</Itemizedlist>
</para>
<para>
The following kernel prompts reflect a 2.0.39 kernel:
</para>
<para>
<Screen>
[ Code maturity level options ]
* Prompt for development and/or incomplete code/drivers (CONFIG_EXPERIMENTAL) [Y/n/?]
- YES: this will allow you to later select the IP Masquerade feature code
[ Loadable module support ]
* Enable loadable module support (CONFIG_MODULES) [Y/n/?] y
- YES: allows you to load kernel IP MASQ modules
* Set version information on all module symbols (CONFIG_MODVERSIONS) [N/y/?] y
- YES: allows newer kernels to load older modules if possible
* Kernel daemon support (e.g. autoload of modules) (CONFIG_KERNELD) [N/y/?] y
- OPTIONAL: Recommended : allows the kernel to load various kernel modules as
it needs them
[ General setup ]
== Non-MASQ options skipped
== (FPU, memory)
* Networking support (CONFIG_NET) [Y/n/?] y
- YES: Enables the network subsystem
== Non-MASQ options skipped
== (memory, PCI, binary format, APM, etc.)
== Don't forget to compile in support for hardware that you might need:
== IDE controllers, HDs, CDROMs, etc.
[ Networking options ]
* Network firewalls (CONFIG_FIREWALL) [Y/n/?] y
- YES: Enables the IPFWADM firewall tool
== Non-MASQ options skipped
== (Aliasing)
* TCP/IP networking (CONFIG_INET) [Y/n/?] y
- YES: Enables the TCP/IP protocol
* IP: forwarding/gatewaying (CONFIG_IP_FORWARD) [N/y/?] y
- YES: Enables Linux network packet forwarding and routing
- Controlled by IPFWADM
* IP: multicasting (CONFIG_IP_MULTICAST) [N/y/?] y
- OPTIONAL: You can enable this if you want to be able to receive
Multicast traffic. Please note that your ISP must
support Multicast as well for this all to work
* IP: syn cookies (CONFIG_SYN_COOKIES) [Y/n/?] y
- YES: HIGHLY recommended for basic network security
* IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?] y
- YES: Enable the packet firewall features
* IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) [Y/n/?] y
- YES: Allows the kernel to report back on various packets traversing
the firewall.
* IP: masquerading (CONFIG_IP_MASQUERADE [Y/n/?] y
- YES: Enable the kernel to perform IP MASQ NAT functionality
* IP: ipautofw masquerade support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [Y/n/?] n
- NO: NOT Recommended : IPautofw is a legacy method of TCP/IP port forwarding.
Though IPautofw works, IPPORTFW is a better choice.
* IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/n/?] y
- YES: This option is ONLY AVAILABLE VIA A PATCH for the 2.0.x kernels.
With this option, external computers on the Internet can directly
communicate to specified internal MASQed machines. This feature is
typically used to access internal SMTP, TELNET, and WWW servers.
FTP port forwarding sometimes might require an additional patch as
described in the FAQ section. Additional information on port
forwarding is available in the Forwards section of this HOWTO.
* IP: MS PPTP masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_PPTP) [N/y/?] (NEW) n
- OPTIONAL: Enabling this feature will allow internal MASQ clients to
properly connect to PPTP servers on the Internet.
* IP: MS PPTP Call ID masq support (CONFIG_IP_MASQUERADE_PPTP_MULTICLIENT) [N/y/?] (NEW) n
- OPTIONAL: If you enabled the CONFIG_IP_MASQUERADE_PPTP above, this
option will allow for multiple internal PPTP clients behind the MASQ
server to communicate to the same PPTP server.
* IP: MS PPTP masq debugging (DEBUG_IP_MASQUERADE_PPTP) [N/y/?] n
- OPTIONAL: NOT recommended : This is not required for IP MASQ or MASQing PPTP
connections unless you need additional troubleshooting help. If enabled,
this can fill up your logs quickly.
* IP: MS PPTP masq verbose debugging (DEBUG_IP_MASQUERADE_PPTP_VERBOSE) [N/y/?] (NEW) n
- OPTIONAL: NOT Recommended : If you enabled the DEBUG_IP_MASQUERADE_PPTP
option above, this will make the logging even more verbose.
* IP: IPSEC ESP & ISAKMP masq support (EXPERIMENTAL) * (CONFIG_IP_MASQUERADE_IPSEC) [N/y/?] m
- OPTIONAL: This option allows for some forms of IPSEC tunnels to be
masquraded
* IP: IPSEC masq table lifetime (minutes) (CONFIG_IP_MASQUERADE_IPSEC_EXPIRE) * [30] (NEW)
- OPTIONAL: This feature allows to change the MASQ table timeouts so that
idle IPSEC tunnels won't be prematurely disconnected.
* IP: Disable inbound ESP destination guessing * (CONFIG_IP_MASQUERADE_IPSEC_NOGUESS) [N/y/?] n
- OPTIONAL: This feature allows the kernel to guess where the fully encrypted IPSEC VPN
might be going and add it to the MASQ table.
* IP: IPSEC masq debugging (DEBUG_IP_MASQUERADE_IPSEC) [N/y/?] ? n
- OPTIONAL: NOT recommended : This is not required for IP MASQ or MASQing IPSEC
connections unless you need additional troubleshooting help. If enabled,
this can fill up your logs quickly.
* IP: IPSEC masq verbose debugging (DEBUG_IP_MASQUERADE_IPSEC_VERBOSE) [N/y/?] (NEW) n
- OPTIONAL: NOT Recommended : If you enabled the DEBUG_IP_MASQUERADE_IPSEC
option above, this will make the logging even more verbose.
* IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) [Y/n/?]
- YES: Enable support for masquerading ICMP packets. Though thought of as
optional, many programs will NOT function properly with out ICMP
support.
* IP: transparent proxy support (EXPERIMENTAL) (CONFIG_IP_TRANSPARENT_PROXY) [N/y/?] n
- OPTIONAL: Not needed for normal MASQ functionality though people who
want to do transparent proxy via Squid will want this. Please note
that there is a PERFORMANCE PENALTY enabling this feature.
* IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]
- YES: This option is ONLY AVAILABLE VIA A PATCH for the 2.0.x kernels.
With this option, internally masqueraded computers can play
NAT-friendly games over the Internet. Explicit details are given
in the FAQ section of this HOWTO.
* IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG) [Y/n/?]
- YES: This feature optimizes IP MASQ connections
== Non-MASQ options skipped
== (Accounting)
* IP: optimize as router not host (CONFIG_IP_ROUTER) [Y/n/?]
- YES: This optimizes the kernel for the network subsystem
== Non-MASQ options skipped
== (Tunneling, Mcast routing, RARP, PMTU, etc.)
* IP: Drop source routed frames (CONFIG_IP_NOSR) [Y/n/?]
- YES: HIGHLY recommended for basic network security
== Non-MASQ options skipped
== (IPX, Bridging, SCSI, etc.)
== Don't forget to compile in support for hardware that you might need:
== SCSI controllers, HDs, CDROMs, etc.
[ Network device support ]
* Network device support (CONFIG_NETDEVICES) [Y/n/?]
- YES: Enables the Linux Network device sublayer
== Non-MASQ options skipped
== (Dummy, EQL, PPP, SLIP, NICs, Wireless, etc.)
== Don't forget to compile in support for hardware that you might need:
== NICs: eth, tr, etc.
== MODEMs: ppp and/or slip
== WANs: T1, T3, ISDN, etc.
== ISDN: for internal ISDN modems
[ File systems ]
== Non-MASQ options skipped
== (Quota, ISO9660, Codepages, NTFS, etc )
* /proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
- YES: Required to dynamically configure the Linux forwarding
and NATing systems
[ Character devices ]
== Non-MASQ options skipped
== (multi-port serial, parallel, mice, Ftape, Sound, etc. )
== Don't forget to compile in serial port support for modem users
== Don't forget to compile in mouse support
</Screen>
</para>
<para>
So go ahead and "exit" and you should be prompted to save your config.
</para>
<para>
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.
</para>
<ItemizedList>
<listitem>
<para>
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
<XRef LinkEnd="kernel-2.0.x-Requirements"> for URLs to the KERNEL howto, etc.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</Sect2>
</Sect1>
<Sect1 id="Addressing-the-LAN">
<Title>Assigning Private Network IP Addresses to the Internal LAN</Title>
<para>
Since all <Emphasis role="strong">INTERNAL MASQed</Emphasis> 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.
</para>
<para>
From the original IP Masquerade FAQ:
</para>
<para>
<ULink URL="http://www.cis.ohio-state.edu/cgi-bin/rfc/INDEX.rfc.html">RFC
1918</ULink> is the official document on which IP addresses are to be used in
a non-connected or "private" network. There are 3 blocks of numbers set aside
specifically for this purpose.
</para>
<para>
<Screen>
Section 3: Private Address Space
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private networks:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
We will refer to the first block as "24-bit block", the second as "20-bit
block", and the third as "16-bit" block". Note that the first block is
nothing but a single class A network number, while the second block is a set
of 16 continuous class B network numbers, and the third block is a set of 255
continuous class C network numbers.
</Screen>
</para>
<para>
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.
</para>
<para>
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
</para>
<para>
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.
</para>
</Sect1>
<Sect1 id="firewall-examples">
<Title>Configuring IP Forwarding Policies</Title>
<para>
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
<XRef LinkEnd="kernel-2.4.x-Requirements">, the 2.2.x
<XRef LinkEnd="kernel-2.2.x-Requirements">, or the 2.0.x
<XRef LinkEnd="kernel-2.0.x-Requirements">.
</para>
<para>
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.
</para>
<para>
<Emphasis role="strong">** This section ONLY provides the user with the
bare minimum firewall ruleset to get IP Masquerading working. </Emphasis>
</para>
<para>
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
<XRef LinkEnd="rc.firewall-iptables-stronger">, the Stronger IPCHAINS ruleset
for 2.2.x kernels in <XRef LinkEnd="rc.firewall-ipchains-stronger">, and
the Stronger IPFWADM ruleset for 2.0.x kernels in
<XRef LinkEnd="rc.firewall-ipfwadm-stronger">. Please note that these
stronger firewall rulesets are more of a template than anything else.
For truly secure firewall rulesets, check out the requirements section
of the HOWTO ( 2.4.x - <XRef LinkEnd="kernel-2.4.x-Requirements">, 2.2.x -
<XRef LinkEnd="kernel-2.2.x-Requirements">, 2.0.x -
<XRef LinkEnd="kernel-2.0.x-Requirements"> ).
</para>
<para>
Instead of manually typing one of these files by hand, I recommend to simply
<ULink
URL="http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/">browse
the Example directory</Ulink> or
<ULink
URL="http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/examples/rc.firewall-examples.tar.gz">
download an archive of all of these rc.firewall-* files</Ulink>.
</para>
<Sect2 id="rc.firewall-iptables">
<Title>Configuring IP Masquerade on Linux 2.6.x and 2.4.x Kernels</Title>
<para>
Please note that IPCHAINS is <Emphasis role="strong">no longer the primary
firewall configuration tool </Emphasis> 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 also be noted that when running in this compatibility mode,
NO IPTABLES modules can be loaded. The reason for this is that none of the
2.2.x IPMASQ modules are compatible with 2.4.x kernels. For a more detailes
for these changes, please see the <XRef LinkEnd="ipchains-on-2.4.x"> section.
</para>
<para>
Ok, as mentioned before, the <literal>/etc/rc.d/rc.local-*</literal> script
can be loaded once after every reboot. The mechanism to load the script varies
between different Linux distros (please see below for some exampels). The
rc.firewall-iptables script will load all required IPMASQ modules as well as
enable the final IPMASQ functionality. For advanced setups, this same file
would contain very secure firewall rulesets as well.
</para>
<para>
Anyway, create the file /etc/rc.d/rc.firewall-iptables with the following
initial SIMPLE ruleset:
</para>
<para>
&lt;rc.firewall-iptables START&gt;
<Screen>
#!/bin/sh
#
# rc.firewall-iptables
FWVER=0.76
#
# Initial SIMPLE IP Masquerade test for 2.6 / 2.4 kernels
# using IPTABLES.
#
# Once IP Masquerading has been tested, with this simple
# ruleset, it is highly recommended to use a stronger
# IPTABLES ruleset either given later in this HOWTO or
# from another reputable resource.
#
#
#
# Log:
# 0.76 - Added comments on why the default policy is ACCEPT
# 0.75 - Added more kernel modules to the comments section
# 0.74 - the ruleset now uses modprobe vs. insmod
# 0.73 - REJECT is not a legal policy yet; back to DROP
# 0.72 - Changed the default block behavior to REJECT not DROP
# 0.71 - Added clarification that PPPoE users need to use
# "ppp0" instead of "eth0" for their external interface
# 0.70 - Added commented option for IRC nat module
# - Added additional use of environment variables
# - Added additional formatting
# 0.63 - Added support for the IRC IPTABLES module
# 0.62 - Fixed a typo on the MASQ enable line that used eth0
# instead of $EXTIF
# 0.61 - Changed the firewall to use variables for the internal
# and external interfaces.
# 0.60 - 0.50 had a mistake where the ruleset had a rule to DROP
# all forwarded packets but it didn't have a rule to ACCEPT
# any packets to be forwarded either
# - Load the ip_nat_ftp and ip_conntrack_ftp modules by default
# 0.50 - Initial draft
#
echo -e "\n\nLoading simple rc.firewall-iptables version $FWVER..\n"
# The location of the iptables and kernel module programs
#
# If your Linux distribution came with a copy of iptables,
# most likely all the programs will be located in /sbin. If
# you manually compiled iptables, the default location will
# be in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
#IPTABLES=/sbin/iptables
IPTABLES=/usr/local/sbin/iptables
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe
#Setting the EXTERNAL and INTERNAL interfaces for the network
#
# Each IP Masquerade network needs to have at least one
# external and one internal network. The external network
# is where the natting will occur and the internal network
# should preferably be addressed with a RFC1918 private address
# scheme.
#
# For this example, "eth0" is external and "eth1" is internal"
#
#
# NOTE: If this doesnt EXACTLY fit your configuration, you must
# change the EXTIF or INTIF variables above. For example:
#
# If you are a PPPoE or analog modem user:
#
# EXTIF="ppp0"
#
#
EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"
#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
echo -en " loading modules: "
# Need to verify that all modules have all required dependencies
#
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
# With the new IPTABLES code, the core MASQ functionality is now either
# modular or compiled into the kernel. This HOWTO shows ALL IPTABLES
# options as MODULES. If your kernel is compiled correctly, there is
# NO need to load the kernel modules manually.
#
# NOTE: The following items are listed ONLY for informational reasons.
# There is no reason to manual load these modules unless your
# kernel is either mis-configured or you intentionally disabled
# the kernel module autoloader.
#
# Upon the commands of starting up IP Masq on the server, the
# following kernel modules will be automatically loaded:
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ
# modules are shown below but are commented out from loading.
# ===============================================================
echo "----------------------------------------------------------------------"
#Load the main body of the IPTABLES module - "iptable"
# - Loaded automatically when the "iptables" command is invoked
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "ip_tables, "
$MODPROBE ip_tables
#Load the IPTABLES filtering module - "iptable_filter"
# - Loaded automatically when filter policies are activated
#Load the stateful connection tracking framework - "ip_conntrack"
#
# The conntrack module in itself does nothing without other specific
# conntrack modules being loaded afterwards such as the "ip_conntrack_ftp"
# module
#
# - This module is loaded automatically when MASQ functionality is
# enabled
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "ip_conntrack, "
$MODPROBE ip_conntrack
#Load the FTP tracking mechanism for full FTP tracking
#
# Enabled by default -- insert a "#" on the next line to deactivate
#
echo -en "ip_conntrack_ftp, "
$MODPROBE ip_conntrack_ftp
#Load the IRC tracking mechanism for full IRC tracking
#
# Enabled by default -- insert a "#" on the next line to deactivate
#
echo -en "ip_conntrack_irc, "
$MODPROBE ip_conntrack_irc
#Load the general IPTABLES NAT code - "iptable_nat"
# - Loaded automatically when MASQ functionality is turned on
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "iptable_nat, "
$MODPROBE iptable_nat
#Loads the FTP NAT functionality into the core IPTABLES code
# Required to support non-PASV FTP.
#
# Enabled by default -- insert a "#" on the next line to deactivate
#
echo -en "ip_nat_ftp, "
$MODPROBE ip_nat_ftp
#Loads the IRC NAT functionality into the core IPTABLES code
# Required to support NAT of IRC DCC requests
#
# Disabled by default -- remove the "#" on the next line to activate
#
#echo -e "ip_nat_irc"
#$MODPROBE ip_nat_irc
echo "----------------------------------------------------------------------"
# Just to be complete, here is a partial list of some of the other
# IPTABLES kernel modules and their function. Please note that most
# of these modules (the ipt ones) are automatically loaded by the
# master kernel module for proper operation and don't need to be
# manually loaded.
# --------------------------------------------------------------------
#
# ip_nat_snmp_basic - this module allows for proper NATing of some
# SNMP traffic
#
# iptable_mangle - this target allows for packets to be
# manipulated for things like the TCPMSS
# option, etc.
#
# --
#
# ipt_mark - this target marks a given packet for future action.
# This automatically loads the ipt_MARK module
#
# ipt_tcpmss - this target allows to manipulate the TCP MSS
# option for braindead remote firewalls.
# This automatically loads the ipt_TCPMSS module
#
# ipt_limit - this target allows for packets to be limited to
# to many hits per sec/min/hr
#
# ipt_multiport - this match allows for targets within a range
# of port numbers vs. listing each port individually
#
# ipt_state - this match allows to catch packets with various
# IP and TCP flags set/unset
#
# ipt_unclean - this match allows to catch packets that have invalid
# IP/TCP flags set
#
# iptable_filter - this module allows for packets to be DROPped,
# REJECTed, or LOGged. This module automatically
# loads the following modules:
#
# ipt_LOG - this target allows for packets to be
# logged
#
# ipt_REJECT - this target DROPs the packet and returns
# a configurable ICMP packet back to the
# sender.
#
echo -e " Done loading modules.\n"
#CRITICAL: Enable IP forwarding since it is disabled by default since
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP,
# enable this following option. This enables dynamic-address hacking
# which makes the life with Diald and similar programs much easier.
#
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# Enable simple IP forwarding and Masquerading
#
# NOTE: In IPTABLES speak, IP Masquerading is a form of SourceNAT or SNAT.
#
# NOTE #2: The following is an example for an internal LAN address in the
# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask
# connecting to the Internet on external interface "eth0". This
# example will MASQ internal traffic out to the Internet but not
# allow non-initiated traffic into your internal network.
#
#
# ** Please change the above network numbers, subnet mask, and your
# *** Internet connection interface name to match your setup
#
#Clearing any previous configuration
#
# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT
# The default for FORWARD is DROP (REJECT is not a valid policy)
#
# Isn't ACCEPT insecure? To some degree, YES, but this is our testing
# phase. Once we know that IPMASQ is working well, I recommend you run
# the rc.firewall-*-stronger rulesets which set the defaults to DROP but
# also include the critical additional rulesets to still let you connect to
# the IPMASQ server, etc.
#
echo " Clearing any existing rules and setting default policy.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
echo " FWD: Allow all connections OUT and only existing and related ones IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG
echo " Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
echo -e "\nrc.firewall-iptables v$FWVER done.\n"
</Screen>
&lt;rc.firewall-iptables STOP&gt;
</para>
<para>
Once you are finished with editing this /etc/rc.d/rc.firewall-iptables ruleset,
make it executable by typing in
<Literal>chmod 700 /etc/rc.d/rc.firewall-iptables</Literal>
</para>
<para>
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:
Redhat (SyS-V style) and Slackware (BSD style)
</para>
<para>
1. Redhat and Redhat-derived distros:
</para>
<ItemizedList>
<listitem>
<para>
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 but
isn't doing things the SYS-V way. All you have to do is add the line:
</para>
<para>
<screen>
echo "Loading the rc.firewall-iptables ruleset.. "
/etc/rc.d/rc.firewall-iptables
</screen>
</para>
<para>
to the end of the /etc/rc.d/rc.local file and thats it (as described earlier
in the HOWTO).
</para>
<para>
The problem with this approach is that the firewall isn't executed until
the last stages of booting.
</para>
</listitem>
<listitem>
<para>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:
</para>
<para>
&lt;firewall-iptables START&gt;
<screen>
#!/bin/sh
#
# chkconfig: 2345 11 89
#
# description: Loads the rc.firewall-iptables ruleset.
#
# processname: firewall-iptables
# pidfile: /var/run/firewall.pid
# config: /etc/rc.d/rc.firewall-iptables
# probe: true
# ----------------------------------------------------------------------------
# v05/24/03
#
# Part of the copyrighted and trademarked TrinityOS document.
# http://www.ecst.csuchico.edu/~dranch
#
# Written and Maintained by David A. Ranch
# dranch@trinnet.net
#
# Updates
# -------
# 05/24/03 - removed a old networking up check that had some
# improper SGML ampersand conversions.
# ----------------------------------------------------------------------------
# Source function library.
. /etc/rc.d/init.d/functions
# Check that networking is up.
[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0
[ -x /sbin/ifconfig ] || exit 0
# The location of various iptables and other shell programs
#
# If your Linux distribution came with a copy of iptables, most
# likely it is located in /sbin. If you manually compiled
# iptables, the default location is in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
IPTABLES=/usr/local/sbin/iptables
# See how we were called.
case "$1" in
start)
/etc/rc.d/rc.firewall-iptables
;;
stop)
echo -e "\nFlushing firewall and setting default policies to DROP\n"
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT DROP
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -F -t nat
# Delete all User-specified chains
$IPTABLES -X
#
# Reset all IPTABLES counters
$IPTABLES -Z
;;
restart)
$0 stop
$0 start
;;
status)
$IPTABLES -L
;;
mlist)
cat /proc/net/ip_conntrack
;;
*)
echo "Usage: firewall-iptables {start|stop|status|mlist}"
exit 1
esac
exit 0
</screen>
&lt;firewall-iptables STOP&gt;
</para>
<para>
With this script in place, all you need to do now is make it executable and
then make it load upon reboot. First, make it executable by running:
<screen>
#Redhat-style
#
chmod 700 /etc/rc.d/init.d/firewall-iptables
</screen>
Now, enable the ruleset load upon reboot:
<screen>
#Redhat style
#
/sbin/chkconfig --level=345 firewall-iptables on
</screen>
That's it! Now upon reboot, the firewall will be loaded automatically. Just
to make sure, run the following command to see that the firewall should start
upon reboot by running the command:
<screen>
#Redhat style
#
chkconfig --list firewall-iptables
#The output should look like:
#
firewall-iptables 0:off 1:off 2:off 3:on 4:on 5:on 6:off
</screen>
</para>
</listitem>
</ItemizedList>
<para>
2. Slackware:
</para>
<para>
<ItemizedList>
<listitem>
<para>
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 but isn't the
most secure (see below). All you have to do is append the following lines to
the /etc/rc.d/rc.local file:
</para>
<para>
<screen>
echo "Loading the rc.firewall-iptables ruleset.."
/etc/rc.d/rc.firewall-iptables
</screen>
</para>
<para>
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 but if you know what you're doing (it's easy), go ahead
and modify the inet2 startup script to load the
/etc/rc.d/rc.firewall-iptables file just after the network is up. If you
want a more detailed guide and/or a stronger firewall ruleset, I recommend
you check out Section 10 of TrinityOS found in the links section at
the bottom of this HOWTO.
</para>
</listitem>
</ItemizedList>
</para>
<para>
<Emphasis role="strong">Notes on how users might want to change the above
firewall ruleset:</Emphasis>
</para>
<para>
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-iptables ruleset.
</para>
<!-- Blah, confirm the -s syntax -->
<para>
<Screen>
#!/bin/sh
#
# Partial IPTABLES config to enable simple IP forwarding and Masquerading
# v0.61
#
# NOTE: The following is an example to allow only IP Masquerading for the
# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a
# "/24" subnet mask connecting to the Internet on interface eth0.
#
# ** Please change the network number, subnet mask, and the Internet
# ** connection interface name to match your internal LAN setup
#
echo " - Setting the default FORWARD policy to DROP"
$IPTABLES -P FORWARD DROP
echo " - Enabling SNAT (IPMASQ) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.2/32 -j MASQUERADE
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -s 192.168.0.8/32 -j MASQUERADE
echo " - Setting the FORWARD policy to 'DROP' all incoming / unrelated traffic"
$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,INVALID -j DROP
$IPTABLES -A FORWARD -i $EXTIF -m state --state NEW,INVALID -j DROP
</Screen>
</para>
<para>
<Emphasis role="strong">Common mistakes:</Emphasis>
</para>
<para>
It appears that a common mistake with new IP Masq users is to make the first
command simply the following:
</para>
<!-- Blah. Confirm the IPTABLES command -->
<para>
<screen>
IPTABLES:
---------
iptables -t nat -A POSTROUTING -j MASQUERADE
</screen>
</para>
<para>
Do <Emphasis role="strong">NOT</Emphasis> 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!
</para>
<para>
Again, you can add these lines to the <Literal>/etc/rc.d/rc.firewall-iptables</Literal>
file, one of the other rc files you prefer, or do it manually every time you
need IP Masquerade.
</para>
<para>
Please see <XRef LinkEnd="rc.firewall-iptables-stronger"> for a detailed guide
on a strong IPTABLES ruleset example. For additional details on IPTABLES usage,
please refer to <ULink URL="http://www.netfilter.org/">
http://www.netfilter.org/</ULink> for the primary IPTABLES site.
</para>
</Sect2>
<Sect2 id="rc.firewall-ipchains">
<Title>Configuring IP Masquerade on Linux 2.2.x Kernels</Title>
<para>
Please note that <Emphasis role="strong">IPFWADM is no longer the firewall
tool </Emphasis> 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 <XRef LinkEnd="FAQ">.
</para>
<para>
Create the file /etc/rc.d/rc.firewall-ipchains with the following initial SIMPLE
ruleset:
</para>
<para>
&lt;rc.firewall-ipchains START&gt;
<Screen>
#!/bin/sh
#
# rc.firewall-ipchains
#
# - Initial SIMPLE IP Masquerade test for 2.1.x and 2.2.x kernels
# using IPCHAINS.
#
# Once IP Masquerading has been tested, with this simple
# ruleset, it is highly recommended to use a stronger
# IPTABLES ruleset either given later in this HOWTO or
# from another reputable resource.
FWVER="1.23"
#
# 1.23 - Added comments on why the default policy is ACCEPT
# 1.22 - ruleset now uses modprobe instead of insmod
# 1.21 - Added clarification that PPPoE users need to use
# "ppp0" instead of "eth0" for their external interface
# 1.20 - Updated the script to use environment vars
# 1.01 - Original version
echo -e "\n\nLoading simple rc.firewall-ipchains : version $FWVER..\n"
# The location of the ipchains and kernel module programs
#
# If your Linux distribution came with a copy of ipchains,
# most likely all the programs will be located in /sbin. If
# you manually compiled ipchains, the default location will
# be in /usr/local/sbin
#
# ** Please use the "whereis ipchains" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
IPCHAINS=/sbin/ipchains
#IPTABLES=/usr/local/sbin/ipchains
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe
#Setting the EXTERNAL and INTERNAL interfaces for the network
#
# Each IP Masquerade network needs to have at least one
# external and one internal network. The external network
# is where the NATing will occur and the internal network
# should preferably be addressed with a RFC1918 private addressing
# scheme.
#
# For this example, "eth0" is external and "eth1" is internal"
#
# NOTE: If this doesnt EXACTLY fit your configuration, you must
# change the EXTIF or INTIF variables above. For example:
#
# If you are a PPPoE or analog modem user:
#
# EXTIF="ppp0"
#
# ** Please change this to reflect your specific configuration **
#
EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"
# Network Address of the Internal Network
#
# This example rc.firewall-ipchains file uses the 192.168.0.0 network
# with a /24 or 255.255.255.0 netmask.
#
# ** Change this variable to reflect your specific setup **
#
INTLAN="192.168.0.0/24"
echo -e " Internal Interface: $INTLAN\n"
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
# are shown below but are commented out from loading.
echo " loading required IPMASQ kernel modules.."
# Needed to initially load modules
#
$DEPMOD -a
echo -en " Loading modules: "
# Supports the proper masquerading of FTP file transfers using the PORT method
#
echo -en "FTP, "
$MODPROBE ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
#echo -en "RealAudio, "
$MODPROBE ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#echo -en "Irc, "
#$MODPROBE ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. This modules is
# for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#echo -en "Quake, "
#Quake I / QuakeWorld (ports 26000 and 27000)
#$MODPROBE ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#$MODPROBE ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#echo -en "CuSeeme, "
#$MODPROBE ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#echo -en "VdoLive "
#$MODPROBE ip_masq_vdolive
echo ". Done loading modules."
#CRITICAL: Enable IP forwarding since it is disabled by default since
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo " enabling forwarding.."
echo "1" &#62; /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmenting since it is disabled by default
# in 2.2.x kernels. This used to be a compile-time option but the
# behavior was changed in 2.2.12
#
echo " enabling AlwaysDefrag.."
echo "1" &#62; /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this
# following option. This enables dynamic-ip address hacking in IP MASQ,
# making the life with Diald and similar programs much easier.
#
#echo " enabling DynamicAddr.."
#echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
# Enable the LooseUDP patch which some Internet-based games require
#
# If you are trying to get an Internet game to work through your IP MASQ box,
# and you have set it up to the best of your ability without it working, try
# enabling this option (delete the "#" character). This option is disabled
# by default due to possible internal machine UDP port scanning
# vulnerabilities.
#
#echo " enabling LooseUDP.."
#echo "1" &#62; /proc/sys/net/ipv4/ip_masq_udp_dloose
#Clearing any previous configuration
#
# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT
# The default for FORWARD is REJECT
#
# Isn't ACCEPT insecure? To some degree, YES, but this is our testing
# phase. Once we know that IPMASQ is working well, I recommend you run
# the rc.firewall-*-stronger rulesets which set the defaults to DROP but
# also include the critical additional rulesets to still let you connect to
# the IPMASQ server, etc.
#
echo " clearing any existing rules and setting default policy.."
$IPCHAINS -P input ACCEPT
$IPCHAINS -P output ACCEPT
$IPCHAINS -P forward REJECT
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F forward
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 160 sec timeout for UDP traffic (Important for MASQ'ed ICQ users)
#
echo " setting default timers.."
$IPCHAINS -M -S 7200 10 160
# DHCP: For people who receive their external IP address from either DHCP or
# BOOTP for connctions such as DSL or Cablemodem users, it is necessary
# to use the following before the deny command.
#
# This example is currently commented out.
#
#
#$IPCHAINS -A input -j ACCEPT -i $EXTIF -s 0/0 67 -d 0/0 68 -p udp
# Enable simple IP forwarding and Masquerading
#
# NOTE: The following is an example for an internal LAN address in the
# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask
# connecting to the Internet on interface eth0.
#
# ** Please change this network number, subnet mask, and your Internet
# ** connection interface name to match your internal LAN setup
#
echo " enabling IPMASQ functionality on $EXTIF"
$IPCHAINS -P forward DENY
$IPCHAINS -A forward -i $EXTIF -s $INTLAN -j MASQ
echo -e "\nrc.firewall-ipchains v$FWVER done.\n"
</Screen>
&lt;rc.firewall-ipchains STOP&gt;
</para>
<para>
Once you are finished with editing the /etc/rc.d/rc.firewall-ipchains ruleset,
make it executable by typing in
<Literal>chmod 700 /etc/rc.d/rc.firewall-ipchains</Literal>
</para>
<para>
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:
Redhat (SyS-V style) and Slackware (BSD style)
</para>
<para>
1. Redhat and Redhat-derived distros:
</para>
<ItemizedList>
<listitem>
<para>
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 but
isn't doing things the Sys-V way. All you have to do is add the line:
</para>
<para>
<screen>
echo "Loading the rc.firewall ruleset.."
/etc/rc.d/rc.firewall-ipchains
</screen>
</para>
<para>
to the end of the /etc/rc.d/rc.local file and thats it (as described earlier
in the HOWTO).
</para>
<para>
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:
</para>
<para>
&lt;firewall-ipchains START&gt;
<screen>
#!/bin/sh
#
# chkconfig: 2345 11 89
#
# description: Loads the rc.firewall-ipchains ruleset.
#
# processname: firewall-ipchains
# pidfile: /var/run/firewall.pid
# config: /etc/rc.d/rc.firewall-ipchains
# probe: true
# ----------------------------------------------------------------------------
# v08/29/02
#
# Part of the copyrighted and trademarked TrinityOS document.
# http://www.ecst.csuchico.edu/~dranch
#
# Written and Maintained by David A. Ranch
# dranch@trinnet.net
#
# Updates
# -------
#
# ----------------------------------------------------------------------------
# Source function library.
. /etc/rc.d/init.d/functions
# Check that networking is up.
# This line no longer work with bash2
#[ ${NETWORKING} = "no" ] && exit 0
# This should be OK.
[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0
[ -x /sbin/ifconfig ] || exit 0
# The location of various iptables and other shell programs
#
# If your Linux distribution came with a copy of iptables, most
# likely it is located in /sbin. If you manually compiled
# iptables, the default location is in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
IPCHAINS=/sbin/ipchains
# See how we were called.
case "$1" in
start)
/etc/rc.d/rc.firewall-ipchains
;;
stop)
echo -e "\nFlushing firewall and setting default policies to REJECT\n"
$IPCHAINS -P input REJECT
$IPCHAINS -P output REJECT
$IPCHAINS -P forward REJECT
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F forward
;;
restart)
$0 stop
$0 start
;;
status)
$IPCHAINS -L
;;
mlist)
$IPCHAINS -M -L
;;
*)
echo "Usage: firewall-ipchains {start|stop|status|mlist}"
exit 1
esac
exit 0
</screen>
&lt;firewall-ipchains STOP&gt;
</para>
<para>
With this script in place, all you need to do now is make it executable and
then make it load upon reboot. First, make it executable by running:
<screen>
#Redhat-style
#
chmod 700 /etc/rc.d/init.d/firewall-ipchains
</screen>
Now, make the ruleset load upon reboot:
<screen>
#Redhat style
#
chkconfig --level=345 firewall-ipchains on
</screen>
That's it! Now upon boot, the firewall will be loaded automatically. Just
to make sure, run the command to see that the firewall should start upon
reboot by running the command:
<screen>
#Redhat style
#
chkconfig --list firewall-ipchains
#The output should look like:
#
firewall-ipchains 0:off 1:off 2:off 3:on 4:on 5:on 6:off
</screen>
</para>
</listitem>
</ItemizedList>
<para>
2. Slackware:
</para>
<para>
<ItemizedList>
<listitem>
<para>
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 but isn't the
most secure (see below). All you have to do is append the following lines to
the /etc/rc.d/rc.local file:
</para>
<para>
<screen>
echo "Loading the rc.firewall-ipchains ruleset.."
/etc/rc.d/rc.firewall-ipchains
</screen>
</para>
<para>
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 but if you know what you're doing (it's easy), go ahead
and modify the inet2 startup script to load the
/etc/rc.d/rc.firewall-ipchains file just after the network is up. If you
want a more detailed guide and/or a stronger firewall ruleset, I recommend
you check out Section 10 of TrinityOS found in the links section at
the bottom of this HOWTO.
</para>
</listitem>
</ItemizedList>
</para>
<para>
<Emphasis role="strong">Notes on how users might want to change the above
firewall ruleset:</Emphasis>
</para>
<para>
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-ipchains ruleset.
</para>
<para>
<Screen>
#!/bin/sh
#
# Enable simple IP forwarding and Masquerading
# v1.01
#
# NOTE: The following is an example used in addition to the simple
# IPCHAINS ruleset anove to allow only IP Masquerading for the
# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a
# "24" bit subnet mask connecting to the Internet on interface $EXTIF.
#
# ** Please change the network number, subnet mask, and the Internet
# ** connection interface name to match your internal LAN setup
#
$IPCHAINS -P forward DENY
$IPCHAINS -A forward -i $EXTIF -s 192.168.0.2/32 -j MASQ
$IPCHAINS -A forward -i $EXTIF -s 192.168.0.8/32 -j MASQ
</Screen>
</para>
<para>
<Emphasis role="strong">Common mistakes:</Emphasis>
</para>
<para>
What appears to be a common mistake with new IP MASQ users is to make the
first command:
</para>
<para>
<screen>
$IPCHAINS -P forward masquerade
</screen>
</para>
<para>
Do <Emphasis role="strong">NOT</Emphasis> 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!
</para>
<para>
Again, you can add these lines to the <Literal>/etc/rc.d/rc.firewall-ipchains</Literal>
file, one of the other rc files you prefer, or do it manually every time you
need IP Masquerade.
</para>
<para>
Please see <XRef LinkEnd="rc.firewall-ipchains-stronger"> for a detailed guide on
IPCHAINS and a strong IPCHAINS ruleset example. For additional details on
IPCHAINS usage, please refer to
<ULink URL="http://www.netfilter.org/ipchains/">
http://www.netfilter.org/ipchains/</ULink>
for the primary IPCHAINS site or the
<ULink URL="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">
Linux IP CHAINS HOWTO Backup</ULink> site
</para>
</Sect2>
<Sect2 id="rc.firewall-ipfwadm">
<Title>Configuring IP Masquerade on Linux 2.0.x Kernels</Title>
<para>
Create the file /etc/rc.d/rc.firewall-ipfwadm with the following initial SIMPLE
ruleset:
&lt;rc.firewall-ipfwadm START&gt;
<Screen>
#!/bin/sh
#
# rc.firewall-ipfwadm
#
# A Initial SIMPLE IP Masquerade setup for 2.0.x kernels using IPFWADM
#
FWVER="2.03"
#
# 2.03 - Added comments on why the default policy is ACCEPT
# 2.02 - Added clarification that PPPoE users need to use
# "ppp0" instead of "eth0" for their external interface
#
#
# Once IP Masquerading has been tested, with this simple
# ruleset, it is highly recommended to use a stronger
# IPTABLES ruleset either given later in this HOWTO or
# from another reputable resource.
#
echo -e "\n\nLoading simple rc.firewall-ipfwadm version $FWVER..\n"
#Setting the EXTERNAL and INTERNAL interfaces for the network
#
# Each IP Masquerade network needs to have at least one
# external and one internal network. The external network
# is where the NATing will occur and the internal network
# should preferably be addressed with a RFC1918 private addressing
# scheme.
#
# For this example, "eth0" is external and "eth1" is internal"
#
# NOTE: If this doesnt EXACTLY fit your configuration, you must
# change the EXTIF or INTIF variables above. For example:
#
# If you are a PPPoE or analog modem user:
#
# EXTIF="ppp0"
#
# ** Please change this to reflect your specific configuration **
#
EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"
# Network Address of the Internal Network
#
# This example rc.firewall-ipfwadm file uses the 192.168.0.0 network
# with a /24 or 255.255.255.0 netmask.
#
# ** Change this variable to reflect your specific setup **
#
INTLAN="192.168.0.0/24"
echo -e " Internal Interface: $INTLAN\n"
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current available IP
# MASQ modules are shown below but are commented out from loading.
echo -en "Loading modules: "
# Needed to initially load modules
#
/sbin/depmod -a
# Supports the proper masquerading of FTP file transfers using the PORT method
#
echo -en "FTP, "
/sbin/modprobe ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
#echo -en "RealAudio, "
#/sbin/modprobe ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#echo -en "Irc, "
#/sbin/modprobe ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. These modules
# are for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#echo -en "Quake, "
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#echo -en "CuSeeme, "
#/sbin/modprobe ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#echo -en "VdoLive, "
#/sbin/modprobe ip_masq_vdolive
echo ". Done loading modules."
#CRITICAL: Enable IP forwarding since it is disabled by default
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo " enabling forwarding.."
echo "1" &#62; /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmenting since it is disabled by default
#
# This used to be a compile-time option but the behavior was changed
# in 2.2.12. This option is required for both 2.0 and 2.2 kernels.
#
echo " enabling AlwaysDefrag.."
echo "1" &#62; /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your Internet IP address dynamically from SLIP, PPP, or DHCP,
# enable the following option. This enables dynamic-ip address hacking in
# IP MASQ, making the life with DialD, PPPd, and similar programs much easier.
#
#echo " enabling DynamicAddr.."
#echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
#Clearing any previous configuration
#
# Unless specified, the defaults for INPUT and OUTPUT is ACCEPT
# The default for FORWARD is REJECT
#
# Isn't ACCEPT insecure? To some degree, YES, but this is our testing
# phase. Once we know that IPMASQ is working well, I recommend you run
# the rc.firewall-*-stronger rulesets which set the defaults to DROP but
# also include the critical additional rulesets to still let you connect to
# the IPMASQ server, etc.
#
echo " clearing any existing rules and setting default policy.."
/sbin/ipfwadm -I -p accept
/sbin/ipfwadm -O -p accept
/sbin/ipfwadm -F -p reject
/sbin/ipfwadm -I -f
/sbin/ipfwadm -O -f
/sbin/ipfwadm -F -f
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 160 sec timeout for UDP traffic (Important for MASQ'ed ICQ users)
#
echo " setting default timers.."
/sbin/ipfwadm -M -s 7200 10 160
# DHCP: For people who receive their external IP address from either DHCP or
# BOOTP such as DSL or Cablemodem users, it is necessary to use the
# following before the deny command.
#
# This example is currently commented out.
#
#
#/sbin/ipfwadm -I -a accept -S 0/0 67 -D 0/0 68 -W $EXTIF -P udp
# Enable simple IP forwarding and Masquerading
#
# NOTE: The following is an example for an internal LAN address in the
# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask
# connecting to the Internet on interface eth0.
#
# ** Please change this network number, subnet mask, and your Internet
# ** connection interface name to match your internal LAN setup.
#
echo " enabling IPMASQ functionality on $EXTIF"
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a m -W $EXTIF -S $INTLAN -D 0.0.0.0/0
echo -e "\nrc.firewall-ipfwadm v$FWVER done.\n"
</Screen>
&lt;rc.firewall-ipfwadm STOP&gt;
</para>
<para>
Once you are finished with editing the /etc/rc.d/rc.firewall-ipfwadm ruleset,
make it executable by typing in "<Literal>chmod 700 /etc/rc.d/rc.firewall-ipfwadm</Literal>"
</para>
<para>
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 (SyS-V style) and Slackware (BSD style)
</para>
<para>
Redhat and Redhat-derived distros:
</para>
<ItemizedList>
<listitem>
<para>
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 but
isn't doing it the Sys-V way. All you have to do is add the line:
</para>
<para>
<screen>
echo "Loading the rc.firewall-ipfwadm ruleset.."
/etc/rc.d/rc.firewall-ipfwadm
</screen>
</para>
<para>
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:
</para>
<para>
&lt;firewall-ipfwadm START&gt;
<screen>
#!/bin/sh
#
# chkconfig: 2345 11 89
#
# description: Loads the rc.firewall-ipfwadm ruleset.
#
# processname: firewall-ipfwadm
# pidfile: /var/run/firewall.pid
# config: /etc/rc.d/rc.firewall-ipfwadm
# probe: true
# ----------------------------------------------------------------------------
# v02/09/02
#
# Part of the copyrighted and trademarked TrinityOS document.
# http://www.ecst.csuchico.edu/~dranch
#
# Written and Maintained by David A. Ranch
# dranch@trinnet.net
#
# Updates
# -------
#
# ----------------------------------------------------------------------------
# Source function library.
. /etc/rc.d/init.d/functions
# Check that networking is up.
# This line no longer work with bash2
#[ ${NETWORKING} = "no" ] && exit 0
# This should be OK.
[ "XXXX${NETWORKING}" = "XXXXno" ] && exit 0
[ -x /sbin/ifconfig ] || exit 0
# The location of various iptables and other shell programs
#
# If your Linux distribution came with a copy of iptables, most
# likely it is located in /sbin. If you manually compiled
# iptables, the default location is in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
IPFWADM=/sbin/ipfwadm
# See how we were called.
case "$1" in
start)
/etc/rc.d/rc.firewall-ipfwadm
;;
stop)
echo -e "\nFlushing firewall and setting default policies to REJECT\n"
$IPFWADM -I -p REJECT
$IPFWADM -O -p REJECT
$IPFWADM -F -p REJECT
$IPFWADM -I -f
$IPFWADM -O -f
$IPFWADM -F -f
;;
restart)
$0 stop
$0 start
;;
status)
$IPFWADM -l
;;
mlist)
$IPFWADM -M -l
;;
*)
echo "Usage: firewall-ipfwadm {start|stop|status|mlist}"
exit 1
esac
exit 0
</screen>
&lt;firewall-ipfwadm STOP&gt;
</para>
<para>
With this script in place, all you need to do now is make it executable and
then make it load upon reboot. First, make it executable by running:
<screen>
#Redhat-style
#
chmod 700 /etc/rc.d/init.d/firewall-ipfwadm
</screen>
Now, make the ruleset load upon reboot:
<screen>
#Redhat style
#
chkconfig --level=345 firewall-ipfwadm on
</screen>
That's it! Now upon boot, the firewall will be loaded automatically. Just
to make sure, run the command to see that the firewall should start upon
reboot by running the command:
<screen>
#Redhat style
#
chkconfig --list firewall-ipfwadm
#The output should look like:
#
firewall-ipfwadm 0:off 1:off 2:off 3:on 4:on 5:on 6:off
</screen>
</para>
</listitem>
</ItemizedList>
<para>
Slackware:
</para>
<ItemizedList>
<listitem>
<para>
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 but isn't the most secure (see below). All you have to do is
append the following lines to the /etc/rc.d/rc.local file:
</para>
<para>
<screen>
echo "Loading the rc.firewall-ipfwadm ruleset.."
/etc/rc.d/rc.firewall-ipfwadm
</screen>
</para>
<para>
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 but if you know what you're doing (it's easy), go ahead
and modify the inet2 startup script to load the
/etc/rc.d/rc.firewall-ipfwadm file just after the network is up. If you
want a more detailed guide and/or a stronger firewall ruleset, I recommend
you check out Section 10 of TrinityOS found in the links section at
the bottom of this HOWTO.
</para>
</listitem>
</ItemizedList>
<para>
<Emphasis role="strong">Notes on how users might want to change the above
firewall ruleset:</Emphasis>
</para>
<para>
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-ipfwadm ruleset.
</para>
<para>
<Screen>
# Enable simple IP forwarding and Masquerading
# v2.01
#
# NOTE: The following is an example to only allow IP Masquerading for the
# 192.168.0.2 and 192.168.0.8 machines with a 255.255.255.0 or a "24"
# bit subnet mask connected to the Internet on interface eth0.
#
# ** Please change this network number, subnet mask, and your Internet
# ** connection interface name to match your internal LAN setup
#
# Please use the following in ADDITION to the simple rulesets above for
# specific MASQ networks.
#
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a m -W $EXTIF -S 192.168.0.2/32 -D 0.0.0.0/0
/sbin/ipfwadm -F -a m -W $EXTIF -S 192.168.0.8/32 -D 0.0.0.0/0
</Screen>
</para>
<para>
<Emphasis role="strong">Common mistakes:</Emphasis>
</para>
<para>
What appears to be a common mistake with new IP Masq users is to make the
first command:
</para>
<para>
<screen>
ipfwadm -F -p masquerade
</screen>
</para>
<para>
Do <Emphasis role="strong">NOT</Emphasis> 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!
</para>
<para>
Again, you can add these lines to the <Literal>/etc/rc.d/rc.firewall-ipfwadm</Literal>
file, one of the other rc files (if you prefer), or manually add those lines
every time you need IP Masquerade.
</para>
<para>
Please see <XRef LinkEnd="rc.firewall-ipfwadm-stronger"> and
<XRef LinkEnd="rc.firewall-ipfwadm-stronger">for a detailed guide and stronger
examples of IPCHAINS and IPFWADM ruleset examples.
</para>
</Sect2>
</Sect1>
</Chapter>
<Chapter id="Configuring-clients">
<Title>Configuring the other internal to-be MASQed machines </Title>
<para>
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.
</para>
<para>
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.
</para>
<para>
After you have properly reconfigured the internal MASQed machines, remember to
restart their appropriate network services or reboot them if need be.
</para>
<para>
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 uses
just like enabling IP Masquerade services.
</para>
<para>
As it stands, the following Platforms have been tested as internal MASQed
machines. This is only an EXAMPLE of all compatible OSes out there:
</para>
<ItemizedList>
<listitem>
<para>
Apple Macintosh OS and OS-X (with MacTCP or Open Transport or the BSD TCP/IP stack)
</para>
</listitem>
<listitem>
<para>
AT&amp;T Unix (Caldera)
</para>
</listitem>
<listitem>
<para>
*BSD systems including Free/Net/Open/BSDi/386/etc.
</para>
</listitem>
<listitem>
<para>
Commodore Amiga (with AmiTCP or AS225-stack)
</para>
</listitem>
<listitem>
<para>
Digital VAX Stations 3520 and 3100 with UCX (TCP/IP stack for VMS)
</para>
</listitem>
<listitem>
<para>
Digital Ultrix, Digital Unix (Compaq Tru/64)
</para>
</listitem>
<listitem>
<para>
HP HP/UX
</para>
</listitem>
<listitem>
<para>
IBM AIX running on RS/6000, PowerPC, etc.
</para>
</listitem>
<listitem>
<para>
IBM OS/2 (including Warp v3)
</para>
</listitem>
<listitem>
<para>
IBM OS400 running on a AS/400
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Microsoft DOS (with NCSA Telnet package, DOS Trumpet works partially)
</para>
</listitem>
<listitem>
<para>
Microsoft Windows 3.1 (with the Netmanage or FTP packages)
</para>
</listitem>
<listitem>
<para>
Microsoft Windows For Workgroup 3.11 (with a TCP/IP package)
</para>
</listitem>
<listitem>
<para>
Microsoft Windows 95, OSR2, 98, 98se, Me
</para>
</listitem>
<listitem>
<para>
Microsoft Windows NT 3.51, 4.0, 2000, XP - (both workstation (professional) and server versions)
</para>
</listitem>
<listitem>
<para>
Novell Netware 4.01, 5.x, etc. with the TCP/IP service
</para>
</listitem>
<listitem>
<para>
SCO Openserver (v3.2.4.2 and 5) and UnixWare (AT&amp;T Unix)
</para>
</listitem>
<listitem>
<para>
Sun Solaris 2.51, 2.6, 7, 8
</para>
</listitem>
<listitem>
<para>
heheh.. what else am I missing?
</para>
</listitem>
</ItemizedList>
<Sect1 id="configuring-win9x">
<Title>Configuring Microsoft Windows 95 and OSR2</Title>
<OrderedList>
<listitem>
<para>
** Please note that some prompts might be different based upon the build
version of Windows95 you are running **
</para>
<para>
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 and
though it is fairly simple, if you haven't done this before, please seek
assitance.
</para>
</listitem>
<listitem>
<para>
Go to the <Emphasis role="strong">'Control Panel'</Emphasis> --&#62;
<Emphasis role="strong">'Network'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Click on <Emphasis role="strong">Add</Emphasis> --&#62;
<Emphasis role="strong">Protocol</Emphasis> --&#62; <Emphasis role="strong">
Manufacture: Microsoft</Emphasis> --&#62; <Emphasis role="strong">Protocol:
</Emphasis> <Emphasis role="strong">'TCP/IP protocol'</Emphasis> if you don't
already have it installed.
</para>
</listitem>
<listitem>
<para>
Highlight the TCP/IP item bound to your correct Windows95 network card
e.g. (TCP/IP --> Intel EtherExpress Pro/100+) and select
<Emphasis role="strong">'Properties'</Emphasis>. Here, you have two
options: configure a static address or use DHCP. Static addresses are simple
but 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).
</para>
<para>
DHCP enabled:
</para>
<para>
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.
<!-- Blah . confirm win95 dialog add URL to TrinityOS -->
</para>
<para>
Static Addresses:
</para>
<para>
Now goto the <Emphasis role="strong">'IP Address'</Emphasis> tab and set IP
Address to 192.168.0.x, (1 &lt; x &lt; 255), and set the Subnet Mask to
255.255.255.0
</para>
</listitem>
<listitem>
<para>
Now select the <Emphasis role="strong">"Gateway"</Emphasis> tab and add
192.168.0.1 as your gateway under <Emphasis role="strong">'Gateway'</Emphasis>
and hit "Add".
</para>
</listitem>
<listitem>
<para>
Under the <Emphasis role="strong">'DNS Configuration'</Emphasis> 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.
</para>
<para>
DHCP: No entries are required as this is configured dynamically via DHCP.
</para>
<para>
STATIC: Add all of the DNS servers that your Linux MASQ server uses (usually
found in <Literal>/etc/resolv.conf</Literal>). Usually these DNS servers are
located at your ISP though you could be running either your own Caching or
Authoritative DNS server on your Linux MASQ server as well. Again, setting
up DNS services is beyond the scope of this HOWTO but it is covered by TrinityOS
as well as the LDP's DNS HOWTO.
<!-- Blah . Add URLs for TrinityOS and the DNS howto -->
</para>
<para>
Optionally, you can add any appropriate domain search suffixes as well. This
allows users to simply type in the hostname of the destination computer instead
of the fully qualified domain name (FQDN). This is similar to the PATH function
for finding common Unix commands.
</para>
</listitem>
<listitem>
<para>
Leave all of the other settings alone as they are unless (even dangerous) if
you don't know what you're doing.
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'OK'</Emphasis> in all dialog boxes and restart
your system.
</para>
</listitem>
<listitem>
<para>
As an initial test, <Literal>Ping</Literal> the Linux MASQ server to test the
network connection: <Emphasis role="strong">'Start/Run'</Emphasis>, type:
<Literal>ping 192.168.0.1</Literal>(This is only an INTERNAL LAN connection
test, you might not be able to <Literal>ping</Literal> the outside world yet.)
If you don't see "replies" to your PINGs, please verify your network
configuration.
</para>
</listitem>
<listitem>
<para>
You can optionally create a <Literal>HOSTS</Literal> file in the C:\Windows
directory so that you can ping the "hostname" of the machines on your LAN
without the need for a DNS server. There is an example called
<Literal>HOSTS.SAM</Literal> in the C:\windows directory for an example.
</para>
</listitem>
</OrderedList>
</Sect1>
<!-- Blah . Reflect the modifications in the Win9x section other sections -->
<Sect1 id="configuring-winnt">
<Title>Configuring Windows NT</Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Go to <Emphasis role="strong">'Control Panel'</Emphasis> --&#62;
<Emphasis role="strong">'Network'</Emphasis> --&#62;
<Emphasis role="strong">Protocols</Emphasis>
</para>
</listitem>
<listitem>
<para>
Add the TCP/IP Protocol and related Components from the <Emphasis role="strong">
'Add Software'</Emphasis> menu if you don't have TCP/IP service installed
already.
</para>
</listitem>
<listitem>
<para>
Under <Emphasis role="strong">'Network Software and Adapter Cards'</Emphasis>
section, highlight the <Emphasis role="strong">'TCP/IP Protocol'</Emphasis> in
the <Emphasis role="strong">'Installed Network Software'</Emphasis> selection
box.
</para>
</listitem>
<listitem>
<para>
In <Emphasis role="strong">'TCP/IP Configuration'</Emphasis>, select the
appropriate adapter, e.g. <Literal>[1]Intel EtherExpress Pro/100+</Literal>.
Then set the IP Address to 192.168.0.x (1 &lt; x &lt; 255), then set the Subnet
Mask to 255.255.255.0 and Default Gateway to 192.168.0.1.
</para>
</listitem>
<listitem>
<para>
Do not enable any of the following options (unless you know what you are doing):
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">'Automatic DHCP Configuration'</Emphasis> : Unless you
have a DHCP server running on your network.
</para>
</listitem>
<listitem>
<para>
Put anything in the <Emphasis role="strong">'WINS Server'</Emphasis> input
areas : Unless you have setup one or more WINS servers.
</para>
</listitem>
<listitem>
<para>
<Emphasis role="strong">Enable IP Forwardings</Emphasis> : Unless you are
routing on your NT machine and really -REALLY- know EXACTLY what you're doing.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'DNS'</Emphasis>, fill in the appropriate
information that your Linux host uses (usually found in /etc/resolv.conf) and
then click <Emphasis role="strong">'OK'</Emphasis> when you're done.
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'Advanced'</Emphasis>, be sure to DISABLE
<Emphasis role="strong">'DNS for Windows Name Resolution'</Emphasis> and
<Emphasis role="strong">'Enable LMHOSTS lookup'</Emphasis> unless you known
what these options do. If you want to use a LMHOSTS file, it is stored in
C:\winnt\system32\drivers\etc.
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'OK'</Emphasis> on all dialog boxes and restart
the system.
</para>
</listitem>
<listitem>
<para>
<Literal>As an initial test, ping</Literal> the Linux MASQ server to test the
network connection: <Emphasis role="strong">'File/Run'</Emphasis>, type:
<Literal>ping 192.168.0.1</Literal>(This is only an INTERNAL LAN connection
test, you might not be able to <Literal>ping</Literal> the outside world
yet.) If you don't see any "replies" to your PINGs, please verify your network
configuration.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-wfwg">
<Title>Configuring Windows for Workgroup 3.11</Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Install the TCP/IP 32b package if you haven't already.
</para>
</listitem>
<listitem>
<para>
In <Emphasis role="strong">'Main'/'Windows Setup'/'Network Setup'</Emphasis>,
click on <Emphasis role="strong">'Drivers'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Highlight <Emphasis role="strong">'Microsoft TCP/IP-32 3.11b'</Emphasis> in
the <Emphasis role="strong">'Network Drivers'</Emphasis> section, click
<Emphasis role="strong">'Setup'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Set the IP Address to 192.168.0.x (1 &lt; x &lt; 255), then set the Subnet
Mask to 255.255.255.0 and Default Gateway to 192.168.0.1
</para>
</listitem>
<listitem>
<para>
Do not enable any of the following options (unless you know what you are
doing):
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">'Automatic DHCP Configuration'</Emphasis> : Unless you
have a DHCP server running on your network.
</para>
</listitem>
<listitem>
<para>
Put anything in the <Emphasis role="strong">'WINS Server'</Emphasis> input
areas : Unless you have setup one or more WINS servers.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'DNS'</Emphasis>, fill in the appropriate
information your Linux host uses (usually found in /etc/resolv.conf). Then
click <Emphasis role="strong">'OK'</Emphasis> when you're done with it.
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'Advanced'</Emphasis>, check
<Emphasis role="strong">'Enable DNS for Windows Name Resolution'</Emphasis>
and <Emphasis role="strong">'Enable LMHOSTS lookup'</Emphasis> found in
c:\windows.</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'OK'</Emphasis> in all dialog boxes and restart
the system.
</para>
</listitem>
<listitem>
<para>
As an initial test, <Literal>ping</Literal> the linux box to test the network
connection: <Emphasis role="strong">'File/Run'</Emphasis>, type: <Literal>ping
192.168.0.1</Literal> (This is only an INTERNAL LAN connection test so you might
not be able to <Literal>ping</Literal> the outside world yet.) If you don't
see "replies" to your PINGs, please verify your network configuration.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-unix">
<Title>Configuring UNIX Based Systems</Title>
<para>
<OrderedList>
<listitem>
<para>
If you haven't installed your network card and either re-configured the network
subsystem 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.
<!-- Blah . Add URL to the Networking HOWTO -->
</para>
</listitem>
<listitem>
<para>
Install TCP/IP networking, such as the net-tools package, if you don't have it
already.
</para>
</listitem>
<listitem>
<para>
Set <Emphasis role="strong">IPADDR</Emphasis> to 192.168.0.x (1 &lt; x &lt;
255), then set <Emphasis role="strong">NETMASK</Emphasis> to 255.255.255.0,
<Emphasis role="strong">GATEWAY</Emphasis> to 192.168.0.1, and <Emphasis
role="strong">BROADCAST</Emphasis> to 192.168.0.255.
</para>
<ItemizedList>
<listitem>
<para>Redhat (Mandrake / TurboLinux / etc): You can edit the
<Literal>/etc/sysconfig/network-scripts/ifcfg-eth0</Literal> file, or simply do so
through the Control Panel (Linuxconf).
</para>
</listitem>
<listitem>
<para>Slackware: You need to edit the /etc/rc.d/rc.inet1 file to configure
the network subsystem.
</para>
</listitem>
<listitem>
<para>To Add: Debian, Suse, Caldera, etc. Please email dranch@trinnet.net
if you can tell me what distro uses what files to configure the networking
subsystem.
</para>
</listitem>
</ItemizedList>
<para>
Beyond this, most Linux distributions use significantly different network
configuration mechanisms let alone other UNIXes such as SunOS, BSDi, Solaris,
AIX, TruUnix, FreeBSD, etc.). Please refer to your specific UNIX
documentation for more details.
</para>
</listitem>
<listitem>
<para>
Add your domain name service (DNS) and domain search suffix in
<Literal>/etc/resolv.conf</Literal> and for the appropreiate UNIX versions,
edit the /etc/nsswitch.conf file to enable DNS services.
</para>
</listitem>
<listitem>
<para>
You may also want to update your <Literal>/etc/networks</Literal> file
depending on your version of UNIX and the system's settings.
</para>
</listitem>
<listitem>
<para>
Restart the appropriate services, or simply restart your system.
</para>
</listitem>
<listitem>
<para>
As an initial test, run the <Literal>ping</Literal> command: <Literal>ping
192.168.0.1</Literal> to test the connection to your gateway machine.
(This is only an INTERNAL LAN connection test, so you might not be able to
<Literal>ping</Literal> the outside world yet.) If you don't see "replies" to
your PINGs, please verify your network configuration.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-dos">
<Title>Configuring DOS using NCSA Telnet package</Title>
<para>
<OrderedList>
<listitem>
<para>
If you haven't installed your network card, do so now. Descriptions to
perform this task is beyond the scope of this document.
</para>
</listitem>
<listitem>
<para>
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
<Literal>nwpd 0x60 10 0x300</Literal>
</para>
</listitem>
<listitem>
<para>
Make a new directory, and then unpack the NCSA Telnet package:
<Literal>pkunzip tel2308b.zip</Literal>
</para>
</listitem>
<listitem>
<para>
Use a text editor to open the <Literal>config.tel</Literal> file
</para>
</listitem>
<listitem>
<para>
Set <Literal>myip=192.168.0.x</Literal> (1 &lt; x &lt; 255), and
netmask=255.255.255.0
</para>
</listitem>
<listitem>
<para>
In this example, you should set <Literal>hardware=packet, interrupt=10,
ioaddr=60</Literal>
</para>
</listitem>
<listitem>
<para>
You should have at least one individual machine specified as the gateway,
i.e. the Linux host:
</para>
<para>
<screen>
name=default
host=yourlinuxhostname
hostip=192.168.0.1
gateway=1
</screen>
</para>
</listitem>
<listitem>
<para>
Have another specified as a domain name service:
</para>
<para>
<screen>
name=dns.domain.com ; hostip=123.123.123.123; nameserver=1
</screen>
</para>
<para>
Note: substitute the appropriate information about the DNS according what your
Linux host uses
</para>
</listitem>
<listitem>
<para>
Save your <Literal>config.tel</Literal> file
</para>
</listitem>
<listitem>
<para>
As an initial test, <Literal>ping</Literal> the Linux MASQ server to test the
network connection: <Literal>ping 192.168.0.1</Literal> If you don't receive
any replies, please verify your network configuration.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-mactcp">
<Title>Configuring MacOS Based System Running MacTCP</Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Open the <Emphasis role="strong">MacTCP control panel</Emphasis>. Select the
appropriate network driver (Ethernet, NOT EtherTalk) and click on the
<Emphasis role="strong">'More...'</Emphasis> button.
</para>
</listitem>
<listitem>
<para>
Under <Emphasis role="strong">'Obtain Address:'</Emphasis>, click
<Emphasis role="strong">'Manually'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Under <Emphasis role="strong">'IP Address:'</Emphasis>, select
<Emphasis role="strong">class C</Emphasis> from the popup menu. Ignore the
rest of the dialog box sections.
</para>
</listitem>
<listitem>
<para>
Fill in the appropriate information under <Emphasis role="strong">'Domain
Name Server Information:'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Under <Emphasis role="strong">'Gateway Address:'</Emphasis>, enter 192.168.0.1
</para>
</listitem>
<listitem>
<para>
Click <Emphasis role="strong">'OK'</Emphasis> to save the settings. In the
main window of the <Emphasis role="strong">MacTCP control panel</Emphasis>,
enter the IP address of your Mac (192.168.0.x, 1 &#60; x &#60; 255) in the
<Emphasis role="strong">'IP Address:'</Emphasis> box.
</para>
</listitem>
<listitem>
<para>
Close the <Emphasis role="strong">MacTCP control panel</Emphasis>. If a
dialog box pops up, notifying you to do so, then restart the system.
</para>
</listitem>
<listitem>
<para>
You may optionally ping the Linux box to test the network connection. If
you have the freeware program <Emphasis role="strong">MacTCP Watcher</Emphasis>
, click on the <Emphasis role="strong">'Ping'</Emphasis> 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.
</para>
</listitem>
<listitem>
<para>
You can optionally create a <Literal>Hosts</Literal> file in your System Folder
so that you can use the hostnames of the machines on your LAN. The file should
already exist in your System Folder, and should contain some (commented-out)
sample entries which you can modify according to your needs.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-opentransport">
<Title>Configuring MacOS Based System Running Open Transport </Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Open the <Emphasis role="strong">TCP/IP Control Panel</Emphasis> and choose
<Emphasis role="strong">'User Mode ...'</Emphasis> from the <Emphasis
role="strong">Edit</Emphasis> menu. Make sure the user mode is set to at
least <Emphasis role="strong">'Advanced'</Emphasis> and click the <Emphasis
role="strong">'OK'</Emphasis> button.
</para>
</listitem>
<listitem>
<para>
Choose <Emphasis role="strong">'Configurations...'</Emphasis> from the
<Emphasis role="strong">File</Emphasis> menu. Select your
<Emphasis role="strong">'Default'</Emphasis> configuration and click the
<Emphasis role="strong">'Duplicate...'</Emphasis> button. Enter 'IP Masq'
(or something to let you know that this is a special configuration) in the
<Emphasis role="strong">'Duplicate Configuration'</Emphasis> dialog, it
will probably say something like <Emphasis role="strong">'Default copy'
</Emphasis>. Then click the <Emphasis role="strong">'OK'</Emphasis> button,
and the <Emphasis role="strong">'Make Active'</Emphasis> button
</para>
</listitem>
<listitem>
<para>
Select <Emphasis role="strong">'Ethernet'</Emphasis> from the
<Emphasis role="strong">'Connect via:'</Emphasis> pop-up.
</para>
</listitem>
<listitem>
<para>
Select the appropriate item from the <Emphasis role="strong">'Configure:'
</Emphasis> pop-up. If you don't know which option to choose, you probably
should re-select your <Emphasis role="strong">'Default'</Emphasis>
configuration and quit. I use <Emphasis role="strong">'Manually'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Enter the IP address of your Mac (192.168.0.x, 1 &#60; x &#60; 255) in the
<Emphasis role="strong">'IP Address:'</Emphasis> box.
</para>
</listitem>
<listitem>
<para>
Enter 255.255.255.0 in the <Emphasis role="strong">'Subnet mask:'</Emphasis>
box.
</para>
</listitem>
<listitem>
<para>
Enter 192.168.0.1 in the <Emphasis role="strong">'Router address:'</Emphasis>
box.
</para>
</listitem>
<listitem>
<para>
Enter the IP addresses of your domain name servers in the
<Emphasis role="strong">'Name server addr.:'</Emphasis> box.
</para>
</listitem>
<listitem>
<para>
Enter the name of your Internet domain (e.g. 'microsoft.com') in the
<Emphasis role="strong">'Starting domain name'</Emphasis> box under
<Emphasis role="strong">'Implicit Search Path:'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
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.
</para>
<para>
Check the <Emphasis role="strong">'802.3'</Emphasis> if your network requires
802.3 frame types.
</para>
</listitem>
<listitem>
<para>
Click the <Emphasis role="strong">'Options...'</Emphasis> button to make
sure that the TCP/IP is active. I use the <Emphasis role="strong">'Load
only when needed'</Emphasis> option. If you continuously run and quit
TCP/IP applications without rebooting your machine, you may find that
unchecking the <Emphasis role="strong">'Load only when needed'</Emphasis>
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.
</para>
</listitem>
<listitem>
<para>
You may ping the Linux box to test the network connection. If you have the
freeware program <Emphasis role="strong">MacTCP Watcher</Emphasis>, click on the
<Emphasis role="strong">'Ping'</Emphasis> 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.
</para>
</listitem>
<listitem>
<para>
You can optionally create a <Literal>Hosts</Literal> file in your System Folder
so that you can use the hostnames of the machines on your LAN. The file may
or may not already exist in your System Folder. If so, it should contain some
(commented-out) sample entries which you can modify according to your needs.
If not, you can get a copy of the file from a system running MacTCP, or just
create your own (it follows a subset of the Unix <Literal>/etc/hosts</Literal>
file format, described on RFC1035). Once you've created the file, open the
<Emphasis role="strong">TCP/IP control panel</Emphasis>, click on the
<Emphasis role="strong">'Select Hosts File...'</Emphasis> button, and open the
<Literal>Hosts</Literal> file.
</para>
</listitem>
<listitem>
<para>
Click the close box or choose <Emphasis role="strong">'Close'</Emphasis> or
<Emphasis role="strong">'Quit'</Emphasis> from the <Emphasis role="strong">File
</Emphasis> menu, and then click the <Emphasis role="strong">'Save'</Emphasis>
button to save the changes you have made.
</para>
</listitem>
<listitem>
<para>
The changes take effect immediately, but rebooting the system won't hurt.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-novell">
<Title>Configuring Novell network using DNS</Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Downloaded tcpip16.exe from
<ULink URL="ftp.novell.com/">The Novell LanWorkPlace
page</ULink>
</para>
</listitem>
<listitem>
<para>
<screen>
edit c:\nwclient\startnet.bat: (here is a copy of mine)
SET NWLANGUAGE=ENGLISH
LH LSL.COM
LH KTC2000.COM
LH IPXODI.COM
LH tcpip
LH VLM.EXE
F:
</screen>
</para>
</listitem>
<listitem>
<para>
<screen>
edit c:\nwclient\net.cfg: (change link driver to yours i.e. NE2000)
Link Driver KTC2000
Protocol IPX 0 ETHERNET_802.3
Frame ETHERNET_802.3
Frame Ethernet_II
FRAME Ethernet_802.2
NetWare DOS Requester
FIRST NETWORK DRIVE = F
USE DEFAULTS = OFF
VLM = CONN.VLM
VLM = IPXNCP.VLM
VLM = TRAN.VLM
VLM = SECURITY.VLM
VLM = NDS.VLM
VLM = BIND.VLM
VLM = NWP.VLM
VLM = FIO.VLM
VLM = GENERAL.VLM
VLM = REDIR.VLM
VLM = PRINT.VLM
VLM = NETX.VLM
Link Support
Buffers 8 1500
MemPool 4096
Protocol TCPIP
PATH SCRIPT C:\NET\SCRIPT
PATH PROFILE C:\NET\PROFILE
PATH LWP_CFG C:\NET\HSTACC
PATH TCP_CFG C:\NET\TCP
ip_address 192.168.0.xxx
ip_router 192.168.0.1
Change the IP address in the above "ip_address" field (192.168.0.x, 1 &#60; x
&#60; 255) and finally create c:\bin\resolv.cfg:
SEARCH DNS HOSTS SEQUENTIAL
NAMESERVER xxx.xxx.xxx.xxx
NAMESERVER yyy.yyy.yyy.yyy
</screen>
</para>
</listitem>
<listitem>
<para>
Now edit the above "NAMESERVER" entries and replace them with the correct
IP addresses for your local DNS server.
</para>
</listitem>
<listitem>
<para>
Issue a <Literal>ping</Literal> command: <Literal>ping 192.168.0.1</Literal>
to test the connection to your gateway machine. (This is only an INTERNAL
LAN connection test, you can't <Literal>ping</Literal> the outside world yet.)
If you don't see "replies" to your PINGs, please verify your network
configuration.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-os2">
<Title>Configuring OS/2 Warp</Title>
<para>
<OrderedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Install the TCP/IP protocol if you don't have it already.
</para>
</listitem>
<listitem>
<para>
Go to <Emphasis role="strong">Programs/TCP/IP (LAN) / TCP/IP</Emphasis>
Settings
</para>
</listitem>
<listitem>
<para>
In <Emphasis role="strong">'Network'</Emphasis>, add your TCP/IP Address
(192.168.0.x) and set your netmask (255.255.255.0)
</para>
</listitem>
<listitem>
<para>
Under <Emphasis role="strong">'Routing'</Emphasis>, press
<Emphasis role="strong">'Add'</Emphasis>. Set the <Emphasis role="strong">
Type</Emphasis> to <Emphasis role="strong">'default'</Emphasis> and type the
IP Address of your Linux Box in the Field <Emphasis role="strong">'Router
Address'</Emphasis>. (192.168.0.1).
</para>
</listitem>
<listitem>
<para>
Set the same DNS (Nameserver) Address that your Linux host uses in
<Emphasis role="strong">'Hosts'</Emphasis>.
</para>
</listitem>
<listitem>
<para>
Close the TCP/IP control panel. Say yes to the following question(s).
</para>
</listitem>
<listitem>
<para>
Reboot your system
</para>
</listitem>
<listitem>
<para>
You may ping the Linux box to test the network configuration. Type
<Literal>'ping 192.168.0.1'</Literal> in a 'OS/2 Command prompt Window'. When
ping packets are received all is ok.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="configuring-os400">
<Title>Configuring OS/400 on a IBM AS/400</Title>
<para>
The descriptions to configure TCP/IP on OS/400 version V4R1M0 running on a
AS/400 is beyond the scope of this document.
</para>
<para>
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.
</para>
<para>
2) Type GO CFGTCP command th reach the Configure TCP/IP menu.
</para>
<para>
3) Select Option 2 - Work with TCP/IP Routes.
</para>
<para>
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)
</para>
</Sect1>
<Sect1 id="configuring-other">
<Title>Configuring Other Systems</Title>
<para>
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
<ULink URL="mailto:ambrose@writeme.com">ambrose@writeme.com</ULink> and
<ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink>.
</para>
</Sect1>
</Chapter>
<!-- Section 5 -->
<Chapter id="Testing">
<Title>Testing IP Masquerade </Title>
<para>
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.
</para>
<para>
Follow these -11- tests to make sure all aspects of your MASQ setup is
running properly:
</para>
<Sect1 id="loading-rc.firewall">
<Title>Loading up the rc.firewall ruleset</Title>
<para>
Step One: run the correct firewall for your machine via command
"/etc/rc.d/rc.firewall-[iptables / ipchains /ipfwadm]". For example, Linux
2.6 users would run "/etc/rc.d/rc.firewall-iptables"
</para>
<para>
Does it load with some strange errors? Here are some exmaples and help to fix
them:
<ItemizedList>
<listitem>
<para>
Problem #1:
</para>
<para>
<screen>
ip_tables, Using /lib/modules/2.4.2-2/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.2-2/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device
or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including
invalid IO or IRQ parameters
</screen>
</para>
<para>
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.
</para>
<para>
To disable this from happening in the future, run the command:
<screen>
chkconfig --level=2345 ipchains off
</screen>
</para>
<para>
To remove the "ipchains" module without rebooting, run the command:
<screen>
/sbin/rmmod ipchains
</screen>
and the re-try to load the rc.firewall-* ruleset.
</para>
</listitem>
<listitem>
<para>
Problem #2:
</para>
<para>
<screen>
.
.
Creating a DROP chain..
iptables v1.2.3: log-level `info' ambiguous
.
.
</screen>
</para>
<para>
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
<XRef LinkEnd="kernel-2.4.x-Requirements"> section.
</para>
</listitem>
<listitem>
<para>
Problem #3:
</para>
<para>
<screen>
No such file:
</screen>
</para>
<para>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.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-the-masqed-pc">
<Title>Testing internal MASQ client PC connectivity</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Two: Testing internal MASQ client PC connectivity
</Emphasis>
</para>
<para>
From an internal MASQed computer, try pinging its local IP address (i.e.
<Emphasis role="strong">ping 192.168.0.10 </Emphasis>). 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 <XRef LinkEnd="Configuring-clients"> of this HOWTO. The
output should look something like the following (hit Control-C to abort the
ping):
</para>
<para>
<ProgramListing>
------------------------------------
masq-client# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 192.168.0.10 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
------------------------------------
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masqed-pc-to-masq-server">
<Title>Testing internal MASQ client to MASQ server connectivity</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Three: Testing internal MASQ client to MASQ server
connectivity</Emphasis>
</para>
<para>
Next, from the same internal MASQed computer, try pinging the IP address of
the Linux MASQ server's INTERNAL interface (i.e. <Emphasis role="strong">ping
192.168.0.1 </Emphasis>). 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 section
for your
2.4.x kernel in <XRef LinkEnd="kernel-2.4.x-Requirements">,
2.2.x kernel in <XRef LinkEnd="kernel-2.2.x-Requirements">, or
2.0.x kernel in <XRef LinkEnd="kernel-2.0.x-Requirements">).
The output should
look something like the following (hit Control-C to abort the ping):
</para>
<para>
<ProgramListing>
------------------------------------
masq-client# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
------------------------------------
</ProgramListing>
</para>
<para>
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 be
found 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 of
packet 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 how
many people I've helped have found that their NIC cards were going bad and
caused them all kinds of grief.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-server-internal">
<Title>Testing internal MASQ server connectivity</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Four: Testing internal MASQ server connectivity
</Emphasis>
</para>
<para>
On the MASQ server, ping the internal IP address of the MASQ server's network
interface card (i.e. <Emphasis role="strong">ping 192.168.0.1</Emphasis>).
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 your
2.4.x kernel in <XRef LinkEnd="kernel-2.4.x-Requirements">,
2.2.x kernel in <XRef LinkEnd="kernel-2.2.x-Requirements">, or
2.0.x kernel in <XRef LinkEnd="kernel-2.0.x-Requirements">). The output
should look something like the following (hit Control-C to abort the ping):
</para>
<para>
<ProgramListing>
--------------------------------------
masq-server# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
---------------------------------------
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-server-to-masqed-pc">
<Title>Testing internal MASQ server to MASQ client connectivity</Title>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Five: Testing internal MASQ server to MASQ client
connectivity</Emphasis>
</para>
<para>
Next from MASQed server, try pinging the IP address of one of the internal
MASQ client computers (i.e. <Emphasis role="strong">ping 192.168.0.10
</Emphasis>). 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 <XRef LinkEnd="Configuring-clients"> of this HOWTO.
Also be sure that the cabling is correct (Ethernet: the NICs connecting the
internal MASQ PC and the MASQ server have the "link" light lit up).
If the ping does work, the output should look something like the following
(hit Control-C to abort the ping):
</para>
<para>
<ProgramListing>
------------------------------------
masq-server# ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 192.168.0.10: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 192.168.0.10: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 192.168.0.10: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 192.168.0.10 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
------------------------------------
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</Sect1>
<Sect1 id="testing-masq-server-external">
<Title>Testing External MASQ server Internet connectivity</Title>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Six: Testing external MASQ server to Internet
connectivity</Emphasis
</para>
<para>
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
<Emphasis role="strong">"/sbin/ifconfig"</Emphasis> 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):
</para>
<para>
<ProgramListing>
------------------------------------
eth0 Link encap:Ethernet HWaddr 00:08:C7:A4:CC:5B
inet addr:12.13.14.15 Bcast:12.13.14.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6108459 errors:0 dropped:0 overruns:0 frame:0
TX packets:5422798 errors:8 dropped:0 overruns:0 carrier:8
collisions:4675 txqueuelen:100
Interrupt:11 Base address:0xfcf0
------------------------------------
</ProgramListing>
</para>
<para>
As you can see from the above, the external IP address is "12.13.14.15" for
this 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):
</para>
<para>
<ProgramListing>
-------------------------------------
masq-server# ping 12.13.14.15
PING 12.13.14.15 (12.13.14.15): 56 data bytes
64 bytes from 12.13.14.15: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 12.13.14.15: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 12.13.14.15: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 12.13.14.15: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 12.13.14.15 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
-------------------------------------
</ProgramListing>
</para>
<para>
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:
</para>
<para>
<ProgramListing>
-------------------------------------
.
.
PPP: version 2.3.7 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
3c59x.c:v0.99H 11/17/98 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/
vortex.html
eth0: 3Com 3c905 Boomerang 100baseTx at 0xfe80, 00:60:08:a7:4e:0e, IRQ 9
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 786f.
Enabling bus-master transmits and whole-frame receives.
eth1: 3Com 3c905 Boomerang 100baseTx at 0xfd80, 00:60:97:92:69:f8, IRQ 9
8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
MII transceiver found at address 24, status 7849.
Enabling bus-master transmits and whole-frame receives.
Partition check:
sda: sda1 sda2 &#60; sda5 sda6 sda7 sda8 &#62;
sdb:
.
.
-------------------------------------
</ProgramListing>
</para>
<para>
Also be sure that the cabling is correct (Ethernet: the NICs connecting the
external MASQ server to your ISP has the "link" light lit up). Finally, 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
your
2.4.x kernel in <XRef LinkEnd="kernel-2.4.x-Requirements">,
2.2.x kernel in <XRef LinkEnd="kernel-2.2.x-Requirements">, or
2.0.x kernel in <XRef LinkEnd="kernel-2.0.x-Requirements">).
</para>
</listitem>
</ItemizedList>
</Sect1>
<Sect1 id="testing-masqed-pc-to-ext-masq-server">
<Title>Testing internal MASQ client to external MASQ server connectivity</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Seven: Testing internal MASQ client to external MASQ
server connectivity</Emphasis>
</para>
<para>
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.
</para>
<para>
If everthing thing is working correctly, the output should look something
like the following (hit Control-C to abort the ping):
</para>
<para>
<ProgramListing>
-------------------------------------
masq-client# ping 12.13.14.15
PING 12.13.14.15 (12.13.14.15): 56 data bytes
64 bytes from 12.13.14.15: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 12.13.14.15: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 12.13.14.15: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 12.13.14.15: icmp_seq=3 ttl=255 time=0.5 ms
^C
--- 12.13.14.15 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.5/0.8 ms
-------------------------------------
</ProgramListing>
</para>
<para>
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.
</para>
<para>
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:
<ItemizedList>
<listitem>
<para>
"<Emphasis role="strong">ifconfig</Emphasis>" : 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.
</para>
</listitem>
<listitem>
<para>
"<Emphasis role="strong">netstat -rn</Emphasis>" : 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:
<ProgramListing>
-------------------------------------
masq-server# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 16384 0 eth1
12.13.14.15 0.0.0.0 255.255.255.255 UH 0 16384 0 eth0
12.13.14.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 16384 0 lo
0.0.0.0 12.13.14.1 0.0.0.0 UG 0 16384 0 eth0
-------------------------------------
</ProgramListing>
Notice the very LAST line that starts with 0.0.0.0? Notice that it also has
an IP address in the "Gateway" field? You should specify an IP address for
your specific setup in that field (this is typically done automatically when
your Internet connection is enabled).
</para>
</listitem>
<listitem>
<para>
"<Emphasis role="strong">cat /proc/sys/net/ipv4/ip_forward</Emphasis>" : Make
sure it says "1" so that Linux forwarding is enabled
</para>
</listitem>
<!-- Blah. Add the command for IPTABLES -->
<listitem>
<para>
Run the command "<Emphasis role="strong">/sbin/ipchains -n -L</Emphasis>" for
2.2.x users or "<Emphasis role="strong">/sbin/ipfwadm -F -l</Emphasis>" 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:
<ProgramListing>
------------------------------------
.
.
Chain forward (policy REJECT):
target prot opt source destination ports
MASQ all ------ 192.168.0.0/24 0.0.0.0/0 n/a
ACCEPT all ----l- 0.0.0.0/0 0.0.0.0/0 n/a
.
.
------------------------------------
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-icmp">
<Title>Testing external MASQ ICMP forwarding </Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Eight: Testing external MASQ ICMP forwarding</Emphasis>
</para>
<para>
From an internal MASQed computer, ping a static TCP/IP address (NOT a
machine by DNS name) out on the Internet (i.e. <Emphasis role="strong">ping
152.2.210.80</Emphasis> (this technically the DNS name "metalab.unc.edu" which
is home of MetaLabs' Linux Archive). If this works, it should look something
like the result below and this ultimately shows that ICMP Masquerading is
working properly. (hit Control-C to abort the ping):
</para>
<para>
<ProgramListing>
-------------------------------------
masq-client# ping 152.2.210.80
PING 12.13.14.15 (152.2.210.80): 56 data bytes
64 bytes from 152.2.210.80: icmp_seq=0 ttl=255 time=133.4 ms
64 bytes from 152.2.210.80: icmp_seq=1 ttl=255 time=132.5 ms
64 bytes from 152.2.210.80: icmp_seq=2 ttl=255 time=128.8 ms
64 bytes from 152.2.210.80: icmp_seq=3 ttl=255 time=132.2 ms
^C
--- 152.2.210.80 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 128.8/131.7/133.4 ms
-------------------------------------
</ProgramListing>
</para>
<para>
If this didn't work, again check your Internet connection. Make sure that
the 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.
</para>
<para>Finally, make sure that the ruleset which enables IP MASQ is pointing
to the correct EXTERNAL interface. PPPoE users should use the MASQ servers's
logical PPP interface such as "ppp0" and /NOT/ the physical external interface
like "eth0".
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-wo-dns">
<Title>Testing MASQ functionality without DNS</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Nine: Testing MASQ functionality without DNS</Emphasis>
</para>
<para>
Now try TELNETing to a remote IP address (i.e. <Emphasis role="strong">telnet
152.2.210.81</Emphasis> ( 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):
<ProgramListing>
--------------------------------
masq-client# telnet 152.2.210.80
Trying 152.2.210.80...
Connected to 152.2.210.80.
Escape character is '^]'.
SunOS 5.7
******************** Welcome to MetaLab.unc.edu *******************
To login to MetaLab as a user, connect to login.metalab.unc.edu.
This machine does not allow public telnet logins.
login: Connection closed by foreign host.
--------------------------------
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-w-dns">
<Title>Testing MASQ functionality with DNS resolution</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Ten: Testing MASQ functionality with DNS
resolution
</Emphasis>
</para>
<para>
Now try TELNETing to a remote machine by DNS name (i.e. <Emphasis
role="strong">"telnet metalab.unc.edu"</Emphasis> (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.
</para>
<para>
<ProgramListing>
--------------------------------
masq-client# telnet MetaLab.unc.edu
Trying 152.2.210.80...
Connected to 152.2.210.80.
Escape character is '^]'.
SunOS 5.7
******************** Welcome to MetaLab.unc.edu *******************
To login to MetaLab as a user, connect to login.metalab.unc.edu.
This machine does not allow public telnet logins.
login: Connection closed by foreign host.
--------------------------------
</ProgramListing>
</para>
<para>
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 <XRef LinkEnd="Configuring-clients">. Please note
that these DNS servers will typically be your ISP's DNS servers and NOT your
local MASQ server. Some people might later choose to setup their OWN DNS
servers but this is beyond the scope of this HOWTO.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-masq-w-dns-extended">
<Title>Testing more MASQ functionality with DNS</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Eleven: Testing more MASQ functionality with DNS</Emphasis>
</para>
<para>
As a last test, try browsing some <Emphasis role="strong">'INTERNET'</Emphasis>
WWW sites on one of your <Emphasis role="strong">MASQ Client</Emphasis>
machines, and see if you can reach them. For example, access the
Linux Documentation Project site at <ULink URL="http://www.tldp.org">
http://www.tldp.org</ULink>. If you are successful in bringing up that
page, you can be fairly certain that everything is working FINE! If some WWW
or FTP sites have problems, where other sites seem to work just fine, see the
next step for more ideas.
</para>
<para>
If you see The Linux Documentation Project homepage, then
<Emphasis role="strong">CONGRATULATIONS! It's working!</Emphasis> 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).
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="testing-final-tests">
<Title>Any remaining functional, performance, etc. issues...</Title>
<para>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">Step Twelve: Any remaining functional, performance,
etc. issues...</Emphasis>
</para>
<para>
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
<XRef LinkEnd="MTU-issues"> FAQ entry. There might be other items in the FAQ
section that will also help you as they have helped many other users in the
past.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
</Chapter>
<Chapter id="ipmasq-support-portfw-and-stronger-rulesets">
<Title>Other IP Masquerade Issues and Software Support </Title>
<Sect1 id="ipmasq-problems">
<Title>Problems with IP Masquerade </Title>
<para>
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.
</para>
</Sect1>
<Sect1 id="incoming-services">
<Title>Incoming services </Title>
<para>
By default, Linux IP Masquerading cannot handle incoming services at all but
there are a few ways that would allow this.
</para>
<para>
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
<XRef LinkEnd="Forwarders">.
</para>
<para>
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.
</para>
<para>
More details on incoming security can be found in the <ULink
URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS</ULink> document and at <ULink URL="http://ipmasq.webhop.net">IP
Masquerade Resource</ULink>.
</para>
</Sect1>
<Sect1 id="Supported-Client-Software">
<Title>Supported Client Software and Other Setup Notes</Title>
<para>
<quote><Emphasis role="strong">** The
<ULink URL="http://www.tsmservices.com/masq/">Linux Masquerade Application
list</ULink> has a lot of good information regarding applications that work
through Linux IP masquerading. This site was recently taken over by Steve
Grevemeyer, who implemented it with a full database backend. It's a great
resource! </Emphasis></quote>
</para>
<para>
Generally, any application that uses standard TCP and UDP should work. If
you have any suggestion, hints, etc., please see the
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resource</ULink> for more
details.
</para>
<Sect2 id="Game-Clients">
<Title>Network Clients that -Work- with IP Masquerade</Title>
<para>
General Clients:
</para>
<para>
<VariableList>
<VarListEntry>
<Term>Archie</Term>
<listitem>
<para>
all supported platforms, file searching client (not all archie clients are
supported)
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>FTP</Term>
<listitem>
<para>
all supported platforms, with the
<Emphasis role="strong">ip_masq_ftp.o</Emphasis> kernel module for active
FTP connections.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Gopher client</Term>
<listitem>
<para>
all supported platforms
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>HTTP</Term>
<listitem>
<para>
all supported platforms, WWW surfing
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>IRC</Term>
<listitem>
<para>
all IRC clients on various supported platforms, DCC is supported via the
<Emphasis role="strong">ip_masq_irc.o</Emphasis> module
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>NNTP (USENET)</Term>
<listitem>
<para>
all supported platforms, USENET news client
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>PING</Term>
<listitem>
<para>
all platforms, with ICMP Masquerading kernel option
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>POP3</Term>
<listitem>
<para>
all supported platforms, email clients
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>SSH</Term>
<listitem>
<para>
all supported platforms, Secure TELNET/FTP clients
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>SMTP</Term>
<listitem>
<para>
all supported platforms, email servers like Sendmail, Qmail, PostFix, etc.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>TELNET</Term>
<listitem>
<para>
all supported platforms, remote session
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>TRACEROUTE</Term>
<listitem>
<para>
UNIX and Windows based platforms, some variations may not work
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>VRML</Term>
<listitem>
<para>
Windows(possibly all supported platforms), virtual reality surfing
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>WAIS client</Term>
<listitem>
<para>
all supported platforms
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
<para>
Multimedia and Communication Clients:
</para>
<para>
<VariableList>
<VarListEntry>
<Term>All H.323 programs</Term>
<listitem>
<para>
- MS Netmeeting, Intel Internet Phone Beta , and other H.323 applications -
There are now two solutions to accomplish this through IPMASQed connections:
</para>
<para>
There is a stable BETA 2.2.x kernel module available on the
<ULink URL="http://ipmasq.webhop.net">MASQ WWW site</ULink> or at
<ULink URL="http://www.coritel.it/projects/nat/implementation.htm">
http://www.coritel.it/projects/nat/implementation.htm</ULink> to work with
Microsoft Netmeeting v3.x code on 2.2.x kernels. There is also another module
version on the MASQ WWW site specifically for Netmeeting 2.x with 2.0.x
kernels, but this does not support Netmeeting v3.x.
</para>
<para>
Another commercial solution is the
<ULink URL="http://www.equival.com.au/phonepatch/index.html">Equivalence's
PhonePatch</ULink> H.323 gateway.
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
<para>
<VariableList>
<VarListEntry>
<Term>Alpha Worlds</Term>
<listitem>
<para>
Windows, Client-Server 3D chat program
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>CU-SeeMe</Term>
<listitem>
<para>
all supported platforms, with the <Emphasis role="strong">ip_masq_cuseeme
</Emphasis> module loaded, please see <XRef LinkEnd="CuSeeme"> for more
details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>ICQ</Term>
<listitem>
<para>
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 have
a SOCKS proxy running. A full description of this configuration is in
<XRef LinkEnd="ICQ">.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Internet Phone 3.2</Term>
<listitem>
<para>
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 <XRef LinkEnd="Forwarders">for more details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Internet Wave Player</Term>
<listitem>
<para>
Windows, network streaming audio
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Powwow</Term>
<listitem>
<para>
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 <XRef LinkEnd="Forwarders">for more
details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Real Audio Player</Term>
<listitem>
<para>
Windows, network streaming audio, higher quality available with the
<Emphasis role="strong">ip_masq_raudio</Emphasis> UDP module
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>True Speech Player 1.1b</Term>
<listitem>
<para>
Windows, network streaming audio
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>VDOLive</Term>
<listitem>
<para>
Windows, with the <Emphasis role="strong">ip_masq_vdolive</Emphasis> patch
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Worlds Chat 0.9a</Term>
<listitem>
<para>
Windows, Client-Server 3D chat program
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
<para>
Games - See <XRef LinkEnd="LooseUDP">for more details on the LooseUDP patch
</para>
<para>
<VariableList>
<VarListEntry>
<Term>Battle.net</Term>
<listitem>
<para>
Works but requires TCP ports 116, 118 and UDP port 6112 IPPORTFWed to the
client game machine. See <XRef LinkEnd="Forwarders">for more details. Please
note that FSGS and Bnetd servers still require IPPORTFW because they have not
been re-written to be NAT-friendly.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>BattleZone 1.4</Term>
<listitem>
<para>
Works with LooseUDP patch and new NAT-friendly -- email <ULink
URL="mailto:dranch@trinnet.net">David Ranch</ULink> for the .DLLs from
Activision
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Dark Reign 1.4</Term>
<listitem>
<para>
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112
IPPORTFWed to the game machine. See <XRef LinkEnd="Forwarders">for more
details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Diablo</Term>
<listitem>
<para>
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 <XRef LinkEnd="Forwarders">for more details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Heavy Gear 2</Term>
<listitem>
<para>
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port
6112 IPPORTFWed to the game machine. See <XRef LinkEnd="Forwarders">for more
details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Quake I/II/III</Term>
<listitem>
<para>
Works right out of the box but requires the
<Emphasis role="strong">ip_masq_quake</Emphasis> 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
<XRef LinkEnd="rc.firewall-ipfwadm"> and <XRef LinkEnd="rc.firewall-ipchains">
rulesets.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>StarCraft</Term>
<listitem>
<para>
Works with the LooseUDP patch, IPPORTFWing TCP, and UDP ports 6112 to the
internal MASQed game machine. See <XRef LinkEnd="Forwarders">for more
details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>WorldCraft</Term>
<listitem>
<para>
Works with LooseUDP patch
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
<para>
Other Clients:
</para>
<para>
<VariableList>
<VarListEntry>
<Term>Linux net-acct package</Term>
<listitem>
<para>
Linux, network administration-account package
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>NCSA Telnet 2.3.08</Term>
<listitem>
<para>
DOS, a suite containing telnet, ftp, ping, etc.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>PC-anywhere for Windows </Term>
<listitem>
<para>
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
<XRef LinkEnd="Forwarders">for more details.
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Socket Watch</Term>
<listitem>
<para>
uses NTP - network time protocol
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
</Sect2>
<Sect2>
<Title>Clients that do not have full support in IP MASQ:</Title>
<para>
<VariableList>
<VarListEntry>
<Term>Intel Streaming Media Viewer Beta 1</Term>
<listitem>
<para>
Cannot connect to server
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>Netscape CoolTalk</Term>
<listitem>
<para>
Cannot connect to opposite side
</para>
</listitem>
</VarListEntry>
<VarListEntry>
<Term>WebPhone</Term>
<listitem>
<para>
Cannot work at present (it makes invalid assumptions about addresses).
</para>
</listitem>
</VarListEntry>
</VariableList>
</para>
</Sect2>
</Sect1>
<Sect1 id="stronger-firewall-examples">
<Title>Stronger firewall rulesets to run after initial testing</Title>
<Sect2 id="rc.firewall-iptables-stronger">
<Title>Stronger IP Firewall (IPTABLES) rulesets </Title>
<para>
&lt;rc.firewall-iptables-stronger START&gt;
<screen>
#!/bin/sh
#
# rc.firewall-iptables-stronger
#
FWVER=0.88s
# An example of a stronger IPTABLES firewall with IP Masquerade
# support for 2.4.x kernels.
#
# Log:
#
# 0.88s - Updated the commands for dynamically addresses machines and
# to point to an expanded FAQ section for more information
#
# 0.87s - Removed the unused drop-and-logit chain as it was only later
# being deleted anyway
# 0.86s - Fixed a typo that had a preceeding ; instead of a #
# 0.85s - renamed from rc.firewall-2.4-stronger to rc.firewall-iptables-
# stronger to reflect this script works for all IPTABLES enabled
# platforms including 2.6.x kernels
# - fixed an incorrect /24 netmask for the INTIP variable
# - removed the unneeded SED variable
# 0.84s - Changed the defaults from 192.168.1.0 to 192.168.0.x to align
# with the rest of the IPMASQ howto
# 0.83s - Added additional comments to make PORTFW configs more obvious
# 0.82s - Added a special ICMP filter to work around a Netfilter security
# issue
# - renamed the drop-and-log-it rule to reject-and-log-it
# 0.81s - Added an additional comment in the INPUT section for NOT
# allowing all traffic in, but only select traffic
# 0.80s - Added a DISABLED ip_nat_irc kernel module section, changed the
# default of the ip_conntrack_irc to NOT load by default, and
# added additional kernel module comments
# 0.79s - ruleset now uses modprobe instead of insmod
# 0.78s - REJECT is not a legal policy yet; back to DROP
# 0.77s - Changed the default block behavior to REJECT not DROP
# 0.76s - Added a comment about the OPTIONAL WWW ruleset and a comment
# where to put optional PORTFW commands
# 0.75s - Added clarification that PPPoE users need to use
# "ppp0" instead of "eth0" for their external interface
# 0.74s - Changed the EXTIP command to work on NON-English distros
# 0.73s - Added comments in the output section that DHCPd is optional
# and changed the default settings to disabled
# 0.72s - Changed the filter from the INTNET to the INTIP to be
# stateful; moved the command VARs to the top and made the
# rest of the script to use them
# 0.70s - Added a disabled examples for allowing internal DHCP
# and external WWW access to the server
# 0.63s - Added support for the IRC module
# 0.62s - Initial version based upon the basic 2.4.x rc.firewall
echo -e "\nLoading rc.firewall-iptables-STRONGER - version $FWVER..\n"
# The location of various iptables and other shell programs
#
# If your Linux distribution came with a copy of iptables, most
# likely it is located in /sbin. If you manually compiled
# iptables, the default location is in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
#IPTABLES=/sbin/iptables
IPTABLES=/usr/local/sbin/iptables
#
LSMOD=/sbin/lsmod
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe
GREP=/bin/grep
AWK=/bin/awk
IFCONFIG=/sbin/ifconfig
#Setting the EXTERNAL and INTERNAL interfaces for the network
#
# Each IP Masquerade network needs to have at least one
# external and one internal network. The external network
# is where the natting will occur and the internal network
# should preferably be addressed with a RFC1918 private address
# scheme.
#
# For this example, "eth0" is external and "eth1" is internal"
#
# NOTE: If this doesnt EXACTLY fit your configuration, you must
# change the EXTIF or INTIF variables above. For example:
#
# If you are a PPPoE or analog modem user:
#
# EXTIF="ppp0"
#
EXTIF="eth0"
INTIF="eth1"
echo " External Interface: $EXTIF"
echo " Internal Interface: $INTIF"
echo " ---"
# Specify your Static IP address here or let the script take care of it
# for you.
#
# If you prefer to use STATIC addresses in your firewalls, un-# out the
# static example below and # out the dynamic line. If you don't care,
# just leave this section alone.
#
# If you have a DYNAMIC IP address, the ruleset already takes care of
# this for you. Please note that the different single and double quote
# characters and the script MATTER.
#
#
# PPP and DHCP (Cablemodem and DSL ) users:
# -----------------------------------------
# PPP: If you get your TCP/IP address via DHCP, **you will need ** to
# enable the # #ed out command below underneath the PPP section AND
# replace the word "eth0" with the name of your EXTERNAL Internet
# connection (ppp0, ippp0, etc) on the lines for "ppp-ip" and "extip".
#
# DHCP and PPP users: The remote DHCP or PPP server can and will change
# IP addresses on you over time. To deal with this, users should configure
# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime
# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry
# in the IPMASQ howto for full details on how to do this.
#
#
# Determine the external IP automatically:
# ----------------------------------------
#
# The following line will determine your external IP address. This
# line is somewhat complex and confusing but it will also work for
# all NON-English Linux distributions:
#
EXTIP="`$IFCONFIG $EXTIF | $AWK \
/$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
# For users who wish to use STATIC IP addresses:
#
# # out the EXTIP line above and un-# out the EXTIP line below
#
#EXTIP="your.static.PPP.address"
echo " External IP: $EXTIP"
echo " ---"
# Assign the internal TCP/IP network and IP address
INTNET="192.168.0.0/24"
INTIP="192.168.0.1/32"
echo " Internal Network: $INTNET"
echo " Internal IP: $INTIP"
echo " ---"
# Setting a few other local variables
#
UNIVERSE="0.0.0.0/0"
#======================================================================
#== No editing beyond this line is required for initial MASQ testing ==
# Need to verify that all modules have all required dependencies
#
echo " - Verifying that all kernel modules are ok"
$DEPMOD -a
echo -en " Loading kernel modules: "
# With the new IPTABLES code, the core MASQ functionality is now either
# modular or compiled into the kernel. This HOWTO shows ALL IPTABLES
# options as MODULES. If your kernel is compiled correctly, there is
# NO need to load the kernel modules manually.
#
# NOTE: The following items are listed ONLY for informational reasons.
# There is no reason to manual load these modules unless your
# kernel is either mis-configured or you intentionally disabled
# the kernel module autoloader.
#
# Upon the commands of starting up IP Masq on the server, the
# following kernel modules will be automatically loaded:
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ
# modules are shown below but are commented out from loading.
# ===============================================================
#Load the main body of the IPTABLES module - "ip_tables"
# - Loaded automatically when the "iptables" command is invoked
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "ip_tables, "
#
#Verify the module isn't loaded. If it is, skip it
#
if [ -z "` $LSMOD | $GREP ip_tables | $AWK {'print $1'} `" ]; then
$MODPROBE ip_tables
fi
#Load the IPTABLES filtering module - "iptable_filter"
#
# - Loaded automatically when filter policies are activated
#Load the stateful connection tracking framework - "ip_conntrack"
#
# The conntrack module in itself does nothing without other specific
# conntrack modules being loaded afterwards such as the "ip_conntrack_ftp"
# module
#
# - This module is loaded automatically when MASQ functionality is
# enabled
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "ip_conntrack, "
#
#Verify the module isn't loaded. If it is, skip it
#
if [ -z "` $LSMOD | $GREP ip_conntrack | $AWK {'print $1'} `" ]; then
$MODPROBE ip_conntrack
fi
#Load the FTP tracking mechanism for full FTP tracking
#
# Enabled by default -- insert a "#" on the next line to deactivate
#
echo -e "ip_conntrack_ftp, "
#
#Verify the module isn't loaded. If it is, skip it
#
if [ -z "` $LSMOD | $GREP ip_conntrack_ftp | $AWK {'print $1'} `" ]; then
$MODPROBE ip_conntrack_ftp
fi
#Load the IRC tracking mechanism for full IRC tracking
#
# Disabled by default -- insert a "#" on the next few lines to activate
#
# echo -en " ip_conntrack_irc, "
#
#Verify the module isn't loaded. If it is, skip it
#
# if [ -z "` $LSMOD | $GREP ip_conntrack_irc | $AWK {'print $1'} `" ]; then
# $MODPROBE ip_conntrack_irc
# fi
#Load the general IPTABLES NAT code - "iptable_nat"
# - Loaded automatically when MASQ functionality is turned on
#
# - Loaded manually to clean up kernel auto-loading timing issues
#
echo -en "iptable_nat, "
#
#Verify the module isn't loaded. If it is, skip it
#
if [ -z "` $LSMOD | $GREP iptable_nat | $AWK {'print $1'} `" ]; then
$MODPROBE iptable_nat
fi
#Loads the FTP NAT functionality into the core IPTABLES code
# Required to support non-PASV FTP.
#
# Enabled by default -- insert a "#" on the next line to deactivate
#
echo -e "ip_nat_ftp"
#
#Verify the module isn't loaded. If it is, skip it
#
if [ -z "` $LSMOD | $GREP ip_nat_ftp | $AWK {'print $1'} `" ]; then
$MODPROBE ip_nat_ftp
fi
#Loads the IRC NAT functionality (for DCC) into the core IPTABLES code
#
# DISABLED by default -- delete the "#" on the next few lines to activate
#
# echo -e "ip_nat_irc"
#
#Verify the module isn't loaded. If it is, skip it
#
# if [ -z "` $LSMOD | $GREP ip_nat_irc | $AWK {'print $1'} `" ]; then
# $MODPROBE ip_nat_irc
# fi
echo " ---"
# Just to be complete, here is a partial list of some of the other
# IPTABLES kernel modules and their function. Please note that most
# of these modules (the ipt ones) are automatically loaded by the
# master kernel module for proper operation and don't need to be
# manually loaded.
# --------------------------------------------------------------------
#
# ip_nat_snmp_basic - this module allows for proper NATing of some
# SNMP traffic
#
# iptable_mangle - this target allows for packets to be
# manipulated for things like the TCPMSS
# option, etc.
#
# --
#
# ipt_mark - this target marks a given packet for future action.
# This automatically loads the ipt_MARK module
#
# ipt_tcpmss - this target allows to manipulate the TCP MSS
# option for braindead remote firewalls.
# This automatically loads the ipt_TCPMSS module
#
# ipt_limit - this target allows for packets to be limited to
# to many hits per sec/min/hr
#
# ipt_multiport - this match allows for targets within a range
# of port numbers vs. listing each port individually
#
# ipt_state - this match allows to catch packets with various
# IP and TCP flags set/unset
#
# ipt_unclean - this match allows to catch packets that have invalid
# IP/TCP flags set
#
# iptable_filter - this module allows for packets to be DROPped,
# REJECTed, or LOGged. This module automatically
# loads the following modules:
#
# ipt_LOG - this target allows for packets to be
# logged
#
# ipt_REJECT - this target DROPs the packet and returns
# a configurable ICMP packet back to the
# sender.
#CRITICAL: Enable IP forwarding since it is disabled by default since
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo " Enabling forwarding.."
echo "1" > /proc/sys/net/ipv4/ip_forward
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP,
# enable the following option. This enables dynamic-address hacking
# which makes the life with Diald and similar programs much easier.
#
echo " Enabling DynamicAddr.."
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
echo " ---"
#############################################################################
#
# Enable Stronger IP forwarding and Masquerading
#
# NOTE: In IPTABLES speak, IP Masquerading is a form of SourceNAT or SNAT.
#
# NOTE #2: The following is an example for an internal LAN address in the
# 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet
# mask connecting to the Internet on external interface "eth0".
# This example will MASQ internal traffic out to the Internet
# but not allow non-initiated traffic into your internal network.
#
#
# ** Please change the above network numbers, subnet mask, and your
#
#Clearing any previous configuration
#
# Unless specified, the defaults for INPUT, OUTPUT, and FORWARD to DROP
#
# You CANNOT change this to REJECT as it isn't a vaild policy setting.
# If you want REJECT, you must explictly REJECT at the end of a giving
# INPUT, OUTPUT, or FORWARD chain
#
echo " Clearing any existing rules and setting default policy to DROP.."
$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT DROP
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -F -t nat
#Not needed and it will only load the unneeded kernel module
#
#$IPTABLES -F -t mangle
# Delete all User-specified chains
$IPTABLES -X
# Reset all IPTABLES counters
$IPTABLES -Z
#Configuring specific CHAINS for later use in the ruleset
#
# NOTE: Some users prefer to have their firewall silently
# "DROP" packets while others prefer to use "REJECT"
# to send ICMP error messages back to the remote
# machine. The default is "REJECT" but feel free to
# change this below.
#
# NOTE: Without the --log-level set to "info", every single
# firewall hit will goto ALL vtys. This is a very big
# pain.
#
echo " Creating a DROP chain.."
$IPTABLES -N reject-and-log-it
$IPTABLES -A reject-and-log-it -j LOG --log-level info
$IPTABLES -A reject-and-log-it -j REJECT
echo -e "\n - Loading INPUT rulesets"
#######################################################################
# INPUT: Incoming traffic from various interfaces. All rulesets are
# already flushed and set to a default policy of DROP.
#
# loopback interfaces are valid.
#
$IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
# local interface, local machines, going anywhere is valid
#
$IPTABLES -A INPUT -i $INTIF -s $INTNET -d $UNIVERSE -j ACCEPT
# remote interface, claiming to be local machines, IP spoofing, get lost
#
$IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j reject-and-log-it
# external interface, from any source, for ICMP traffic is valid
#
# If you would like your machine to "ping" from the Internet,
# enable this next line
#
#$IPTABLES -A INPUT -i $EXTIF -p ICMP -s $UNIVERSE -d $EXTIP -j ACCEPT
# remote interface, any source, going to the MASQ servers IP address is valid
#
# ENABLE this line if you want ALL Internet traffic to connect to your
# the various servers running on the MASQ server. This includes
# web servers, ssh servers, dns servers, etc.
#
# I DON'T recommend you enable this rule. Instead, only enable specific
# access to select server ports under the "OPTIONAL INPUT Section".
# An example of enabling HTTP (WWW) has been given below:
#
#
#$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -j ACCEPT
# Allow any related traffic coming back to the MASQ server in.
#
# STATEFULLY TRACKED
#
$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state \
ESTABLISHED,RELATED -j ACCEPT
# ----- Begin OPTIONAL INPUT Section -----
#
# DHCPd - Enable the following lines if you run an INTERNAL DHCPd server
#
#$IPTABLES -A INPUT -i $INTIF -p tcp --sport 68 --dport 67 -j ACCEPT
#$IPTABLES -A INPUT -i $INTIF -p udp --sport 68 --dport 67 -j ACCEPT
# HTTPd - Enable the following lines if you run an EXTERNAL WWW server
#
# NOTE: This is NOT needed for simply enabling PORTFW. This is ONLY
# for users that plan on running Apache on the MASQ server itself
#
#echo -e " - Allowing EXTERNAL access to the WWW server"
#$IPTABLES -A INPUT -i $EXTIF -m state --state NEW,ESTABLISHED,RELATED \
# -p tcp -s $UNIVERSE -d $EXTIP --dport 80 -j ACCEPT
#
# ----- End OPTIONAL INPUT Section -----
# Catch all rule, all other incoming is denied and logged.
#
$IPTABLES -A INPUT -s $UNIVERSE -d $UNIVERSE -j reject-and-log-it
# ---------------------------------------------------------------------
echo -e " - Loading OUTPUT rulesets"
#######################################################################
# OUTPUT: Outgoing traffic from various interfaces. All rulesets are
# already flushed and set to a default policy of DROP.
#
# Workaround bug in netfilter
# See http://www.netfilter.org/security/2002-04-02-icmp-dnat.html
#
$IPTABLES -A OUTPUT -m state -p icmp --state INVALID -j DROP
# loopback interface is valid.
#
$IPTABLES -A OUTPUT -o lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT
# local interfaces, any source going to local net is valid
#
$IPTABLES -A OUTPUT -o $INTIF -s $EXTIP -d $INTNET -j ACCEPT
# local interface, MASQ server source going to the local net is valid
#
$IPTABLES -A OUTPUT -o $INTIF -s $INTIP -d $INTNET -j ACCEPT
# outgoing to local net on remote interface, stuffed routing, deny
#
$IPTABLES -A OUTPUT -o $EXTIF -s $UNIVERSE -d $INTNET -j reject-and-log-it
# anything else outgoing on remote interface is valid
#
$IPTABLES -A OUTPUT -o $EXTIF -s $EXTIP -d $UNIVERSE -j ACCEPT
# ----- Begin OPTIONAL OUTPUT Section -----
#
# DHCPd - Enable the following lines if you run an INTERNAL DHCPd server
# - Remove BOTH #s all the #s if you need this functionality.
#
#$IPTABLES -A OUTPUT -o $INTIF -p tcp -s $INTIP --sport 67 \
# -d 255.255.255.255 --dport 68 -j ACCEPT
#$IPTABLES -A OUTPUT -o $INTIF -p udp -s $INTIP --sport 67 \
# -d 255.255.255.255 --dport 68 -j ACCEPT
#
# ----- End OPTIONAL OUTPUT Section -----
# Catch all rule, all other outgoing is denied and logged.
#
$IPTABLES -A OUTPUT -s $UNIVERSE -d $UNIVERSE -j reject-and-log-it
echo -e " - Loading FORWARD rulesets"
#######################################################################
# FORWARD: Enable Forwarding and thus IPMASQ
#
# ----- Begin OPTIONAL FORWARD Section -----
#
# Put PORTFW commands here
#
# ----- End OPTIONAL FORWARD Section -----
echo " - FWD: Allow all connections OUT and only existing/related IN"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
# Catch all rule, all other forwarding is denied and logged.
#
$IPTABLES -A FORWARD -j reject-and-log-it
echo " - NAT: Enabling SNAT (MASQUERADE) functionality on $EXTIF"
#
#More liberal form
#$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
#
#Stricter form
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
#######################################################################
echo -e "\nrc.firewall-iptables-stronger $FWVER done.\n"
</screen>
&lt;rc.firewall-iptables-stronger STOP&gt;
</para>
<para>
To automatically start this stronger firewall ruleset at the proper time,
please see the end of the <XRef LinkEnd="rc.firewall-ipchains"> section for
full details. Please make sure you make the correct "rc.firewall-iptables" to
"rc.firewall-iptables-stronger" substitutions!!
</para>
</Sect2>
<Sect2 id="rc.firewall-ipchains-stronger">
<Title>Stronger IP Firewall (IPCHAINS) rulesets </Title>
<para>
This section provides a more in-depth guide to using the 2.2.x firewall tool,
IPCHAINS. See above sections for IPFWADM rulesets.
</para>
<para>
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 <Emphasis role="strong">
FORBIDDEN</Emphasis> (well.. rejected actually). If your IP MASQ box breaks
after implementing this rc.firewall-ipchains-stronger 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.
</para>
<para>
For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets
for PPP, Cablemodem users, etc., please see
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS - Section 10</ULink> and <ULink URL="http://www.greatcircle.com/">
GreatCircle's Firewall WWW page</ULink>
</para>
<para>
<Emphasis role="strong">
NOTE #1: --- UPDATE YOUR KERNEL ---
</Emphasis>
Linux 2.2.x kernels less than version 2.2.20 contain several different
<ULink URL="http://www.linux.org.uk/VERSION/">security
vulnerabilities</Ulink> (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.
</para>
<para>
<Emphasis role="strong">NOTE #2:</Emphasis> If you get a dynamically assigned
TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you <Emphasis
role="strong">CANNOT load</Emphasis> 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-ipchains-stronger ruleset more
intelligent. To do this for various types of connections such as PPP or
DHCP users, please see the <XRef LinkEnd="masq-and-dyn-addr"> FAQ entry for all
the details.
</para>
<para>
<Emphasis role="strong">Please also be aware that there are several GUI Firewall
creation tools available as well. Please see <XRef LinkEnd="FAQ">for full
details.</Emphasis>
</para>
<para>
Lastly, if you are using a STATIC PPP IP address, change the
"EXTIF="your.static.PPP.address"" line to reflect your address.
</para>
<para>
----------------------------------------------------------------
</para>
<para>
&lt;rc.firewall-ipchains-stronger START&gt;
<screen>
#!/bin/sh
#
# /etc/rc.d/rc.firewall-ipchains-stronger: An example of a Stronger IPCHAINS
# firewall ruleset for 2.2 kernels
#
FWVER=0.75s
#
# Log:
# 0.75s - Updated the commands for dynamically addresses machines and
# to point to an expanded FAQ section for more information
#
# 0.74s - renamed from rc.firewall-2.2-stronger to
# rc.firewall-ipchains-stronger to better reflect that this ruleset can
# can run on different major kernel versions
# - removed unused SED variable
# 0.73s - Added additional comments to make PORTFW configs more obvious
# 0.72s - #ed out the rule that would allow all traffic destined for the
# MASQ server itself to be accepted. Use the OPTIONAL INPUT
# section to only allow explicit services.
# - Fixed an INTLAN rule that was allowing traffic from ANY IP address
# instead of the proper INTIP IP address only. This aligns the
# IPCHAINS ruleset with the IPTABLES and IPFWADM ruleset examples
# 0.71s - ruleset now uses modprobe instead of insmod
# 0.70s - Added missing execution variables
# - fixed a missing -p tcp for the commented HTTPd section
# 0.65s - Added comments HTTPd rules to the INPUT and OUTPUT section
# - Added a comment where to insert IPPORTFW commands
# 0.60s - Changed the EXTIP command to work on NON-English distros
# - Updated the CASE of some of the script variables
#
echo -e "\nLoading rc.firewall-ipchains-stronger : version $FWVER..\n"
# The location of various iptables and other shell programs
#
# If your Linux distribution came with a copy of iptables, most
# likely it is located in /sbin. If you manually compiled
# iptables, the default location is in /usr/local/sbin
#
# ** Please use the "whereis iptables" command to figure out
# ** where your copy is and change the path below to reflect
# ** your setup
#
IPCHAINS=/sbin/ipchains
LSMOD=/sbin/lsmod
DEPMOD=/sbin/depmod
MODPROBE=/sbin/modprobe
GREP=/bin/grep
AWK=/bin/awk
IFCONFIG=/sbin/ifconfig
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# Global variables
# ----------------
# ALL PPP and DHCP users must set this for the correct EXTERNAL and
# INTERNAL interfaces names. Examples: eth0, ppp0, ippp0, etc.
# See more info about this below.
#
EXTIF="ppp0"
INTIF="eth0"
# The INTERNAL IP address
#
INTIP="192.168.0.1/32"
INTNET="192.168.0.0/24"
echo " Internal IP: $INTIP"
echo " Internal Network: $INTNET"
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
# are shown below but are commented from loading.
# Needed to initially load modules
#
$DEPMOD -a
# Supports the proper masquerading of FTP file transfers using the PORT method
#
$MODPROBE ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
$MODPROBE ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#$MODPROBE ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. These modules are
# for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#$MODPROBE ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#$MODPROBE ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#$MODPROBE ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#$MODPROBE ip_masq_vdolive
#CRITICAL: Enable IP forwarding since it is disabled by default
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" &#62; /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmentation since it is disabled by default
# in 2.2.x kernels
#
# This used as a compile-time option but the behavior was changed
# in 2.2.12. It should also be noted that some distributions have
# removed this option from the /proc table. If this entry isn't
# present in your /proc, don't worry about it.
#
echo "1" &#62; /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this
# following option. This enables dynamic-ip address hacking in IP MASQ,
# making life with Diald and similar programs much easier.
#
#echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
# Enable the LooseUDP patch which some Internet-based games require
#
# If you are trying to get an Internet game to work through your IP MASQ box,
# and you configured it to the best of your ability without it working, try
# enabling this option (delete the "#" character). This option is disabled
# by default due to possible internal machine UDP port scanning
# vulnerabilities.
#
#echo "1" &#62; /proc/sys/net/ipv4/ip_masq_udp_dloose
# Specify your Static IP address here.
#
# If you have a DYNAMIC IP address, you need to make this ruleset recognize
# your IP address everytime you get a new IP. To do this, enable the
# following one-line script. (Please note that the different single and
# double quote characters MATTER).
#
#
# DHCP users (Cablemodem and DSL ) users:
# ---------------------------------------
# If you get your TCP/IP address via DHCP, **you will need ** to enable the
# #ed out command below underneath the PPP section AND replace the word
# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1, etc)
# on the lines for "ppp-ip" and "EXTIP".
#
# DHCP and PPP users: The remote DHCP or PPP server can and will change
# IP addresses on you over time. To deal with this, users should configure
# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime
# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry
# in the IPMASQ howto for full details on how to do this.
#
#
# Determine the external IP automatically:
# ----------------------------------------
#
# The following line will determine your external IP address. This
# line is somewhat complex and confusing but it will also work for
# all NON-English Linux distributions.
#
# Make sure the EXTIF variable above is set to reflect the name
# of your Internet connection
#
EXTIP="`$IFCONFIG $EXTIF | $AWK \
/$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec
# firewall timeout in ICQ itself)
#
$IPCHAINS -M -S 7200 10 60
#############################################################################
# Incoming, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
$IPCHAINS -F input
$IPCHAINS -P input REJECT
# local interface, local machines, going anywhere is valid
#
$IPCHAINS -A input -i $INTIF -s $INTNET -d 0.0.0.0/0 -j ACCEPT
# remote interface, claiming to be local machines, IP spoofing, get lost
#
$IPCHAINS -A input -i $EXTIF -s $INTNET -d 0.0.0.0/0 -l -j REJECT
# remote interface, any source, going to the MASQ servers IP address is valid
#
# ENABLE this line if you want ALL Internet traffic to connect to your
# the various servers running on the MASQ server. This includes
# web servers, ssh servers, dns servers, etc.
#
# I DON'T recommend you enable this rule. Instead, only enable specific
# access to select server ports under the "OPTIONAL INPUT Section".
# An example of enabling HTTP (WWW) has been given below:
#
#
#$IPCHAINS -A input -i $EXTIF -s 0.0.0.0/0 -d $EXTIP/32 -j ACCEPT
# loopback interface is valid.
#
$IPCHAINS -A input -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# ----- Begin OPTIONAL INPUT Section -----
#
# HTTPd - Enable the following lines if you either run a WWW server on
# the IPMASQ server -OR- plan on PORTFW'ing HTTP traffic to
# an internal WWW server
#
#$IPCHAINS -A input -i $EXTIF -p tcp -s 0.0.0.0/0 -d $EXTIP 80 -j ACCEPT
#
# ----- End OPTIONAL INPUT Section -----
# catch all rule, all other incoming is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
$IPCHAINS -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Outgoing, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
$IPCHAINS -F output
$IPCHAINS -P output REJECT
# local interface, MASQ server source going to the local net is valid
#
$IPCHAINS -A output -i $INTIF -s $INTIP -d $INTNET -j ACCEPT
# outgoing to local net on remote interface, stuffed routing, deny
#
$IPCHAINS -A output -i $EXTIF -s 0.0.0.0/0 -d $INTNET -l -j REJECT
# outgoing from local net on remote interface, stuffed masquerading, deny
#
$IPCHAINS -A output -i $EXTIF -s $INTNET -d 0.0.0.0/0 -l -j REJECT
# anything else outgoing on remote interface is valid
#
$IPCHAINS -A output -i $EXTIF -s $EXTIP/32 -d 0.0.0.0/0 -j ACCEPT
# loopback interface is valid.
#
$IPCHAINS -A output -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
# ----- Begin OPTIONAL OUTPUT Section -----
#
# HTTPd - Enable the following lines if you either run a WWW server on
# the IPMASQ server -OR- plan on PORTFW'ing HTTP traffic to
# an internal WWW server
#
#$IPCHAINS -A output -i $EXTIF -p tcp -s $EXTIP 80 -d 0.0.0.0/0 -j ACCEPT
#
# ----- End OPTIONAL OUTPUT Section -----
# catch all rule, all other outgoing is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
$IPCHAINS -A output -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#############################################################################
# Forwarding, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
$IPCHAINS -F forward
$IPCHAINS -P forward DENY
# ----- Begin OPTIONAL FORWARD Section -----
#
# Put PORTFW commands here
#
# ----- End OPTIONAL FORWARD Section -----
# Masquerade from local net on local interface to anywhere.
#
$IPCHAINS -A forward -i $EXTIF -s $INTNET -d 0.0.0.0/0 -j MASQ
#
# catch all rule, all other forwarding is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
$IPCHAINS -A forward -s 0.0.0.0/0 -d 0.0.0.0/0 -l -j REJECT
#End of file.
</screen>
&lt;rc.firewall-ipchains-stronger STOP&gt;
</para>
<para>
To automatically start this stronger firewall ruleset at the proper time,
please see the end of the <XRef LinkEnd="rc.firewall-ipchains"> section for
full details. Please make sure you make the correct "rc.firewall-ipchains" to
"rc.firewall-ipchains-stronger" substitutions!!
</para>
<para>
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:
</para>
<para>
Using "input" rules:
</para>
<para>
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.
</para>
<para>
Anyway, to block 204.50.10.13:
</para>
<para>
<screen>
In the /etc/rc.d/rc.firewall-ipchains-stronger ruleset:
... start of "input" rules ...
# reject and log local interface, local machines going to 204.50.10.13
#
ipchains -A input -s 192.168.0.0/24 -d 204.50.10.13/32 -l -j REJECT
# local interface, local machines, going anywhere is valid
#
ipchains -A input -s 192.168.0.0/24 -d 0.0.0.0/0 -l -j ACCEPT
... end of "input" rules ...
</screen>
</para>
<para>
Using "output" rules:
</para>
<para>
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.
</para>
<para>
... 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 ...
</para>
<para>
Using "forward" rules:
</para>
<para>
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).
</para>
<para>
... 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 ...
</para>
<para>
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.
</para>
<para>
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.
</para>
</Sect2>
<Sect2 id="rc.firewall-ipfwadm-stronger">
<Title>Stronger IP Firewall (IPFWADM) Rulesets</Title>
<para>
This section provides a more in-depth guide on using the 2.0.x firewall tool,
IPFWADM. See below for IPCHAINS rulesets
</para>
<para>
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
<Emphasis role="strong">FORBIDDEN</Emphasis> (well.. rejected, actually).
If your IP MASQ box breaks after implementing this rc.firewall-ipfwadm-stronger
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.
</para>
<para>
For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets
for PPP, Cablemodem users, etc., please see
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS - Section 10</ULink> and <ULink URL="http://www.greatcircle.com/">
GreatCircle's Firewall WWW page</ULink>
</para>
<para>
<Emphasis role="strong">NOTE #2:</Emphasis> If you get a dynamically assigned
TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you <Emphasis
role="strong">CANNOT load</Emphasis> 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-ipchains-stronger ruleset more
intelligent. To do this for various types of connections such as PPP or
DHCP users, please see the <XRef LinkEnd="masq-and-dyn-addr"> FAQ entry for all
the details.
</para>
<para>
<Emphasis role="strong">Please also be aware that there are several GUI Firewall
creation tools available as well. Please see <XRef LinkEnd="FAQ">for full
details.</Emphasis>
</para>
<para>
Lastly, if you are using a STATIC PPP IP address, change the
"ppp_ip="your.static.PPP.address"" line to reflect your address.
</para>
<para>
----------------------------------------------------------------
</para>
<para>
&lt;rc.firewall-ipfwadm-stronger START&gt;
<screen>
#!/bin/sh
#
# /etc/rc.d/rc.firewall-ipfwadm-stronger: An example of a semi-STRONG
# IPFWADM firewall ruleset for 2.0 kernels
#
FWVER=0.74s
#
# Log:
# 0.74s - Updated the commands for dynamically addresses machines and
# to point to an expanded FAQ section for more information
#
# 0.73s - renamed from rc.firewall-2.0-stronger to
# rc.firewall-ipfwadm-stronger
#
# 0.72s - #ed out the rule that would allow all traffic destined for the
# MASQ server itself to be accepted. Use the OPTIONAL INPUT
# section to only allow explicit services.
PATH=/sbin:/bin:/usr/sbin:/usr/bin
# testing, wait a bit then clear all firewall rules.
# uncomment the following lines if you want the firewall to automatically
# disable after 10 minutes.
#
# Disabled by default
#
# (sleep 600; \
# ipfwadm -I -f; \
# ipfwadm -I -p accept; \
# ipfwadm -O -f; \
# ipfwadm -O -p accept; \
# ipfwadm -F -f; \
# ipfwadm -F -p accept; \
# ) &
# Load all required IP MASQ modules
#
# NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
# are shown below but are commented from loading.
# Needed to initially load modules
#
/sbin/depmod -a
# Supports the proper masquerading of FTP file transfers using the PORT method
#
/sbin/modprobe ip_masq_ftp
# Supports the masquerading of RealAudio over UDP. Without this module,
# RealAudio WILL function but in TCP mode. This can cause a reduction
# in sound quality
#
#/sbin/modprobe ip_masq_raudio
# Supports the masquerading of IRC DCC file transfers
#
#/sbin/modprobe ip_masq_irc
# Supports the masquerading of Quake and QuakeWorld by default. This modules is
# for multiple users behind the Linux MASQ server. If you are going to
# play Quake I, II, and III, use the second example.
#
# NOTE: If you get ERRORs loading the QUAKE module, you are running an old
# ----- kernel that has bugs in it. Please upgrade to the newest kernel.
#
#Quake I / QuakeWorld (ports 26000 and 27000)
#/sbin/modprobe ip_masq_quake
#
#Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
#/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
# Supports the masquerading of the CuSeeme video conferencing software
#
#/sbin/modprobe ip_masq_cuseeme
#Supports the masquerading of the VDO-live video conferencing software
#
#/sbin/modprobe ip_masq_vdolive
#CRITICAL: Enable IP forwarding, since it is disabled by default
#
# Redhat Users: you may try changing the options in /etc/sysconfig/network
# from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" &#62; /proc/sys/net/ipv4/ip_forward
#CRITICAL: Enable automatic IP defragmenting since it is disabled by default
# in 2.2.x kernels
#
# This used to be a compile-time option but the behavior was changed
# in 2.2.12
#
echo "1" &#62; /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this
# following option. This allows dynamic-ip address hacking in IP MASQ,
# making the life with Diald and similar programs much easier.
#
#echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
# Specify your Static IP address here.
#
# If you have a DYNAMIC IP address, you need to make this ruleset understand
# your IP address everytime you get a new IP. To do this, enable the
# following one-line script. (Please note that the different single and
# double quote characters MATTER).
#
#
# DHCP (Cablemodem and DSL) and PPP users:
# ----------------------------------------
# If you get your TCP/IP address a dynamic IP address **you will need ** to
# enable the #ed out command below underneath the PPP section AND replace the word
# "ppp0" with the name of your EXTERNAL Internet connection (eth0, eth1,
# etc).
#
# DHCP and PPP users: The remote DHCP or PPP server can and will change
# IP addresses on you over time. To deal with this, users should configure
# their DHCP or PPP client to re-run the rc.firewall-* ruleset everytime
# the IP address is changed. Please see the "masq-and-dyn-addr" FAQ entry
# in the IPMASQ howto for full details on how to do this.
#
#
# PPP and DHCP Users:
# -------------------
# Remove the # on the line below and place a # in front of the line after that.
#
#ppp_ip="`/sbin/ifconfig ppp0 | grep 'inet addr' | awk '{print $2}' | sed -e 's/.*://'`"
#
ppp_ip="your.static.PPP.address"
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec
# firewall timeout in ICQ itself)
#
/sbin/ipfwadm -M -s 7200 10 60
#############################################################################
# Incoming, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p reject
# 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
# remote interface, claiming to be local machines, IP spoofing, get lost
#
/sbin/ipfwadm -I -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# remote interface, any source, going to the MASQ servers IP address is valid
#
# ENABLE this line if you want ALL Internet traffic to connect to your
# the various servers running on the MASQ server. This includes
# web servers, ssh servers, dns servers, etc.
#
# I DON'T recommend you enable this rule. Instead, only enable specific
# access to select server ports under the "OPTIONAL INPUT Section".
# An example of enabling HTTP (WWW) has been given below:
#
#
#/sbin/ipfwadm -I -a accept -V $ppp_ip -S 0.0.0.0/0 -D $ppp_ip/32
# loopback interface is valid.
#
/sbin/ipfwadm -I -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other incoming is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -I -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Outgoing, flush and set default policy of reject. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -O -f
/sbin/ipfwadm -O -p reject
# local interface, MASQ server source going to the local net is valid
#
/sbin/ipfwadm -O -a accept -V 192.168.0.1 -S 0.0.0.0/0 -D 192.168.0.0/24
# outgoing to local net on remote interface, stuffed routing, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 192.168.0.0/24 -D 0.0.0.0/0 -o
# outgoing from local net on remote interface, stuffed masquerading, deny
#
/sbin/ipfwadm -O -a reject -V $ppp_ip -S 0.0.0.0/0 -D 192.168.0.0/24 -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
# loopback interface is valid.
#
/sbin/ipfwadm -O -a accept -V 127.0.0.1 -S 0.0.0.0/0 -D 0.0.0.0/0
# catch all rule, all other outgoing is denied and logged. pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -O -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#############################################################################
# Forwarding, flush and set default policy of deny. Actually the default policy
# is irrelevant because there is a catch all rule with deny and log.
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p reject
# 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
#
# catch all rule, all other forwarding is denied and logged. Pity there is no
# log option on the policy but this does the job instead.
#
/sbin/ipfwadm -F -a reject -S 0.0.0.0/0 -D 0.0.0.0/0 -o
#End of file.
</screen>
&lt;rc.firewall-ipfwadm-stronger STOP&gt;
</para>
<para>
To automatically start this stronger firewall ruleset at the proper time,
please see the end of the <XRef LinkEnd="rc.firewall-ipfwadm"> section for
full details. Please make sure you make the correct "rc.firewall-ipfwadm" to
"rc.firewall-ipfwadm-stronger" substitutions!!
</para>
<para>
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:
</para>
<para>
Using -I (input ) rules:
</para>
<para>
Probably the fastest and most efficient method to block traffic but it only
stops the MASQed machines, and NOT the firewall machine itself. Of course,
you might want to allow that combination.
</para>
<para>
Anyway, to block 204.50.10.13:
</para>
<para>
In the /etc/rc.d/rc.firewall-ipfwadm-stronger 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 ...
</para>
<para>
Using -O (output) rules:
</para>
<para>
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.
</para>
<para>
... 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 ...
</para>
<para>
Using -F (forward) rules:
</para>
<para>
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).
</para>
<para>
... 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 ...
</para>
<para>
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.
</para>
<para>
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.
</para>
</Sect2>
</Sect1>
<Sect1 id="multiple-masqed-lans">
<Title>IP Masquerading multiple internal networks</Title>
<para>
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.
</para>
<para>
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 interface
and 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:
</para>
<Sect2 id="iptables-masqing-multiple-lans">
<Title>iptables support for multiple internal lans</Title>
<ItemizedList>
<listitem>
<para>
<screen>
# 2.6.x and 2.4.x kernels with IPTABLES
#
# The following rules build upon the rc.firewall-iptables-stronger ruleset.
# Please see that ruleset in Section 6 for how all variables get set, etc.
#Enable internal interfaces to communication between each other
#
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $INTIF2 -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -A FORWARD -i $INTIF2 -o $INTIF -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP
</screen>
</para>
</listitem>
</ItemizedList>
</sect2>
<Sect2 id="ipchains-masqing-multiple-lans">
<Title>ipchains support for multiple internal lans</Title>
<ItemizedList>
<listitem>
<para>
<screen>
# 2.2.x kernels with IPCHAINS
#
# The following rules build upon the rc.firewall-ipchains-stronger ruleset.
# Please see that ruleset in Section 6 for how all variables get set, etc.
#Enable internal interfaces to communication between each other
$IPCHAINS -A forward -i eth1 -d 192.168.0.0/24 -j ACCEPT
$IPCHAINS -A forward -i eth2 -d 192.168.1.0/24 -j ACCEPT
#Enable internal interfaces to MASQ out to the Internet
$IPCHAINS -A forward -j MASQ -i eth0 -s 192.168.0.0/24 -d 0.0.0.0/0
$IPCHAINS -A forward -j MASQ -i eth0 -s 192.168.1.0/24 -d 0.0.0.0/0
</screen>
</para>
</listitem>
</ItemizedList>
</sect2>
<Sect2 id="ipfwadm-masqing-multiple-lans">
<Title>ipfwadm support for multiple internal lans</Title>
<ItemizedList>
<listitem>
<para>
<screen>
# 2.0.x kernels with IPFWADM
#
# The following rules build upon the rc.firewall-ipfwadm-stronger ruleset.
# Please see that ruleset in Section 6 for how all variables get set, etc.
#Enable internal interfaces to communication between each other
/sbin/ipfwadm -F -a accept -V 192.168.0.1 -D 192.168.1.0/24
/sbin/ipfwadm -F -a accept -V 192.168.1.1 -D 192.168.0.0/24
#Enable internal interfaces to MASQ out to the Internet
/sbin/ipfwadm -F -a masq -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0
/sbin/ipfwadm -F -a masq -W eth0 -S 192.168.1.0/24 -D 0.0.0.0/0
</screen>
</para>
</listitem>
</ItemizedList>
<para>
Please note that it is CORRECT to have "eth0" specified multiple times for the
exmples shown above. The reason for this is the Linux kernel needs to know
which interface is used for OUTGOING traffic. Since eth0 in the above examples
is the Internet connection, it is listed for each internal interface.
</para>
</Sect2>
</Sect1>
<Sect1 id="Dial-on-Demand">
<Title>IP Masquerade and Dial-on-Demand Connections</Title>
<para>
<OrderedList>
<listitem>
<para>
If you would like to setup your network to automatically dial up the Internet,
either the <Emphasis role="strong">Diald</Emphasis> demand dial-up or new
versions of the <Emphasis role="strong">PPPd</Emphasis> packages will be of
great utility. Both Diald and PPPd are very powerful in their configuration
flexibility.
</para>
</listitem>
<listitem>
<para>
To setup PPPd for Dial-on-Demand, pease check out the
<ULink URL="http://www.samba.org/ppp/index.html">PPPd Homepage</ULink>
</para>
</listitem>
<listitem>
<para>
To setup Diald, please check out the
<ULink URL="http://diald.sourceforge.net/">Diald Homepage</ULink> or
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS - Section 23</ULink>
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
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
<Emphasis role="strong">echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr</Emphasis>
kernel option to help with this initial setup.
</para>
</listitem>
</OrderedList>
</para>
</Sect1>
<Sect1 id="Forwarders">
<Title>Port Forwarding with IPTABLES or external tools like IPPORTFW,
IPMASQADM, IPAUTOFW, REDIR, UDPRED, and other Port Forwarding tools </Title>
<para>
IPTABLES as well as IPPORTFW, IPAUTOFW, REDIR, UDPRED, and other programs offer
generic TCP and/or UDP port forwarding for Linux IP Masquerade. 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.
</para>
<para>
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, and SMTP.
Protocols such as FTP, legacy ICQ, and others require special handling via
kernel modules (see below).
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>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 <Emphasis role="strong">STILL NEED</Emphasis> 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.
</para>
<para>
So why all the different choices? IPTABLES, IPPORTFW, MARK (MFW), IPMASQADM
(PORTFW or AUTOFW), IPAUTOFW, REDIR, and UDPRED (all URLs are in
<XRef LinkEnd="ipmasq-compiling3.1.3">) are the various tools available to IP
MASQ users to allow this type of functionality depending on their kernel
version. Later, as the Linux IP Masquerade feature matured, many of these
tools were eventually replaced by the IPTABLES or PORTFW and MARK systems
which are far more intelligent solutions.
</para>
<para>
For the later 2.2.x kernels, the IPMASQADM tool combined the legacy IPAUTOFW and
IPPORTFW 2.0.x kernel tools into one binary. Both the IPMASQADM tool for 2.2.x
kernels as well as IPTABLES for the 2.6.x and 2.4.x kernels also supports a
new mechanism called "MARK" or MFW for PORTFW functionality. 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 internal
destination. Currently, this HOWTO doesn't cover the MARK solution but it
will in the future.
</para>
<para>
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 <Emphasis role="strong">CRASH</Emphasis> your
Linux server with extreme use.
</para>
<para>
<Emphasis role="strong">NOTE #2: </Emphasis>With enabling PORTFW functionality
in ANY 2.2/2.0 Linux kernel (2.6.x. and 2.4.x users won't use these specific
tools anyway), <Emphasis role="strong">internal
machines typically CANNOT use the same "external" PORTFWed IP address to
access a given internal" machine.</Emphasis> 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 use the REDIR tool for older 2.2.x and
2.0.x kernels to let internal machines get redirected to the internal servers
too. 2.6.x and 2.4.x kernels users running IPTABLES solves this issue once
and for all and is fully covered in a FAQ entry in
<XRef LinkEnd="portfw-local"> below. If you would like a technical
explination on why this internal/external forwarding doesn't work, please page
down towards the bottom of the 2.2.x PORTFW section for a note from
Juan Jose Ciarlante.
</para>
<para>
NOTE #3: The forwarding of non-NAT friendly traffic such as FTP server traffic
to an internal MASQed FTP server, known as <Emphasis role="strong">PORTFW
FTP</Emphasis>, is now fully supported in the 2.6.x and 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 require
the use of different patches.
</para>
<para>
<Emphasis role="strong">WARNING!</Emphasis> Before jumping right into
installing ANY of these tools, it needs to be mentioned that network security
can be an issue with <Emphasis>ANY</Emphasis> 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:
</para>
<para>
<Screen>
"Port Forwarding is only called within masquerading functions so it
fits inside the same IPFWADM/IPCHAINS rules. Masquerading is an extension to
IP forwarding. Therefore, ipportfw only sees a packet if it fits
both the input and masquerading ipfwadm rule sets."
</Screen>
</para>
<para>
What that means in English is that if you have a strong packet firewall
running, 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.
</para>
<para>
With this said, it's important to have a strong firewall ruleset. Please see
<XRef LinkEnd="rc.firewall-iptables-stronger">,
<XRef LinkEnd="rc.firewall-ipchains-stronger">,
and <XRef LinkEnd="rc.firewall-ipfwadm-stronger"> for more details on getting
strong rulesets.
</para>
<para>
<ItemizedList>
<listitem>
<para>
2.6.x and 2.4.x kernels have PORTFW functional already built in using the
IPTABLES tool. 2.2.x and 2.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.
</para>
</listitem>
<listitem>
<para>
The latest 2.2.x kernel users will already have the PORTFW kernel option
available to them though you might still need to recompile the kernel via the
normal kernel "make" procedures.
</para>
</listitem>
<listitem>
<para>
2.0.x users will need to apply a simple kernel option patch to have access to
then enable this via the normal kernel "make" procedures.
</para>
</listitem>
</ItemizedList>
</para>
<Sect2 id="portfw-via-iptables-prerouting">
<Title>IPTABLES-based PORTFWD'ing: Using IPTABLES's PREROUTING option for 2.6.x
and 2.4.x kernels</Title>
<para>
As mentioned before, a port forward or "PORTFW" allows a single or range
of TCP/IP ports from the external side of the network to be forwarded into
the inside network.
</para>
<para>
Unlike ALL previous Linux kernels, the 2.6.x and 2.4.x series kernels now
allows for full PORTFW, PORTFW FTP, and PORTFW REDIR functionality within
the "iptables" tool itself.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>Once you enable a port forwarder on
say port 80 (forward WWW traffic through the MASQ server to an internal WWW
server), that port will no longer be used by the Linux IP Masquerade server
itself. 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.
</para>
<para>
To enable port forwarding on an IPTABLES (2.6.x or 2.4.x kernel):
<ItemizedList>
<listitem>
<para>Edit the /etc/rc.d/rc.firewall-iptables ruleset and place the lines
shown below just ABOVE the "<Literal remap="tt">FWD: Allow all
connections OUT and only existing and related ones IN</Literal>"
line (in the "Optional FORWARD section"). Please
<Emphasis role="strong">be sure </Emphasis>to replace the word
"$EXTIP" with your specific Internet IP address.
</para>
</listitem>
<listitem>
<para>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.
</para>
</listitem>
</ItemizedList>
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">NOTE: </Emphasis> If you get a dynamically assigned
TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you <Emphasis
role="strong">CANNOT load</Emphasis> 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-ipchains-stronger ruleset more
intelligent. To do this for various types of connections such as PPP or
DHCP users, please see the <XRef LinkEnd="masq-and-dyn-addr"> FAQ entry for all
the details.
</para>
</listitem>
</ItemizedList>
</para>
<para>
/etc/rc.d/rc.firewall-*
<Screen>
#echo "Enabling PORTFW Redirection on the external LAN.."
#
# This will forward ALL port 80 traffic from the external IP address
# to port 80 on the 192.168.0.10 machine
#
# Be SURE that when you add these new rules to your rc.firewall-*, you
# add them before a direct or implict DROP or REJECT.
#
PORTFWIP="192.168.0.10"
# NOTE: If you are using the basic rc.firewall-iptables ruleset, you
# will need to enable the following EXTIP option. Users of the
# rc.firewall-iptables-stronger ruleset already have this defined.
#
# *PLEASE* look over the rc.firewall-iptables-stronger ruleset for more
# specific issues regarding dynamic vs. static IP addresses
#
#
# Determine the external IP automatically:
# ----------------------------------------
#
# The following line will determine your external IP address. This
# line is somewhat complex and confusing but it will also work for
# all NON-English Linux distributions:
#
# DISABLED by default -- to enable, REMOVE both the "#" characters below
#
#EXTIP="`$IFCONFIG $EXTIF | $AWK \
#/$EXTIF/'{next}//{split($0,a,":");split(a[2],a," ");print a[1];exit}'`"
# Allow forwarding of new and existing port 80 connections from the external
# interface. This rule is required as our default FORWARD policy is DENY.
#
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -m state \
--state NEW,ESTABLISHED,RELATED -j ACCEPT
#Enable PORTFW of this port 80 traffic from the external interface
#
$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 80 -m state \
--state NEW,ESTABLISHED,RELATED -j DNAT --to $PORTFWIP:80
</Screen>
</para>
<para>
That's it! Just re-run your /etc/rc.d/rc.firewall-iptables ruleset and test
it out! If you would like to learn more about this, please see the
<XRef LinkEnd="portfw-local">
</para>
<para>
--------------------------------------------------------------------------
</para>
<para>
Running the rc.firewall-iptables-stronger ruleset? Good for you! To get
PORTFW running 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:
<ItemizedList>
<listitem>
<para>Take the ruleset lines shown above (for the generic rc.firewall-*
ruleset) and place them just *after* the "<Literal remap="tt">#FORWARD
Enable Forwarding and thus IPMASQ</Literal>" comment lines. It should
also be noted that you <Emphasis role="strong">DO NOT</Emphasis> have
to enable the "HTTPD" rules under the "Optional 'INPUT' section" for
2.4-based kernels. With 2.4 kernels, those lines are ONLY used if
you want to allow HTTP traffic to terminate on the MASQ server's own
local httpd process (usually Apache).
</para>
</listitem>
</itemizedlist>
</para>
<para>
<Emphasis role="strong">PORTFW FTP: </Emphasis>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 port "21" should do the
trick. This is much easier than the configuration for the older IPCHAINS /
IPFWADM tools for the 2.2.x / 2.0.x kernels!
</para>
<para>
Please note, if you setup PORTFW to redirect traffic to an internal FTP server
that is running on a NON-standard FTP port, say port 8021 instead of the usual
port 21, you MUST tell the "ip_conntrack_ftp" module to be aware of the new
FTP port. The reason for this configuration change is that FTP is not a
NAT-friendly protocol. By telling the FTP NAT module about this non-standard
FTP port, the NAT module and do it's job again. To enable this, edit your
rc.firewall-* file and change the loading of the FTP module to look something
like this:
</para>
<para>
<Screen>
/sbin/insmod ip_conntrack_ftp ports=21,8021
</Screen>
</para>
<para>
<Emphasis role="strong">PORTFW Redirection of Internal requests:</Emphasis>
</para>
<para>
In the past, if users PORTFWed port 80 on their EXTERNAL IP address to some
internal machine, only the machines out on the Internet would be able to
properly reach this internal WWW server. If you tried to contact this
internal WWW server via the MASQ server's EXTERNAL address, it would fail.
Fortunately, there are workarounds for all Linux kernels. IPTABLES for the
2.6.x and 2.4.x kernels supports this functionality natively. IPCHAINS support
for the 2.2.x kernels and IPFWADM support for the 2.0.x kernels need to use
the external REDIR tool (not currently covered in the HOWTO). For those of
you who understand IPTABLES fairly well, the rule of thumb is a
PREROUTING/DNAT rule is for enabling PORTFW from *external* machines and a
POSTROUTING/SNAT rule is for enabling PORTFW from *internal* machines.
</para>
<para>
To support redirection like this from an internal host, add a rule like
the one shown below ABOVE the "Catch all" FORWARDing rule in the rc.firewall-*
file. The following example will REDIRECT all external as well as internal
WWW traffic to the internal machine noted as PORTFWIP (192.168.0.10). This
traffic will have the source IP address of the IP Masq server's internal
IP address. Please change the IP address of the PORTFWIP variable to reflect
your specific configuration:
</para>
<para>
<Screen>
#The following rule should be configured in *addition* to the above rule
# for enabling external to internal PORTFWing
$IPTABLES -t nat -A POSTROUTING -d $PORTFWIP -s $INTLAN -p tcp \
--dport 80 -m state --state NEW,ESTABLISHED,RELATED -j SNAT \
--to $INTIP
</Screen>
</para>
</Sect2>
<Sect2 id="portfwding-via-2.2.x-ipmasqadm">
<Title>IPMASQADM-based PORTFWD'ing: Using IPMASQADM with 2.2.x kernels</Title>
<para>
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
<XRef LinkEnd="ipmasq-compiling3.1.2"> section for full details. Next,
download the "ipmasqadm.c" program from <XRef LinkEnd="kernel-2.2.x-Requirements">
into the /usr/src/kernel directory.
</para>
<para>
Next, you'll need to compile the 2.2.x kernel as shown in
<XRef LinkEnd="ipmasq-compiling3.1.2"> section. Be sure to say "YES" to the
IPPORTFW option when you configure the kernel. Once the kernel compile is
complete and you have rebooted, return to this section.
</para>
<para>
Now, compile and install the IPMASQADM tool:
</para>
<para>
<Screen>
cd /usr/src
tar xzvf ipmasqadm-x.tgz
cd ipmasqadm-x
make
make install
</screen>
</para>
<para>
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.
</para>
<para>
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
<Emphasis role="strong">IP_MASQ_FTP</Emphasis> 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 <XRef LinkEnd="kernel-2.2.x-Requirements">.
It should also be noted that the FTP kernel module also supports the adding of
additional PORTFW FTP ports on the fly without the requirement of unloading and
reloading the IP_MASQ_FTP module and thus breaking any existing FTP transfers.
You can find more about this new code at the IPMASQ WWW site at
<ULink URL="http://ipmasq.webhop.net">http://ipmasq.webhop.net;</ULink>. There are
also examples and some additional information about PORTFWed FTP connection
below in the 2.0.x. kernel section.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>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.
</para>
<para>
Anyway, to enable port forwarding for HTTPd:
<ItemizedList>
<listitem>
<para>Edit the /etc/rc.d/rc.firewall-* ruleset and ENABLE the "Optional"
"HTTP" sections in both the INPUT and OUTPUT subsections.
</para>
</listitem>
<listitem>
<para>Add the following lines shown below JUST BELOW the
"<Literal remap="tt">ipchains -P forward DENY</Literal>" rule
(in the "Optional FORWARD section"). Be sure to replace the
"$EXTIP" variable's contents with your EXTERNAL Internet IP
address on the IPMASQ server.
</para>
</listitem>
</ItemizedList>
</para>
<para>
<Emphasis role="strong">NOTE #2:</Emphasis> If you get a dynamically assigned
TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you <Emphasis
role="strong">CANNOT load</Emphasis> 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-ipchains-stronger ruleset more
intelligent. To do this for various types of connections such as PPP or
DHCP users, please see the <XRef LinkEnd="masq-and-dyn-addr"> FAQ entry for all
the details.
</para>
<para>
/etc/rc.d/rc.firewall-*
<Screen>
#echo "Enabling IPPORTFW Redirection on the external LAN.."
#
# This will forward ALL port 80 traffic from the external IP address
# to port 80 on the 192.168.0.10 machine
#
PORTFWIP="192.168.0.10"
/usr/sbin/ipmasqadm portfw -f
/usr/sbin/ipmasqadm portfw -a -P tcp -L $EXTIP 80 -R $PORTFWIP 80
</Screen>
</para>
<para>
That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out!
</para>
<para>
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.
</para>
<para>
<Emphasis role="strong">PORTFW Redirection of Internal requests:</Emphasis>
</para>
<para>
It should be mention that this IPMASQ HOWTO currently does *NOT* provide any
explination or examples on how to use the REDIR tool. If you need help
setting it up for 2.2.x kernels, send me an email. For those who want to
understand why PORTFW cannot redirect traffic for both external and internal
interfaces (what the REDIR tool fixes), here is an email from Juanjo that
better explains it.
</para>
<para>
<ProgramListing>
From Juanjo Ciarlante
--
&#62;If I use:
&#62;
&#62; ipmasqadm portfw -a -P tcp -L 1.2.3.4 80 -R 192.168.2.3 80
&#62;
&#62;Everything works great from the outside but internal requests for the same
&#62;1.2.3.4 address fail. Are there chains that will allow a machine on localnet
&#62;192.168.2.0 to accesss www.periapt.com without using a proxy?
Actually not.
I usually setup a ipmasqadm rule for outside, *AND* a port
redirector for inside. This works because ipmasqadm hooks before
redir will get the eventual outside connection, _but_ leaves things
ok if not (stated by APPROPIATE rules).
The actual "conceptual" problem comes from the TRUE client (peer) IP
goal (thanks to masq) being in the same net as target server.
The failing scenario for "local masq" is :
client: 192.168.2.100
masq: 192.168.2.1
serv: 192.168.2.10
1)client-&#62;server packet
a) client: 192.168.2.100:1025 -&#62; 192.168.2.1:80 [SYN]
b) (masq): 192.168.2.100:1025 -&#62; 192.168.2.10:80 [SYN]
(and keep 192.168.2.1:61000 192.168.2.100:1025 related)
c) serv: gets masqed packet (1b)
2)server-&#62;client packet
a) serv: 192.168.2.10:80 -&#62; 192.168.2.100:1025 [SYN,ACK]
b) client: 192.168.2.100:1025 -&#62; 192.168.2.10:80 [RST]
Now take a moment to compare (1a) with (2a).
You see, the server replied DIRECTLY to client bypassing masq (not
letting masq to UNDO the packet hacking) because it is in SAME net, so
the client resets the connection.
hope I helped.
Warm regards
Juanjo
</ProgramListing>
</para>
</Sect2>
<Sect2 id="portfwding-via-2.0.x-ipportfw">
<Title>IPPORTFW-based PORTFWD'ing: Using IPPORTFW on 2.0.x kernels</Title>
<para>
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
<XRef LinkEnd="ipmasq-compiling3.1.3"> for full details. Next, download the
"ipportfw.c" program and the "subs-patch-x.gz" kernel patch from
<XRef LinkEnd="ipmasq-compiling3.1.3"> into the /usr/src/ directory.
</para>
<para>
NOTE: Please replace the "x" in the "subs-patch-x.gz" file name with the
most current version available on the site.
</para>
<para>
Next, if you plan on port forwarding FTP traffic to an internal server, you
will have to apply an additional <Emphasis role="strong">NEW</Emphasis>
<Emphasis>IP_MASQ_FTP</Emphasis> module patch found in
<XRef LinkEnd="ipmasq-compiling3.1.3">. More details regarding this are later
in this section. Please note that this is NOT the same patch as for the 2.2.x
kernels so some functionality such as the dynamic FTP PORT functionality is
not present.
</para>
<para>
Now, copy the IPPORTFW patch (subs-patch-x.gz) into the Linux directory
<Screen>
cp /usr/src/subs-patch-1.37.gz /usr/src/linux
</Screen>
</para>
<para>
Next, apply the kernel patch to create the IPPORTFW kernel option:
<Screen>
cd /usr/src/linux
zcat subs-patch-1.3x.gz | patch -p1
</Screen>
</para>
<para>
Ok, time to compile the kernel as shown in
<XRef LinkEnd="ipmasq-compiling3.1.3">. Be sure to say YES to the IPPORTFW
option now available when you configure the kernel. Once the compile is
complete and you have rebooted, return to this section.
</para>
<para>
Now with a newly compiled kernel, please compile and install the actual
"IPPORTFW" program
<Screen>
cd /usr/src
gcc ipportfw.c -o ipportfw
mv ipportfw /usr/local/sbin
</Screen>
</para>
<para>
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.
</para>
<para>
<Emphasis role="strong">NOTE:</Emphasis> 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 <Emphasis role="strong">:8080
</Emphasis> to the URL to then contact the internal MASQed WWW server.
</para>
<para>
Anyway, to enable port forwarding, edit the <Emphasis role="strong">
/etc/rc.d/rc.firewall-*</Emphasis> ruleset. Add the follow lines but be sure
to replace the word "$extip" with your Internet IP address.
</para>
<para>
<Emphasis role="strong">NOTE #2:</Emphasis> If you get a dynamically assigned
TCP/IP address from your ISP (PPP, DSL, Cablemodems, etc.), you <Emphasis
role="strong">CANNOT load</Emphasis> 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-ipchains-stronger ruleset more
intelligent. To do this for various types of connections such as PPP or
DHCP users, please see the <XRef LinkEnd="masq-and-dyn-addr"> FAQ entry for all
the details.
</para>
<para>
/etc/rc.d/rc.firewall-*
<Screen>
#echo "Enabling IPPORTFW Redirection on the external LAN.."
#
# This will forward ALL port 80 traffic from the external IP address
# to port 80 on the 192.168.0.10 machine
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/80 -R 192.168.0.10/80
</Screen>
</para>
<para>
That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out!
</para>
<para>
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.
</para>
<para>
Port Forwarding FTP servers:
</para>
<para>
If you plan on port forwarding FTP to an internal machine, things get more
complicated. The reason for this is because the standard
<Emphasis role="strong">IP_MASQ_FTP</Emphasis> 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.
</para>
<para>
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.
</para>
<para>
So, to get the 2.0.x patch working, you need to:
</para>
<para>
<ItemizedList>
<listitem>
<para>
FIRST, apply the IPPORTFW kernel patch as shown earlier in this section.
</para>
</listitem>
<listitem>
<para>
Download the "msqsrv-patch-36" from Fred Viles's FTP server in
<XRef LinkEnd="ipmasq-compiling3.1.3">and put it into /usr/src/linux.
</para>
</listitem>
<listitem>
<para>
Patch the kernel with this new code by running "cat msqsrv-patch-36 &verbar;
patch -p1"
</para>
</listitem>
<listitem>
<para>
Next, replace the original <Emphasis role="strong">"ip_masq_ftp.c"</Emphasis>
kernel module with the new one
</para>
<para>
mv /usr/src/linux/net/ipv4/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c.orig
</para>
<para>
mv /usr/src/linux/ip_masq_ftp.c /usr/src/linux/net/ipv4/ip_masq_ftp.c
</para>
</listitem>
<listitem>
<para>
Lastly, build and install the kernel with this new code in place.
</para>
</listitem>
</ItemizedList>
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
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.
</para>
<para>
/etc/rc.d/rc.firewall-*
<Screen>
#echo "Enabling IPPORTFW Redirection on the external LAN.."
#
/usr/local/sbin/ipportfw -C
/usr/local/sbin/ipportfw -A -t$extip/21 -R 192.168.0.10/21
#NOTE: If you are using multiple local port numbers to PORTFW
# to multuple internal FTP servers (say, 21, 2121, 2112,
# etc, you need to configure the ip_masq_ftp nodule to
# listen to these ports. To do this, edit the
# /etc/rc.d/rc.firewall-* script as shown in this HOWTO
# to look like:
#
# /sbin/modprobe ip_masq_ftp ports=21,2121,2112
#
# Re-run the /etc/rc.d/rc.firewall-* script for these changes to
# take effect.
#Please note that PORTFWing port 20 is probably NOT required
# for ACTIVE connections as the internal FTP server will
# initiate this port 20 connection and it will be properly
# handled by the classic MASQ mechanisms.
</Screen>
</para>
<para>
That's it! Just re-run your /etc/rc.d/rc.firewall-* ruleset and test it out!
</para>
<para>
<Emphasis role="strong">PORTFW Redirection of Internal requests:</Emphasis>
</para>
<para>
It's not clear if the REDIR tool will compile or work against legacy 2.0.x
kernels. It should also be mentioned that this IPMASQ HOWTO currently does
*NOT* provide any explination or examples on how to use the REDIR tool. If
you need help setting it up, send me an email. If you would like to learn
more about REDIR, please see the above section for the 2.2.x kernels.
</para>
</Sect2>
</Sect1>
<Sect1 id="CuSeeme">
<Title>CU-SeeMe and Linux IP-Masquerade</Title>
<para>
Linux IP Masquerade supports CuSeeme via the <Emphasis role="strong">"ip_masq_cuseeme"
</Emphasis> 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.
</para>
<para>
NOTE: It is recommended to use the IPPORTFW tool instead of the old IPAUTOFW
tool for running CuSeeme.
</para>
<para>
If you need more explicit information on configuring CuSeeme, see
<ULink URL="http://www.swampgas.com/vc/ipmcus.htm">Michael Owings's CuSeeMe
page</ULink> for a Mini-HOWTO or <ULink URL="http://ipmasq.webhop.net/">The IP
Masquerade Resources</ULink> for a mirror of the Mini-HOWTO.
</para>
</Sect1>
<Sect1 id="ICQ">
<Title>Mirabilis ICQ </Title>
<para>
ICQ, the instant messaging client now owned by AOL, has changed over the
years. All modern ICQ clients are NAT friendly and thus DON'T require
any special NAT modules, PORTFW tricks, etc.
</para>
<para>
IF, for some reason, you want to run an OLD ICQ client, you can read this
section. If not, just IGNORE all this info. I am leaving this in the
HOWTO demonstrate large a LARGE PORTFW example.
</para>
<para>
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.
</para>
<para>
MODULE: The ICQ module was written for the older generation of ICQ clients
for 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 and
ports used for ICQ. Because of this, many users might find that the
ip_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.
</para>
<para>
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.
</para>
<para>
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 ICQ
clients to be reconfigured to use it and the installation and configuration
of a SOCKS server has nothing to do with IP Masquerade. Because of this,
SOCKS is not covered in this HOWTO.
</para>
<para>
If you are interested in Andrew Deryabin's <ULink URL="mailto:djsf@usa.net">
djsf@usa.net</ULink> ICQ IP Masq module for the 2.2.x and 2.0.x kernels,
please see <XRef LinkEnd="kernel-2.2.x-Requirements"> for details.
</para>
<para>
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.
</para>
<ItemizedList>
<listitem>
<para>
First, you need to be running a Linux kernel with IPPPORTFW enabled.
Please see <XRef LinkEnd="Forwarders">for more details.
</para>
</listitem>
<listitem>
<para>
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:
</para>
</listitem>
<listitem>
<para>
The following example is for a 2.2.x kernel with IPCHAINS:
</para>
<para>
I have included two examples here for the user: Either one would work
fine:
</para>
<para>
Example #1
<ProgramListing>
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2000 -R 192.168.0.10 2000
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2001 -R 192.168.0.10 2001
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2002 -R 192.168.0.10 2002
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2003 -R 192.168.0.10 2003
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2004 -R 192.168.0.10 2004
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2005 -R 192.168.0.10 2005
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2006 -R 192.168.0.10 2006
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2007 -R 192.168.0.10 2007
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2008 -R 192.168.0.10 2008
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2009 -R 192.168.0.10 2009
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2010 -R 192.168.0.10 2010
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2011 -R 192.168.0.10 2011
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2012 -R 192.168.0.10 2012
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2013 -R 192.168.0.10 2013
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2014 -R 192.168.0.10 2014
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2015 -R 192.168.0.10 2015
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2016 -R 192.168.0.10 2016
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2017 -R 192.168.0.10 2017
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2018 -R 192.168.0.10 2018
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2019 -R 192.168.0.10 2019
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 2020 -R 192.168.0.10 2020
</ProgramListing>
Example #2
<ProgramListing>
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipmasqadm portfw -a -P tcp -L 10.1.2.3 $port -R 192.168.0.10 $port
port=$((port+1))
done
</ProgramListing>
</para>
</listitem>
<listitem>
<para>
The following example is for a 2.0.x kernel with IPFWADM:
</para>
<para>
I have included two examples here for the user: Either one would work
fine:
</para>
<para>
Example #1
<ProgramListing>
/usr/local/sbin/ipportfw -A -t10.1.2.3/2000 -R 192.168.0.10/2000
/usr/local/sbin/ipportfw -A -t10.1.2.3/2001 -R 192.168.0.10/2001
/usr/local/sbin/ipportfw -A -t10.1.2.3/2002 -R 192.168.0.10/2002
/usr/local/sbin/ipportfw -A -t10.1.2.3/2003 -R 192.168.0.10/2003
/usr/local/sbin/ipportfw -A -t10.1.2.3/2004 -R 192.168.0.10/2004
/usr/local/sbin/ipportfw -A -t10.1.2.3/2005 -R 192.168.0.10/2005
/usr/local/sbin/ipportfw -A -t10.1.2.3/2006 -R 192.168.0.10/2006
/usr/local/sbin/ipportfw -A -t10.1.2.3/2007 -R 192.168.0.10/2007
/usr/local/sbin/ipportfw -A -t10.1.2.3/2008 -R 192.168.0.10/2008
/usr/local/sbin/ipportfw -A -t10.1.2.3/2009 -R 192.168.0.10/2009
/usr/local/sbin/ipportfw -A -t10.1.2.3/2010 -R 192.168.0.10/2010
/usr/local/sbin/ipportfw -A -t10.1.2.3/2011 -R 192.168.0.10/2011
/usr/local/sbin/ipportfw -A -t10.1.2.3/2012 -R 192.168.0.10/2012
/usr/local/sbin/ipportfw -A -t10.1.2.3/2013 -R 192.168.0.10/2013
/usr/local/sbin/ipportfw -A -t10.1.2.3/2014 -R 192.168.0.10/2014
/usr/local/sbin/ipportfw -A -t10.1.2.3/2015 -R 192.168.0.10/2015
/usr/local/sbin/ipportfw -A -t10.1.2.3/2016 -R 192.168.0.10/2016
/usr/local/sbin/ipportfw -A -t10.1.2.3/2017 -R 192.168.0.10/2017
/usr/local/sbin/ipportfw -A -t10.1.2.3/2018 -R 192.168.0.10/2018
/usr/local/sbin/ipportfw -A -t10.1.2.3/2019 -R 192.168.0.10/2019
/usr/local/sbin/ipportfw -A -t10.1.2.3/2020 -R 192.168.0.10/2020
</ProgramListing>
</para>
<para>
Example #2
<ProgramListing>
port=2000
while [ $port -le 2020 ]
do
/usr/local/sbin/ipportfw -A t10.1.2.3/$port -R 192.168.0.10/$port
port=$((port+1))
done
</ProgramListing>
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Now, in ICQ's Preferences--&#62;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 <XRef
LinkEnd="rc.firewall-ipfwadm">
and <XRef LinkEnd="rc.firewall-ipchains"> rulesets. Finally, click on Next
and configure ICQ to "Use the following TCP listen ports.." from "2000" to
"2020". Now click done.
</para>
<para>
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.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</Sect1>
<Sect1 id="LooseUDP">
<Title>Gamers: The LooseUDP patch</Title>
<para>
The LooseUDP patch allows semi-NAT-friendly games that usually use UDP
connections to both WORK behind a Linux IP Masquerade server.
</para>
<para>
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 modern
2.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. If
the 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.
</para>
<para>
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).
</para>
<para>
To get LooseUDP running on a 2.0.x kernel, follow the following steps:
<ItemizedList>
<listitem>
<para>
Have the newest 2.0.x kernel sources uncompressed in the /usr/src/linux directory
</para>
</listitem>
<listitem>
<para>
ABSOLUTELY REQUIRED for v2.0.x: Download and install the IPPORTFW patch from
<XRef LinkEnd="ipmasq-compiling3.1.3">and as described in
<XRef LinkEnd="Forwarders">of the HOWTO.
</para>
</listitem>
<listitem>
<para>
Download the LooseUDP patch from <XRef LinkEnd="ipmasq-compiling3.1.3">
</para>
<para>
Now, put the LooseUDP patch in the /usr/src/linux directory. Once this is
done, type in:
</para>
<para>
<Screen>
For a compressed patch file: zcat loose-udp-2.0.36.patch.gz &verbar; patch -p1
</Screen>
</para>
<para>
<Screen>
For a NON-compressed patch file: cat loose-udp-2.0.36.patch &verbar; patch -p1
</Screen>
</para>
<para>
Now, depending on the version of your "patch", You will then see the following text:
</para>
<para>
<Screen>
patching file `CREDITS'
patching file `Documentation/Configure.help'
patching file `include/net/ip_masq.h'
patching file `net/ipv4/Config.in'
patching file `net/ipv4/ip_masq.c'
</Screen>
</para>
</listitem>
<listitem>
<para>
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.
</para>
<para>
Once the patch is installed, re-configure the kernel as shown in
<XRef LinkEnd="ipmasq-compiling3.1.3"> and be sure to say "Y" to the
"IP: loose UDP port managing (EXPERIMENTAL) (CONFIG_IP_MASQ_LOOSE_UDP) [Y/n/?]"
option.
</para>
</listitem>
</ItemizedList>
</para>
<para>
To get LooseUDP running on a 2.2.x kernel, follow the following steps:
<ItemizedList>
<listitem>
<para>
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:
<Literal>echo "0" &#62; /proc/sys/net/ipv4/ip_masq_udp_dloose</Literal>
to a "1" and re-run the rc.firewall-* ruleset. An example of this is given in
both <XRef LinkEnd="rc.firewall-ipchains"> example and
<XRef LinkEnd="rc.firewall-ipfwadm-stronger"> example.
</para>
</listitem>
</ItemizedList>
</para>
<para>
NOTE: The LooseUDP code is /not/ available (?required?) for the 2.4.x kernels
<ItemizedList>
<listitem>
<para>
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.
</para>
</listitem>
</ItemizedList>
</para>
<para>
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
<XRef LinkEnd="Game-Clients"> for more details.
</para>
</Sect1>
</Chapter>
<!-- Section 7 -->
<Chapter id="FAQ">
<Title>Frequently Asked Questions</Title>
<para>
If you can think of any useful FAQ suggestions, please send it to
<ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink>. Please
clearly state the question and an appropriate answer (if you have it). Thank
you!
</para>
<Sect1 id="MASQ-supported-Distributions">
<Title>( Distro ) - What Linux Distributions support IP Masquerading?</Title>
<para>
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.
</para>
<para>
NOTE: If you can help us fill out this table, please email
<ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink>.
</para>
<para>
<ItemizedList>
<listitem>
<para>
Caldera &#60; v1.2 : NO - ?
</para>
</listitem>
<listitem>
<para>
Caldera v1.3 : YES - 2.0.35 based
</para>
</listitem>
<listitem>
<para>
Caldera v2.2 : YES - 2.2.5 based
</para>
</listitem>
<listitem>
<para>
Caldera eServer v2.3 : YES - ? based
</para>
</listitem>
<listitem>
<para>
Debian v1.3 : NO - ?
</para>
</listitem>
<listitem>
<para>
Debian v2.0 : NO - ?
</para>
</listitem>
<listitem>
<para>
Debian v2.1 : YES - 2.2.1 based
</para>
</listitem>
<listitem>
<para>
Debian v2.2 : YES - 2.2.15 based
</para>
</listitem>
<listitem>
<para>
Debian v3.0 : YES - 2.4.18 based
</para>
</listitem>
<listitem>
<para>
DLX Linux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
DOS Linux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
FloppyFW v1.0.2 : ? - ?
</para>
</listitem>
<listitem>
<para>
Gentoo v1.4 : YES - ? Based
</para>
</listitem>
<listitem>
<para>
Hal91 Linux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
Linux PPC vR4 : NO - ?
</para>
</listitem>
<listitem>
<para>
Linux Pro v? : ? - ?
</para>
</listitem>
<listitem>
<para>
LinuxWare v? : ? - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v5.3 : YES - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v6.0 : YES - 2.2.5
</para>
</listitem>
<listitem>
<para>
Mandrake v6.1 : YES - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v7.0 : YES - 2.2.14
</para>
</listitem>
<listitem>
<para>
Mandrake v7.1 : YES - 2.2.15
</para>
</listitem>
<listitem>
<para>
Mandrake v7.2 : YES - 2.2.17
</para>
</listitem>
<listitem>
<para>
Mandrake v8.0 : YES - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v8.1 : YES - 2.4.8
</para>
</listitem>
<listitem>
<para>
Mandrake v8.2 : YES - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v9.0 : YES - ?
</para>
</listitem>
<listitem>
<para>
Mandrake v9.1 : YES - 2.4.21-pre
</para>
</listitem>
<listitem>
<para>
MkLinux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
MuLinux v3rl : YES - ?
</para>
</listitem>
<listitem>
<para>
Redhat &#60; v4.x : NO - ?
</para>
</listitem>
<listitem>
<para>
Redhat v5.0 : YES - ?
</para>
</listitem>
<listitem>
<para>
Redhat v5.1 : YES - 2.0.34 based
</para>
</listitem>
<listitem>
<para>
Redhat v5.2 : YES - 2.0.36 based
</para>
</listitem>
<listitem>
<para>
Redhat v6.0 : YES - 2.2.5 based
</para>
</listitem>
<listitem>
<para>
Redhat v6.1 : YES - 2.2.12 based
</para>
</listitem>
<listitem>
<para>
Redhat v6.2 : YES - 2.2.14 based
</para>
</listitem>
<listitem>
<para>
Redhat v7.0 : YES - 2.2.16 based
</para>
</listitem>
<listitem>
<para>
Redhat v7.2 : YES - 2.4.7 based
</para>
</listitem>
<listitem>
<para>
Redhat v7.3 : YES - 2.4.? based
</para>
</listitem>
<listitem>
<para>
Redhat v8.0 : YES - 2.4.18? based
</para>
</listitem>
<listitem>
<para>
Redhat v9.0 : YES - 2.4.20 based
</para>
</listitem>
<listitem>
<para>
Slackware v3.0 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.1 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.2 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.3 : ? - 2.0.34 based
</para>
</listitem>
<listitem>
<para>
Slackware v3.4 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.5 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.6 : ? - ?
</para>
</listitem>
<listitem>
<para>
Slackware v3.9 : ? - 2.0.37pre10 based
</para>
</listitem>
<listitem>
<para>
Slackware v4.0 : YES - 2.2.6 based
</para>
</listitem>
<listitem>
<para>
Slackware v7.0 : YES - 2.2.13 based
</para>
</listitem>
<listitem>
<para>
Slackware v7.1 : YES - 2.2.16 based
</para>
</listitem>
<listitem>
<para>
Slackware v8.0 : YES - 2.4.17 based
</para>
</listitem>
<listitem>
<para>
Slackware v8.1 : YES - ? based
</para>
</listitem>
<listitem>
<para>
Stampede Linux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
SuSE v5.2 : YES - 2.0.32 base
</para>
</listitem>
<listitem>
<para>
SuSE v5.3 : YES - ?
</para>
</listitem>
<listitem>
<para>
SuSE v6.0 : YES - 2.0.36 based
</para>
</listitem>
<listitem>
<para>
SuSE v6.1 : YES - 2.2.5 based
</para>
</listitem>
<listitem>
<para>
SuSE v6.3 : YES - 2.2.13 based
</para>
</listitem>
<listitem>
<para>
Tomsrbt Linux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
TurboLinux Lite v4.0 : YES - ?
</para>
</listitem>
<listitem>
<para>
TurboLinux v6.0 : YES - 2.2.12 based
</para>
</listitem>
<listitem>
<para>
TriLinux v? : ? - ?
</para>
</listitem>
<listitem>
<para>
Yggdrasil Linux v? : ? - ?
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="FAQ-Hardware">
<Title>( Requirements ) - What are the minimum hardware requirements and any
limitations for IP Masquerade? How well does it perform?</Title>
<para>
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.
</para>
<para>
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 <XRef LinkEnd="No-Free-Ports"> of
the FAQ for more details.
</para>
<para>
While we are at it:
</para>
<para>
There is a hard limit of 4096 concurrent connections each for TCP &amp; UDP.
This limit can be changed by fiddling the values in <Emphasis role="strong">
/usr/src/linux/net/ipv4/ip_masq.h</Emphasis> - a maximum limit of 32000 should
by OK. If you want to change the limit - you need to change the PORT_MASQ_BEGIN
&amp; PORT_MASQ_END values to get an appropriately sized range above 32K and
below 64K.
</para>
</Sect1>
<Sect1 id="faq-command-not-found">
<Title>( Errors ) - When I run my specific rc.firewall-* ruleset, I get
"command not found" errors.
Why?</Title>
<para>
First off, when I say rc.firewall-*, what I really mean is to use one of the various
types of firewall rulesets depending on what kernel version you're running.
Your options from this HOWTO include: rc.firewall-iptables or rc.firewall-iptables-stronger
or rc.firewall-ipchains or rc.firewall-ipchains-stronger or rc.firewall-ipfwadm
or rc.firewall-ipfwadm-stronger.
</para>
<para>
Next, how did you put the rc.firewall-* onto your machine? Did you cut&amp;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 &circ;M. If they do, delete all the &circ;M and try again.
</para>
</Sect1>
<Sect1 id="still-wont-work">
<Title>( Still wont work ) - I've checked all my configurations, I still can't get IP Masquerade to
work. What should I do?</Title>
<para>
<ItemizedList>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Again, go through all the steps in <XRef LinkEnd="Testing">. 99% of all
first-time Masquerade users who have problems haven't looked here.
</para>
</listitem>
<listitem>
<para>
Check the <ULink
URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade Mailing List
Archives</ULink>, most likely your questions or problems are a common one and
can be found in a simple Archive search.
</para>
</listitem>
<listitem>
<para>
Check out the <ULink
URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS"
>TrinityOS</ULink> document. It covers IP Masquerading for both the 2.0.x and
2.2.x kernels and MANY other topics including PPPd, DialD, DHCP, DNS, Sendmail,
etc.
</para>
</listitem>
<listitem>
<para>
Make sure that you aren't running ROUTED or GATED. To verify, run "ps aux
&verbar; grep -e routed -e gated"
</para>
</listitem>
<listitem>
<para>
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
<XRef LinkEnd="Testing"> in your email!!
</para>
</listitem>
<listitem>
<para>
Post your question to a related Linux NNTP newsgroup.
</para>
</listitem>
<listitem>
<para>
Send email to <ULink URL="mailto:ambrose@writeme.com">ambrose@writeme.com
</ULink> and <ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink>.
You have a better chance of getting a reply from the IP Masquerading Email
list than either of us.
</para>
</listitem>
<listitem>
<para>
Check your configurations again :-)
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="Masq-List">
<Title>( Email list ) - How do I join or view the IP Masquerade and/or IP Masqurade Developers
mailing lists and archives?</Title>
<para>
There are two ways to join the two Linux IP Masquerading mailing lists. The
first way is to send an email to <ULink URL="mailto:masq-request@indyramp.com">
masq-request@indyramp.com</ULink>. To join the Linux IP Masquerading Developers
mailing list, send an email to <ULink URL="mailto:masq-dev-request@indyramp.com">
masq-dev-request@indyramp.com</ULink>. Please see the bullet below for more
details.
</para>
<para>
<ItemizedList>
<listitem>
<para>
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.
</para>
<para>
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.
</para>
</listitem>
</ItemizedList>
</para>
<para>
The second method is to use a WWW browser and subscribe via a form at
<ULink
URL="http://home.indyramp.net/mailman/listinfo/masq">http://home.indyramp.net/mailman/listinfo/masq</ULink>
for the main MASQ list or <ULink URL="http://home.indyramp.net/mailman/listinfo/masq-dev">
http://home.indyramp.net/mailman/listinfo/masq-dev</ULink> for the MASQ-DEV list.
</para>
<para>
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.
</para>
<para>
Lastly, please note that you can only post to the MASQ list from the original
account/address you used to subscribe.
</para>
<para>
If you have any problems regarding the mailing list or the mailing list
archive, please contact <ULink URL="mailto:masq-owner@indyramp.com">Robert
Novak</ULink>.
</para>
</Sect1>
<Sect1 id="what-is-masq">
<Title>( NAT vs. Proxy ) - How does IP Masquerade differ from Proxy or NAT services? </Title>
<para>
<ProgramListing>
Proxy: Proxy servers are available for: Win95, NT, Linux, Solaris, etc.
Pro: + (1) IP address ; cheap
+ Optional caching for better performance (WWW, etc.)
Con: - All applications behind the proxy server must both SUPPORT
proxy services (SOCKS) and be CONFIGURED to use the Proxy
server
- Screws up WWW counters and WWW statistics
A proxy server uses only (1) public IP address, like IP MASQ, and acts
as a translator to clients on the private LAN (WWW browser, etc.).
This proxy server receives requests like TELNET, FTP, WWW,
etc. from the private network on one interface. It would then in turn,
initiate these requests as if someone on the local box was making the
requests. Once the remote Internet server sends back the requested
information, it would re-translate the TCP/IP addresses back to the
internal MASQ client and send traffic to the internal requesting host.
This is why it is called a PROXY server.
Note: ANY applications that you might want to use on the
internal machines *MUST* have proxy server support
like Netscape and some of the better TELNET and FTP
clients. Any clients that don't support proxy servers
won't work.
Another nice thing about proxy servers is that some of them
can also do caching (Squid for WWW). So, imagine that you have 50
proxied hosts all loading Netscape at once. If they were installed
with the default homepage URL, you would have 50 copies of the same
Netscape WWW page coming over the WAN link for each respective computer.
With a caching proxy server, only one copy would be downloaded by the
proxy server and then the proxied machines would get the WWW page from
the cache. Not only does this save bandwidth on the Internet
connection, it will be MUCH MUCH faster for the internal proxied
machines.
MASQ: IP Masq is available on Linux and a few ISDN routers such
or as the Zytel Prestige128, Cisco 770, NetGear ISDN routers, etc.
1:Many
NAT
Pro: + Only (1) IP address needed (cheap)
+ Doesn't require special application support
+ Uses firewall software so your network can become
more secure
Con: - Requires a Linux box or special ISDN router
(though other products might have this.. )
- Incoming traffic cannot access your internal LAN
unless the internal LAN initiates the traffic or
specific port forwarding software is installed.
Many NAT servers CANNOT provide this functionality.
- Special protocols need to be uniquely handled by
firewall redirectors, etc. Linux has full support
for this (FTP, IRC, etc.) capabilty but many routers
do NOT (NetGear DOES).
Masq or 1:Many NAT is similar to a proxy server in the sense that the
server will perform IP address translation and fake out the remote server
(WWW for example) as if the MASQ server made the request instead of an
internal machine.
The major difference between a MASQ and PROXY server is that MASQ servers
don't need any configuration changes to all the client machines. Just
configure them to use the linux box as their default gateway and everything
will work fine. You WILL need to install special Linux modules for things
like RealAudio, FTP, etc. to work)!
Also, many users operate IP MASQ for TELNET, FTP, etc. *AND* also setup a
caching proxy on the same Linux box for WWW traffic for the additional
performance.
NAT: NAT servers are available on Windows 95/NT, Linux, Solaris, and some
of the better ISDN routers (not Ascend)
Pro: + Very configurable
+ No special application software needed
Con: - Requires a subnet from your ISP (expensive)
Network Address Translation is the name for a box that would have a pool of
valid IP addresses on the Internet interface which it can use. Whenever the
Internal network wanted to go to the Internet, it associates an available
VALID IP address from the Internet interface to the original requesting
PRIVATE IP address. After that, all traffic is re-written from the NAT
public IP address to the NAT private address. Once the associated PUBLIC
NAT address becomes idle for some pre-determined amount of time, the
PUBLIC IP address is returned back into the public NAT pool.
The major problem with NAT is, once all of the free public IP addresses are
used, any additional private users requesting Internet service are out of
luck until a public NAT address becomes free.
</ProgramListing>
</para>
<para>
For an excellent and very comprehensive description of the various forms of
NAT, please see:
<ItemizedList>
<listitem>
<para>
<ULink URL="http://www.suse.de/~mha/linux-ip-nat/diplom/nat.html">http://www.suse.de/~mha/linux-ip-nat/diplom/nat.html/</ULink>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Here is another good site to learn about NAT, although many of the URLs are
old but still valid:
<ItemizedList>
<listitem>
<para>
<ULink URL="http://www.linas.org/linux/load.html">http://www.linas.org/linux/load.html/</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="gui-tools">
<Title>( GUI ) - Are there any GUI firewall creation/management tools? </Title>
<para>
Yes! They vary in the type of user interface, complexity, etc. but they are
quite good though most are only for the IPFWADM tool so far. Here is a short
list of available tools in alphabetical order. If you know of any others or
have any thoughts on which ones are good/bad/ugly, please email David.
</para>
<para>
<ItemizedList>
<listitem>
<para>
John Hardin's <ULink URL="http://www.impsec.org/~jhardin/">IPFWADM Dot
file generator</ULink> - a IPCHAINS version is in the works
</para>
</listitem>
<listitem>
<para>
Sonny Parlin's <ULink URL="http://www.innertek.com">fBuilder</ULink>: From the
author of FWCONFIG, this new solution is fully WWW based and offers redundancy
options, etc for both IPCHAINS and NetFilter.
</para>
</listitem>
<listitem>
<para>
William Stearns's <ULink URL="http://www.pobox.com/~wstearns/mason/">Mason
</ULink> - A Build-a-ruleset on-the-fly type system
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="masq-and-dyn-addr">
<Title>( MASQ and Dynamic IPs ) - Does IP Masquerade work with dynamically
assigned IP addresses? </Title>
<para>
<Emphasis role="strong">Yes</Emphasis>, it works with either dynamic IP
addressed assigned by your ISP via either PPP or a DHCP server (common for
Cablemodem and DSL users). As long as you have a valid Internet IP address,
it should work. Of course, static IPs work too. If you plan on implementing
a strong IPTABLES, IPCHAINS, or IPFWADM ruleset and/or plan on using a Port
forwarder, your ruleset will have to be re-executed everytime your IP address
changes.
</para>
<para>
So, re-running the rc-firewall-* ruleset really depends on which method you
get your IP addresses:
</para>
<para>
<ItemizedList>
<listitem>
<para>
PPP: The /etc/ppp/ip-up script is always run when a PPP connection comes
up. Because of this, we can make the rc.firewall-* go get the new PPP IP
address and update the firewall ruleset. If the /etc/ppp/ip-up file doesn't
exist or if does exists, simply edit that file and append a line containing
the name of your chosen firewall ruleset. For example, to run the SIMPLE
IPTABLES ruleset:
</para>
<para>
<screen>
/etc/rc.d/rc.firewall-iptables
</screen>
</para>
</listitem>
<listitem>
<para>
DHCP: If you get your IP address via DHCP, common for Cablemodem and DSL
users, it's easy get the rc.firewall-* ruleset to run when you get a new
IP lease. How this happens depends on what DHCP client your distribution
uses:
<itemizedlist>
<listitem>
<para>
<Emphasis role="strong">dhclient</Emphasis> : Most modern Linux distributions
use dhclient from ISC. To re-run your specific rc-firewall-* script when your
system gets a new IP address, add the following line to the
/etc/dhclient-exit-hooks file. Please note that this example is loging the
SIMPLE IPTABLES ruleset. Please use the correct rc.firewall-* name for your
specific setup:
<screen>
/etc/rc.d/rc.firewall-iptables
</screen>
</para>
</listitem>
<listitem>
<para>
<Emphasis role="strong">pump</Emphasis> : Many older Redhat distributions use
this DHCP client. To re-run the rc-firewall-* script when your system gets a
new IP address, add the following line to the /etc/pump.conf file. Please
note that this example is loading the SIMPLE IPTABLES ruleset. Please use the
correct rc.firewall-* name for your specific setup:
<screen>
script /etc/rc.d/rc.firewall-iptables
</screen>
</para>
</listitem>
<listitem>
<para>
<Emphasis role="strong">dhcpcd</Emphasis> : Many older distros use this DHCP
client. To re-run the rc-firewall-* script when your system gets a new IP
address depends on which verion of dhcpcd you're using.
</para>
<para>
For newer dhcpcd client versions, append the following line to the
/etc/dhcpcd-[interface].exe file. Please note that you have to replace the
[interface] text with the name of your Interface connecting to the Internet.
For this example, we are going run the SIMPLE IPTABLES ruleset against the
eth0 interface by editing the /etc/dhcpc/dhcpcd-eth0.exe file:
<screen>
/etc/rc.d/rc.firewall-iptables
</screen>
</para>
<para>
For old dhcpcd client versions, you need to figure out what script starts up
dhcpcd (depends on the Linux distribution and it's version). From there, you
need to replace the specific dhcpcd line with the folling line with the
correct Internet-facing interface name. For this example, dhcpcd will run
the SIMPLE IPTABLES ruleset against the eth0 interface:
<screen>
dhcpcd -c /etc/rc.d/rc.firewall eth0
</screen>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Please also see the top of
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">TrinityOS - Section 10</ULink>
for additional help with strong firewall rulesets and Dynamic IP addresses.
</para>
</Sect1>
<Sect1 id="diff-network-support">
<Title>( MASQ and various networks ) - Can I use a cable modem (both
bi-directional and with modem returns), DSL, satellite link, etc. to connect
to the Internet and use IP Masquerade?</Title>
<para>
<Emphasis role="strong">Yes</Emphasis>, as long as Linux supports that network
interface, it should work. If you receive a dynamic IP address, please see the
URL under the "Does IP Masquerade work with dynamically assigned IP" FAQ item
above.
</para>
</Sect1>
<Sect1 id="masq-and-dod">
<Title>( Dial on Demand ) - Can I use Diald or the Dial-on-Demand feature of
PPPd with IP MASQ?</Title>
<para>
Definitely! IP Masquerading is totally transparent to Diald or PPP. The only
thing that might become an issue is if you use STRONG firewall rulesets with
dynamic IP addresses. See the FAQ item, "Does IP Masquerade work with
dynamically assigned IP addresses?" above for more details. </para>
</Sect1>
<Sect1 id="masq-supported-apps">
<Title>( Apps ) - What applications are supported with IP Masquerade?</Title>
<para>
It is very difficult to keep track of a list of "working applications".
However, most of the normal Internet applications are supported, such as WWW
browsing (Netscape, MSIE, etc.), FTP (such as WS_FTP), TELNET, SSH, RealAudio,
POP3 (incoming email - Pine, Eudora, Outlook), SMTP (outgoing email), etc. A
somewhat more complete list of MASQ-compatible clients can be found in
<XRef LinkEnd="Supported-Client-Software"> in this HOWTO.
</para>
<para>
Applications involving more complicated protocols or special connection methods
such as video conferencing software need special helper tools.
</para>
<para>
For more details, please see the
<ULink URL="http://www.tsmservices.com/masq/">Linux IP masquerading Applications</ULink>
page.
</para>
</Sect1>
<Sect1 id="distro-specific">
<Title>( Distro Setup ) - How can I get IP Masquerade running on Redhat,
Debian, Slackware, etc.?</Title>
<para>
No matter which Linux distribution you have, the procedures for setting up IP
Masquerade mentioned in this HOWTO should apply. Some distributions may have
GUI or special configuration files that make the setup easier. We tried our
best to write this HOWTO as general as possible.
</para>
</Sect1>
<Sect1 id="masq-timeouts">
<Title>( Timeouts ) - Connections seem to break if I don't use them often.
Why is that?</Title>
<para>
IP Masq, by default, sets its timers for TCP session, TCP FIN, and UDP traffic
to 15 minutes. It is recommend to use the following settings (as already shown
in this HOWTO's /etc/rc.d/rc.firewall-* ruleset) for most users:
</para>
<para>
Linux 2.4.x with IPTABLES
</para>
<para>
<screen>
IPMASQ timeouts are NOT adjustable under IPTABLES
</screen>
</para>
<para>
Linux 2.2.x with IPCHAINS:
</para>
<para>
<screen>
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec
# firewall timeout in ICQ itself)
#
/ipchains -M -S 7200 10 60
</screen>
</para>
<para>
Linux 2.0.x with IPFWADM:
</para>
<para>
<screen>
# MASQ timeouts
#
# 2 hrs timeout for TCP session timeouts
# 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
# 60 sec timeout for UDP traffic (MASQ'ed ICQ users must enable a 30sec
# firewall timeout in ICQ itself)
#
/sbin/ipfwadm -M -s 7200 10 60
</screen>
</para>
</Sect1>
<Sect1 id="masq-behavior">
<Title>( Odd Behavior ) - When my Internet connection first comes up, nothing
works. If I try again, everything then works fine. Why is this?</Title>
<para>
The reason is because you have a dynamic IP address and when your Internet
connection first comes up, IP Masquerade doesn't know its IP address. There is
a solution to this. In your /etc/rc.d/rc.firewall-* ruleset, add the following:
</para>
<para>
<screen>
# Dynamic IP users:
#
# If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this
# following option. This enables dynamic-ip address hacking in IP MASQ, making
# the life with Diald and similar programs much easier.
#
echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
</screen>
</para>
</Sect1>
<Sect1 id="MTU-issues">
<Title>( MTU ) - IP MASQ seems to be working fine but some sites don't work.
This usually happens with WWW and some FTP sites.</Title>
<para>
Depending on what Linux kernel version you are running on the MASQ server,
some will people disagree on the real problem. The two following arguments
have valid points, are inter-related, and users from each camp continue to
debate this to this day.
<ItemizedList>
<listitem>
<para>
With modern 2.4.x Linux systems, most users point their finger at the
adminstrators of these remote broken sites (typically SSL-encrypted WWW
sites, etc.) or your MASQ server's upstream router run by your ISP. The
main though it that these machines are either filtering or not properly
responding to SOME or ALL FORMS of ICMP packets (specifically ICMP Code 3
Type 4 - Fragmentation Needed) messages due to a fray of misplaced security
paranoia.
</para>
<para>
What does that all mean? Basically, say your machine is connected to the
Internet with a MTU of 1492 bytes (Maximum Transmission Unit -- the maximum
packet size your computer can transmit) which is common for PPPoE users.
At the same time, the remote WWW/FTP site is connected to the Internet at a
MTU of 1500 bytes. The way that TCP/IP works is that when a TCP connection
is being negotiated for your HTTP / FTP connection, the remote side will
try to verify that a 1500 byte packet can reach your computer via the
initial TCP "SYN" packet.
</para>
<para>
Since the packet is too big for your connection, your upstream router (run
by your ISP) will send a ICMP 3:4 (fragmentation needed) packet back to the
remote WWW / FTP server. Within this packet is a recommended smaller MTU
size to retry with. The problem is that either your local upstream router,
some router between you and the remote server, or the remote HTTP / FTP
server is either misconfigured or has a firewall in front of it that is
BLOCKing these ICMP packets.
</para>
</listitem>
<listitem>
<para>
The final UNCOMMON possibility is a debatable 2.0 / 2.2 kernel bug in the
IPMASQ code. Some users point their finger to the fact that IPMASQ might
have problems with ICMP packets that have the DF or "Don't Fragment" bit set.
Basically, when a MASQ box connects to the Internet with an MTU of anything
less than 1500, some packets will have the DF field set. Though changing
the MTU of the MASQ server's Internet link to 1500 seemingly fixes the
problem, the possible bug is still there. What is believed to be happening
in these older kernels is that the MASQ code is not properly re-writing the
return IP addresses of the ICMP 3 Sub 4 code packets back to the originating
MASQed computer. Because of this, these critical packets get dropped.
</para>
</listitem>
</ItemizedList>
</para>
<para>
No worries though. A there are several perfectly good ways to fix this
nasty MTU problem:
<ItemizedList>
<listitem>
<para>
Enable PMTU clamping in PPPoE
</para>
<para>
This solution is mostly for modern 2.4.x and 2.2.x kernel users connected
to the Internet via a PPPoE DSL or Cablemodem connections. This solution
allows for changes to be done ONLY on the MASQ server itself and not on all
of the internal MASQ clients.
</para>
</listitem>
<listitem>
<para>
Enable PMTU clamping via IPTABLES
</para>
<para>
This solution is only modern 2.4.x kernel users connected via ANY type
of Internet connection. This solution allows for changes to be done ONLY on
the MASQ server itself and not on all of the internal MASQ clients.
</para>
</listitem>
<listitem>
<para>
Change your MASQ server's Internet Link MTU
</para>
<para>This solution will work for any Linux kernel version but is NOT a
solution if you have a PPPoE connection for DSL or Cablemodem users.
</para>
<para>
It should be noted that some users will balk at this solution because it
can hurt some latency specific programs like TELNET and Internet games but
the impact is only slight. On the other hand, most HTTP and FTP traffic
will SPEED UP!
</para>
</listitem>
<listitem>
<para>
Change the MTU of all internal MASQed machines
</para>
<para>
This solution requires the most work as you have to make minor changes to
ALL of the internal IPMASQed machines. Basically, you would be changing the
MTU on all of the internal machines to match the MTU of your MASQ server's
Internet connection. Fortunately, this solution is usually bulletproof
where as some of the other solutions mentioned in this section might rarely
not work.
</para>
</listitem>
</ItemizedList>
</para>
<Sect2>
<Title>Enabling PMTU Clamping for PPPoE and some PPP Users:</Title>
<para>
For those users who use PPPoE clients for (DSL / Cablemodem) or PPP (Dialup),
your Internet connection is NOT "eth0" (for example) but usually "ppp0".
In addition to this, your Internet link's MTU or Maximum Transmission Unit
(largest packet you can transmit over the Internet) isn't 1500 bytes but
1492. The 1492 byte MTU comes from the link size of Ethernet (1518 bytes) -
Ethernet MAC overhead (18) = 1500. Then you subtract the PPPoE header (8
bytes) == MTU of 1492. This overhead isn't a big deal but sometimes ISPs or
remote Internet sites do stupid things to break PPPoE or non-1500 byte MTU
connected machines.
</para>
<para>
You can find more info about this topic on the web. Specifically, here is
good presentaion on the topic:
<ULink URL="http://www.phildev.net/mss/mss-talk.pdf">mss-talk presentation
(PDF)</ULink>. Here is the entire
<ULink URL="http://www.phildev.net/mss/lisa.html">Write
up and other good info</ULink>
</para>
<para>
To enable clamping in both the RP or PPPd PPPoE clients, add the following
line to your /etc/ppp/pppoe.conf file:
<screen>
# - If you have a computer acting as a gateway for a LAN, choose "1412".
# The setting of 1412 is safe for either setup, but uses slightly more
# CPU power.
#
CLAMPMSS=1412
</screen>
</para>
</Sect2>
<Sect2>
<Title>Clamping the MSS via IPTABLES:</Title>
<para>
As mentioned above for PPPoE users, some ISPs and WWW sites filter critical
ICMP packets like MTU Path Discovery. Because of this, many users might find
more Internet sites work but others hang or work poorly. Fortunately,
recent IPTABLES have added PMTU Clamping support which should help you. If
your using IPTABLES and think you're hitting this issue, try adding the
following line to the end of your rc.firewall-iptables ruleset. It should be noted
that there is no PMTU clamping support in IPCHAINS.
<screen>
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
</screen>
</para>
<para>
If this line causes an error when you re-run the rc.firewall-iptables* firewall
rulesets, you might need to upgrade your version of IPTABLES which includes
the "TCPMSS" IPTABLES module.
</para>
</Sect2>
<Sect2>
<Title>Changing the External MTU of the MASQ server:</Title>
<para>
This solution usually only applies to DIALUP users since PPPoE users cannot
INCREASE their MTU because of PPPoE's header overhead.
</para>
<para>
To use this solution, first see what your current MTU for your Internet link
is. To do so, run "/bin/ifconfig" on the MASQ server. Look at the lines
that corresponds to your Internet connection and look for the MTU (for
example, ppp0). This NEEDs to be set to 1500. Usually, Ethernet links
will default to 1500 for Ethernet but serial / DIALUP modem PPP links might
default to 576.
</para>
<para>
<ItemizedList>
<listitem>
<para>
To change the MTU on a standard Ethernet link to your bridged or routed
DSL, Cablemodem, etc. connection, you need to edit the correct network
startup scripts for your Linux distribution. Please see the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS - Section 16</ULink> document for network optimizations.
</para>
</listitem>
<listitem>
<para>
To change the MTU issue on a PPP (not PPPoE) Internet link, edit your
"/etc/ppp/options" file and towards the top, add the following text on two
seperate lines, add:
<screen>
mtu 1500
mru 1500
</screen>
</para>
<para>
Save these new changes and then restart PPP. Like shown above, verify that
your PPP link has the correct MTU and MTU.
</para>
<para>
CUA Users: Lastly, though this isn't a common problem, some Linux 2.0.x
kernel users have found a MTU solution to the following problem. With PPP
users, verify what port is your PPPd code connecting to. Is it a /dev/cua*
port or a /dev/ttyS* port? It NEEDS to be a /dev/ttyS* port as the
/dev/cua* device ststem has been deprecated and it breaks some things in
very odd ways.
</para>
</listitem>
</ItemizedList>
</para>
</Sect2>
<Sect2>
<Title>Changing the MTU of various operating systems:</Title>
<para>
If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external
Internet link's MTU (for example, 1492 for PPPoE users), everything should
work fine and this method is sometimes the MOST EFFECTIVE way of fixing things.
This is including ALL of the solutions mentioned above. But doing things this
way can be a lot of work if there are lots of internal MASQed machines or be
even impossible to do if you don't have administrative access to all the
internal MASQed machines.
</para>
<para>
Follow these simple steps for your respective operating system:
</para>
<para>
The follow examples utilize an MTU of 1492 for typical PPPoE connections for
some DSL and Cablemodem users. It is recommended to use the HIGHEST values
possible for all connections that are 128Kb/s and faster.
It should be noted that some PPPoE ISPs might require an MTU setting of 1460
(not 1492) for proper connectivity due to additional overhead in the ISP's
internal network.
</para>
<para>
The only real reason to use smaller MTUs than 1492 or 1460 is to lower your
Internet link's latency but at the cost of throughput. Please see
<ULink URL="http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu">
http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu</ULink>
for more details on this topic.
</para>
<para>
If you know how to make similar changes like these to other
OSes like OS/2, MacOS, etc. please email <ULink URL="mailto:dranch@trinnet.net">
David Ranch</ULink> so it can be included in the HOWTO.
</para>
<Sect3>
<Title>Changing the MTU on Linux:</Title>
<para>
<ProgramListing>
------------------------------------------
1. The setting of MTU can vary from Linux distribution to distribution.
For Redhat: You need to edit the various "ifconfig" statements in
the /sbin/ifup script
For Slackware: You need to edit the various "ifconfig" statements in
the /etc/rc.d/rc1.inet
2. Here is one good, any-distribution-will-work example, edit the
/etc/rc.d/rc.local file and put the following at the END of the file:
echo "Changing the MTU of ETH0"
/sbin/ifconfig eth0 mtu 1492
Replace "eth0" with the interface name that is the machine's upstream
connection which is connected to the Internet.
3. For advanced options like "TCP Receive Windows" and such, detailed examples
on how to edit the respective networking scripts for your specific Linux
distro, etc., please see Chapter 16 of
http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows 2000</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Navigate down to the key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\&#60;ID for Adapter&#62;
Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway,
subnet mask, etc. Find the key one that is for your network card.
5. Create the following Entry:
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp?LN=EN-US&amp;SD=gn&amp;FR=0
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 2000, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows NT 4.x</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Create the following keys in the Registry trees, choose two
possible Registry trees. Multiple entries are for various
network devices like DialUp Networking (ppp), Ethernet NICs,
PPTP VPNs, etc.
http://support.microsoft.com/support/kb/articles/Q102/9/73.asp?LN=EN-US&amp;SD=gn&amp;FR=0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
and
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\&#60;Adapter-name&#62;\Parameters\Tcpip]
Replace "&#60;Adapter-Name&#62;" with the respective name of your uplink LAN NIC
interface
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal&#62;")
(Do NOT include the quotes)
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 4.x, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to make the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows 98: </Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. You should make a backup copy of your Registry before doing anything. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry--&#62;Export Registry
File--&#62;Save a copy of your registry" would only perform Registry MERGES
and NOT do a replacement.
4. Search though each of the Registry trees that end in "n" (e.g. 0007)
and have a Registry entry called "IPAddress" which has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=STRING
name="MaxMTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=STRING
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal&#62;")
type=STRING
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal&#62;")
6. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows 95: </Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. You should make a backup copy of your Registry before continuing. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry--&#62;Export Registry
File--&#62;Save a copy of your registry" would only do Registry MERGES and NOT
do a replacement.
4. Search through each of the Registry trees that end in "n" (e.g. 0007)
and have a Registry entry called "IPAddress", which has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=DWORD
name="MaxMTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
type=DWORD
name="MaxMSS" (Do NOT include the quotes)
value=1450 (Decimal) (Do NOT include the text "(Decimal&#62;")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=DWORD
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal&#62;")
type=DWORD
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal&#62;")
6. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
</Sect2>
</Sect1>
<Sect1 id="masqed-ftp">
<Title>( FTP ) - MASQed FTP clients don't work. </Title>
<para>
Check to see that the "ip_masq_ftp" module is loaded. To do this, log into the
MASQ server and run the command "/sbin/lsmod". If you don't see the
"ip_masq_ftp" module loaded, make sure that you followed the BASIC
/etc/rc.d/rc.firewall-* recommendations found in
<XRef LinkEnd="firewall-examples">.
If you are implementing your own ruleset, make sure you include most of the
examples from the HOWTO or you will have many susequent problems.
</para>
</Sect1>
<Sect1 id="masq-performace">
<Title>( Performance ) - IP Masquerading seems slow</Title>
<para>
There might be a few reasons for this:
<ItemizedList>
<listitem>
<para>
You might be unrealistic about how much available bandwidth is on your modem
line. Lets do the math for a typical 56k modem connection:
</para>
<para>
<OrderedList>
<listitem>
<para>
56k modems = 56,000 bits per second.
</para>
</listitem>
<listitem>
<para>
You really DON'T have a 56k modem but a 52k modem per US FCC limitations.
</para>
</listitem>
<listitem>
<para>
You'll almost NEVER get 52k, the best connection I used to get was &nbsp;48k
</para>
</listitem>
<listitem>
<para>
48,000 bits per second is 4,800 BYTES per second (8 bits to a byte +
2 bits for the START and STOP RS-232 serial bits)
</para>
</listitem>
<listitem>
<para>
With an MTU of 1500, you will get (3.2) packets in one second. Since
this will involve fragmentation, you need to round DOWN to (3) packets per
second.
</para>
</listitem>
<listitem>
<para>
Again with MTU of 1500, thats 3.2 x 40 bytes of TCP/IP overhead (8%)
</para>
</listitem>
<listitem>
<para>
So the BEST throughput you could hope for is 4.68KB/s w/o compression.
Compression, be it v.42bis hardware compression, MNP5, or MS/Stac compression
can yeild impressive numbers on highly compressable stuff like TEXT files, but
acutally slow things down when transfering pre-compressed files like ZIPs,
MP3s, etc.
</para>
</listitem>
</OrderedList>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Ethernet attached setups (DSL, Cablemodem, LANs, etc)
<ItemizedList>
<listitem>
<para>
Make sure you don't have both your INTERNAL and EXTERNAL networks running on
the same network card with the "IP Alias" feature. If you
<Emphasis role="strong">ARE</Emphasis> doing this, it can be made to work
but it will be excessively slow due to high levels of collisions, IRQ usage,
etc. It is highly recommended that you install another network card for the
internal and external networks to have their own interface.
</para>
</listitem>
<listitem>
<para>
Make sure you have the right Ethernet settings for both SPEED and DUPLEX.
</para>
</listitem>
<listitem>
<para>
Some 10Mb/s Ethernet cards and most 100Mb/s cards support FULL Duplex
connections. Direct connections from an Ethernet card to, say, a DSL modem
(without any hubs in between) *CAN* be set to FULL DUPLEX but only if the
DSL modem supports it. You should also be sure that you have Ethernet cables
with all eight wires used and that they are in good condition.
</para>
<para>
Internal networks that use HUBs -cannot- use Full Duplex. You need either a
10 or 100Mb.s Ethernet <Emphasis role="strong">SWITCH</Emphasis> to be able
to do this.
</para>
<para>
Both auto 10/100Mb/s SPEED negotiation and Full/Half DUPLEX negotiation on
Ethernet cards can wreck havoc on networks. I recommend to hard code both the
NIC speed and duplex into the NIC(s) if possible. This is directly possible
via Linux NIC kernel modules but isn't directly possible in monolithic kernels.
You will need to either use MII utililies from
<XRef LinkEnd="Donald-Beckers-NIC-drivers-and-utils-FAQ-HW"> or hardcode the
kernel source.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Optimize your MTU and set the TCP Sliding window to at least 8192
<ItemizedList>
<listitem>
<para>
Though this is COMPLETELY out of the scope of this document, this helps QUITE A
BIT with ANY network link you have, be it an internal or external PPP, Ethernet,
TokenRing, etc. link. For more details, this topic is briefly touched in an
above section in <XRef LinkEnd="MTU-issues">. For even more details, check
out the Network Optimization section of
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS"
>TrinityOS - Section 16</ULink
>.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Serial based modem users with PPP
<ItemizedList>
<listitem>
<para>
If you have an external modem, make sure you have a good serial cable. Also,
many PCs have cheesy ribbon cables connecting the serial port from the
motherboard or I/O card to the serial port connection. If you have one of
these, make sure it is in good condition. Personally, I have ferrite coils
(those grey-black metal like rings) around ALL of my ribbon cables.
</para>
</listitem>
<listitem>
<para>
Make sure your MTU is set to 1500 as described in the FAQ section of this
HOWTO above
</para>
</listitem>
<listitem>
<para>
Make sure that your serial port is a 16550A or better UART. Run
"dmesg &verbar; more" to verify
</para>
</listitem>
<listitem>
<para>
Setup IRQ-Tune for your serial ports.
</para>
<para>
On most PC hardware, the use of Craig Estey's
<ULink URL="http://cae.best.vwh.net/irqtune/"> IRQTUNE</ULink> tool and
significantly increase serial port performance including SLIP and PPP
connections.
</para>
</listitem>
<listitem>
<para>
Make sure that your serial port for your PPP connection is running at 115200
(or faster if both your modem and serial port can handle it.. a.k.a ISDN
terminal adapters)
<ItemizedList>
<listitem>
<para>
2.0.x kernels: The 2.0.x kernels are kind of an odd ball because you can't
directly tell the kernel to clock the serial ports at 115200. So, in one of
your startup scripts like the /etc/rc.d/rc.local or /etc/rc.d/rc.serial file,
execute the following commands for a modem on COM2:
</para>
</listitem>
<listitem>
<para>
setserial /dev/ttyS1 spd_vhi
</para>
</listitem>
<listitem>
<para>
In your PPPd script, edit the actual pppd execution line to include the speed
"38400" per the pppd man page.
</para>
</listitem>
<listitem>
<para>
2.2.x kernels: Unlike the 2.0.x kernels, both the 2.1.x and 2.2.x kernels
don't have this "spd_vhi" issue.
</para>
<para>
So, in your PPPd script, edit the actual pppd execution line to include the
speed "115200" per the pppd man page.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</para>
<para>
All interface types:
</para>
</Sect1>
<Sect1 id="portfw-issues">
<Title>( PORTFW ) - IP Masquerading with PORTFWing seems to break when my line
is idle for long periods</Title>
<para>
If you have a DSL or Cablemodem, this behavior is unfortunately quite common.
Basically your ISP is putting your connection into a very low priority queue
to better service non-idle connections. The problem is that some enduser's
connections will actually be taken OFFLINE until some traffic from the user's
DSL/Cablemodem connection awakens the ISP's hardware.
</para>
<para>
<ItemizedList>
<listitem>
<para>
Some DSL installations can take an idle connection OFFLINE and only be checked
for activity once every 30 seconds or so.
</para>
</listitem>
<listitem>
<para>
Some Cablemodem setups can set an idle connection into a low priority queue
and only be checked for activity every minute or so.
</para>
</listitem>
</ItemizedList>
</para>
<para>
What do I recommend to do? Ping your default gateway every 30 seconds. To
do this, edit the /etc/rc.d/rc.local file and add the following to the bottom
of the file:
</para>
<para>
<ProgramListing>
ping -i 30 100.200.212.121 &#62; /dev/null &#38;
</ProgramListing>
</para>
<para>
Replace the 100.200.212.121 with your default router (upstream router).
</para>
</Sect1>
<Sect1 id="portfw-local">
<Title>( PORTFW - Locally ) - I can't reach my PORTFWed server from the INTERNAL lan
</Title>
<para>
Basically, say your domain, acme.com, has an external IP address of 1.2.3.4
and you are PORTFWing all WWW traffic to an internal machine, say,
192.168.0.20/24. Then an /internal/ user on the 192.169.0.x network tries to
contact to http://www.acme.com and expects things to work. Well, that isn't
going to happen with a basic config. Let me explain. Basically,
http://www.acme.com is being resolved to the IP of http://1.2.3.4 by your
chosen DNS server. What really should be happening is the web request should
resolve that request to http://192.168.0.20.
</para>
<para>
See the difference?
</para>
<para>
The proper solution to this is to setup a SPLIT DNS server. Internal users
would be configured to use an /internal/ DNS server which would resolve
requests like this with the 192.168.0.20 address when asked for www.acme.com.
All external users should be serviced by an /external/ DNS server which will
will resolve the requrest to the 1.2.3.4 IP address. From there,
IPTABLES/IPCHAINS/IPFWADM would then PORTFW the traffic to the 192.168.0.20
server as normal.
</para>
<para>
But you're probably thinking that you don't want to setup a split DNS server
and there has to be another way. There are a few alternatives! The first
alternative is if you only have a few internal machines. Here, you can
setup a "hosts" file entry on *all* internal machines. That static hosts entry
would basically look like:
</para>
<para>
<Screen>
www.acme.com 192.168.0.20
</Screen>
</para>
<para>
Got it? With that in place, the machine would consult the hosts table before
going to the DNS server to resolve the host. This works well but if you change
the IP address on that internal web server, you're going to need to manually
update the hosts file on all of those internal machines. If you are
interested in doing the more scalable split DNS approach, TrinityOS completely
covers split and chrooted DNS servers.
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">TrinityOS - Section 24</ULink>
http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos
</para>
<para>
Now, if neither the split DNS nor the hosts file approach interests you, you
still have a simple but effective alternative to get things working. What you
can do is add some specific rules to your rc.firewall-* ruleset. Please see
the "PORTFW Redirection of Internal requests" section under the
<XRef LinkEnd="Forwarders"> chapter.
</para>
<para>
Why didn't I mention this alternative solution first? The main reason is
that it's not the ideal solution. The primary problem with this approach is
that every packet will be going from the internal MASQed client to the MASQ
server. There, the MASQ server will SNAT each packet to the internal MASQed
WWW server's IP and then forward it to the internal web server. Once the
packet is received and responded to by the web server, that response has to
go back through all that processing back to the original client machine. This
process is overly wasteful on both network bandwidth and MASQ server CPU
cycles!
</para>
</Sect1>
<Sect1 id="masq-logs">
<Title>( Logs ) - Now that I have IP Masquerading up, I'm getting all sorts of weird
notices and errors in the SYSLOG log files. How do I read the IPTABLES/IPCHAINS/IPFWADM
firewall errors?</Title>
<para>
There is probably a few common things that you are going to see:
<ItemizedList>
<listitem>
<para>
<Emphasis role="strong">MASQ: Failed TCP Checksum error:</Emphasis> You
might see this error when a packet coming from the Internet gets corrupt in
the data section of the packet but the rest of it "seems" ok. When the Linux
box receives this packet, it will calculate the CRC of the packet and
determine that its corrupt. On most machines running OSes like Microsoft
Windows, they just silently drop the packets but Linux IP MASQ reports it. If
you get a LOT of them over your PPP link, first follow the FAQ entry above for
"(Performance) - Masq seems is slow".
</para>
<para>
If the (Performance) FAQ tips don't help and you run PPP over dialup or PPPoE,
you might try adding the line "-vj" (disabled VanJacobson header compression) to
your /etc/ppp/options file and restart the PPPd connection.
</para>
</listitem>
<listitem>
<para>
<Emphasis role="strong">Firewall hits</Emphasis>: Because you are on the
Internet with a decent firewall, you will be surprised with the number of users
trying to penetrate your Linux box! So what do all these firewall logs mean?
</para>
<para>
More so, if they are filling your logs, see the next FAQ entry on thoughts
<Emphasis>how to reduce</Emphasis> all these log entries.
</para>
</listitem>
<listitem>
<para>
The following details are from the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">TrinityOS - Section 10</ULink>
documentation I also wrote:
</para>
<para>
<ProgramListing>
With the use of various firewall rulesets, a given ruleset can either
DENY (silently drop) or REJECT traffic (sends back a ICMP error). If
firewall logging is enabled, the errors will show up in the SYSLOG
"messages" file found at:
Redhat: /var/log
Slackware: /var/adm
If you take a look at one of these firewall logs, you would see something
like:
---------------------------------------------------------------------
IPTABLES:
---------
Feb 23 07:37:01 Roadrunner kernel: IPTABLES IN=eth0 OUT=
MAC=00:50:da:2e:e5:fb:00:03:47:73:c9:d2:08:00 SRC=12.75.147.174
DST=100.200.0.212 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=39034 DF PROTO=TCP
SPT=4313 DPT=23 WINDOW=32120 RES=0x00 SYN URGP=0
IPCHAINS:
---------
Feb 23 07:37:01 Roadrunner kernel: input REJECT eth0 PROTO=6
12.75.147.174:1633 100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64
IPFWADM:
--------
Feb 23 07:37:01 Roadrunner kernel: IP fw-in rej eth0 TCP 12.75.147.174:1633
100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64
---------------------------------------------------------------------
There is a LOT of information in just this one line of SYSLOG. Lets break
out this example. You should refer back to the original firewall hit as you
read this.
--------------
1. ===================================================================
- This packet firewall "hit" occurred on "Feb 23 07:37:01"
2. ===================================================================
- This packet was logged on the "RoadRunner" computer via the kernel
3. ===================================================================
- IPTABLES: the SYSLOG prepend string is "iptables" for information purposes
- IPCHAINS: the packet was stopped on the INPUT chain
- IPFWADM: the packet was an IP packet
4. ===================================================================
- IPTABLES: the packet came IN on interface "eth0"
- IPCHAINS: the packet was REJECTED (vs. dropped or accepted)
- IPFWADM: the packet was stopped on INPUT (vs. "fw-out" for OUT or
"fw-fwd" for FORWARD)
5. ===================================================================
- IPTABLES: the packet had NO output interface
- IPCHAINS: the packet came in on the "eth0" interface
- IPFWADM: the packet was REJECTED "rej" (vs. "deny" or "accept")
6. ===================================================================
- IPTABLES: this display's the MAC address of the source and destination
Ethetnet MAC address (only relivant for Ethernet networks)
- IPCHAINS: the packet was IP protocol 6 or TCP
* If you don't know that protocol 6 is for TCP, look at
your /etc/protocols file to see what other protocol numbers
are used for.
- IPFWADM: the packet on the "eth0" interface
7. ===================================================================
- IPTABLES: the packet's source IP address was 12.75.147.174
- IPCHAINS: the packet's source IP address was 12.75.147.174
- IPFWADM: the packet was a "TCP" packet
8. ===================================================================
- IPTABLES: the packet's destination IP address was 100.200.0.212
- IPCHAINS: the packet's source PORT was 1633
- IPFWADM: the packet's source IP address was 12.75.147.174
9. ===================================================================
- IPTABLES: the packet's length was 44 bytes
- IPCHAINS: the packet's destination IP address was 100.200.0.212
- IPFWADM: the packet's source PORT was 1633
10. ===================================================================
- IPTABLES: the packet's TOS markings (type of service which basically
means class of service) was 0x00 or zero.
- IPCHAINS: the packet's destination PORT was 23 (telnet)
* If you don't know that port 23 is for TELNETing, look at
your /etc/services file to see what other ports are used
for.
- IPFWADM: the packet's destination IP address was 100.200.0.212
11. ===================================================================
- IPTABLES: the packet's precedense markings (class of service) was
0x00 or zero.
- IPCHAINS: the packet's length was 44 bytes
- IPFWADM: the packet's destination PORT was 23 (telnet)
* If you don't know that port 23 is for TELNETing, look at
your /etc/services file to see what other ports are used
for.
12. ==================================================================
- IPTABLES: the packet's TTL or Time to Live was 64 or 64 router hops
* Every router hop over the Internet will subtract (1) from
this number. Usually, packets will start with a number of
255 (depends on the operating system) and if that number
ever reaches (0), it means that realistically, the packet
was lost in a network loop and should be deleted.
- IPCHAINS: the packet's TOS markings (type of service which basically
means class of service) was 0x00 or zero.
* divide this by 4 to get the Type of Service (presidence)
- IPFWADM: the packet was 44 bytes long
13. ==================================================================
- IPTABLES: the packet had various TCP flags set such as SYN, SYN+ACK,
etc. (shown in HEX)
- IPCHAINS: the packet had various TCP flags set (shown in hex)
- IPFWADM: the packet's TOS markings (type of service which basically
means class of service) was 0x00 or zero.
14. ==================================================================
- IPTABLES: the packet's "don't fragment" or DF bit was set from the
source computer
- IPCHAINS: the packet had a fragmentation offset of 40 (shown in HEX)
--Don't worry if you don't understand this..
* A value that started with "0x2..." or "0x3..." means the
"More Fragments" bit was set so more fragmented packets
will be coming in to complete this one BIG packet.
* A value which started with "0x4..." or "0x5..." means that
the "Don't Fragment" bit was set
* Any other values are the Fragment offset (divided by 8) to
be later used to recombine into the original LARGE packet
- IPFWADM: the packet had various TCP flags set such as SYN, SYN+ACK,
etc. (shown in HEX)
15. ==================================================================
- IPTABLES: the packet was a TCP packet
- IPCHAINS: the packet's TTL or Time to Live was 64 or 64 router hops
* Every router hop over the Internet will subtract (1) from
this number. Usually, packets will start with a number of
255 (depends on the operating system) and if that number
ever reaches (0), it means that realistically, the packet
was lost in a network loop and should be deleted.
- IPFWADM: the packet had a fragmentation offset of 40 (shown in HEX)
--Don't worry if you don't understand this..
* A value that started with "0x2..." or "0x3..." means the
"More Fragments" bit was set so more fragmented packets
will be coming in to complete this one BIG packet.
* A value which started with "0x4..." or "0x5..." means that
the "Don't Fragment" bit was set
* Any other values are the Fragment offset (divided by 8) to
be later used to recombine into the original LARGE packet
16. ==================================================================
- IPTABLES: the packet's soure PORT was 4313
- IPCHAINS:
- IPFWADM: the packet's TTL or Time to Live was 64 or 64 router hops
* Every router hop over the Internet will subtract (1) from
this number. Usually, packets will start with a number of
255 (depends on the operating system) and if that number
ever reaches (0), it means that realistically, the packet
was lost in a network loop and should be deleted.
17. ==================================================================
- IPTABLES: the packet's destination PORT was 23 (telnet)
* If you don't know that port 23 is for TELNETing, look at
your /etc/services file to see what other ports are used
for.
- IPCHAINS:
- IPFWADM:
18. ==================================================================
- IPTABLES: the packet's TCP window (sliding or selective TCP ack)
was 32120 bytes
- IPCHAINS:
- IPFWADM:
19. ==================================================================
- IPTABLES: the packet's TCP reserved bits were 0x00 (HEX) - unused
- IPCHAINS:
- IPFWADM:
20. ==================================================================
- IPTABLES: the packet's TCP header SYN bit was set
* IPTABLES displays all the TCP header bits by name and not
by a HEX dump
- IPCHAINS:
- IPFWADM:
21. ==================================================================
- IPTABLES: the packet's TCP header URGENT bit was set - rarely used
- IPCHAINS:
- IPFWADM:
</ProgramListing>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="reducing-masq-logs">
<Title>( Log Reduction ) - My logs are filling up with packet hits due to the
new "stronger" rulesets. How can I fix this? </Title>
<para>
So your realizing that a good firewall is catching a LOT of bad Internet
traffic. That's a good thing but it's also filling up your logs to the point
that you won't read them; that's bad.
What to do?
</para>
<para>
What you need to figure out is what traffic you DON"T want to log, explicitly
match those packets in the firewall, and NOT log the packets when you drop
them.
</para>
<para>
For example, the TrinityOS firewall ruleset in section 10.7 (this would be a
"strongest" ruleset in IPMASQ speak) gives some ideas:
<ULink
URL="http://www.ecst.csuchico.edu/~dranch/LINUX/TrinityOS/cHTML/TrinityOS-c-10.html">
TrinityOS - Section 10.7</Ulink>
</para>
<para>
Things I recommend to filter:
<ItemizedList>
<listitem>
<para>All RFC1918 address space (TCP/IP address ranges: 10.x.y.z/8,
172.16-31.y.z/12, and 192.168.y.x/16). You should /never/ receive these
packets from an Internet connection. If you do, they are most likely spoofed
packets</para>
</listitem>
<listitem>
<para>Windows File and Print Sharing (Samba or CIFS): ports 137, 138, 139,
and 445. Windows machines like to talk a lot though most computers don't care
what they're saying.</para>
</listitem>
<listitem>
<para>Class-D Multicast addresses (if you don't use Multicast): 224.0.0.0/4
</para>
</listitem>
<listitem>
<para>Class-E and F "future" addresses: 240.0.0.0/5 and 248.0.0.0/5
</para>
</listitem>
</ItemizedList>
</para>
<para>
To a much lesser extent, you might want to filter other packets. I recommend
that you verify that you are receiving these specific packet types before
you filter them out.
<ItemizedList>
<listitem>
<para>RIP (the routing protocol): port 520</para>
</listitem>
<listitem>
<para>Some specific forms of ICMP packets - NOT all of them (that will
break your machine and IPMASQ in general)</para>
</listitem>
</ItemizedList>
</para>
<para>
Finally, you'll probably find that some individual TCP/IP address out on the
Internet always seem to attack your IP. So, in addition to filtering various
PORTS like above, you might want to also filter by specific SOURCE IP address
too. After all, it is *YOUR* firewall.
</para>
</Sect1>
<Sect1 id="masq-host-security">
<Title>( MASQ Security ) - Can I configure IP MASQ to allow Internet users to
directly contact internal MASQed servers?</Title>
<para>
Yes! With IPPORTFW, you can allow ALL or only a select few Internet hosts to
contact ANY of your internal MASQed computers. <Emphasis role="strong">This
topic is completely covered in
<XRef LinkEnd="Forwarders"> in this HOWTO.</Emphasis>
</para>
</Sect1>
<Sect1 id="No-Free-Ports">
<Title>( Free Ports ) - I'm getting "kernel: ip_masq_new(proto=UDP): no free ports." in my
SYSLOG files. Whats up?</Title>
<para>
One of your internal MASQed machines are creating an abnormally high number of
packets destined for the Internet. As the IP Masq server builds the MASQ
table and forwards these packets out over the Internet, the table is quickly
filling. Once the table is filled, it will give you this error.
</para>
<para>
The only application that I have known which temporarily creates this situation
is a gaming program called "GameSpy". Why? Gamespy builds a server list and
then pings all of the servers in the list (1000s of game servers). By creating
all these pings, it creates 1,000s of quick connections in a VERY short period
of time. Until these sessions timeout via the IP MASQ timeouts, the MASQ tables
become "FULL".
</para>
<para>
So what can you do about it? Realistically, don't use programs that do things
like this. If you do get this error in your logs, find it and stop using it.
If you really like GameSpy, just don't refresh the server too often.
Regardless, once you stop running this MASQ'ed program, this MASQ error will
go away as these connections will eventually timeout in the MASQ tables.
</para>
</Sect1>
<Sect1 id="setsockopt">
<Title>( SETSOCKOPT ) - I'm getting "ipfwadm: setsockopt failed: Protocol not
available" when I try to use IPPORTFW! </Title>
<para>
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.
</para>
<para>
Please see the end of <XRef LinkEnd="Forwarders"> for full details.
</para>
</Sect1>
<Sect1 id="samba">
<Title>( SAMBA ) - Microsoft File and Print Sharing and Microsoft Domain clients
don't work through IP Masq!</Title>
<para> To properly support Microsoft's SMB protocol, an IP
Masq module would need to be written but there are three viable work-arounds.
For more details, please see
<ULink URL="http://support.microsoft.com/default.aspx?scid=kb;en-us;172227">
this Microsoft KnowledgeBase article</ULink>.
</para>
<para>
The first way to work around this problem is to configure IPPORTFW from
<XRef LinkEnd="Forwarders"> and portfw TCP ports 137, 138, and 139 to the
internal Windows machine's IP address. Though this solution works, it would
only work for ONE internal machine.
</para>
<para>
The second solution is to install and configure
<ULink URL="http://www.samba.org">Samba</ULink> on the Linux MASQ server.
With Samba running, you can then map your internal Windows File and Print
shares onto the Samba server. Then, you can mount these newly mounted SMB
shares to all of your external clients. Configuring Samba is fully covered
in a HOWTO found in a Linux Documentation Project and in the TrinityOS document
as well.
</para>
<para>
The third solution is to configure a VPN (virtual private network) between the
two Windows machines or between the two networks. This can either be done via
the PPTP or IPSEC VPN solutions. There is a <XRef LinkEnd="VPNs"> patch for
Linux and also a full IPSEC implementation available for both 2.0.x and 2.2.x
kernels. This solution would probably be the most reliable and secure method
of all three solutions.
</para>
<para>
All of these solutions are NOT covered by this HOWTO. I recommend that you
look at the TrinityOS documentation for IPSEC help and John Hardin's PPTP
page for more information.
</para>
<para>
<Emphasis role="strong">Also PLEASE understand that Microsoft's SMB protocol
is VERY insecure. Because of this, running either Microsoft File and Print
sharing or Windows Domain login traffic over the Internet without any encryption
is a VERY BAD idea.</Emphasis>
</para>
</Sect1>
<Sect1 id="ident">
<Title>( IDENT ) - IRC won't work properly for MASQed IRC users. Why?</Title>
<para>
The main possible reason is because most common Linux distribution's IDENT or
"Identity" servers can't deal with IP Masqueraded links. No worries though,
there are IDENTs out there that will work.
</para>
<para>
Installing this software is beyond the scope of this HOWTO but each tool has
its own documentation. Here are some of the URLs:
<ItemizedList>
<listitem>
<para>
<ULink URL="http://freshmeat.net/projects/oidentd/?topic_id=150">
Oident</ULink> is a favorite IDENT server for MASQ users.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://freshmeat.net/projects/midentd/?topic_id=24">
Mident</ULink> is another popular IDENT server.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://http://home.indyramp.net/lists/masq/insecurity.net/sidentd.gz">Sident</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="ftp://sunsite.unc.edu/pub/Linux/system/network/daemons/">Other Idents</ULink>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Please note that some Internet IRC servers still won't allow multiple
connections from the same host even if they get Ident info and the users are
different though. Complain to the remote sys admin. :-)
</para>
</Sect1>
<Sect1 id="irc-dcc">
<Title>( IRC DCC ) - mIRC doesn't work with DCC Sends</Title>
<para>
This is a configuration problem on your copy of mIRC. To fix this, first
disconnect mIRC from the IRC server. Now in mIRC, go to File --&#62; Setup
and click on the "IRC servers tab". Make sure that it is set to port 6667.
If you require other ports, see below. Next, goto File --&#62; Setup --&#62;
Local Info and clear the fields for Local Host and IP Addresses. Now select
the checkboxes for "LOCAL HOST" and "IP address" (IP address may be checked
but disabled). Next under "Lookup Method", configure it for "normal". It
will NOT work if "server" is selected. That's it. Try to the IRC server
again.
</para>
<para>
If you require IRC server ports other than 6667, (for example, 6969) you need
to edit the /etc/rc.d/rc.firewall-* startup file where you load the IRC MASQ
modules. Edit this file and the line for "modprobe ip_masq_irc" and add to
this line "ports=6667,6969". You can add additional ports as long as they
are separated with commas.
</para>
<para>
Finally, close down any IRC clients on any MASQed machines and re-load the IRC
MASQ module:
</para>
<para>
/sbin/rmmod ip_masq_irc
/etc/rc.d/rc.firewall-*
</para>
</Sect1>
<Sect1 id="aliasing">
<Title>( IP Aliasing ) - Can IP Masquerade work with only ONE Ethernet network card?</Title>
<para>
<Emphasis role="strong">Yes and no</Emphasis>. With the "IP Alias" kernel
feature, users can setup multiple aliased interfaces such as eth0:1, eth0:2,
etc but its is NOT recommended to use aliased interfaces for IP Masquerading.
Why? Providing a secure firewall becomes very difficult with a single NIC
card. In addition to this, you will experience an abnormal amount of errors
on this link since incoming packets will almost simultaneously be sent out
at the same time. Because of all this and NIC cards now costs less than
$10, I highly recommend to just get a NIC card for each MASQed network segment.
</para>
<para>
Users should also understand that IP Masquerading will only work with a physical
interface such as eth0, eth1, etc. MASQing out an aliased interface such as
"eth0:1, eth1:1, etc" will NOT work. In other words, the following WILL NOT
WORK reliably:
</para>
<para>
<ItemizedList>
<listitem>
<para>
It is rumored that you can simply use the destination IP address (the IP
address associated with the ALIASed interface like eth0:1, etc.) IN PLACE
of specifing the interface (eth0:1). This solution is not untested --
please email dranch@trinnet.net if you have any positive or negative
results
</para>
</listitem>
<listitem>
<para>
/sbin/ipchains -A forward -i eth0:1 -s 192.168.0.0/24 -j MASQ"
</para>
</listitem>
<listitem>
<para>
/sbin/ipfwadm -F -a m -W eth0:1 -S 192.168.0.0/24 -D 0.0.0.0/0
</para>
</listitem>
</ItemizedList>
</para>
<para>
If you are still interested in using aliased interfaces, you need to enable
the "IP Alias" feature in the kernel. You will then need to re-compile and
reboot. Once running the new kernel, you need to configure Linux to use the
new interface (i.e. eth0:1, etc.). After that, you can treat it as a
normal Ethernet interface with some restrictions like the one above.
</para>
</Sect1>
<Sect1 id="multiple-lans">
<Title>( Multiple-LANs ) - I have two MASQed LANs but they cannot communicate with
each other!</Title>
<para>
Please see <XRef LinkEnd="multiple-masqed-lans"> for full details.
</para>
</Sect1>
<Sect1 id="shaping">
<Title>( SHAPING ) - I want to be able to limit the speed of specific types of
traffic</Title>
<para>
I receive lots of emails from people asking something like the following:
</para>
<para>
<screen>
How can I control the internet bandwidth among the LAN PCs behind the IPMASQ
server? Some times any local pc is downloading and it it will take the majority
of the bandwidth and thus the other PCs get little bandwidth.
</screen>
</para>
<para>
This topic really doesn't have anything to do with IPMASQ and everthing to do
with Linux's built-in traffic shaping and rate-limiting abilities.
You will find information about this on the LDP such as the
<ULink
URL="http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/index.html">
ADSL Bandwidth HOWTO</ULink>, the <ULink
URL="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO-9.html">Advanced Rouring
HOWTO</ULink>, and the <ULINK
URL="http://www.tldp.org/HOWTO/Bandwidth-Limiting-HOWTO/index.html">Bandwidth
Limiting HOWTO</ULink>. Please understand this is an advanced topic and any
question you may have will be better served from people from those forums.
</para>
</Sect1>
<Sect1 id="accounting">
<Title>( ACCOUNTING ) - I need to do accounting on who is using the network</Title>
<para>
Though this doesn't have much to do with IPMASQ, here are a few ideas. If you
know of a better solution, please email the author of this HOWTO so it can be
added to the HOWTO.
</para>
<para>
<ItemizedList>
<listitem>
<para>
Idea #1: You could run the command:
<screen>
IPCHAINS: "ipchains -L -M"
IPTABLES: "cat /proc/net/ip_conntrack"
IPFWADM:
</screen>
once a second and log all of those entries. You could then write a program
to merge this information into one large file. Again, this will only
provide you with the remote IP address and nothing about the content viewed
or downloaded.
</para>
</listitem>
<listitem>
<para>
Idea #2: Log every packet: You can match any specific traffic flows but
this method will create VERY LARGE log files. Unfortunately, these log files
aren't very readable and it doesn't tell you what was transfered (FTP files,
etc.). Fortunately, setting up this form of accounting is easy.
</para>
</listitem>
<listitem>
<para>
Idea #3: Say you want to log all traffic going out onto the internet. You
can setup a firewall rule to accept port 80 traffic with the SYN bit set
and log it. Now mind you, this will create smaller log files than the idea
above but you will only know the destination IP address and NOT the WWW pages
viewed.
</para>
</listitem>
<listitem>
<para>
Idea #4: Transparent Proxy: This method really doesn't use IPMASQ since it
requires the installation and setup of the Squid HTTP/FTP proxy server.
The benefit of this method is that internal users won't notice anything
different in terms of connectivity but now the SysAdmin gets a LOT more
information (files downloaded, etc). But, there are pros/cons to setting this
up:
</para>
<para>
Pro:
</para>
<ItemizedList>
<listitem>
<para>
+ full logging of all transferred files and issues FTP commands
</para>
</listitem>
<listitem>
<para>
+ you can enable caching on the proxy server. With caching, you can save
bandwidth since once a file is downloaded, any identical file
requests will be served via the cache and not redownloaded via
the Internet connection.
</para>
</listitem>
</ItemizedList>
<para>
Con:
</para>
<ItemizedList>
<listitem>
<para>
- Setting up a transparent proxy is complicated as it requires kernel
changes, setting up Squid, etc.
</para>
</listitem>
<listitem>
<para>
- Could be overkill for a small installation.
</para>
</listitem>
</ItemizedList>
<para>
Please see the <ULink URL="http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/index.html">
Advanced Routing HOWTO</Ulink> for more details.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="multiple-ips">
<Title>( MULTIPLE IPs - DMZ segments) - I have several EXTERNAL IP addresses that I want to
PORTFW to several internal machines. How do I do this?</Title>
<para>
Though technically possible, DON'T do this with IP MASQ. There are far better
solutions for this network design.
</para>
<para>
MASQ is a 1:Many NAT setup which is the incorrect tool to perform what you are
looking for. You are looking for is either Many:Many NAT solution or a Briding
setup.
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis>For users out there who are thinking
about enabling multiple IP addresses on one internal NIC using "IP Alias" and
then just PORTFWeding ALL of those ports (0-65535), and and finally use
IPROUTE2 to maintain the proper source/destination IP pairs. This has been
done SUCCESSFULLY on 2.0.x kernels and less successfully on 2.2.x kernels.
Regardless of success, that isn't the proper way to do it, it's a total HACK,
and it is not a supported MASQ configuration. Please, give IPTABLES on the
2.4.x kernels a serious look or to a much lesser extent,
<XRef LinkEnd="shaping"> IPROUTE2 look for 2.2.x kernels.
</para>
<para>
Anyway, for forwarding external IP address to internal hosts, you basically
have three possibilites:
<ItemizedList>
<listitem>
<para>
<screen>
1. Route the external IPs
(This does NOT involve IPMASQ at all but requires special WAN addressing
and routing setup from your ISP):
Internet -- Some public WAN -- Linux -- DMZ segment
IP address Server PUBLIC IPs
|
+------ Internal net
private IPs
</screen>
</para>
</listitem>
<listitem>
<para>
<screen>
2. 1:1 NAT
(Most easily done via IPTABLES or with IPCHAINS and IPROUTE2 but still
some protocols cannot deal with NAT)
Internet -- Linux -- DMZ segment
Server Private IPs natted to 1:1 PUBLIC IPs
|
+------ Internal net
private IPs
</screen>
</para>
</listitem>
<listitem>
<para>
<screen>
3. Bridging or ProxyARP:
The Bridging method is one of the more popular methods that many commercial
firewalls do and it's very slick. Alternatively, you can use the ProxyARP
method which works well without some of the complications (or benefits of
bridging). With both solutions, all public IPs can transparently flow
through the Linux server to the DMZ but via firewall inspection.
Internet -- Linux -- DMZ segment
Server PUBLIC IPs
|
+------ Internal net
private IPs
</screen>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Each of these solutions have pros and cons
</para>
<para>
Item #1: If you're lucky enough to have an ISP that will set this up for you
(pretty rare), all you need to do is use basic 'route' commands to get this
running. This is the most rebust solution and doesn't require any form of
IPMASQ or NAT to work.
</para>
<para>
Item #2: 1:1 NAT isn't covered in this HOWTO yet but if you need a hand, just
email me and I'll give you a hand.
</para>
<para>
Item #3: ProxyARP is pretty strait forward but only works in specific
situations and only works with Ethernet networks. Bridging is more powerful
but will probably require the re-compiling of the kernel and some advanced
configuration. Ultimately, neither of these solutions are IPMASQ anymore and
thus I can't help you set them up. Fortunately, there are other HOWTOs out
there that cover this topic:
<ItemizedList>
<listitem>
<para>
<ULink
URL="http://www.tldp.org/HOWTO/Proxy-ARP-Subnet/index.html">http://www.tldp.org/HOWTO/Proxy-ARP-Subnet/index.html</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.bridging.html">
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.bridging.html</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO.html">
http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO.html</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://bridge.sourceforge.net/">http://bridge.sourceforge.net/
</ULink>
</para>
</listitem>
</ItemizedList
</para>
<para>
<Emphasis role="strong">NOTE: </Emphasis> If you have a bridged DSL or
Cablemodem connection (not PPPoE), things are a little more difficult because
your setup isn't routed. No worries though, check out the
<ULink
URL="http://www.tldp.org/HOWTO/mini/Bridge+Firewall.html">Bridge+Firewall Mini
HOWTO</ULink> and the
<ULink
URL="http://www.tldp.org/HOWTO/mini/Bridge+Firewall+DSL.html">
Bridge+Firewall+DSL Mini HOWTO</ULink>. These HOWTOs will teach you how to
get your Linux box to support multiple IP addresses on a single interface!
</para>
</Sect1>
<Sect1 id="one-to-one-nat">
<Title>( 1:1 NAT ) - I'd like to do 1:1 NAT but I can't figure out how to do it
</Title>
<para>
Please see the previous FAQ entry named <XRef LinkEnd="multiple-ips"> for all
the details.
</para>
</Sect1>
<Sect1 id="netstat">
<Title>( Netstat ) - I'm trying to use the NETSTAT command to show my Masqueraded
connections but its not working</Title>
<para>
There might be a problem with the "netstat" program in 2.0.x-based Linux
distros. After a Linux reboot, running "netstat -M" works fine but after a
MASQed computer runs some successful ICMP traffic like ping, traceroute,
etc., you might see something like:
</para>
<para>
masq_info.c: Internal Error `ip_masquerade unknown type'.
</para>
<para>
The workaround for this is to use the "/sbin/ipfwadm -M -l" command. You
will also notice that once the listed ICMP masquerade entries timeout,
"netstat" works again.
</para>
</Sect1>
<Sect1 id="VPNs">
<Title>( VPNs ) - I would like to get Microsoft PPTP (GRE tunnels) and/or
IPSEC (Linux SWAN) tunnels running through IP MASQ </Title>
<para>
This IS possible for specific modes. Specifically, all of the kernel versions
(2.4.x, 2.2.x, and 2.0.x) support patches to allow for both ONE or MULTIPLE
PPTP users behind a IPMASQ server to connect to the -same- PPTP server. The
2.4.x kernels currently have a PPTP module now in the newest versions of
the IPTABLES program and there is another version available on the IPMASQ WWW
site. Please check out John Hardin's
<ULink URL="http://www.impsec.org/linux/masquerade/ip_masq_vpn.html">PPTP Masq</ULink>
page for details.
</para>
</Sect1>
<Sect1 id="games">
<Title>( Games ) - I want to get the XYZ network game to work through IP MASQ but it won't
work. Help!</Title>
<para>
First, check <ULink URL="http://www.tsmservices.com/masq/">Steve Grevemeyer's
MASQ Applications page</ULink>. If your solution isn't listed there, try
patching your Linux kernel with Glenn Lamb's
<ULink URL="http://ipmasq.webhop.net/files20/loose-udp-2.0.36.patch.gz">
http://ipmasq.webhop.net/files20/loose-udp-2.0.36.patch.gz
LooseUDP</ULink> patch which is covered in <XRef LinkEnd="LooseUDP"> above.
Also check out Dan Kegel's
<ULink URL="http://www.alumni.caltech.edu/~dank/peer-nat.html">NAT Page</ULink>
for more information.
</para>
<para>
If you are technically inclined, use the program "tcpdump" and sniff your
network. Try to find out what protocols and port numbers your XYZ game is
using. With this information in hand, subscribe to the
<ULink URL="mailto://masq-subscribe@tiffany.indyramp.com">IP Masq email list
</ULink> and email your results for help.
</para>
</Sect1>
<Sect1 id="masq-stops-working">
<Title>( Stops working ) - IP MASQ works fine for a while but then it stops working. A reboot
seems to fix this. Why?</Title>
<para>
I bet you are using IPAUTOFW and/or you have it compiled into the kernel huh??
This is a known problem with IPAUTOFW. It is recommend to NOT even configure
IPAUTOFW into the Linux kernel and use IPPORTFW option instead. This is covered
with more details in <XRef LinkEnd="Forwarders">.
</para>
</Sect1>
<Sect1 id="smtp">
<Title>( SMTP Relay ) - Internal MASQed computers cannot send SMTP or POP-3 mail!</Title>
<para>
Though this isn't a Masquerading issue but many users do this so it should be
mentioned.
</para>
<para>
SMTP: The issue is that you are probably using your Linux box as an SMTP
relay server and get the following error:
</para>
<para>
<Screen>
"error from mail server: we do not relay"
</Screen>
Newer versions of Sendmail and other Mail Transfer Agents (MTAs) disable
relaying by default (this is a good thing). So do the following to fix this:
</para>
<para>
<ItemizedList>
<listitem>
<para>
Sendmail: Enable specific relaying for your internal MASQed machines by editing
the /etc/sendmail.cw file and add the hostname and domain name of your internal
MASQed machine. You should also check to see that the /etc/hosts file has the
IP address and Fully Qualified Domain Name (FQDN) configured in it. Once this
is done, you need to restart Sendmail for it to re-read its configuration
files. This is covered in
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">TrinityOS - Section 25</ULink>
</para>
</listitem>
</ItemizedList>
</para>
<para>
POP-3: Some users configure their internal MASQ'ed computer's POP-3 clients to
connect to some external SMTP server. While this is fine, many SMTP servers
out there will try to IDENT your connection on port 113. Most likely your
problem stems around your default Masquerade policy being set to DENY. This is
BAD. Set it to REJECT and re-run your rc.firewall-* ruleset.
</para>
</Sect1>
<Sect1 id="iproute2">
<Title>( Source Routing ) - I need different internal MASQed networks to exit
on different external IP addresses</Title>
<para>
Say you have the following setup: You have multiple internal networks and also
multiple external IP addresses and/or networks. What you want to do is have
LAN #1 to only use External IP #1 but you wan LAN #2 to use External IP #2.
</para>
<para>
Internal LAN ----------&#62; official IP
</para>
<para>
LAN #1 External IP #1
192.168.0.x --&#62; 123.123.123.11
</para>
<para>
LAN #2 External IP #2
192.168.1.x --&#62; 123.123.123.12
</para>
<para>
Basically, what we have described here is routing NOT only on the destination
address (typical IP routing) but also routing based upon the SOURCE address
as well. This is typically called "policy-based routing" or "source routing".
This functionality is NOT available in 2.0.x kernels, it *IS* available for
2.2.x kernels via the IPROUTE2 package, and it is built into the new 2.4.x
kernels using IPTABLES.
</para>
<para>
First, you have to understand that both IPFWADM and IPCHAINS get involved
*AFTER* the routing system has decided where to send a given packet. This
statement really ought to be stamped in big red letters on all
IPFWADM/IPCHAINS/IPMASQ documentation. The reason for this is that users
MUST first have their routing setup correct, then start adding
IPFWADM/IPCHAINS and/or Masq features.
</para>
<para>
Anyways, for the example case shown above, you will need to persuade the routing
system to direct packets from 192.168.0.x via 123.123.1233.11 and packets from
192.168.1.x via 123.123.123.12. That is the hardest part and adding Masq on
top of correct routing is easy.
</para>
<para>
To do this fancy routing, you will use IPROUTE2. Because this functionality has
NOTHING to do with IPMASQ, this HOWTO does not cover this topic in great detail.
Please see <XRef LinkEnd="kernel-2.2.x-Requirements"> for complete URLs and
documentation for this topic.
</para>
<para>
The "iprule" and "iproute" commands are the same as "ip rule" and "ip route"
commands (I prefer the former since it is easier to search for.) All the
commands below are completely untested, if they do not work, please let
David Ranch know about it but please contact the IPROUTE2 email list for
help. This function has NOTHING to do with IP Masquerading.
</para>
<para>
2.4.x. kernels:
</para>
<para>
The following would be integrated into the END of your rc.firewall-iptables ruleset
<screen>
EXTIF="eth0"
INTNET1="192.168.0.0/24"
INTNET2="192.168.1.0/24"
EXTIP1="123.123.123.11"
EXTIP2="123.123.123.12"
iptables -t nat -A POSTROUTING -o $EXTIF -s $INTNET1 -j SNAT --to $EXTIP1
iptables -t nat -A POSTROUTING -o $EXTIF -s $INTNET2 -j SNAT --to $EXTIP2
</screen>
</para>
<para>
2.2.x. kernels:
</para>
<para>
The first few commands only need to be done once at boot, say in
/etc/rc.d/rc.local file.
</para>
<para>
<Screen>
# Allow internal LANs to route to each other, no masq.
/sbin/iprule add from 192.168.0.0/16 to 192.168.0.0/16 table main pref 100
# All other traffic from 192.168.1.x is external, handle by table 101
/sbin/iprule add from 192.168.1.0/24 to 0/0 table 101 pref 102
# All other traffic from 192.168.2.x is external, handle by table 102
/sbin/iprule add from 192.168.2.0/24 to 0/0 table 102 pref 102
These commands need to be issued when eth0 is configured, perhaps in
/etc/sysconfig/network-scripts/ifup-post (for Redhat systems). Be sure to
do them by hand first to make sure they work.
# Table 101 forces all assigned packets out via 123.123.123.11
/sbin/iproute add table 101 via 123.123.123.11
# Table 102 forces all assigned packets out via 123.123.123.12
/sbin/iproute add table 102 via 123.123.123.12
At this stage, you should find that packets from 192.168.1.x to the
outside world are being routed via 123.123.123.11, packets from
192.168.2.x are routed via 123.123.123.12.
It is IMPORTANT that these IPROUTE2 rules be run /BEFORE/ the rc.firewall-*
ruleset is run.
If everything hangs together, the masq code will see packets being
routed out on 123.123.123.11 and 123.123.123.12 and will use those addresses
as the masq source address.
</Screen>
</para>
</Sect1>
<Sect1 id="ipchains-on-2.4.x">
<Title>( IPCHAINS rulesets on 2.4.x kernels ) - What the ipchains.o module can
do on 2.4.x kernels</Title>
<para>
Some people would like to continue using their legacy IPCHAINS rulesets on
2.4.x-based kernelw. Unfortunately, unless you are
<Emphasis role="strong">only doing packet firewalling </Emphasis>and not trying
to do any NATing (MASQ), PORTFW, or other advanced features, you're in
trouble.
</para>
<para>
<ItemizedList>
<listitem>
<para>
If you ARE only doing IPCHAINS filtering, all you need to do is unload all
IPTABLES modules shown from the "<Literal>/sbin/lsmod</Literal>" command.
After that, load the IPCHAINS module by running
"<Literal>/sbin/modprobe ipchains</Literal>". After that, load your
IPCHAINS ruleset as normal.
<ItemizedList>
<listitem>
<para>
Please note that if you compiled IPTABLES support statically into the
kernel, you CANNOT load the "ipchains" module (it shouldn't be even
present) as it will conflict with the IPTABLES kernel code. Your ONLY
option in this case is to recompile your kernel but make the IPTABLES and
IPCHAINS options as modules.
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</para>
<para>
So why can't you run IPCHAINS MASQ/PORTFW functionality with a 2.4.x kernel?
Once the IPCHAINS module is loaded, you CANNOT use any IPTABLES commands or
modules since the code conflicts. In addition to this, you cannot use any
legacy 2.2.x IPCHAINS masq modules on a 2.4.x kernel as the kernels are so
radically different. Plus, this really shouldn't be an issue as all of this
functionality is available via native IPTABLES modules now. Finally, you
cannot use the IPMASQADM tool with a 2.4.x kernel as the program both won't
compile and ultimately the PORTFW kernel handlers aren't present anymore (it's
now done natively by the IPTABLES code). So, considering all of these facts:
</para>
<para>
<ItemizedList>
<listitem>
<para>
You cannot run any form of PORTFW on this 2.4.x machine
</para>
</listitem>
<listitem>
<para>
Protocols that require special handling like FTP, IRC, CuSeeme, RealAudio,
etc. will no longer work
</para>
</listitem>
</ItemizedList>
</para>
<para>
Basically, the ipchains kernel module included with the 2.4.x kernels is
intended for basic packet firewall compatibility and NOT any NAT(MASQ)
functionality.
</para>
</Sect1>
<Sect1 id="iptables-vs-ipchains-vs-ipfwadm">
<Title>( IPTABLES vs. IPCHAINS vs. IPFWADM ) - Why do the 2.4.x, 2.2.x,
and 2.0.x kernels use different firewall systems?</Title>
<para>
IPTABLES supports the following features that IPCHAINS and IPFWADM doesn't:
</para>
<para>
<ItemizedList>
<listitem>
<para>
Stateful IPv4 protocol and application tracking
</para>
</listitem>
<listitem>
<para>
Stateful IPv6 protocol tracking
</para>
</listitem>
<listitem>
<para>
True 1:1 and 1:Many NAT
</para>
</listitem>
<listitem>
<para>
Built-in PORTFW functionality
</para>
</listitem>
<listitem>
<para>
See the <XRef LinkEnd="kernel-2.4.x-requirements"> section for
more details
</para>
</listitem>
</ItemizedList>
</para>
<para>
IPCHAINS supports the following features that IPFWADM doesn't:
</para>
<para>
<ItemizedList>
<listitem>
<para>
"Quality of Service" (QoS support)
</para>
</listitem>
<listitem>
<para>
A TREE style chains system vs. LINEAR system like IPFWADM (Eg. this allows
something like "if it is ppp0, jump to this chain (which contains its own
difference set of rules)"
</para>
</listitem>
<listitem>
<para>
IPCHAINS is more flexible with configuration. For example, it has the "replace"
command (in addition to "insert" and "add"). You can also negate rules (e.g.
"discard any outbound packets that don't come from my registered IP" so that
you aren't the source of spoofed attacks).
</para>
</listitem>
<listitem>
<para>
IPCHAINS can filter any IP protocol explicitly, not just TCP, UDP, ICMP
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="upgrades">
<Title>( Upgrades ) - I've just upgraded to the x.y.z kernel, why isn't IP
Masquerade working?</Title>
<para>
There are several things you should check assuming your Linux IP Masq box
already has proper connections to the Internet and your LAN:
</para>
<para>
<ItemizedList>
<listitem>
<para>
Make sure you have the necessary features and modules are compiled and loaded.
See earlier sections for details.
</para>
</listitem>
<listitem>
<para>
Check <Literal>/usr/src/linux/Documentation/Changes</Literal> and make sure you
have the minimal requirement for the network tools installed.
</para>
</listitem>
<listitem>
<para>
Make sure you followed all of the tests in <XRef LinkEnd="Testing"> of the
HOWTO.
</para>
</listitem>
<listitem>
<para>
Make sure you are using the proper firewall tool for you kernel be it IPTABLES,
IPCHAINS, or IPFWADM.
</para>
</listitem>
<listitem>
<para>
If you are doing PORTFW functionality, make sure you use the correct tool
for your kernel version. IPTABLES has everything built-in, IPCHAINS requires
the use of IPMASQADM, and IPFWADM reaquires the use of IPPORTFW or IPAUTOFW.
This is completely covered in <XRef LinkEnd="Forwarders">.
</para>
</listitem>
<listitem>
<para>
Go through all setup and configuration again! Usually, it's just a typo or
a simple mistake you are overlooking.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="eql">
<Title>( EQL ) - I need help with EQL connections and IP Masq</Title>
<para>
EQL has nothing to do with IP Masq though they are commonly teamed up on Linux
boxes. Because of this, I recommend checking out the NEW version of
<ULink URL="http://home.indyramp.com/masq/eql/eql.html">Robert Novak's EQL HOWTO</ULink>
for all your EQL needs.
</para>
</Sect1>
<Sect1 id="wussing-out">
<Title>( Wussing out ) - I can't get IP Masquerade to work! What options do I
have for Windows Platforms?</Title>
<para>
Looking to give up a free, reliable, high performance solution that works on
minimal hardware and pay a fortune for something that needs more hardware, is
lower performance and did I say less reliable? (IMHO. And yes, I have real
life experience with these ;-)
</para>
<para>
Okay, it's your call. If you want a Windows NAT and/or proxy solution, here
is a decent listing. I don't prefer any one of these tools over another,
especially since I haven't used them before.
<ItemizedList>
<listitem>
<para>
Firesock (from the makers of Trumpet Winsock)
<ItemizedList>
<listitem>
<para>
Does Proxy
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.trumpet.com.au">http://www.trumpet.com.au</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Iproute
<ItemizedList>
<listitem>
<para>
DOS program designed to run on 286+ class computers
</para>
</listitem>
<listitem>
<para>
requires another box like Linux MASQ
</para>
</listitem>
<listitem>
<para>
(UNAVAILABLE) www.mischler.com/iproute/
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Microsoft Proxy
<ItemizedList>
<listitem>
<para>
Requires Windows NT Server
</para>
</listitem>
<listitem>
<para>
Quite expensive
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.microsoft.com">http://www.microsoft.com</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
NAT32
<ItemizedList>
<listitem>
<para>
Windows 95/98/NT compatible
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.nat32.com">http://www.nat32.com</ULink>
</para>
</listitem>
<listitem>
<para>
Roughly $25 for Win9x and $47 for Win9x and WinNT
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
SyGate
<ItemizedList>
<listitem>
<para>
<ULink URL="http://www.sygate.com">http://www.sygate.com</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Wingate
<ItemizedList>
<listitem>
<para>
Does proxy
</para>
</listitem>
<listitem>
<para>
Costs roughly $30 for 2-3 IPs
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.wingate.com">http://www.wingate.com</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
<listitem>
<para>
Winroute
<ItemizedList>
<listitem>
<para>
Does NAT
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.kerio.com/kerio.html">
WinRoute </ULink>
</para>
</listitem>
</ItemizedList>
</para>
</listitem>
</ItemizedList>
</para>
<para>
Lastly, do a web search on "MS Proxy Server", "Wingate", "WinProxy", or goto
<ULink URL="http://www.download.com">www.download.com</ULink>. And definitely
DON'T tell anyone that we sent you.
</para>
</Sect1>
<Sect1 id="developers">
<Title>( Developers ) - I want to help with IP Masquerade development. What
can I do?</Title>
<para>
Join the Linux IP Masquerading DEVELOPERS list and ask the developers there
what you can do to help. For more details on joining the list, check out
<XRef LinkEnd="Masq-List"> FAQ section.
</para>
<para>
Please DON'T ask NON-IP-Masquerade development related questions there!!!!
</para>
</Sect1>
<Sect1 id="more-info">
<Title>( More INFO ) - Where can I find more information on IP Masquerade? </Title>
<para>
You can find more information on IP Masquerade at the
<ULink URL="http://ipmasq.webhop.net/">Linux IP Masquerade Resource</ULink> that
Ambrose Au maintains.
</para>
<para>
You can also find more information at
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">Dranch's Linux page</ULink>
where the TrinityOS and other Linux documents are kept.
</para>
<para>
You may also find more information at <ULink
URL="http://home.indyramp.net/mailman/listinfo/masq">
The Semi-Original Linux IP Masquerading Web Site</ULink> maintained by Indyramp
Consulting, who also provides the IP Masq mailing list.
</para>
<para>
Lastly, you can look for specific questions in the IP MASQ and IP MASQ DEV
email archives or ask a specific question on these lists. Check out
<XRef LinkEnd="Masq-List"> FAQ item for more details.
</para>
</Sect1>
<Sect1 id="translators">
<Title>( Translators ) - I want to translate this HOWTO to another language,
what should I do?</Title>
<para>
Make sure the language you want to translate to is not already covered by
someone else. But, most of the translated HOWTOs are now OLD and need to be
updated. A list of available HOWTO translations are available at the
<ULink URL="http://ipmasq.webhop.net/">Linux IP Masquerade Resource</ULink>.
</para>
<para>
If a copy of a <Emphasis role="strong">current</Emphasis> IP MASQ HOWTO isn't
in your proposed language, please download the newest copy of the IP-MASQ
HOWTO SGML code from the <ULink URL="http://ipmasq.webhop.net/">Linux IP
Masquerade Resource</ULink>. From there, begin your work while maintaining
good SGML coding. For more help on SGML, check out
<ULink URL="http://www.sgmltools.org">www.sgmltools.org</ULink>
</para>
</Sect1>
<Sect1 id="updates">
<Title>( Updates ) - This HOWTO seems out of date, are you still maintaining
it? Can you include more information on ...? Are there any plans for making
this better?</Title>
<para>
Yes, this HOWTO is still being maintained. In the past, Ambrose was guilty of
being too busy working on two jobs and didn't have much time to work on this,
my apologies. As of v1.50, David Ranch revamped the document and got it current
again.
</para>
<para>
If you think of a topic that could be included in the HOWTO, please send email
<ULink URL="mailto:dranch@trinnet.net">dranch@trinnet.net</ULink>. It will be
even better if you can provide that information. We will then include the
information into the HOWTO once it is both found appropriate and tested.
Many thanks for your contributions!
</para>
<para>
We have a lot of new ideas and plans for improving the HOWTO, such as case
studies that will cover different network setup involving IP Masquerade, more on
security via strong IPFWADM/IPCHAINS firewall rulesets, IPCHAINS usage, more
FAQ entries, etc. If you think you can help, please do! Thanks.
</para>
</Sect1>
<Sect1 id="thanks">
<Title>( Thanks ) - I got IP Masquerade working, it's great! I want to thank
you guys, what can I do?</Title>
<para>
<ItemizedList>
<listitem>
<para>
Can you translate the newer version of the HOWTO to another language?
</para>
</listitem>
<listitem>
<para>
Thank the developers and appreciate the time and effort they spent on this.
</para>
</listitem>
<listitem>
<para>
Join the IP Masquerade email list and support new MASQ users
</para>
</listitem>
<listitem>
<para>
Send an email to us and let us know how happy you are
</para>
</listitem>
<listitem>
<para>
Introduce other users to Linux and help them when they have problems.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
</Chapter>
<Chapter>
<Title>Miscellaneous</Title>
<Sect1 id="Donald-Beckers-NIC-drivers-and-utils-FAQ-HW">
<Title>Useful Resources </Title>
<para>
<ItemizedList>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resource page</ULink>
Will have all the current information for setting up IP Masquerade on 2.0.x,
2.2.x, and even old 1.2 kernels!
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/juanjox/">Juan Jose Ciarlante's WWW site
(mirror)</ULink> who is one of the current Linux IP Masquerade maintainers.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade
mailing list Archives</ULink> contains the recent messages sent to the mailing
lists.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">
David Ranch's Linux page including the TrinityOS Linux document and current
versions of the IP-MASQ-HOWTO.</ULink>. Topics such as IP MASQ, strong
IPFWADM/IPCHAINS rulesets, PPP, Diald, Cablemodems, DNS, Sendmail, Samba,
NFS, Security, etc. are covered.
</para>
</listitem>
<listitem>
<para>
The <ULink URL="http://www.tsmservices.com/masq/">IP Masquerading Applications
page</ULink>: A comprehensive list of applications that work or can be tuned
to work through a Linux IP masquerading server.
</para>
</listitem>
<listitem>
<para>
For users setting up IP Masq on MkLinux, email Taro Fukunaga at
<ULink URL="mailto:tarozax@earthlink.net">tarozax@earthlink.net</ULink> for
a copy of his short MkLinux version of this HOWTO.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.indyramp.com/masq/ip_masquerade.txt">IP masquerade
FAQ</ULink> has some general information
</para>
</listitem>
<listitem>
<para>
Paul Russel's <ULink URL="http://www.netfilter.org/ipchains/">
http://www.netfilter.org/ipchains/</ULink>
doc and its possibly older backup at
<ULink URL="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html">
Linux IPCHAINS
HOWTO</ULink>. This HOWTO has lots of information for IPCHAINS usage, as well
as source and binaries for the ipchains tool.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.xos.nl/linux/ipfwadm/">X/OS Ipfwadm page</ULink> contains
sources, binaries, documentation, and other information about the
<Literal>ipfwadm</Literal> package
</para>
</listitem>
<listitem>
<para>
Check out the <ULink URL="http://www.greatcircle.com/">GreatCircle's Firewall
mailing list</ULink> for a great resource about strong firewall rulesets.
</para>
</listitem>
<listitem>
<para>
The <ULink URL="http://www.tldp.org/LDP/nag2/index.html">
LDP Network
Administrator's Guide</ULink> is a MUST for the beginner Linux administrator
trying to set up a network.
</para>
</listitem>
<listitem>
<para>
The <ULink URL="http://www.tldp.org/HOWTO/Net-HOWTO/index.html">
Linux NET HOWTO</ULink>
is also another comprehensive document on how to setup and configure Linux
networking.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.tldp.org/HOWTO/ISP-Hookup-HOWTO.html">
Linux ISP
Hookup HOWTO</ULink> and <ULink URL="http://www.tldp.org/HOWTO/PPP-HOWTO/index.html">
Linux PPP HOWTO</ULink> gives you information on how to connect your Linux host
to the Internet
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.tldp.org/HOWTO/Ethernet-HOWTO.html">
Linux
Ethernet-Howto</ULink> is a good source of information about setting up a
LAN running over Ethernet.
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.scyld.com/network">Donald Becker's NIC
drivers and Support Utils</ULink>
</para>
</listitem>
<listitem>
<para>
You may also be interested in
<ULink URL="http://www.tldp.org/HOWTO/Firewall-HOWTO.html">
Linux Firewalling and Proxy Server HOWTO</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html">
Linux Kernel
HOWTO</ULink> will guide you through the kernel compilation process</para>
</listitem>
<listitem>
<para>
Other <ULink URL="http://www.tldp.org/HOWTO/HOWTO-INDEX/howtos.html">
Linux HOWTOs</ULink> such as Kernel HOWTO</para>
</listitem>
<listitem>
<para>
Posting to the USENET newsgroup: <ULink URL="news:comp.os.linux.networking">
comp.os.linux.networking</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="resources">
<Title>Linux IP Masquerade Resource </Title>
<para>
The <ULink URL="http://ipmasq.webhop.net/">Linux IP Masquerade Resource </ULink>
is a website dedicated to Linux IP Masquerade information also maintained by
Ambrose Au. It has the latest information related to IP Masquerade and may have
information that is not being included in the HOWTO.
</para>
<para>
You may find the Linux IP Masquerade Resource at the following locations:
<ItemizedList>
<listitem>
<para>
<ULink URL="http://ipmasq.webhop.net/">http://ipmasq.webhop.net/</ULink>, Primary
Site, redirected to
<ULink URL="http://ipmasq.webhop.net/">http://ipmasq.webhop.net/</ULink>
</para>
</listitem>
<listitem>
<para>
<ULink URL="http://ipmasq2.webhop.net/">http://ipmasq2.webhop.net/</ULink>,
Secondary Site, redirected to
<ULink URL="http://www.e-infomax.com/ipmasq/">http://www.e-infomax.com/ipmasq</ULink>
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="supporters">
<Title>Thanks to the following supporters..</Title>
<para>
In Alphabetical order:
<ItemizedList>
<listitem>
<para>
Gabriel Beitler, gabrielb@voicenet.com on providing section 3.3.8 (setting up
Novell)
</para>
</listitem>
<listitem>
<para>
Juan Jose Ciarlante, irriga@impsat1.com.ar for contributing his work on the
IPMASQADM port forward tool, the 2.1.x and 2.2.x kernel code, and the original
LooseUDP patch, etc.
</para>
</listitem>
<listitem>
<para>
Steven Clarke, steven@monmouth.demon.co.uk for contributing his IPPORTFW IP port
forwarder tool
</para>
</listitem>
<listitem>
<para>
Andrew Deryabin, djsf@usa.net for contributing his ICQ MASQ module
</para>
</listitem>
<listitem>
<para>
Ed Doolittle, dolittle@math.toronto.edu for suggestions to <Literal>-V</Literal>
option in the<Literal>ipfwadm</Literal> command for improved security
</para>
</listitem>
<listitem>
<para>
Matthew Driver, mdriver@cfmeu.asn.au for helping extensively on this HOWTO, and
providing section 3.3.1 (setting up Windows 95)
</para>
</listitem>
<listitem>
<para>
Ken Eves, ken@eves.com for the FAQ that provides invaluable information for
this HOWTO
</para>
</listitem>
<listitem>
<para>
John Hardin, jhardin@impsec.org for his PPTP and IPSEC forwarding tools
</para>
</listitem>
<listitem>
<para>
Glenn Lamb, mumford@netcom.com for the LooseUDP patch
</para>
</listitem>
<listitem>
<para>
Ed. Lott, edlott@neosoft.com for a long list of tested system and software
</para>
</listitem>
<listitem>
<para>
Nigel Metheringham, Nigel.Metheringham@theplanet.net for contributing his
version of the IP Packet Filtering and IP Masquerading HOWTO, which makes this
HOWTO a better and in-depth technical document section 4.1, 4.2, and others
</para>
</listitem>
<listitem>
<para>
Keith Owens, kaos@ocs.com.au for providing an excellent guide on ipfwadm
section 4.2 on correction to <Literal>ipfwadm -deny</Literal> option which
avoids a security hole, and clarified the status of <Literal>ping</Literal>
over IP Masquerade
</para>
</listitem>
<listitem>
<para>
Michael Owings, mikey@swampgas.com for providing the section about CU-SeeMe
and Linux IP-Masquerade Teeny How-To
</para>
</listitem>
<listitem>
<para>
Rob Pelkey, rpelkey@abacus.bates.edu for providing section 3.3.6 and 3.3.7
(setting up MacTCP and Open Transport)
</para>
</listitem>
<listitem>
<para>
Harish Pillay, h.pillay@ieee.org for providing section 4.5 (dial-on-demand
using Diald)
</para>
</listitem>
<listitem>
<para>
Mark Purcell, purcell@rmcs.cranfield.ac.uk for providing section 4.6 (IPautofw)
</para>
</listitem>
<listitem>
<para>
David Ranch, dranch@trinnet.net for maintaining the HOWTO, helping with the
Linux IP Masquerade Resource Page, the TrinityOS document, ...,
too many to list here :-)
</para>
</listitem>
<listitem>
<para>
Paul Russell, rusty@linuxcare.com.au for all his work on IPTABLES, IPCHAINS,
the IP Masquerade kernel patches in general, etc. The man is a IP NATing fool!
</para>
</listitem>
<listitem>
<para>
Ueli Rutishauser, rutish@ibm.neton providing section 3.3.9 (setting up OS/2
Warp)
</para>
</listitem>
<listitem>
<para>
Steve Grevemeyer, grevemes@tsmservices.com for taking over the IP Masq
Applications page from Lee Nevo and updating it to a full DB backend.
</para>
</listitem>
<listitem>
<para>
Fred Viles, fv@episupport.com for his patches on proper port forarding of FTP.
</para>
</listitem>
<listitem>
<para>
John B. (Brent) Williams, forerunner@mercury.net on providing section 3.3.7
(setting up Open Transport)
</para>
</listitem>
<listitem>
<para>
Enrique Pessoa Xavier, enrique@labma.ufrj.bron the BOOTp setup suggestion
</para>
</listitem>
<listitem>
<para>
All the users on the IP-MASQ email list, masq@indyramp.com for their
help and support for all the new Linux MASQ users.
</para>
</listitem>
<listitem>
<para>
Other code and documentation developers of IP Masquerade for this great feature
</para>
</listitem>
<listitem>
<para>
Delian Delchev, delian@wfpa.acad.bg
</para>
</listitem>
<listitem>
<para>
David DeSimone (FuzzyFox), fox@dallas.net
</para>
</listitem>
<listitem>
<para>
Jeanette Pauline Middelink, middelin@polyware.iaf.nl
</para>
</listitem>
<listitem>
<para>
Miquel van Smoorenburg, miquels@q.cistron.nl
</para>
</listitem>
<listitem>
<para>
Jos Vos, jos@xos.nl
</para>
</listitem>
<listitem>
<para>
And others who I may have failed to mention here (please let me know)
</para>
</listitem>
<listitem>
<para>
All users sending feedback and suggestions to the mailing list, especially
those who reported errors in the document and the clients who are supported and
not supported
</para>
</listitem>
<listitem>
<para>
We apologize if we have omitted any important names, not included information
that some fellow users have sent us yet, etc. There were many suggestions and
ideas sent but there wasn't enough time to verify and integrate these changes.
David Ranch is constantly trying his best to incorporate all of the information
sent to me into the HOWTO. I thank you for the effort, and I hope you understand
our situation.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="references">
<Title>Reference </Title>
<para>
<ItemizedList>
<listitem>
<para>
Original IP masquerade FAQ by Ken Eves
</para>
</listitem>
<listitem>
<para>
IP masquerade mailing list archive by Indyramp Consulting
</para>
</listitem>
<listitem>
<para>
IP Masquerade WWW site by Ambrose Au
</para>
</listitem>
<listitem>
<para>
Ipfwadm page by X/OS
</para>
</listitem>
<listitem>
<para>
Various networking related Linux HOWTOs
</para>
</listitem>
<listitem>
<para>
Some topics covered in TrinityOS by David Ranch
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
<Sect1 id="ChangeLOG">
<Title>ChangeLOG </Title>
<para>
TO do - HOWTO:
<ItemizedList>
<listitem>
<para>
Add the scripted IPMASQADM example to the Forwarders section. Also confirm
the syntax.
</para>
</listitem>
<listitem>
<para>
Add a little section on having multiple subnets behind a MASQ server
</para>
</listitem>
<listitem>
<para>
Confirm the IPCHAINS ruleset and make sure it is consistant with the IPFWADM
ruleset
</para>
</listitem>
</ItemizedList>
</para>
<para>
TO DO - WWW page:
<ItemizedList>
<listitem>
<para>
Update the PPTP patch on the masq site
</para>
</listitem>
<listitem>
<para>
Update the portfw FTP patch
</para>
</listitem>
</ItemizedList>
</para>
<!-- Blah -->
<!-- ChangeLOG -->
<para>
Changes from 05/22/05 to 11/13/05
<ItemizedList>
<listitem>
<para>
11/13/05 - Fix a bug where the PORTFW example rule in section 6.7 was
incorrect. Updated the IPTABLES PORTFW section to include state tracking
for the pre-routing rule, added a cross-reference to the PORTFW FAQ entry,
and reduced some duplicate PORTFW examples in different chapters of the HOWTO.
Thanks to Thomas Zajic for bringing this to my attention.
</para>
</listitem>
<listitem>
<para>
10/23/05 - Updated the dynamic IP FAQ section to give complete examples
on how to re-run the rc.firewall-* scripts for various different DHCP clients
</para>
</listitem>
<listitem>
<para>
10/19/05 - Updated the HOWTO to be very clear on loading the various
rc.firewall-* rulesets (there are 6 of them in this HOWTO both simple and
stronger versions for IPTABLES, IPCHAINS, and IPFWADM) files vs. loading a
generic rc.firewall file. I also updated the troubleshooting section to
reflect this possibly confusing point.
</para>
</listitem>
<listitem>
<para>
05/27/05 - Updated the Multiple NAT situation to include ProxyARP solutions
</para>
</listitem>
<listitem>
<para>
05/26/05 - Clarified the section for IPMASQ on multiple internal LAN segments
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 05/03/05 to 05/22/05
<ItemizedList>
<listitem>
<para>
05/22/05 - Updated the rc.firewall-iptables-stronger ruleset to 0.87s.
Removed the unused drop-and-logit chain as it was only later being deleted
anyway. Thanks to Matthew Concannon for this one.
</para>
</listitem>
<listitem>
<para>
05/21/05 - Updated the Multiple-IPs FAQ entry a bit
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 04/17/05 to 05/03/05
<ItemizedList>
<listitem>
<para>
05/03/05 - Updated the rc.firewall-iptables-stronger ruleset to fix a typo
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 03/19/04 to 04/17/05
<ItemizedList>
<listitem>
<para>
04/30/05 - Updated the IP address for unc.metalab.org and published the
HOWTO to the web.
</para>
</listitem>
<listitem>
<para>
12/18/04 - Added some comments in the IPTABLES, IPCHAINS, and IPFWADM
rulesets why the default policy is ACCEPT and not something like DROP.
</para>
</listitem>
<listitem>
<para>
07/24/04: Renamed the rc.firewall-2.4/2.2/2.0-* rulesets to
rc.firewall-iptables/ipchains/ipfwadm-*. This change better reflects that
these rulesets can run on different kernel versions (such as 2.6.x). Updated
the rc.firewall-iptables-stronger ruleset to 0.85s to fix an improper /24
netmask for the INTIP variable.
</para>
</listitem>
<listitem>
<para>
04/10/04: Updated the rc.firewall-2.4-stronger ruleset to use the 192.16.0.x
network instead of 192.168.1.x network to better align with the rest of the
HOWTO
</para>
</listitem>
<listitem>
<para>
04/04/04: Added that Redhat9 supports IPMASQ
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 11/10/03 to 03/18/04
<ItemizedList>
<listitem>
<para>
03/18/04: Added a sub-section for supporting multiple internal networks for
IPTABLES
</para>
</listitem>
<listitem>
<para>
02/02/04: Updated some old jhardin rubyriver to impsec.org URLs
</para>
</listitem>
<listitem>
<para>
01/10/04: Updated the rc.firewall-2.4-stronger and 2.2 rulesets to make
placement of PORTFW configs more obvious
</para>
</listitem>
<listitem>
<para>
01/01/04: Some systems require that the /etc/rc.d/init.d/firewall-2.* files
be executable. Fixed. Thanks to Chris Carter and others for the nudge.
</para>
</listitem>
<listitem>
<para>
01/01/04: Some systems require that the /etc/rc.d/init.d/firewall-2.* files
be executable. Fixed. Thanks to Chris Carter and others for the nudge.
</para>
</listitem>
<listitem>
<para>
01/01/04: Added an additional chkconfig check on Redhat systems to make sure
that the firewall will load upon init level change. Thanks to Chris Carter
for the idea.
</para>
</listitem>
<listitem>
<para>
12/19/03: Updated the rc.firewall-2.4-stronger ruleset to 0.82. This
new ruleset has a special ICMP filter to work around a Netfilter bug.
Also, the drop-and-log-it chain has been renamed to reject-and-log-it
since that's actually what it's doing. Thanks to Bart Martens for the
recommendations.
</para>
</listitem>
<listitem>
<para>
12/13/03: Fixed some minor grammar issues. Thanks to Lawrence Berlinsk
for pointing them out.
</para>
</listitem>
<listitem>
<para>
11/30/03: Updated the rc.firewall-2.4-stronger ruleset to 0.81s, the
rc-firewall-2.2-stronger ruleset to 0.72s, and updated the
rc.firewall-2.0-stronger ruleset to 0.72s (never had a version # before).
These changes reflect either the ruleset not having strong enough comments
or allowing all traffic destined to the MASQ server itself from being
protected. It's recommend that if you want to enable access to servers running
on the MASQ server itself (http, ssh, etc.), selectively enable them under the
OPTIONAL INPUT section.
</para>
</listitem>
<listitem>
<para>
11/03/03: Updated the rc.firewall-2.2-stronger ruleset where an INTLAN rule
that was allowing traffic from ANY IP address instead of the proper INTIP IP
address only. This aligns the IPCHAINS ruleset with the IPTABLES and IPFWADM
ruleset examples
</para>
</listitem>
<listitem>
<para>
11/10/03: Deleted all kernelnotes.org URLS (juanjox URLs)
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 06/22/03 to 11/09/03
<ItemizedList>
<listitem>
<para>
10/25/03: Fixed a dead RFC1918 URL in section 3.3. Thanks to Mark Sobell for the report.
</para>
</listitem>
<listitem>
<para>
07/07/03: Added the "reducing-masq-log" FAQ entry to help people reduce the
size of their firewall logs.
</para>
</listitem>
<listitem>
<para>
06/27/03: Updated the rc.firewall-2.4-stronger ruleset to 0.80s. Added a
DISABLED ip_nat_irc kernel module section, changed the default of the
ip_conntrack_irc to NOT load by default, and added additional kernel module
comments.
</para>
</listitem
<listitem>
<para>
06/27/03: Updated the rc.firewall-2.4 ruleset to 0.75. Added additional
iptables kernel module comments.
</para>
</listitem
<listitem>
<para>
06/24/03: Added Debian 3.0 to the supported distro list
</para>
</listitem
<listitem>
<para>
06/23/03: Change the PMTU URLs to point to Phil's primary www site
</para>
</listitem
</ItemizedList
</para
<para>
Changes from 05/26/03 to 06/22/03
<ItemizedList>
<listitem>
<para>
06/22/03: Updated the various Indyramp MASQ email URLs again as things seemed
to have changed. Again.
</para>
</listitem>
<listitem>
<para>
06/21/03: Rewrote the MTU FAQ section to be more clear, include specific
information of the problems, and also fixed a bad typo for PPPoE users who
were trying to configure "--clamp-mss-to-mtu" when it should have been
"--clamp-mss-to-pmtu" (missing the p in pmtu).
</para>
</listitem>
<listitem>
<para>
06/13/03: Added kernel info for Mandrake 8.1
</para>
</listitem>
<listitem>
<para>
06/02/03: Fixed a typo where extended 2.2.x kernel checks for IPMASQ
functionality was using "cat" and not "ls"
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 04/08/03 to 05/26/03
<ItemizedList>
<listitem>
<para>
05/26/03: updated the firewall rulesets: rc.firewall-2.4 (to 0.74),
rc.firewall-2.2 (to 1.22), rc.firewall-2.4-stronger (to 0.79s), and
rc.firewall-2.2-strongerw (to 0.71s) to use modprobe instead of insmod.
</para>
</listitem>
<listitem>
<para>
05/26/03: Added how to dump IPTABLES MASQ entries in the Accounting FAQ
section
</para>
</listitem>
<listitem>
<para>
05/26/03: Added Clamp-MSS recommendations to the MTU faq section
</para>
</listitem>
<listitem>
<para>
05/26/03: Added additional troubleshooting steps in Section 5 when the MASQ
client cannot ping the MASQ server.
</para>
</listitem>
<listitem>
<para>
05/26/03: Added additional traffic shaping / traffic limiter URLs to the
SHAPING FAQ entry
</para>
</listitem>
<listitem>
<para>
05/26/03: Renamed the "IPROUTE2" FAQ entry to "Souce Routing"; Added IPTABLES
examples to the section; fixed an incorrect IP address of 62123.123.123.123
</para>
</listitem>
<listitem>
<para>
05/25/03: Fixed a SGML script that was improperly converting ampersands
for the downloadable firewall-* and rc.firewall-* scripts. Also caught a
SGML ampersand bug in a comment section of the rc.firewall-2.0 file
</para>
</listitem>
<listitem>
<para>
05/25/03: Deleted several dead links: ftp.gts.cz, novell.com LWP5,
Old Juanjox mirror (geocities), old ipmasq2.webhop.net URL,
old zzdmacka NAT information URL, old linux.org/uk/VERSION url,
old netfilter.samba.org URLs (no longer a netfilter mirror - redirect),
old Activision BattleZone DLL url, old iproute2 (rpms, ras.ru, donlug,
dontsk, tusur, waaug, etc.) urls, old rlynch ipautofw mirror
</para>
</listitem>
<listitem>
<para>
05/25/03: Updated several URLs: suse/proxy_suite/, www.indyramp.net URLs,
several urls with " ~ " in it became ~732 for some reason,
updated all of the jhardin URls to point from wolfnet.com to impsec.org,
updated all LDP urls (linuxdoc.org to tldp.org), IPCHAINS patches for 2.0.x
kernels, metalab to tldp.org, winfiles.com to download.com,
Microsoft technet article 172227, Oidentd, mumford LooseUDP URL,
2.2.x PORT-FTP URL, IRQTUNE url, midentd URL
</para>
</listitem>
<listitem>
<para>
05/25/03: Pending updates from remote webmasters: Indyramp EQL URL,
insecurity.net sidentd
</para>
</listitem>
<listitem>
<para>
05/25/03: Lots of little updates like:: updated the Intro section verbage a
little to reflect BETA kernels and not OLD kernels; Updated the Forward
section (not PORTFW) to be a little more generic; Added a link in the Forward
to the IPMASQ email list; Updated the dates in the copyright notice;
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the "Current Status" to add the remark that some
programs have been updated to use NAT-friendly protocols and thus special
NAT modules are no longer required
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the 2.4 Requirements section: deleted a duplicate line
(true 1:1 NAT); cleaned some addition things up; Added CuSeeme to the 2.4
ported list
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the 2.2 / 2.0 Requirements section: Deleted the reference
to the obsoltele IPMASQ ICQ module; Updated the link for the LooseUDP URL;
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the Compiling Linux 2.2.x / 2.0.x section: Deleted the
recommendations to load the rc.firewall ruleset via rc.local. This should
come later in the HOWTO and offer other methods for different Linux
distributions
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the ICQ Application section to say that these steps are
/not/ required for modern ICQ clients. I've left this section in the HOWTO
to demonstrate a large PORTFW example
</para>
</listitem>
<listitem>
<para>
05/24/03: Made some of the FAQ entries more kernel version generic and also
deleted the 2.0.x "upgrades-cont.html" FAQ entry as it was basically a
duplicate
</para>
</listitem>
<listitem>
<para>
05/24/03: Updated the LooseUDP game section to explain how it works,
explain how much of this was properly solved under the stateful IPTABLES
systtem, and also say that it is NOT available for the 2.4.x kernels.
If IPTABLES's stateful UDP tracking doesn't work for, you're probably out
of luck.
</para>
</listitem>
<listitem>
<para>
05/24/03: Mentioned in the FAQ section that MASQ timers are NOT adjustable
under IPTABLES
</para>
</listitem>
<listitem>
<para>
05/24/03: Vastly expanded the packet firewall log FAQ entry and finally added
a IPTABLES packet log description section. I also aligned the IPCHAINS
example to match the IPFWADM entry
</para>
</listitem>
<listitem>
<para>
04/11/03: Fixed a incorrect echo statement saying the IPTABLES policy was
being set to REJECT and not DROP.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 01/31/03 to 04/08/03
<ItemizedList>
<listitem>
<para>
04/08/03: Added additional formatting and the "ip_masquerade" /proc entry
into Section 3.2. This helps users determine if their kernel is MASQ-ready.
</para>
</listitem>
<listitem>
<para>
03/08/03: Added the EXTIP variable to the 2.4.x PORTFW example as several
people were trying to use this with the BASIC ruleset and I had assumed they
were using the STRONGER ruleset. Thanks to Greg Lukins for bringing this
to my attention.
</para>
</listitem>
<listitem>
<para>
03/08/03: Added Distros to the MASQ compatibility list: Mandrake, Gentoo
</para>
</listitem>
<listitem>
<para>
02/08/03: Forgot to update the VERSION number for the
rc.firewall-2.4-stronger rulese. Added some additional formatting
</para>
</listitem>
<listitem>
<para>
02/01/03: Added additional checking in the kernel compiling section to
understand if your kernel supports IPMASQ via modules or by being statically
compiled in.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 01/12/03 to 01/31/03
<ItemizedList>
<listitem>
<para>
01/31/03: Doh. I should have read my own comments. I've reversed the
2.4.x. policy settings from REJECT back to DROP. REJECT, for some lame
reason, is not a legal policy. The recommended REJECT action is still
carried out via the "drop-and-log-it" user chain.
</para>
</listitem>
<listitem>
<para>
01/30/03: Updated the Multiple-IPs FAQ entry to better describe how users
that want to put external IPs behind a Linux router. Added additional URLs
and cleaned up the text a bit too.
</para>
</listitem>
<listitem>
<para>
01/30/03: Updated the 2.4.x requirement section to reflect more of the pros
of IPTABLES as well as updated the update status of some old legacy 2.2.x
modules
</para>
</listitem>
<listitem>
<para>
01/30/03: Added an additional FAQ entry that clearly explains what the
ipchains.o module can and CANNOT do on 2.4.x. kernels
</para>
</listitem>
<listitem>
<para>
01/28/03: Extensively updated the 2.4.x kernel compilation section to reflect
a 2.4.20 kernel with IPTABLES 1.2.7a. The section also reflects the new
methods to compile IPTABLES, apply Patch-O-Matic patches, and also included
lots of example output too.
</para>
</listitem>
<listitem>
<para>
01/28/03: Updated the kernel compiling section to be a little more clear on how
different Linux distros can have different kernels (modules vs. monolithic)
</para>
</listitem>
<listitem>
<para>
01/17/03: Fixed a major issue where the rc.firewall-2.2-stronger ruleset
was referencing missing executable variables. This was taken from the
2.4-stronger ruleset but I guess I forgot to finish it off. Fixed.
Thanks to Samuel Kim for catching this!
</para>
</listitem>
<listitem>
<para>
01/17/03: Fixed an issue where the rc.firewall-2.2-stronger's commented
HTTP section was missing the "-p tcp" option.
Thanks to Samuel Kim for catching this!
</para>
</listitem>
<listitem>
<para>
01/16/03: Updated the URL for DJSF's ICQ module
</para>
</listitem>
<listitem>
<para>
01/16/03: Changed the default policy and drop chain from DENY to REJECT
on both IPTABLES rulesets and on the advanced IPFWADM rulset.
Thanks to Jonathan Hutchins for bringing this to my attention.
</para>
</listitem>
<listitem>
<para>
01/16/03: Fixed a typo in the commented out HTTPd OUTPUT section of the
rc.firewall-2.2-s ruleset
</para>
</listitem>
<listitem>
<para>
01/13/03: Updated the IPMASQ www site URL from ipmasq.cjb.net to
ipmasq.webhop.net. CJB started to change their policies so we switched.
</para>
</listitem>
<listitem>
<para>
01/13/03: Added to the 2.4.x Requirements section that IPTABLES v1.2.7a is
out and recommended.
</para>
</listitem>
<listitem>
<para>
01/13/03: Added an additional test item to the "Test Section - Section 5" for
versions of IPTABLES that are too old. I also cleaned up this section to read
easier.
</para>
</listitem>
<listitem>
<para>
01/13/03: Updated the rc.firewall-2.4-stronger ruleset to include commented
rules to allow in HTTP traffic to a local HTTP server. Also added a rule
comment in the FORWARD section to help users know where to put PORTFW commands.
</para>
</listitem>
<listitem>
<para>
01/13/03: Updated the rc.firewall-2.2-stronger ruleset to include commented
rules to allow in HTTP traffic to a local HTTP server. Also added a rule
comment in the FORWARD section to help users know where to put PORTFW commands.
</para>
</listitem>
<listitem>
<para>
01/13/03: Clarified the PORTFW section to help users better understand where
the PORTFW commands should go in the rc.firewall rulesets. I also cleaned up
this section to read a little better.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 12/13/02 to 01/12/03
<ItemizedList>
<listitem>
<para>
01/03/03: Added Redhat 7.3 and 8.0 to the compatibility chart.
</para>
</listitem>
<listitem>
<para>
01/03/03: Fixed various typos. Thanks to Gabriel Withington for the sharp
eye.
</para>
</listitem>
<listitem>
<para>
12/22/02: Updated the 2.2.x H.323 kernel patch URL. Thanks to Maxime Plante
for pointing this out.
</para>
</listitem>
<listitem>
<para>
12/22/02: Updated the 2.4.x kernel compiling section to let users know that
most modern kernels don't need IPTABLES Patch-o-matic patches to be applied
except to fix bugs or add additional functionality.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 10/20/02 to 12/13/02
<ItemizedList>
<listitem>
<para>
11/27/02: Fixed the init.d scripts to point the header to the correct config
file. This must be due to newer versions of "chkconfig" doing better checking.
Please note that this might still be a problem for the rc.firewall-2.?-stronger
rulesets. Thanks to Joris Van Puyenbroeck for the heads up.
</para>
</listitem>
<listitem>
<para>
11/25/02: Updated all the firewall comments to reflect that PPPoE users need to
user the "ppp0" logical interface as their external interface instead of the
physical interface such as "eth0". Thanks to Meng Cheah for the nudge.
</para>
</listitem>
<listitem>
<para>
11/13/02: Updated the URL for the Donald Becker based NIC drivers. Thanks to
Bruce Gorgon for the heads up.
</para>
</listitem>
<listitem>
<para>
11/01/02: Added a new FAQ section that covers redirection of local INTERNAL
traffic to internal PORTFWed servers
</para>
</listitem>
<listitem>
<para>
11/01/02: Updated the PORTFW section to be a little more clear.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 04/19/02 to 10/20/02
<ItemizedList>
<listitem>
<para>
09/29/02: Fixed a stray incorrect IP address pointing to metalab.unc.edu
</para>
</listitem>
<listitem>
<para>
08/29/02: Fixed a typo in the firewall-2.2 startup script which
was starting the 2.4 firewall and not the 2.2. version.
Thanks to Jean-Marc Vanel for catching this.
</para>
</listitem>
<listitem>
<para>
08/25/02: Updated the rc.firewall-2.2-stronger and rc.firewall-2.2
scripts to use shell environment variables.
</para>
</listitem>
<listitem>
<para>
07/09/02: Updated the FTP PORTFW section to be more readible
</para>
</listitem>
<listitem>
<para>
07/06/02: Replaced all the filewatcher.org URLs with netfilter.org
URLs
</para>
</listitem>
<listitem>
<para>
06/12/02: Changed some of the formatting to try and help newbies
better understand that the "\" character is used as a continuation
of the previous line.
</para>
</listitem>
<listitem>
<para>
06/12/02: Updated the IP address of metalab.unc.edu in Section 5.
Thanks to Pete Trachy for bringing this to my attention but please note
that even major sites like Metalab change their IPs, subnets, or even
ISPs from time to time.
</para>
</listitem>
<listitem>
<para>
06/02/02: Updated the rc.firewall-2.4 ruleset to include a commented
option for NATing IRC DCCs, added the use of more environment vars, and
added additional formatting.
</para>
</listitem>
<listitem>
<para>
05/18/02: Added some extra # lines the commented section of the
rc.firewall-2.4-stronger ruleset to better serve Cut and Paste users.
</para>
</listitem>
<listitem>
<para>
05/04/02: - Updated the various PPTP MASQ links to point to a valid URL.
Also updated the HOWTO to reflect that PPTP is now supported on the 2.4.x
kernels.
</para>
</listitem>
<listitem>
<para>
05/03/02: - Updated the 2.4.x kernel requirements section to point out
that IPCHAINS compatibility under 2.4.x kernels isn't very good. If you
want to use IPMASQ under a 2.4.x kernel, you should use IPTABLES rules only.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 01/05/02 to 04/19/02 - v2.00.041902 pubsished to the LDP
<ItemizedList>
<listitem>
<para>
04/01/02: - Updated the rc.firewall-2.4-stronger ruleset to denote
and disable internal DHCP server support on the OUTPUT rules
</para>
</listitem>
<listitem>
<para>
02/09/02: - Added Redhat-style init.d scripts to start the
rc.firewall files
</para>
</listitem>
<listitem>
<para>
02/09/02: - Updated all the various chapters to use human readable
file names vs. things like x2623.html.
</para>
</listitem>
<listitem>
<para>
02/09/02: - Expanded the IPMASQ accounting section
</para>
</listitem>
<listitem>
<para>
02/04/02: - Deleted an extra "$" from the PORTFW variable in section
6.7.1
</para>
</listitem>
<listitem>
<para>
01/31/02: - Updated the URLs for the PPPd and Diald homepages
</para>
</listitem>
<listitem>
<para>
01/26/02: - Fixed some typos and added a LooseUDP clarification to tell
users to read the example rc.firewall-2.2 ruleset comments on how to enable
LooseUDP.
</para>
</listitem>
<listitem>
<para>
01/08/02: - Made some slight clarifications to IP Alias support
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 11/19/01 to 01/05/02 - 010502 pubsished to the LDP
<ItemizedList>
<listitem>
<para>01/05/02: - Added disabled rules to the rc.firewall-2.4-stronger
ruleset to support INTERNAL DHCP server and EXTERNAL access to a WWW server
running on the MASQ machine.
</para>
</listitem>
<listitem>
<para>01/05/02: - Added required changes to the loading of the
ip_conntrack_ftp module if people PORTFW to non-standard FTP ports.
</para>
</listitem>
<listitem>
<para>01/05/02: - Added an example in the 2.4.x PORTFW section on
how to REDIRECT internal traffic back to an INTERNAL server. This is
the same as running REDIR under 2.2.x and 2.0.x kernels.
</para>
</listitem>
<listitem>
<para>01/05/02: - Added Juanjox mirror URLs to the HOWTO.
</para>
</listitem>
<listitem>
<para>01/04/02: - Clarified and cleaned up the ICQ PORTFW section; Added
thoughts on the ip_masq_icq, PORTFW, and SOCKS solutions
</para>
</listitem>
<listitem>
<para>01/05/02: - Added Slackware 8.0 to the supported list.
</para>
</listitem>
<listitem>
<para>01/04/02: - Fixed some spelling mistakes in the 2.4 and 2.2
rulesets. Thanks to Michael Ott for the sharp eye.
</para>
</listitem>
<listitem>
<para>12/19/01: - Fixed a minor comment typo in the rc.firewall-2.4
file. Thanks to Bruno Negrao for this one.
</para>
</listitem>
<listitem>
<para>12/02/01: - Fixed some minor version typos in the 2.4.x rc.firewall
ruleset; Added a missing $PORTFWIF variable for the 2.4.x PORTFW example.
Thanks to Neil Bunn for the errata.
</para>
</listitem>
<listitem>
<para>11/25/01: - Expanded on the ipchains module conflict error messages
in Section 5
</para>
</listitem>
<listitem>
<para>11/23/01: - Updated the HOWTO to reflect a new PPTP kernel module
for the 2.4.x kernels
</para>
</listitem>
<listitem>
<para>11/19/01: - Clarified the PPTP supports for 2.4.x kernels
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 08/26/01 to 11/18/01 - 111801 published to the LDP
<ItemizedList>
<listitem>
<para>11/12/01: - updated various comments to reflect new versions:linux 2.4.14,
iptables 1.2.4, and linux 2.2.20.
</para>
</listitem>
<listitem>
<para>11/12/01: - Added the rc.firewall-2.4-stronger ruleset to the HOWTO,
updated the 2.4.x kernel and IPTABLES compiling steps to
reflect 2.4.14 and 1.2.4.
</para>
</listitem>
<listitem>
<para>11/10/01: - Added the directly downloadable versions of the 2.4,
2.4-stronger, 2.2, 2.2-stronger, 2.0, and and 2.0.x-stronger
rulesets to the WWW.
</para>
</listitem>
<listitem>
<para>11/10/01: - Updated the 2.4.x PORTW example to add the missing
FORWARD option.
</para>
</listitem>
<listitem>
<para>11/10/01: - Updated the DSL-HOWTO link in the HOWTO
</para>
</listitem>
<listitem>
<para>10/27/01: - Updated the network diagram in section 2.5 to be a little
more verbose.
</para>
</listitem>
<listitem>
<para>
09/18/01: - Fixed some broken reference links pointing to the respective
2.4.x, 2.2.x, and 2.0.x kernel compiling recommendations.
</para>
</listitem>
<listitem>
<para>
09/16/01: - Cleaned up and updated the PORTFW section to also include
PREROUTING examples for 2.4.x kernels.
</para>
</listitem>
<listitem>
<para>
09/13/01: - Updated the IPTABLES simple rc.firewall ruleset to 0.62.
This fixed a typo on the MASQ enable line that used eth0
instead of $EXTIF.
Thanks to Hafi for reporting this.
</para>
</listitem>
<listitem>
<para>
09/07/01: - It seems that most people who are getting IPCHAINS and IPTABLES
conflicts are running Redhat 7.1. I have updated section
5 on how to fix this. Thanks to Jason Wenzel for helping me
with this.
</para>
</listitem>
<listitem>
<para>
09/07/01: - Noted that IPTABLES v1.2.3 is current version. All versions
less than v1.2.3 have an FTP module bug that can bypass strong
firewall rulesets. Please upgrade your copy of IPTABLES now.
</para>
</listitem>
<listitem>
<para>
09/07/01: - Created version numbers for the simple rc.firewall rulesets
(IPTABLES - v0.61) (IPCHAINS - v1.01) (IPFWADM - v2.01). and
cleaned up some of the comments in each section.
</para>
</listitem>
<listitem>
<para>
09/07/01: - Added rules to the simple rc.firewall rulesets to flush the
various tables. In addition to this, I have added the use
of environment variables and more echo statements in the
rulesets to make things easier to edit and monitor.
Thanks to Ian Bishop for the good idea.
</para>
</listitem>
<listitem>
<para>
09/07/01: - Added the use of EXTIF and INTIF interface variables in each of
the rc.firewall and partial firewall rulesets for better
clarity (similar to how TrinityOS has been doing for a while
now). Thanks to Sean McKeon for the nudge.
</para>
</listitem>
<listitem>
<para>
09/07/01: - Fixed a typo in the UNIX client configuration section where the
network broadcast was 192.168.0.25 instead of .255.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 2.01 to 2.05 - 08/26/01
<ItemizedList>
<listitem>
<para>
08/19/01: - Added an additional testing step in Section5 to make sure the
rc.firewall file loads ok. Thanks to Steven Levis for the good idea.
</para>
</listitem>
<listitem>
<para>
08/15/01: - Change the reference for the /etc/hosts file from RFC952 to
RFC1035. Thanks to Michael F. Maggard for the correction.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.96 to 2.01 - 08/12/01
<ItemizedList>
<listitem>
<para>
08/12/01: - Updated the basic IPTABLES ruleset to 0.60 which fixed a major
issue where all MASQed packets were being dropped. Ultimately,
I forgot to add a rule to ACCEPT correct packets through the
forwarding chain.
</para>
</listitem>
<listitem>
<para>
- Added an additional rule to log all bogus FORWARD packets
</para>
</listitem>
<listitem>
<para>
- Load the FTP nat modules now by default
</para>
</listitem>
<listitem>
<para>
- Changed the load order of some of the kernel modules to not
create bogus error messages
</para>
</listitem>
<listitem>
<para>
- Added an IPTABLES section on how to MASQ specific hosts vs. an
entire subnet
</para>
</listitem>
<listitem>
<para>
- Added more MASQ-client compatible operating systems
</para>
</listitem>
</ItemizedList>
<ItemizedList>
<listitem>
<para>
07/19/01: - The advanced IPCHAINS example for forwarding between multiple
interfaces was missing the critital "-j ACCEPT" to actually let
the packets flow.
Thanks to Shingo Yamaguchi for catching this.
</para>
</listitem>
</ItemizedList>
Changes from 1.96 to 2.00 - 06/10/01
<ItemizedList>
<listitem>
<para>
06/21/01: Updated Section 5 (Testing Section) to add an additional test to
help users troubleshoot their MASQ setup. There are now a total
of -11- tests.
06/16/01: Updated the intro History section at the beginning of the HOWTO.
06/14/01: Added mirror Netfilter and IPCHAINs mirror URLs
06/13/01: Updated the H.323 URL
</para>
</listitem>
<listitem>
<para>
06/10/01:
Double DOH! The simple rc.firewall script for the 2.4 kernels had
two major errors in it. The new version is far more informative
and even works!
I am continuing to go through the HOWTO and cleaning things up
but I'm not done quite yet.
</para>
</listitem>
<listitem>
<para>
06/02/01:
Updated the lists of known compatible MASQ'ed operating systems
(Windows M3, Linux 2.3, 2.4, etc)
Made more references to DHCP and DNS in the various different MASQ client
configuration guides.
</para>
</listitem>
<listitem>
<para>
04/12/01:
Thanks to the Joshua X and the other people at Command Prompt, Inc.
for the port of the HOWTO from LinuxDoc to DocBook.
Add email list URL to line 126
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.90 to 1.95 - 11/11/00
<ItemizedList>
<listitem>
<para>
A BIG thanks to the Joshua X and the other people at Command Prompt, Inc.
for the port of the HOWTO from LinuxDoc to DocBook.
</para>
</listitem>
<listitem>
<para>
Added a quick upfront notice in the intro that running a SINGLE NIC in MASQ
mutliple ethernet segments is NOT recommended and linked to the relivant FAQ
entry. Thanks to Daniel Chudnov for helping the HOWTO be more clear.
</para>
</listitem>
<listitem>
<para>
Added a pointer in the Intro section to the FAQ section for users looking for
how MASQ is different from NAT and Proxy services.
</para>
</listitem>
<listitem>
<para>
Reordered the Kernel requirements sections to be 2.2.x, 2.4.x, 2.0.x
</para>
</listitem>
<listitem>
<para>
Expanded the kernel testing in Section 3 to see if a given kernel already
supports MASQ or not.
</para>
</listitem>
<listitem>
<para>
Reversed the order of the displayed simple MASQ ruleset examples (2.2.x and 2.0.x)
</para>
</listitem>
<listitem>
<para>
Cleaned up some formatting issues in the 2.0.x and 2.2.x rc.firewall files
</para>
</listitem>
<listitem>
<para>
Noted in the 2.2.x rc.firewall that the defrag option is gone in some distro's
proc (Debian, TurboLinux, etc)
</para>
</listitem>
<listitem>
<para>
Added a NOTE #3 to the rc.firewall scripts to include instructions for Pump.
Thanks to Ross Johnson for this one.
</para>
</listitem>
<listitem>
<para>
Cleaned up the simple MASQ ruleset examples for both the 2.2.x and 2.2.x
kernels
</para>
</listitem>
<listitem>
<para>
Updated the simple and stronger IPCHAINS and IPFWADM rulesets to include the
external interface names (IPCHAINS is -i; IPFWADM is -W) to avoid some internal
traffic MASQing issues.
</para>
</listitem>
<listitem>
<para>
Vastly expanded the Section 5 (testing) with even more testing steps with added
complete examples of what the output of the testing commands should look like.
</para>
</listitem>
<listitem>
<para>
Moved the H.323 application documentation from NOT supported to Supported. :-)
</para>
</listitem>
<listitem>
<para>
Reordered the Multiple LAN section examples (2.2.x then 2.0.x)
</para>
</listitem>
<listitem>
<para>
Made some additional clarifications to the Multiple LAN examples
</para>
</listitem>
<listitem>
<para>
Fixed a critical typo with multiple NIC MASQing where the network examples had
the specified networks reversed. Thanks to Matt Goheen for catching this.
</para>
</listitem>
<listitem>
<para>
Added a little intro to MFW in the PORTFW section.
</para>
</listitem>
<listitem>
<para>
Reveresed the 2.0.x and 2.2.x sections for PORTFW
</para>
</listitem>
<listitem>
<para>
Updated the news regarding PORTFWing FTP traffic for 2.2.x kernels
<ProgramListing>
NOTE: At this time, there *IS* a BETA level IP_MASQ_FTP module
for PORT Forwarding FTP connections 2.2.x kernels which also supports
adding additional PORTFW FTP ports on the fly without the requirement
of unloading and reloading the IP_MASQ_FTP module and thus breaking
any existing FTP transfers.
</ProgramListing>
</para>
</listitem>
<listitem>
<para>
Added a top level note about PORTFWed FTP support
</para>
</listitem>
<listitem>
<para>
Added a noted to the 2.0.x PORTFW'ed FTP example why users DON'T need to PORTFW
port 20.
</para>
</listitem>
<listitem>
<para>
Updated the PORTFW section to also mention that users can use FTP proxy
applications like the one from SuSe to support PORTFWed FTP-like
functionality. Thanks to Stephen Graham for this one.
</para>
</listitem>
<listitem>
<para>
Updated the example for how to enable PORTFWed FTP to also include required
configurations on how the ip_masq_ftp module is loaded for users who use
multiple PORTs to contact multiple internal FTP servers. Thanks to Bob Britton
for reminding me about this one.
</para>
</listitem>
<listitem>
<para>
Added a FAQ entry for users who have embedded &circ;Ms in their rc.firewall
file
</para>
</listitem>
<listitem>
<para>
Expanded the FAQ entry talking about how MASQ is different from NAT and Proxy
to include some informative URLs.
</para>
</listitem>
<listitem>
<para>
Updated the explanation of the MASQ MTU issue and described the two main
explanations for the issue.
</para>
</listitem>
<listitem>
<para>
Clarified that the RFC, PPPoE should only require an MTU of 1492 though some
ISPs require a setting of 1460. Because of this, I have updated the example
to show an MTU of 1492.
</para>
</listitem>
<listitem>
<para>
Broke out the Windows 9x sections into Win95 and Win98 as they use different
settings (DWORD vs. STRING). I also updated the sections to be clearer and the
Registry backup methods have been updated.
</para>
</listitem>
<listitem>
<para>
Fixed a typo where the NT 4.0 Registry entries were backwards
(Tcpip/Parameters vs. Parameters/Tcpip).
</para>
</listitem>
<listitem>
<para>
Fixed an issue where the WinNT entry should have been a DWORD and not a
STRING.
</para>
</listitem>
<listitem>
<para>
A serious thanks goes out to Geoff Mottram for his various PPPoE and various
Windows Registry entry fixes.
</para>
</listitem>
<listitem>
<para>
Added an explict URL for Oident in the IRC FAQ entry
</para>
</listitem>
<listitem>
<para>
Updated the FAQ section regarding some broken "netstat" versions
</para>
</listitem>
<listitem>
<para>
Added new FAQ sections for MASQ accounting ideas and traffic shaping
</para>
</listitem>
<listitem>
<para>
Expanded the IPROUTE2 FAQ entry on what Policy-routing is.
</para>
</listitem>
<listitem>
<para>
Moved the IPROUTE2 URLs to the 2.2.x Kernel requirements section and also added
a few more URLs as well.
</para>
</listitem>
<listitem>
<para>
Corrected the "intnet" varible in the stronger IPCHAINS ruleset to reflect the
192.168.0.0 network to be consistent with the rest of the example. Thanks to
Ross Johnson for this one.
</para>
</listitem>
<listitem>
<para>
Added a new FAQ section for users asking about forwarding problems between
multiple internal MASQed LANs.
</para>
</listitem>
<listitem>
<para>
Added a new FAQ section about users wanting to PORTFW all ports from multiple
external IP addresses to internal ones. I also touched on users who were trying
to PORTFW all ports on multiple IP ALIASed interfaces and also noted the
Bridge+Firewall HOWTO for DSL and Cablemodem users who have multiple IPs in a
non-routed environment.
</para>
</listitem>
<listitem>
<para>
Added Mandrake 7.1, Mandrake 7.2, and Slackware 7.1 to the supported list
</para>
</listitem>
<listitem>
<para>
Added Redhat 7.0 to the MASQ supported distros. Thanks to Eugene Goldstein for
this one.
</para>
</listitem>
<listitem>
<para>
Fixed a mathematical error in the "Maximum Throughput" calculation in the FAQ
section. Thanks to Joe White @ ip255@msn.com for this one.
</para>
</listitem>
<listitem>
<para>
Fixed the Windows9x MTU changes to be a STRING change and not a DWORD change
to the registry. Thanks to jmoore@sober.com for this one.
</para>
</listitem>
<listitem>
<para>
Updated the comments in the 2.0.x rc.firewall script to note that the ip_defrag
option is for both 2.0 and 2.2 kernels. Thanks to pumilia@est.it for this
clarification.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.85 to 1.90 - 07/03/00
<ItemizedList>
<listitem>
<para>
Updated the URL for TrinityOS to reflect its newest layout
</para>
</listitem>
<listitem>
<para>
Caught a typo in the IPCHAINS rulesets where I was setting "ip_ip_always_defrag"
instead of "ip_always_defrag"
</para>
</listitem>
<listitem>
<para>
The URL to Taro Fukunaga was invaild since it was using "mail:" instead of
"mailto:"
</para>
</listitem>
<listitem>
<para>
Added some clarification to the "Masqing multiple internal interfaces" where
some users didn't understand why eth0 was referenced multiple times.
</para>
</listitem>
<listitem>
<para>
Fixed another "space after the EXTIP variable" bug in the stronger IPCHAINS
section. I guess I missed one.
</para>
</listitem>
<listitem>
<para>
In Test #7 of Section 5, I referred users to go back to step #4. That should
have been step #6.
</para>
</listitem>
<listitem>
<para>
Updated the kernel versions that came with SuSe 5.2 and 6.0
</para>
</listitem>
<listitem>
<para>
Fixed a typo (or vs. of) in Section 7.2
</para>
</listitem>
<listitem>
<para>
Added Item #9 to the Testing MASQ section to refer users who are still haing
MASQ problems to read the MTU entry in the FAQ
</para>
</listitem>
<listitem>
<para>
Improved the itemization in Section 5
</para>
</listitem>
<listitem>
<para>
Updated the IPCHAINS syntax to show the MASQ/FORWARD table. Before, it was
valid to run "ipchains -F -L" but now only "ipchains -M -L" works.
</para>
</listitem>
<listitem>
<para>
Updated the LooseUDP documentation to reflect the new LooseUDP behavior in
2.2.16+ kernels. Before, it was always enabled, now, it defaults to OFF due
to a possible MASQed UDP port scanning vulnerability. I updated the BASIC and
SEMI-STRONG IPCHAINS rulesets to reflect this option.
</para>
</listitem>
<listitem>
<para>
Updated the recommended 2.2.x kernel to be 2.2.16+ since there is a TCP root
exploit vulnerability on all lesser versions.
</para>
</listitem>
<listitem>
<para>
Added Redhat 6.2 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Updated the link for Sonny Parlin's FWCONFIG to point to fBuilder.
</para>
</listitem>
<listitem>
<para>
Updated the various examples of IP addresses from 111.222.333.444 to be
111.222.121.212 and within a valid IP address range
</para>
</listitem>
<listitem>
<para>
Updated the URL for the BETA H.323 MASQ module
</para>
</listitem>
<listitem>
<para>
Finally updated the MTU FAQ section to help out PPPoE DSL and Cablemodem users.
Basically, <XRef LinkEnd="MTU-issues"> now reflects the fact that users can
also change the MTU settings of all of their INTERNAL machines to solve the
dreaded MASQ MTU issue.
</para>
</listitem>
<listitem>
<para>
Added a clarification to the PORTFW section that PORTFWed connections which
work for EXTERNAL clients but will not work for INTERNAL clients. If you also
need INTERNAL portfw, you will need to also implement the REDIR tool as well.
I also noted that this issue is fixed in the 2.4.x kernels with Netfilter.
</para>
</listitem>
<listitem>
<para>
I also added a technical explanation from Juanjo to the end of the PORTFW
section to why this senario doesn't work properly.
</para>
</listitem>
<listitem>
<para>
Updated all of the IPCHAINS URLs to point to Paul Rusty's new site at
http://www.netfilter.org/ipchains/
</para>
</listitem>
<listitem>
<para>
Updated Paul Rustys email address
</para>
</listitem>
<listitem>
<para>
Added a new FAQ section for users whose connections remain idle for a long
period of time and PORTFWed connections no longer work.
</para>
</listitem>
<listitem>
<para>
Updated all the URLs to the LDP that pointed to metalab.unc.edu to the new
site of linuxdoc.org
</para>
</listitem>
<listitem>
<para>
Updated the Netfilter URLs to point to renamed HOWTOs, etc.
</para>
</listitem>
<listitem>
<para>
I also updated the status of the 2.4.x support to note that I *will* add full
Netfilter support to this HOWTO and if the time comes, then split that support
off into a different HOWTO.
</para>
</listitem>
<listitem>
<para>
Updated the 2.4.x Requirements section to reflect how NetFilter has changed
compared to IPFWADM and IPCHAINS and gave a PROs/CONs list of new features and
changes to old behaviors.
</para>
</listitem>
<listitem>
<para>
Added a TCP/IP math example to the "My MASQ connection is slow" FAQ entry to
better explain what a user should expect performance wise.
</para>
</listitem>
<listitem>
<para>
Updated the HOWTO to reflect that newer versions of the "pump" DHCP client now
can run scripts upon bringup, lease renew, etc.
</para>
</listitem>
<listitem>
<para>
Updated the PORTFWing of FTP to reflect that several users say they can
successfully forward FTP traffic to internal machines without the need of a
special ip_masq_ftp module. I have made the HOWTO reflect that users should
try it without the modified module first and then move to the patch if required.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.82 to 1.85 - 05/29/00
<ItemizedList>
<listitem>
<para>
Ambrose Au's name has been taken off the title page as David Ranch has been
the primary maintainer for the HOWTO for over a year. Ambrose will still be
involved with the WWW site though.
</para>
</listitem>
<listitem>
<para>
Deleted a stray SPACE in section 6.4
</para>
</listitem>
<listitem>
<para>
Re-ordered the compatible MASQ'ed OS section and added instructions for
setting up a AS/400 system running on OS/400. Thanks to jaco@libero.it for
the notes.
</para>
</listitem>
<listitem>
<para>
Added an additional PORFW-FTP patch URL for FTP access if HTTP access fails.
</para>
</listitem>
<listitem>
<para>
Updated the kernel versions for Redhat 5.1 &#38; 6.1 in the FAQ
</para>
</listitem>
<listitem>
<para>
Added FloppyFW to the list of MASQ-enabled Linux distros
</para>
</listitem>
<listitem>
<para>
Fixed an issue in the Stronger IPFWADM rule set where there were spaces between
"ppp_ip" and the "=".
</para>
</listitem>
<listitem>
<para>
In the kernel compiling section for 2.2.x kernels, I removed the reference to
enable "CONFIG_IP_ALWAYS_DEFRAG". This option was removed from the compiling
section and enabled by default with MASQ enabled in 2.2.12.
</para>
</listitem>
<listitem>
<para>
Because of the above change in the kernel behavior, I added the enabling of
ip_always_defrag to all the rc.firewall examples.
</para>
</listitem>
<listitem>
<para>
Updated the status of support for H.323. There are now ALPHA versions of
modules to support H.323 on both 2.0.x and 2.2.x kernels.
</para>
</listitem>
<listitem>
<para>
Added Debian v2.2 to the supported MASQ distributions list
</para>
</listitem>
<listitem>
<para>
Fixed a long standing issue where the section that covered explict filtering
of IP addresses for IPCHAINS had old IPFWADM syntax. I've also cleaned this
section up a little and made it understandable.
</para>
</listitem>
<listitem>
<para>
Doh! Added Juan Ciarlante's URL to the important MASQ resources section.
Man.. you guys need to make me more honest than this!!
</para>
</listitem>
<listitem>
<para>
Updated the HOWTO to reflect kernels 2.0.38 and 2.2.15
</para>
</listitem>
<listitem>
<para>
Reversed the order shown to compile kernels to show 2.2.x kernels first as
2.0.x is getting pretty old.
</para>
</listitem>
<listitem>
<para>
Updated the 2.2.x kernel compiling section to reflect the changed options
for the latter 2.2.x kernels.
</para>
</listitem>
<listitem>
<para>
Added a possible solution for users that fail to get past MASQ test #5.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.81 to 1.82 - 01/22/00
<ItemizedList>
<listitem>
<para>
Added a missing subsection for /proc/sys/net/ipv4/ip_dynaddr in the stronger
IPCHAINS ruleset. Section 6.5
</para>
</listitem>
<listitem>
<para>
Changed the IP Masq support for Debian 2.1 to YES
</para>
</listitem>
<listitem>
<para>
Reorganized and updated the "Masq is slow" FAQ section to include fixing
Ethernet speed and duplex issues.
</para>
</listitem>
<listitem>
<para>
Added a link to Donald Becker's MII utilities for Ethernet NIC cards
</para>
</listitem>
<listitem>
<para>
Added a missing ")" for the 2.2.x section (previously fixed it only for the
2.0.x version) to the ICQ portfw script and changed the evaluation from -lt
to -le
</para>
</listitem>
<listitem>
<para>
Added Caldera eServer v2.3 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Added Mandrake 6.0, 6.1, 7.0 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Added Slackware v7.0 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Added Redhat 6.1 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Added TurboLinux 4.0 Lite to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Added SuSe 6.3 to the MASQ supported list
</para>
</listitem>
<listitem>
<para>
Updated the recommended stable 2.2.x kernel to be anything newer than 2.2.11
</para>
</listitem>
<listitem>
<para>
In section 3.3, the HOWTO forgot how to tell the user how to load the
/etc/rc.d/rc.firewall upon each reboot. This has now been covered for Redhat
(and Redhat-based distros) and Slackware.
</para>
</listitem>
<listitem>
<para>
Added clarification in the Windows WFWG v3.x and NT setup sections why users
should NOT configure the DHCP, WINS, and Forwarding options.
</para>
</listitem>
<listitem>
<para>
Added a FAQ section on how to fix FTP problems with MASQed machines.
</para>
</listitem>
<listitem>
<para>
Fixed a typo in the Stronger firewall rulesets. The "extip" variabl cannot
have the SPACE between the variable name and the "=" sign. Thanks to
johnh@mdscomp.com for the sharp eye.
</para>
</listitem>
<listitem>
<para>
Updated the compatibly section: Mandrake 7.0 is based on 2.2.14 and TurboLinux
v6.0 runs 2.2.12
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.80 to 1.81 - 01/09/00
<ItemizedList>
<listitem>
<para>
Updated the ICQ section to reflect that the new ICQ Masq module supports file
transfer and real-time chat. The 2.0.x module still has those limitations.
</para>
</listitem>
<listitem>
<para>
Updated Steven E. Grevemeyer's email address. He is the maintainer of the
IP Masq Applications page.
</para>
</listitem>
<listitem>
<para>
Fixed a few lines that were missing the work AREN'T for the "setsockopt" errors.
</para>
</listitem>
<listitem>
<para>
Updated a error the strong IPCHAINS ruleset where it was using the variable
name "ppp_ip" instead of "extip".
</para>
</listitem>
<listitem>
<para>
Fixed a "." vs a "?" typo in section 3.3.1 in the DHCP comment section.
</para>
</listitem>
<listitem>
<para>
Added a missing ")" to the ICQ portfw script and changed the evaluation from
-lt to -le
</para>
</listitem>
<listitem>
<para>
Updated the Quake Module syntax to NOT use the "ports=" verbage
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.79 to 1.80 - 12/26/99
<ItemizedList>
<listitem>
<para>
Fixed a space typo when setting the "ppp_ip" address.
</para>
</listitem>
<listitem>
<para>
Fixed a typo in the simple IPCHAINS ruleset. "deny" to "DENY"
</para>
</listitem>
<listitem>
<para>
Updated the URLs for Bjorn's "modutils" for Linux
</para>
</listitem>
<listitem>
<para>
Added verbage about NetFilter and IPTables and gave URLs until it is added
to this HOWTO or a different HOWTO.
</para>
</listitem>
<listitem>
<para>
Updated the simple /etc/rc.d/rc.firewall examples to notify users about the
old Quake module bug.
</para>
</listitem>
<listitem>
<para>
Updated the STRONG IPFWADM /etc/rc.d/rc.firewall to clarify users about dynamic
IP addresses (PPP &#38; DHCP), newer DHCPCD syntax, and the old Quake module
bug.
</para>
</listitem>
<listitem>
<para>
Updated the STRONG IPCHAINS /etc/rc.d/rc.firewall to ADD a missing section on
dynamic IP addresses (PPP &#38; DHCP) and the old Quake module bug.
</para>
</listitem>
<listitem>
<para>
Added a note in the "Applications that DO NOT work" section that there IS a
beta module for Microsoft NetMeeting (H.323 based) v2.x on 2.0.x kernels. There
is NO versions available for Netmeeting 3.x and/or 2.2.x kernels as of yet.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.78 to 1.79 - 10/21/99
<ItemizedList>
<listitem>
<para>
Updated the HOWTO name to reflect that it isn't a MINI anymore!
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.77 to 1.78 - 8/24/99
<ItemizedList>
<listitem>
<para>
Fixed a typo in "Section 6.6 - Multiple Internal Networks" where the -a policy
was ommited.
</para>
</listitem>
<listitem>
<para>
Deleted the 2.2.x kernel configure option "Drop source routed frames" since it is now enabled by default and the kernel compile option was removed.
</para>
</listitem>
<listitem>
<para>
Updated the 2.2.x and all other IPCHAINS sections to notify users of the IPCHAINS fragmentation bug.
</para>
</listitem>
<listitem>
<para>
Updated all of the URLs pointing at Lee Nevo's old IP Masq Applications page
to Seg's new page.
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.76 to 1.77 - 7/26/99
<ItemizedList>
<listitem>
<para>
Fixed a typo in the Port fowarding section that used "ipmasqadm ipportfw -C"
instead of "ipmasqadm portfw -f"
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.75 to 1.76 - 7/19/99
<ItemizedList>
<listitem>
<para>
Updated the "ipfwadm: setsockopt failed: Protocol not available" message in the
FAQ to be clearer instead of making the user hunt for the answer in the Forwarders
section.
</para>
</listitem>
<listitem>
<para>
Fixed incorrect syntax in section 6.7 for IPMASQADM and "portfw"
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 1.72 to 1.75 - 6/19/99
<ItemizedList>
<listitem>
<para>
Fixed the quake module port setup order for the weak IPFWADM &#38; IPCHAINS
ruleset and the strong IPFWADM ruleset as well.
</para>
</listitem>
<listitem>
<para>
Added a user report about port forwarding ICQ 4000 directly in and using ICQ's
default settings WITHOUT enabling the "Non-Sock" proxy setup.
</para>
</listitem>
<listitem>
<para>
Updated the URLs for the IPMASQADM tool
</para>
</listitem>
<listitem>
<para>
Added references to Taro Fukunaga, tarozax@earthlink.net for his MkLinux port
of the HOWTO
</para>
</listitem>
<listitem>
<para>
Updated the blurb about Sonny Parlin's FWCONFIG tool to note new IPCHAINS
support
</para>
</listitem>
<listitem>
<para>
Noted that Fred Vile's patch for portfw'ed FTP access is ONLY available for the
2.0.x kernels
</para>
</listitem>
<listitem>
<para>
Updated the 2.2.x kernel step with a few clarifications on the Experiemental tag
</para>
</listitem>
<listitem>
<para>
Added Glen Lamb's name to the credits for the LooseUDP patch
</para>
</listitem>
<listitem>
<para>
Added a clarification on installing the LooseUDP patch that it should use "cat"
for non-compressed patches.
</para>
</listitem>
<listitem>
<para>
Fixed a typo in the IPAUTO FAQ section
</para>
</listitem>
<listitem>
<para>
I had the DHCP client port numbers reversed for the IPFWADM and IPCHAINS
rulesets. The order I had was if your Linux server was a DHCP SERVER.
</para>
</listitem>
<listitem>
<para>
Added explict /sbin path to all weak and strong ruleset examples.
</para>
</listitem>
<listitem>
<para>
Made some clarifications in the strong IPFWADM section regarding Dynamic IP
addresses for PPP and DHCP users. I also noted that the strong rulesets should
be re-run when PPP comes up or when a DHCP lease is renewed.
</para>
</listitem>
<listitem>
<para>
Added references in the 2.2.x requirements, updated the ICQ FAQ section, and
added Andrew Deryabin to the credits section for his ICQ MASQ module.
</para>
</listitem>
<listitem>
<para>
Added some clarifcations to the FAQ section explaining why the 2.1.x and 2.2.x
kernels went to IPCHAINS.
</para>
</listitem>
<listitem>
<para>
Added a little FAQ section on Microsoft File/Print/Domain services (Samba)
through a MASQ server. I also added an URL to a Microsoft Knowledge based
document for more details.
</para>
</listitem>
<listitem>
<para>
Added clarifications to the FAQ section that NO Debian distribution supports IP
masq out of the box.
</para>
</listitem>
<listitem>
<para>
Updated the supported MASQ distributions in the FAQ section.
</para>
</listitem>
<listitem>
<para>
Added to the Aliased NIC section of the FAQ that you CANNOT masq out of an
aliased interface.
</para>
</listitem>
<listitem>
<para>
Wow.. never caught this before but the "ppp-ip" variable in the strong ruleset
section is an invalid variable name! It has been renamed to "ppp_ip"
</para>
</listitem>
<listitem>
<para>
In both the IPFWADM and IPCHAINS simple ruleset setup areas, I had a commented
out section on enabling DHCP traffic. Problem is, it was below the final
reject line! Doh! I moved both up a section.
</para>
</listitem>
<listitem>
<para>
In the simple IPCHAINS setup, the #d out line for DHCP users, I was using the
IPFWADM "-W" command instead of IPCHAINS's "-i" parameter.
</para>
</listitem>
<listitem>
<para>
Added a little blurb to the Forwarders section the resolution to the famous
"ipfwadm: setsockopt failed: Protocol not available" error. This also includes
a little /proc test to let users confirm if IPPORTFW is enabled in the kernel.
I also added this error to a FAQ section for simple searching.
</para>
</listitem>
<listitem>
<para>
Added a Strong IPCHAINS ruleset to the HOWTO
</para>
</listitem>
<listitem>
<para>
Added a FAQ section explaining the "kernel: ip_masq_new(proto=UDP): no free ports." error.
</para>
</listitem>
<listitem>
<para>
Added an example of scripting IPMASQADM PORTFW rules
</para>
</listitem>
<listitem>
<para>
Updated a few of the Linux Documentation Project (LDP) URLs
</para>
</listitem>
<listitem>
<para>
Added Quake III support in the module loading sections of all the rc.firewall
rulesets.
</para>
</listitem>
<listitem>
<para>
Fixed the IPMASQADM forwards for ICQ
</para>
</listitem>
<listitem>
<para>
1.72 - 4/14/99 - Dranch: Added a large list of Windows NAT/Proxy alternatives
with rough pricing and URLs to the FAQ.
</para>
</listitem>
<listitem>
<para>
1.71 - 4/13/99 - Dranch: Added IPCHAINS setups for multiple internal MASQed
networks. Changed the ICQ setup to use ICQ's default 60 second timeout and
changed IPFWADM/IPCHAINS timeout to 160 seconds. Updated the MASQ and MASQ-DEV
email list and archive subscription instructions.
</para>
</listitem>
<listitem>
<para>
1.70 - 3/30/99 - Dranch: Added two new FAQ sections that cover SMTP/POP-3
timeout problems and how to masquerade multiple internal networks out onto
different external IP addresses with IPROUTE2.
</para>
</listitem>
<listitem>
<para>
1.65 - 3/29/99 - Dranch: Typo fixes, clarifications of required 2.2.x kernel
options, added dynamic PPP IP address support to the strong firewall section,
additional quake II module ports, noted that the LooseUDP patch is built into
later 2.2.x kernels and its from Glenn Lamb and not Dan Kegel, added more game
info in the compatibility section.
</para>
</listitem>
<listitem>
<para>
1.62 - Dranch: Make the final first-draft changes to the doc and now announce
it in the MASQ email list.
</para>
</listitem>
<listitem>
<para>
1.61 - Dranch: Made editorial changes, cleaned things up and fixed some errors
in the Windows95 and NT setups.
</para>
</listitem>
<listitem>
<para>
1.58 - Dranch: Addition of the port forwarding sections; LooseUDP setup; Ident
servers for IRC users, how to read firewall logs, deleted the CuSeeme Mini-HOWTO
since it is rarely used.
</para>
</listitem>
<listitem>
<para>
1.55 - Dranch: Complete overhaul, feature and FAQ addition, and editing sweep
of the v1.50 HOWTO. Completed the 2.2.x kernel and IPCHAINS configurations.
Did a conversion from IPAUTOFW to IPPORTFW for the examples that applied.
Added many URLs to various other documentation and utility sites. There are so
many changes.. I hope everyone likes it. Final publishing of this new rev of
the HOWTO to the LDP project won't happen until the doc is looked over and
approved by the IP MASQ email list (then v2.00).
</para>
</listitem>
<listitem>
<para>
1.50 - Ambrose: A serious update to the HOWTO and the initial addition of the
2.2.0 and IPCHAINS configurations.
</para>
</listitem>
<listitem>
<para>
1.20 - Ambrose: One of the more recent HOWTO versions that solely dealt with
&#60; 2.0.x kernels and IPFWADM.
</para>
</listitem>
</ItemizedList>
</para>
</Sect1>
</Chapter>
</Book>
View Git Blame Copy Permalink