If you can think of any useful FAQ suggestions, please send it to ambrose@writeme.com and dranch@trinnet.net. Please clearly state the question and an appropriate answer (if you have it). Thank you!
If your Linux distribution doesn't support IP MASQ out of the box, don't worry. All you have to do is re-compile a kernel as shown above in this HOWTO.
NOTE: If you can help us fill out this table, please email ambrose@writeme.com or dranch@trinnet.net.
A 486/66 box with 16MB of RAM was more than sufficient to fill a 1.54Mb/s T1 100%! MASQ has also be known run quite well on 386SX-16s with 8MB or RAM. Yet, it should be noted that Linux IP Masquerade starts thrashing with more than 500 MASQ entries.
The only application that I known that 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 time. Until these sessions timeout, the MASQ tables become "FULL". See the No-Free-Ports section of the FAQ for more details.
While we are at it:
There is a hard limit of 4096 concurrent connections each for TCP & UDP. This limit can be changed by fiddling the values in /usr/src/linux/net/ipv4/ip_masq.h - a upwards limit of 32000 should by OK. If you want to change the limit - you need to change the PORT_MASQ_BEGIN & PORT_MASQ_END values to get an appropriately sized range above 32K and below 64K.
There are two ways to join the two Linux IP Masquerading mailing lists. The first way is to send an email to masq-request@indyramp.com. To join the Linux IP Masquerading Developers mailing list, send an email to masq-dev-request@indyramp.com. Please see the bullet below for more details.
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 needed to to later unsubscribe from the list or change your options.
The second method is to use a WWW browser and subscribe via a form at http://www.indyramp.com/masq-list/ for the main MASQ list or http://www.indyramp.com/masq-dev-list/ for the MASQ-DEV list.
Once subscribed, you will get emails from your subscribed list. It should be also noted that both subscribed and NON-subscribed users can access the two list's archives. To do this, please see the above two WWW URLs for more details.
Lastly, please note that you can only post to the MASQ list from an account/address you originally subscribed from.
If you have any problem regarding the mailing lists or the mailing list archive, please contact Robert Novak.
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 do IP address translating 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 people use 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 a name for a box that would have a pool of
valid IP addresses on the Internet interface that it can use. When on the
Internal network wanted to goto 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.
Yes! They vary in 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 Ambrose or David.
Yes, it works with either dynamic IP addressed assigned by your ISP via either PPP or a DHCP/BOOTp server. As long as you have an valid Internet IP address, it should work. Of course, static IP works too. Yet, if you plan on implementing a strong IPFWADM/IPCHAINS ruleset and/or plan on using a Port forwarder, your ruleset will have to be re-executed everytime your IP address changes. Please see the top of TrinityOS - Section 10 for additional help with strong firewall rulesets and Dynamic IP addresses.
Yes, 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.
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.
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 the Clients section of this HOWTO.
Applications involving more complicated protocols or special connection methods such as video conferencing software need special helper tools.
For more detail, please see the Linux IP masquerading Applications page.
No matter what 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 try our best to write the HOWTO as general as possible.
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:
Linux 2.0.x with IPFWADM:
# 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
Linux 2.2.x with IPCHAINS:
# 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
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:
# 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" > /proc/sys/net/ipv4/ip_dynaddr
There is two possible reasons for this. The first one is VERY common and the second is very UNCOMMON.
No worries though. A perfectly good workaround is to change your Internet link's MTU to 1500. Now some users will balk at this because it can hurt some latency specific programs like TELNET and games but the impact is only slight. On the flip site, most HTTP and FTP traffic will SPEED UP!
To fix this, first see what your MTU for your Internet link is now. To do this, run "/bin/ifconfig". Now look at the lines that corresponds to your Internet connection and look for the MTU. This NEEDs to be set to 1500. Usually, Ethernet links will default to this but PPP will default to 576.
There might be a few reasons for this:
There is probably two common things that you are going to see:
From the TrinityOS - Section 10 doc:
In the below rulesets, any lines that either DENY or REJECT any
traffic also have a "-o" to LOG this firewall hit to the SYSLOG
messages file found either in:
Redhat: /var/log
Slackware: /var/adm
If you look at one of these firewall logs, do would see something like:
---------------------------------------------------------------------
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=254
IPCHAINS:
Packet log: input DENY eth0 PROTO=17 12.75.147.174:1633 100.200.0.212:23
L=44 S=0x00 I=54054 F=0x0040 T=254
---------------------------------------------------------------------
There is a LOT of information in this just one line. Lets break out this example
so refer back to the original firewall hit as you read this. Please note that this
example is for IPFWADM though it is DIRECTLY readable for IPCHAINS users.
--------------
- This firewall "hit" occurred on "Feb 23 07:37:01"
- This hit was on the "RoadRunner" computer.
- This hit occurred on the "IP" or TCP/IP protocol
- This hit came IN to ("fw-in") the firewall
* Other logs can say "fw-out" for OUT or "fw-fwd" for FORWARD
- This hit was then "rejECTED".
* Other logs can say "deny" or "accept"
- This firewall hit was on the "eth0" interface (Internet link)
- This hit was a "TCP" packet
- This hit came from IP address "12.75.147.174" on return port "1633".
- This hit was addressed to "100.200.0.212" on port "23" or TELNET.
* If you don't know that port 23 is for TELNET, look at your
/etc/services file to see what other ports are used for.
- This packet was "44" bytes long
- This packet did NOT have any "Type of Service" (TOS) set
--Don't worry if you don't understand this.. not required to know
* divide this by 4 to get the Type of Service for ipchains users
- This packet had the "IP ID" number of "18"
--Don't worry if you don't understand this.. not required to know
- This packet had a 16bit fragment offset including any TCP/IP packet
flags of "0x0000"
--Don't worry if you don't understand this.. not required to know
* A value that started with "0x2..." or "0x3..." means the "More
Fragments" bit was set so more fragmented packet 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 is set.
* Any other values is the Fragment offset (divided by 8) to be later
used to recombine into the original LARGE packet
- This packet had a TimeToLive (TTL) of 20.
* Every hop over the Internet will subtract (1) from this number. Usually,
packets will start with a number of (255) and if that number ever reaches
(0), it means that realistically the packet was lost and will be deleted.
Yes! With IPPORTFW, you can allow ALL or only a select few Internet hosts to contact ANY of your internal MASQed computers. This topic is completely covered in the Forwarders section of this HOWTO.
One of your internal MASQed machine is 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 full, it will give you this error.
The only application that I known that 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 10,000s of quick connections in a VERY short time. Until these sessions timeout via the IP MASQ timeouts, the MASQ tables become "FULL".
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 do a lot of server refreshes. Regardless, once you stop running this MASQ'ed program, this MASQ error will go away as these connections timeout in the MASQ tables.
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.
Please see the end of the Forwarders section for full details.
To properly support Microsoft's SMB protocol, a IP Masq module would need to be written but there are three viable work-arounds. For more detail, please see this Microsoft KnowledgeBase article.
The first work-around is to configure IPPORTFW from the Forwarders section and portfw TCP ports 137, 138, and 139 to the internal Windows machine's IP address. Though this solution works, it will only works for ONE internal machine.
The second solution is to install and configure Samba 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.
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 PPTP patch for Linux and also a full IPSEC implimentation available for both 2.0.x and 2.2.x kernels. This solution will probably be the most reliable and secure method of all three solutions.
All of these solutions are NOT covered by this HOWTO. I recommend that you look at the TrinityOS documentation for IPSEC help and JJohn Hardin's PPTP page for more information.
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.
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.
Installing this software is beyond the scope of this HOWTO but each tool has its own documentation. Here are some of the URLs:
Please note that some Internet IRCs 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. :)
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 --> 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 --> Setup --> Local Info and clear the fields for Local Host and IP Address. 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.
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.
Finally, close down any IRC clients on any MASQed machines and re-load the IRC MASQ module:
/sbin/rmmod ip_masq_irc /etc/rc.d/rc.firewall
Yes and no. 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 cost less than $10, I highly recommend to just get a NIC card for each MASQed network segment.
Users should also understand that IP Masquerading will only work out 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:
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. /dev/eth0:1, etc.). After that, you can treat it as a normal Ethernet interface with some restrictions like the one above.
There is a problem with the "netstat" program. 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:
masq_info.c: Internal Error `ip_masquerade unknown type'.
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.
This IS possible. Though it is somewhat out of the scope of this document, check out John Hardin's PPTP Masq page for all the details.
First, check Steve Grevemeyer's MASQ Applications page. If your solution isn't listed there, try patching your Linux kernel with Glenn Lamb's LooseUDP patch which is covered in the LooseUDP section above. Also check out Dan Kegel's NAT Page for more information.
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 IP Masq email list and email your results for help.
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 all covered in more detail in the Forwarders section.
Though this isn't a Masquerading issue per se but many people do this so it should be mentioned.
SMTP: The issue is that you are probably using your Linux box as a SMTP relay server and get the following error:
"error from mail server: we do not relay"
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.
Say you have the following problem:
LAN ----------> official IP 192.168.1.x --> 123.123.123.11 192.168.2.x -->123.123.123.12
You have to first understand that both IPFWADM and IPCHAINS run *AFTER* the routing system has decided where to send a packet. This ought to be stamped in big red letters on all IPFWADM/IPCHAINS/IPMASQ documentation. You will need to get your routing right first and then add IPFWADM/IPCHAINS and/or Masq.
In the case shown above, you need to persuade the routing system to direct packets from 192.168.1.x via 123.123.1233.11 and packets from 192.168.2.x via 123.123.123.12. That is the hard part and adding Masq on top of correct routing is easy.
To do this fancy routing, you will use IPROUTE2.
Primary FTP site is:
Mirrors are:
ftp://linux.wauug.org/pub/net ftp://ftp.nc.ras.ru/pub/mirrors/ftp.inr.ac.ru/ip-routing/ ftp://ftp.gts.cz/MIRRORS/ftp.inr.ac.ru/ ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/ (STM1 to USA) ftp://sunsite.icm.edu.pl/pub/Linux/iproute/ ftp://ftp.sunet.se/pub/Linux/ip-routing/ ftp://ftp.nvg.ntnu.no/pub/linux/ip-routing/ ftp://ftp.crc.ca/pub/systems/linux/ip-routing/ ftp://ftp.paname.org (France) ftp://donlug.ua/pub/mirrors/ip-route/ ftp://omni.rk.tusur.ru/mirrors/ftp.inr.ac.ru/ip-routing/
RPMs are available at ftp://omni.rk.tusur.ru/Tango/ and at ftp://ftp4.dgtu.donetsk.ua/pub/RedHat/Contrib-Donbass/KAD/
NOTE: The following instructions are given below ONLY because currently there is very little documentation to the IPROUTE2 tool available. Check out http://www.compendium.com.ar/policy-routing.txt for the beginnings of a IPROUTE2 howto.
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 contact the author of IPROUTE2.. not David Ranch, Ambrose Au, or anyone on the Masq email list as it has NOTHING to do with IP Masquerading.
The first few commands only need to be done once at boot, say in /etc/rc.d/rc.local file.
# 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 62123.123.123.11
# Table 102 forces all assigned packets out via 123.123.123.12
/sbin/iproute add table 102 via 62123.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.
Once routing is correct, now you can add any IPFWADM or IPCHAINS rules.
The following examples are for IPCHAINS:
/sbin/ipchains -A forward -i ppp+ -j MASQ
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.
IPCHAINS supports the following features that IPFWADM doesn't:
There are several things you should check assuming your Linux IP Masq box already have proper connection to the Internet and your LAN:
/usr/src/linux/Documentation/Changes and make sure you have the minimal requirement for the network tools installed.
There are several things you should check assuming your Linux IP Masq box already have proper connection to the Internet and your LAN:
/usr/src/linux/Documentation/Changes and make sure you have the minimal requirement for the network tools installed.
EQL has nothing to do with IP Masq though they are commonly teamed up on Linux boxes. Because of this, I recommend to check out the NEW version of Robert Novak's EQL HOWTO for all your EQL needs.
Giving up a free, reliable, high performance solution that works on minimal hardware and pay a fortune for something that needs more hardware, lower performance and less reliable? (IMHO. And yes, I have real life experience with these ;-)
Okay, it's your call. If you want a Windows NAT and/or proxy solution, here is a decent listing. I have no preference of these tools since I haven't used them before.
Lastly, do a web search on "MS Proxy Server", "Wingate", "WinProxy", or goto www.winfiles.com. And definitely DON'T tell anyone that we sent you.
Join the Linux IP Masquerading DEVELOPERS list and ask the developers there what you can help with. For more details on joining the lists, check out the Masq-List FAQ section.
Please DON'T ask NON-IP-Masquerade development related questions there!!!!
You can find more information on IP Masquerade at the Linux IP Masquerade Resource that both David Ranch and Ambrose Au maintain.
You can also find more information at Dranch's Linux page where the TrinityOS and other Linux documents are kept.
You may also find more information at The Semi-Original Linux IP Masquerading Web Site maintained by Indyramp Consulting, who also provides the IP Masq mailing lists.
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 the Masq-List FAQ item for more details.
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 Linux IP Masquerade Resource.
If a copy of a current IP MASQ HOWTO isn't in your proposed language, please download the newest copy of the IP-MASQ HOWTO SGML code from the Linux IP Masquerade Resource. From there, begin your work while maintaining good SGML coding. For more help on SGML, check out www.sgmltools.org
Yes, this HOWTO is still being maintained. In the past, we've been guilty of being too busy working on two jobs and don't have much time to work on this, my apology. As of v1.50, David Ranch has begun to revamp the document and get it current again.
If you think of a topic that could be included in the HOWTO, please send email to ambrose@writeme.com and dranch@trinnet.net. 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!
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.