dranch@trinnet.net
This document describes how to enable the Linux IP Masquerade feature on a given Linux host. IP Masq is a form of Network Address Translation or NAT that allows internally connected computers that do not have one or more registered Internet IP addresses to have the ability to communicate to the Internet via your Linux box's single Internet IP address. It is possible to connect your internal machines to the Linux host with LAN technologies like Ethernet, TokenRing, FDDI, as well as other kinds of connections such as dialup PPP or SLIP links. This document uses Ethernet for the primary example since it is the most common scenario.
This document is intended for users using either of the stable Linux kernels: 2.0.38+ and 2.2.17+ on a IBM-compatible PC. Older kernels such as 1.2.x, 1.3.x, and 2.1.x are NOT covered in this document and, in some kernel versions, can be considered broken. Please upgrade to one of the stable Linux kernels before using IP Masquerading. The new 2.3 and 2.4 kernels with the new NetFilter code aren't covered yet but URLs are provided below. Once the feature set for Netfilter is final, the new code will be covered in this HOWTO.If you are configuring IP Masq for use on a Macintosh, please email Taro Fukunaga, tarozax@earthlink.net for a copy of his short MkLinux version of this HOWTO.
As a new user, I found it very confusing to setup IP masquerade on Linux kernel, (1.2.x kernel back then). Although there is a FAQ and a mailing list, there was no document that was dedicated to it. There were also some requests on the mailing list for such a HOWTO. So, I decided to write this HOWTO as a starting point for new users and possibly create a building block for other knowledgeable users to use add to in the future. If you have any ideas for this document, corrections, etc., feel free to tell us so that we can make it better.
This document was originally based on the original FAQ by Ken Eves and numerous helpful messages from the IP Masquerade mailing list. A special thanks to Mr. Matthew Driver whose mailing list message inspired me to set up IP Masquerade and eventually writing this. Recently, David Ranch re-wrote the HOWTO and added a substantial number of sections to the HOWTO to make this document as complete as possible.
Please feel free to send any feedback or comments to ambrose@writeme.com and dranch@trinnet.net if you have any corrections or if any information/URLs/etc. is missing. Your invaluable feedback will certainly influence the future of this HOWTO!
This HOWTO is meant to be a fairly comprehensive guide on getting your Linux IP Masquerading network working in the shortest time possible. David is not a technical writer by trade so you might find the information in this document not as general and/or objective as it could be. The latest news and information regarding this HOWTO and other IP MASQ details can be found at the IP Masquerade Resource web page that we actively maintain. If you have any technical questions on IP Masquerade, please join the IP Masquerade Mailing List instead of sending email to David. Most MASQ problems are common for ALL MASQ users and can be easily solved by someone on the list. In addition to this, the response time of the IP MASQ email list will be much faster than a reply from David.
The latest version of this document can be found at the following sites which also contains HTML and postscript versions
This document is copyright(c) 2000 David Ranch and it is a FREE document. You may redistribute it under the terms of the GNU General Public License.
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, there is the chance that mistakes, bugs, etc. might happen from time to time.
No person, group, or other body is responsible for any damage on your computer(s) and any other losses by using the information on this document. i.e.
THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT.
Ok, with all this behind us... On with the show..
IP Masquerade is a networking function in Linux similar to one-to-many NAT (Network Address Translation) found in many commercial firewalls and network routers. For example, if a Linux host is connected to the Internet via PPP, Ethernet, etc., the IP Masquerade feature allows other "internal" computers connected to this Linux box (via PPP, Ethernet, etc.) to also reach the Internet as well. Linux IP Masquerading allows for this functionality even though these internal machines don't have an officially assigned IP addresses.
MASQ allows a set of machines to invisibly access the Internet via the MASQ gateway. To other machines on the Internet, all this 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 VERY secure networking environment. With a well built firewall, breaking the security of a well configured masquerading system and internal LAN should be considerably difficult.
If you would like to know more on how MASQ differs from 1:1 NAT and Proxy solutions, please see the what-is-masq FAQ entry.
IP Masquerade has been out for several years now and is fairly mature as Linux enters the 2.2.x kernel 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.
Common network uses like Web browsing, TELNET, FTP, PING, TRACEROUTE, etc. work well over IP Masquerade. Other communications such as FTP, IRC, and Real Audio work well with the appropriate IP MASQ modules loaded. Other network-specific programs like streaming audio (MP3s, True Speech, etc) work too. Some fellow users on the mailing list have even had good results with video conferencing software.
It should also 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 the aliasing FAQ section for full details.
Anyway, please refer to Supported Client Software section for a more complete listing of software supported.
IP Masquerade works well as a server to other 'client machines' running various different OS and hardware platforms. There are successful cases with internal MASQed systems using :
The list goes on and on but the point is, if your OS platform talks TCP/IP, it should work with IP Masquerade!
From the original IP Masquerade FAQ by Ken Eves:
Here is a drawing of the most simple setup:
SLIP/PPP +------------+ +-------------+
to ISP provider | Linux | SLIP/PPP | Anybox |
<---------- modem1| #1 |modem2 ----------- modem3| |
111.222.121.212 | | 192.168.0.100 | |
+------------+ +-------------+
In the above drawing, a Linux box with IP_MASQUERADING is installed as
Linux #1 and is connected to the Internet via SLIP/or/PPP using modem1. It has
an assigned public IP address of 111.222.121.212. It also has modem2 connected
to allow callers to dial-in and start a SLIP/or/PPP connection.
The second system (which doesn't have to be running Linux) calls into the
Linux #1 box and starts a SLIP/or/PPP connection. It does NOT have a publicly
assigned IP address from the Internet so it uses the private address
192.168.0.100. (see below for more info)
With IP Masquerade and the routing configured properly, the machine
"Anybox" can interact with the Internet as if it was directly connected to the
Internet (with a few small exceptions).
Quoting Pauline Middelink:
Do not forget to mention that the "ANYBOX" machine should have the
Linux #1 box configured as its gateway (whether is be the default route or just
a subnet is no matter). If the "ANYBOX" machine can not do this, the Linux
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 the document.
The following is an excerpt from a previous post on comp.os.linux.networking which
has been edited to match the names used in the above example:
o I tell machine ANYBOX that my PPP or SLIPed Linux box is its gateway.
o When a packet comes into the Linux box from ANYBOX, it will assign it
a new TCP/IP source port number and slap its own IP address in the packet
header, saving the originals. The MASQ server will then send the modified
packet out over the SLIP/PPP interface to the Internet.
o When a packet returns from the Internet to the Linux box, Linux examines
if the port number is one of those ports that was assigned above. If so, the
MASQ server will get 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.
Another IP Masquerading Example:
A typical example is given in the diagram below:
+----------+
| | Ethernet
| A-box |::::::
| |.2 : 192.168.0.x
+----------+ :
: +----------+ PPP
+----------+ : .1 | Linux | link
| | :::::::| Masq-Gate|:::::::::::::::::::// Internet
| B-box |:::::: | | 111.222.121.212
| |.3 : +----------+
+----------+ :
:
+----------+ :
| | :
| C-box |::::::
| |.4
+----------+
| | |
| <-Internal Network--> | | <- External Network ---->
| | |
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 connection to the Internet comes through (terminal server, etc.) and
that there is some remote host (very far off to the right of the page)
out on the Internet that you are interested communicating with). The
Linux system Masq-Gate is the IP Masquerading gateway for ALL
the internal network of machines A-box, B-box and
C-box to get to the Internet. The internal network uses one
of the
several RFC-1918 assigned private network addresses where in this
case, the Class-C network 192.168.0.0. The Linux box having the TCP/IP
address 192.168.0.1 while the other systems having the addresses:
The three machines, A-box, B-box and C-box,
can be running any operating system as long as they can speak TCP/IP.
OSes such as Windows 95, Macintosh MacTCP or OpenTransport or even another Linux box can connect to other machines on the
Internet. When running, the masquerading system or MASQ-gate
converts all of these internal connections so that they appear to originate
from masq-gate itself. MASQ then arranges so that data coming
back in to a masqueraded connection is relayed back to the proper
originating system. Because of this, the systems on the internal
network see a direct route to the internet and are unaware that their
data is being masqueraded. This is called a "Transparent" connection.
NOTE: Please see the FAQ for more details on topics such as:
** Please refer to IP Masquerade Resource for the latest information. **
NOTE #2: Most newer MASQ-supported-Distributions such as Redhat 5.2 might not be Linux 2.2.x ready for your setup. Tools like DHCP, NetUtils, etc. will need to be upgraded. More details can be found in the HOWTO.
ICQ MASQ module
PORTFW FTP Solutions:
IPROUTE2 for True 1:1 NAT, Policy-based (source) routing, and Traffic Shaping:
Some source code 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/
Please see the IP Masquerade Resource page for more information available on these patches and possibly others as well.
** Please refer to IP Masquerade Resource for the latest information. **
Some of the new functionality includes the following pros and cons:
PROs:
CONs:
ip_masq_cuseeme.o ip_masq_icq.o ip_masq_quake.o ip_masq_user.o ip_masq_irc.o ip_masq_raudio.o ip_masq_vdolive.o
There is documentation on how to do this porting at http://netfilter.kernelnotes.org/unreliable-guides/netfilter-hacking-HOWTO-5.html, If you have the time, you talent would highly appreciated to get these ported over quickly.
As of this version of the HOWTO, Netfilter is NOT covered. Once the feature set of NetFilter is set, it will be added to -this- HOWTO or possibly a new HOWTO. Until then, please see the following links for the available NetFilter documentation. As it stands, the new NetFilter code will share 95% of the same setup and troubleshooting issues that IPCHAINS users have today. Because of this fact, this HOWTO is still very relevant for NetFilter firewall and NAT users.
http://netfilter.filewatcher.org/unreliable-guides/index.html and more specifically http://netfilter.filewatcher.org/unreliable-guides/NAT-HOWTO.html
Please see the IP Masquerade Resource page for more information available on these patches and possibly others as well.
** Please refer to IP Masquerade Resource for the latest information. **
PORTFWed FTP:
X-Windows display forwarders:
ICQ MASQ module
PPTP (GRE) and SWAN (IPSEC) VPNs tunneling forwarders:
Game specific patches:
Please note that some WWW browsers with automatically uncompress this .gz file. To download this file, hold down the SHIFT key as you click on the above URL.
Also check out Dan Kegel's NAT Page for more information. Additional information can be found in the Game-Clients section and the FAQ section.
Please see the IP Masquerade Resource page for more information available on these patches and possibly others as well.
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 to the Internet but it also can allow someone on the Internet to possibly get into your internal network.Once you have IP MASQ functioning, it is HIGHLY recommended for the user to implement a STRONG IPFWADM/IPCHAINS firewall ruleset. Please see the Strong-IPFWADM-Rulesets and Strong-IPCHAINS-Rulesets sections below for more details.
If your Linux distribution already has all the required feature support compiled such as:and all MASQ-related modules compiled (most modular kernels will have all you need), then you will NOT need to re-compile the kernel. If you aren't sure if you Linux distribution is MASQ ready, see the MASQ-supported-Distributions section. If you don't trust this list or if your distribution isn't listed, try the following tests:
- IPFWADM/IPCHAINS
- IP forwarding
- IP masquerading
- IP Firewalling
- etc.
If they do, your kernel is ready to go.
- Run the command "ls /proc/sys/net/ipv4" while logged into the Linux box.
- See if files such as "ip_forward", "ip_masq_debug", "ip_masq_udp_dloose"(optional), and "ip_always_defrag"(optional) exist.
If you can't find any of the above files or if your distribution does support IP Masquerading by default, ASSUME IT DOESN'T support MASQ by default. If so.. you'll need to compile a kernel but don't worry.. it isn't hard.
Regardless of native support or not, reading this section is still highly recommended as it contains other useful information.
Please see the 2.2.x-Requirements section for any required software, patches, etc.
NOTE #1: Linux 2.2.x kernels less than 2.2.16 have a TCP root exploit vunerability and versions less than 2.2.11 have a IPCHAINS fragmentation bug. Because of this, people running strong IPCHAINS rulesets are open to attack. Please upgrade your kernel to a fixed version.
NOTE #2: As the 2.2.x train as progressed, they keep changing the compile-time options. As of this version, this section reflects the settings for 2.2.15. If you are running a previous kernel version, the dialogs will look different. It is recommended that you update to the newest kernel for all the new features and stability they bring.
/usr/src/ with a command: tar xvzf linux-2.2.x.tar.gz -C /usr/src, where the "x" in 2.2.x is the current Linux 2.2 kernel. Once finished, make sure there is a directory or symbolic link to /usr/src/linux/
Please note the YES or NO ANSWERS to the following. Not all options will be available without the proper kernel patches described later in this HOWTO:
* 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
-- Non-MASQ options skipped --
* Enable loadable module support (CONFIG_MODULES) [Y/n/?]
- YES: allows you to load kernel IP MASQ modules
-- Non-MASQ options skipped --
* Networking support (CONFIG_NET) [Y/n/?]
- YES: Enables the network subsystem
-- Non-MASQ options skipped --
* Sysctl support (CONFIG_SYSCTL) [Y/n/?]
- YES: Enables the ability to enable disable options such as forwarding,
dynamic IPs, LooseUDP, etc.
-- Non-MASQ options skipped --
* 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
* Kernel/User netlink socket (CONFIG_NETLINK) [Y/n/?]
- YES: Though this is OPTIONAL, this feature will allow the logging of advanced firewall issues such as routing messages, etc
* Routing messages (CONFIG_RTNETLINK) [Y/n/?]
- NO: This option does not have anything to do with packet firewall logging
-- Non-MASQ options skipped --
* Network firewalls (CONFIG_FIREWALL) [Y/n/?]
- YES: Enables the kernel to be comfigured by the IPCHAINS firewall tool
* Socket Filtering (CONFIG_FILTER) [Y/n/?]
- 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/?]
- YES: This enables the UNIX TCP/IP sockets mechanisms
* TCP/IP networking (CONFIG_INET) [Y/n/?]
- YES: Enables the TCP/IP protocol
-- Non-MASQ options skipped --
* IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?]
- YES: This will allow you to configure advanced MASQ options farther down
* IP: policy routing (CONFIG_IP_MULTIPLE_TABLES) [N/y/?]
- NO: Not needed by MASQ though users who need advanced features such as
TCP/IP source address-based or TOS-enabled routing will need to
enable this option.
* IP: equal cost multipath (CONFIG_IP_ROUTE_MULTIPATH) [N/y/?]
- NO: Not needed for normal MASQ functionality
* IP: use TOS value as routing key (CONFIG_IP_ROUTE_TOS) [N/y/?]
- NO: Not needed for normal MASQ functionality
* IP: verbose route monitoring (CONFIG_IP_ROUTE_VERBOSE) [Y/n/?]
- YES: This is useful if you use the routing code to drop IP spoofed packets (highly recommended) and you want to log them.
* IP: large routing tables (CONFIG_IP_ROUTE_LARGE_TABLES) [N/y/?]
- NO: Not needed for normal MASQ functionality
* IP: kernel level autoconfiguration (CONFIG_IP_PNP) [N/y/?] ?
- NO: Not needed for normal MASQ functionality
* IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?]
- YES: Enable the firewalling feature
* IP: firewall packet netlink device (CONFIG_IP_FIREWALL_NETLINK) [Y/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/?]
- NO: Not needed for normal MASQ functionality
* IP: masquerading (CONFIG_IP_MASQUERADE) [Y/n/?]
- YES: Enable IP Masquerade to re-address specific internal to external TCP/IP packets
* IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) [Y/n/?]
- 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/?]
- YES: Though OPTIONAL, this enables the OPTION to later enable the TCP/IP Port forwarding system to allow external computers to directly connect to specified internal MASQed machines.
* IP: ipautofw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [N/y/m/?]
- NO: IPautofw is a legacy method of port forwarding. It is mainly old code and has been found to have some issues. NOT recommended.
* IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/m/n/?]
- YES: Enables IPPORTFW which allows external computers on the Internet to directly communicate to specified internal MASQed machines. This feature is typically used to access internal SMTP, TELNET, and WWW servers. FTP port forwarding will need an additional patch as described in the FAQ section of the MASQ HOWTO. Additional information on port forwarding is available in the Forwards section of this HOWTO.
* IP: ip fwmark masq-forwarding support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_MFW) [Y/m/n/?]
- OPTIONAL: This is a new method of doing PORTFW. With this option, IPCHAINS can mark packets that should have additional work on. Using a UserSpace tool, much like IPMASQADM or IPPORFW, IPCHAINS would then automaticaly re-address the packets. Currently, this code is less tested than PORTFW but it looks promising. For now, the recommended method is to use IPMASQADM and IPPORTFW. If you have thoughts on MFW, please email me.
* IP: optimize as router not host (CONFIG_IP_ROUTER) [Y/n/?]
- YES: This optimizes the kernel for the network subsystem though it isn't known if it makes a siginificant performance difference.
* IP: tunneling (CONFIG_NET_IPIP) [N/y/m/?]
- NO: This OPTIONAL section is for IPIP tunnels through IP Masq. If you
need tunneling/VPN functionality, it is recommended to use either GRE or
IPSEC tunnels.
* 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 --
* 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 --
* 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 --
* Network device support (CONFIG_NETDEVICES) [Y/n/?]
- YES: Enables the Linux Network device sublayer
-- Non-MASQ options skipped --
* Dummy net driver support (CONFIG_DUMMY) [M/n/y/?]
- YES: Though OPTIONAL, this option can help when debugging problems
== Don't forget to compile in support for your network card !! ==
-- Non-MASQ options skipped --
== Don't forget to compile in support for PPP/SLIP if you use a modem or
use a PPPoE DSL modem ==
-- Non-MASQ options skipped --
* /proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
- YES: Required to enable the Linux network forwarding system
NOTE: These are just the components you need for IP Masquerade. You will need to select whatever other options needed for your specific setup.
make modules; make modules_install
/etc/rc.d/rc.local file to load the IP Masquerade modules and enable IP MASQ automatically after each reboot:
.
.
.
#rc.firewall script - Start IPMASQ and the firewall
/etc/rc.d/rc.firewall
.
.
.
Please see the 2.0.x-Requirements section for any required software, patches, etc.
/usr/src/ with a command: tar xvzf linux-2.0.x.tar.gz -C /usr/src, where the "x" in 2.0.x is the current Linux 2.0 kernel. Once finished, make sure there is a directory or symbolic link to /usr/src/linux/
Please note the YES or NO ANSWERS to the following options. Not all options will be available without the proper kernel patches described later in this HOWTO:
* 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
* Enable loadable module support (CONFIG_MODULES) [Y/n/?]
- YES: allows you to load kernel IP MASQ modules
* Networking support (CONFIG_NET) [Y/n/?]
- YES: Enables the network subsystem
* Network firewalls (CONFIG_FIREWALL) [Y/n/?]
- YES: Enables the IPFWADM firewall tool
* TCP/IP networking (CONFIG_INET)
- YES: Enables the TCP/IP protocol
* IP: forwarding/gatewaying (CONFIG_IP_FORWARD)
- YES: Enables Linux network packet forwarding and routing - Controlled by IPFWADM
* IP: syn cookies (CONFIG_SYN_COOKIES) [Y/n/?]
- YES: HIGHLY recommended for basic network security
* IP: firewalling (CONFIG_IP_FIREWALL) [Y/n/?]
- YES: Enable the firewalling feature
* IP: firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) [Y/n/?]
- YES: (OPTIONAL but HIGHLY recommended): Allows for the reporting of firewall hits
* IP: masquerading (CONFIG_IP_MASQUERADE [Y/n/?]
- YES: Enable IP MASQ to re-address specific internal to external TCP/IP packets
* IP: ipautofw masquerade support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPAUTOFW) [Y/n/?]
- NO: IPautofw is a legacy method of TCP/IP port forwarding. Though it works, IPPORTFW
is a better way so IPAUTOFW is not recommended.
* IP: ipportfw masq support (EXPERIMENTAL) (CONFIG_IP_MASQUERADE_IPPORTFW) [Y/n/?]
- 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: 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: 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 - HIGHLY recommended
* IP: optimize as router not host (CONFIG_IP_ROUTER) [Y/n/?]
- YES: This optimizes the kernel for the network subsystem
* IP: Drop source routed frames (CONFIG_IP_NOSR) [Y/n/?]
- YES: HIGHLY recommended for basic network security
* Dummy net driver support (CONFIG_DUMMY) [M/n/y/?]
- YES: Though OPTIONAL, this option can help when debugging problems
* /proc filesystem support (CONFIG_PROC_FS) [Y/n/?]
- YES: Required to enable the Linux network forwarding system
NOTE: These are just the components you need for IP Masquerade functionality. You will need to also select whatever other options you need for your specific network and hardware setup.
make modules; make modules_install
/etc/rc.d/rc.local file to load the IP Masquerade script and thus enable IP MASQ automatically after each reboot:
.
.
.
#rc.firewall script - Start IPMASQ and the firewall
/etc/rc.d/rc.firewall
.
.
.
The 2.3.x and 2.4.x kernels are NOT covered in this HOWTO yet. Please see the 2.3.x/2.4.x-Requirements section for URLs, etc until it is covered by this or a NEW howto.
Since all INTERNAL MASQed machines should NOT have official Internet assigned addressees, there must be specific and accepted way to allocate address to those machines without conflicting with anyone else's Internet addresses.
From the original IP Masquerade FAQ:
RFC 1918 is the official document on which IP addresses are to be used on a non-connected or "private" network. There are 3 blocks of numbers set aside specifically for this purpose
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 to 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 contiguous class B network numbers, and
third block is a set of 255 contiguous class C network numbers.
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 this HOWTO reflects this. But, any of the above private networks are valid but just be SURE to use the correct subnet-mask.
So, if you're using a Class-C network, you should number your TCP/IP enabled machines as 192.168.0.1, 192.168.0.2, 192.168.0.3, ..., 192.168.0.x
192.168.0.1 is usually the internal gateway or Linux MASQ machine to get out to 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 work properly.
At this point, you should have your kernel and other required packages installed. All network IP addresses, gateway, and DNS addresses should be configured on your Linux MASQ server as well. If you don't know how to configure your Linux network cards, please consult the HOWTOs listed in either the 2.0.x-Requirements or 2.2.x-Requirements sections.
Now, the only thing left to do is to configure the IP firewalling tools to both FORWARD and MASQUERADE the appropriate packets to the appropriate machine:
** This can be accomplished in many different ways. The following suggestions and examples worked for me, but you may have different ideas or needs.
** This section ONLY provides you with the bare minimum firewall ruleset to get the IP Masquerade feature working. Once IP MASQ has been successfully tested (as described later in this HOWTO), please refer to the Strong-IPFWADM-Rulesets and Strong-IPCHAINS-Rulesets sections for more secure firewall rulesets. In addition, check out the IPFWADM (2.0.x) and/or IPCHAINS(2.2.x) man pages for more details.
Please note that IPFWADM is no longer the firewall tool for manipulating IP Masquerading rules for both the 2.1.x and 2.2.x kernels. These new kernels now use the IPCHAINS tool. For a more detailed reason for this change, please see the FAQ section.
Create the file /etc/rc.d/rc.firewall with the following initial SIMPLE ruleset:
#!/bin/sh
#
# rc.firewall - Initial SIMPLE IP Masquerade test for 2.1.x and 2.2.x kernels
# using IPCHAINS
#
# 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.
# 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 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 since
#
# Redhat Users: you may try changing the options in
# /etc/sysconfig/network from:
#
# FORWARD_IPV4=false
# to
# FORWARD_IPV4=true
#
echo "1" > /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" > /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 "1" > /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
# vunerabilities.
#
#echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose
# 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)
#
/sbin/ipchains -M -S 7200 10 160
# DHCP: For people who receive their external IP address from either DHCP or
# BOOTP such as ADSL or Cablemodem users, it is necessary to use the
# following before the deny command. The "bootp_client_net_if_name"
# should be replaced the name of the link that the DHCP/BOOTP server
# will put an address on to? This will be something like "eth0",
# "eth1", etc.
#
# This example is currently commented out.
#
#
#/sbin/ipchains -A input -j ACCEPT -i bootp_clients_net_if_name -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
#
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -i eth0 -s 192.168.0.0/24 -j MASQ
Once you are finished with editing the /etc/rc.d/rc.firewall ruleset, make it
executable by typing in chmod 700 /etc/rc.d/rc.firewall
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 (a pain) or add it to the boot scripts. We have covered two methods below:
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do the /etc/rc.d/rc.local way. If you want the stronger system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
/etc/rc.d/rc.firewall
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn' t executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do the /etc/rc.d/rc.local way. If you want the strong er system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
Notes on how users might want to change the above firewall ruleset:
You could have also enabled IP Masquerading on a PER MACHINE basis instead of the above method enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall ruleset.
#!/bin/sh
#
# Enable simple IP forwarding and Masquerading
#
# 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 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
#
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -i eth0 -s 192.168.0.2/32 -j MASQ
/sbin/ipchains -A forward -i eth0 -s 192.168.0.8/32 -j MASQ
Common mistakes:
What appears to be a common mistake with new IP Masq users is to make the first command:
/sbin/ipchains -P forward masquerade
Do NOT make your default policy be MASQUERADING. Otherwise someone who can manipulate their routing tables will be able to tunnel straight back through your gateway, using it to masquerade their OWN identity!
Again, you can add these lines to the /etc/rc.d/rc.firewall file, one of the
other rc files you prefer, or do it manually every time you need IP Masquerade.
Please see the Strong-IPFWADM-Rulesets and Strong-IPCHAINS-Rulesets sections for a detailed guide on IPCHAINS and a strong IPCHAINS ruleset example. For additional details on IPCHAINS usage, please refer to http://netfilter.filewatcher.org/ipchains/ for the primary IPCHAINS site or the Linux IP CHAINS HOWTO Backup site
Create the file /etc/rc.d/rc.firewall with the following initial SIMPLE ruleset:
# rc.firewall - Initial SIMPLE IP Masquerade setup for 2.0.x kernels using
# IPFWADM
#
# 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.
# 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 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" > /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 "1" > /proc/sys/net/ipv4/ip_always_defrag
# Dynamic IP users:
#
# If you get your Internet 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, PPPd, and similar programs much easier.
#
#echo "1" > /proc/sys/net/ipv4/ip_dynaddr
# 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)
#
/sbin/ipfwadm -M -s 7200 10 160
# DHCP: For people who receive their external IP address from either DHCP or
# BOOTP such as ADSL or Cablemodem users, it is necessary to use the
# following before the deny command. The "bootp_client_net_if_name"
# should be replaced the name of the link that the DHCP/BOOTP server
# will put an address on to. This will be something like "eth0",
# "eth1", etc.
#
# This example is currently commented out.
#
#
#/sbin/ipfwadm -I -a accept -S 0/0 67 -D 0/0 68 -W bootp_clients_net_if_name -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
#
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a m -W eth0 -S 192.168.0.0/24 -D 0.0.0.0/0
Once you are finished with editing the /etc/rc.d/rc.firewall ruleset, make it
executable by typing in "chmod 700 /etc/rc.d/rc.firewall"
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 (a pain) or add it to the boot scripts. We have covered two methods below:
/etc/rc.d/rc.firewall
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn't executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do the /etc/rc.d/rc.local way. If you want the stronger system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
/etc/rc.d/rc.firewall
to the end of the /etc/rc.d/rc.local file and thats it. The problem with this approach is that if you are running a STRONG firewall ruleset, the firewall isn' t executed until the last stages of booting. The preferred approach is to have the firewall loaded just after the networking subsystem is loaded. For now, the HOWTO only covers how to do the /etc/rc.d/rc.local way. If you want the strong er system, I recommend you check out Section 10 of TrinityOS found in the links section at the bottom of this HOWTO.
Notes on how users might want to change the above firewall ruleset:
You could have also enabled IP Masquerading on a PER MACHINE basis instead of the above method enabling an ENTIRE TCP/IP network. For example, say if I wanted only the 192.168.0.2 and 192.168.0.8 hosts to have access to the Internet and NOT any of the other internal machines. I would change the in the "Enable simple IP forwarding and Masquerading" section (shown above) of the /etc/rc.d/rc.firewall ruleset.
# Enable simple IP forwarding and Masquerading
#
# 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 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
#
# Please use the following in ADDITION to the simple ruleset above for
# specific MASQ networks.
#
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a m -W eth0 -S 192.168.0.2/32 -D 0.0.0.0/0
/sbin/ipfwadm -F -a m -W eth0 -S 192.168.0.8/32 -D 0.0.0.0/0
Common mistakes:
What appears to be a common mistake with new IP Masq users is to make the first command:
ipfwadm -F -p masquerade
Do NOT make your default policy be MASQUERADING. Otherwise someone who can manipulate their routing tables will be able to tunnel straight back through your gateway, using it to masquerade their OWN identity!
Again, you can add these lines to the /etc/rc.d/rc.firewall file, one of the
other rc files you prefer, or do it manually every time you need IP Masquerade.
Please see the Strong-IPCHAINS-Rulesets and Strong-IPFWADM-Rulesets sections for a detailed guide and stronger examples of IPCHAINS and IPFWADM ruleset examples.
Besides setting the appropriate IP address for each internal MASQed machine, 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 (usually 192.168.0.1) as the machine's gateway address.
For the Domain Name Service, you can add in any DNS servers that are available. The most apparent one should be the one that your Linux server is using. You can optionally add any "domain search" suffix as well.
After you have properly reconfigured the internal MASQed machines, remember to restart their appropriate network services or reboot them.
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.
As it stands, the following Platforms have been tested as internal MASQed machines. This is only an EXAMPLE of all of the compatible OSes out there:
/etc/resolv.conf). Usually these DNS servers are located at your ISP though you can be running either your own CACHING or Authoritative DNS server on your Linux MASQ server as well. Optionally, you can add any appropriate domain search suffixes as well.
Ping the linux box to test the network connection: 'Start/Run', type: ping 192.168.0.1ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
HOSTS 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 HOSTS.SAM in the C:\windows directory.
[1]Novell NE2000 Adapter. Then set the IP Address to 192.168.0.x (1 < x < 255), then set Subnet Mask to 255.255.255.0 and Default Gateway to 192.168.0.1
Ping the linux box to test the network connection: 'File/Run', type: ping 192.168.0.1ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
Ping the linux box to test the network connection: 'File/Run', type: ping 192.168.0.1 ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
For example with Redhat Linux systems, you can edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file, or simply do it through the Control Panel. These changes are different for other UNIXes such as SunOS, BSDi, Slackware Linux, Solaris, SuSe, Debian, etc...). Please refer to your UNIX documentation for more information.
/etc/resolv.conf and for the appropreiate UNIX versions, edit the /etc/nsswitch.conf file to enable DNS services.
/etc/networks file depending on your settings.
ping command: ping 192.168.0.1 to test the connection to your gateway machine.ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
nwpd 0x60 10 0x300
pkunzip tel2308b.zip
config.tel file
myip=192.168.0.x (1 < x < 255), and netmask=255.255.255.0
hardware=packet, interrupt=10, ioaddr=60
name=default
host=yourlinuxhostname
hostip=192.168.0.1
gateway=1
name=dns.domain.com ; hostip=123.123.123.123; nameserver=1
Note: substitute the appropriate information about the DNS that your Linux host uses
config.tel file
telnet 192.168.0.1 If you don't receive a LOGIN prompt, please verify your network configuration.
Hosts 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.
Check the '802.3' if your network requires 802.3 frame types.
Hosts 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 /etc/hosts file format, described on RFC952). Once you've created the file, open the TCP/IP control panel, click on the 'Select Hosts File...' button, and open the Hosts file.
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:
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 < x < 255) and finally create c:\bin\resolv.cfg: SEARCH DNS HOSTS SEQUENTIAL NAMESERVER xxx.xxx.xxx.xxx NAMESERVER yyy.yyy.yyy.yyy
ping command: ping 192.168.0.1 to test the connection to your gateway machine.ping the outside world yet.) If you don't see "replies" to your PINGs, please verify your network configuration.
'ping 192.168.0.1' in a 'OS/2 Command prompt Window'. When ping packets are received all is ok.
The description of how to configure TCP/IP on OS/400 version V4R1M0 running on a AS/400 is beyond the scope of this document.
1) To perform any communications configuration tasks on your AS/400, you must have the special authority of *IOSYSCFG (I/O System Configuration) defined in your user profile. You can check the characteristics of your user profile with the DSPUSRPRF command.
2) Type GO CFGTCP command th reach the Configure TCP/IP menu.
3) Select Option 2 - Work with TCP/IP Routes.
4) Enter a 1 on the Opt field to add a route. * In Route Destination type *DFTROUTE * In Subnet Mask type *NONE * In Type of Service type *NORMAL * In Nex Hop type the address of your gataway (the Linux box)
The same logic should apply to setting up other platforms. Consult the sections above. If you're interested in writing about any of systems that have not been covered yet, please send a detail setup instruction to ambrose@writeme.com and dranch@trinnet.net.
Finally, it's time to give IP Masquerading an official try after all this hard work. If you haven't already rebooted your Linux box, do so to make sure the machines boots ok, executes the /etc/rc.d/rc.firewall ruleset, etc. Next, make sure that both the internal LAN connection and connection of your Linux hosts to the Internet is okay.
Follow these -10- tests to make sure all aspects of your MASQ setup is running properly:
From an internal MASQed computer, try pinging its local IP address (i.e. ping 192.168.0.10 ). This will verify that TCP/IP is correctly working on the local machine. Almost ALL modern operating systems have built-in support for the "ping" command. If this ping doesn't work, make sure that TCP/IP is correctly configured on the MASQed PC as described earlier in Configuring-clients section of this HOWTO. The output should look something like the following (hit Control-C to abort the ping):
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 --- 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
On the MASQ server itself, ping then internal IP address of the MASQ server's network interface card (i.e. ping 192.168.0.1). The output should look something like the following (hit Control-C to abort the ping):
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 --- 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
Next ping the external IP address of the MASQ server's network interface card connected to the Internet. This address might be from a PPP, Ethernet, etc connection to your ISP. If you don't know what this IP address is, run the Linux command "/sbin/ifconfig" on the MASQ server itself to get the Internet address. The output should look something like the following (we are looking for the IP address of eth0):
eth0 Link encap:Ethernet HWaddr 00:08:C7:A4:CC:5B
inet addr:12.13.14.15 Bcast:64.220.150.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
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 --- 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
If either of these tests doesn't work, you need to go back and double check your network cabling, and verify that the two NICs in the MASQ server are seen in "dmesg". An example of this output would be the following towards the END of the "dmesg" command:
. . 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 < sda5 sda6 sda7 sda8 > sdb: . .
Also, don't forget to verify the NIC configurations under the Linux distro is correct, etc. per the recommendations in the beginning of this HOWTO.
On a internal MASQed computer, try pinging the IP address of the Masquerading Linux box's internal Ethernet card, (i.e. ping 192.168.0.1). This will prove that your internal network and routing is ok. The output should look something like the following (hit Control-C to abort the ping):
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 --- 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
If this fails, make sure Ethernet cards of the MASQ server and the MASQed computer have "link". This is usually a LED light on either the back of each Ethernet card and also on the Ethernet hub/switch (if you are using one). If this fails, make sure that the internal MASQ machine is correctly configured as shown in the Configuring-clients section. If the MASQ client is ok, double-check your network cabling, make sure you have a LINK light on both the internal MASQed computer's NIC -and- the internal NIC on the Linux box.
From an internal MASQed computer, ping the IP address of the MASQ server's EXTERNAL TCP/IP address obtained in Step THREE above. This address might be your PPP, Ethernet, etc. address connected to your ISP. This ping test will prove that masquerading is working (ICMP Masquerading specifically).
If it doesn't work, first make sure that the "Default Gateway" on the MASQed PC is pointing to the IP address on the MASQ -SERVERs- INTERNAL NIC. Also double check that the /etc/rc.d/rc.firewall script was run without any errors. Just as a test, try re-running the /etc/rc.d/rc.firewall script now to see if it runs ok. Also, though most kernels support it by default, make sure that you enabled "ICMP Masquerading" in the kernel comfiguration and "IP Forwarding" in your /etc/rc.d/rc.firewall script.
If you still can't get things to work, take a look at the output from the following commands run on the Linux MASQ server:
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
. . 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 . .
From an internal MASQed computer, now ping a static TCP/IP address out on the Internet (i.e. ping 152.19.254.81 (this is http://metalab.unc.edu - home of MetaLabs' Linux Archive). If this works, that means that ICMP Masquerading is working over the Internet. If it didn't work, again check your Internet connection. If this still doesn't work, make sure you are using the simple rc.firewall ruleset and that you have ICMP Masqurading compiled into the Linux kernel. Also, make sure that the ruleset that enable IP MASQ is pointing to the correct EXNTERNAL interface.
Now try TELNETing to a remote IP address (i.e. telnet 152.2.254.81 (metalab.unc.edu - Note that this might take a while to get a login prompt since this is a VERY busy server.) Did you get a login prompt after a while? If that worked, that 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 now. An example of this output might look like (hit Control-D to exit out of the TELNET):
masq-client# telnet 152.2.254.81
Trying 152.2.254.81...
Connected to 152.2.254.81.
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 allows no public telnet logins.
login: Connection closed by foreign host.
Now try TELNETing to a remote HOSTNAME (i.e. "telnet metalab.unc.edu" (152.2.254.81). If this works, this means that DNS is working fine as well. If this didn't work but step SIX did work, make sure that you have valid DNS servers configured on your MASQed computer as shown in the Configuring-clients section.
As a last test, try browsing some 'INTERNET' WWW sites on one of your MASQed machines, and see if you can reach them. For example, access the Linux Documentation Project site. If this works, you can be fairly certain that everything is working FINE! If some sites are having problems where others work just fine, see the next step for more ideas.
If you see The Linux Documentation Project homepage, then CONGRATULATIONS! It's working! If that WWW site comes up correctly, then all other standard network tolls 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! If FTP, IRC, RealAudio, Quake I/II/III, etc. aren't working or are performing poorly, make sure 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 give IP MASQ module).
If your system passes all of these tests above but things like WWW browsing, FTP, and other types of traffic aren't reliable, I recommend that you read the MTU-issues FAQ entry in Section 7. There might be other items in the FAQ section that will help you as they have helped many users in the past.
Some TCP/IP application protocols will not currently work with Linux IP Masquerading because they either assume things about port numbers or encode TCP/IP addresses and/or port numbers in their data stream. These latter protocols need specific proxies or IP MASQ modules built into the masquerading code to make them work.
By default, Linux IP Masquerading cannot handle incoming services at all but there are a few ways of allowing them.
If you do not require high levels of security then you can simply forward or redirect IP ports. There are various ways of doing this though the most stable method is to use IPPORTFW. For more information, please see the Forwarders section.
If you wish to have some level of authorization on incoming connections then you will need to either configure TCP-wrappers or Xinetd to then allow only specific IP addresses through. The TIS Firewall Toolkit is a good place to look for tools and information.
More details on incoming security can be found in the TrinityOS document and at IP Masquerade Resource.
** The Linux Masquerade Application list has a lot of good information regarding applications that work through Linux IP masquerading. This site was recently taken over by Steve Grevemeyer who implimented it with a full database backend. Its a great resource!
Generally, any application that uses standard TCP and UDP should work. If you have any suggestion, hints, etc., please see the IP Masquerade Resource for more details.
General Clients:
all supported platforms, file searching client (not all archie clients are supported)
all supported platforms, with the ip_masq_ftp.o kernel module for active FTP connections.
all supported platforms
all supported platforms, WWW surfing
all IRC clients on various supported platforms, DCC is supported via the ip_masq_irc.o module
all supported platforms, USENET news client
all platforms, with ICMP Masquerading kernel option
all supported platforms, email clients
all supported platforms, Secure TELNET/FTP clients
all supported platforms, email servers like Sendmail, Qmail, PostFix, etc.
all supported platforms, remote session
UNIX and Windows based platforms , some variations may not work
Windows(possibly all supported platforms), virtual reality surfing
all supported platforms
Multimedia and Communication Clients:
- MS Netmeeting, Intel Internet Phone Beta , and other H.323 applications - There are now two solutions to get this to work through IPMASQed connections:
There is a stable BETA module available on the MASQ WWW site or at http://www.coritel.it/projects/sofia/nat.html 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 it doesn't support Netmeeting v3.x.
Another commercial solution is the Equivalence's PhonePatch H.323 gateway.
Windows, Client-Server 3D chat program
all supported platforms, with the ip_masq_cuseeme module loaded, please see the CuSeeme section for more details.
all supported clients. Requires the Linux kernel to be compiled with IPPORTFW support and ICQ is configured to be behind a NON-SOCKS proxy. A full description of this configuration is in the ICQ section.
Windows, Peer-to-peer audio communications, people can reach you only if you initiate the call, but people cannot call you without a specific port forwarding setup. See the Forwarders section for more details.
Windows, network streaming audio
Windows, Peer-to-peer Text audio whiteboard communications, people can reach you only if you initiate the call, but people cannot call you without a specific port forwarding setup. See the Forwarders se ction for more details.
Windows, network streaming audio, higher quality available with the ip_masq_raudio UDP module
Windows, network streaming audio
Windows, with the ip_masq_vdolive patch
Windows, Client-Server 3D chat program
Games - See the LooseUDP section for more details on the LooseUDP patch
Works but requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details. Please note that FSGS and Bnetd servers still require IPPORTFW since they haven't been re-written to be NAT-friendly.
Works with LooseUDP patch and new NAT-friendly .DLLs from Activision
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details.
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 the Forwarders section for more details.
Works with LooseUDP patch or requires TCP ports 116 and 118 and UDP port 6112 IPPORTFWed to the game machine. See the Forwarders section for more details.
Works right out of the box but requires the ip_masq_quake module if there are more than one Quake I/II/III player behind a MASQ box. Also, this module only supports Quake I and QuakeWorld by default. If you need to support Quake II or non-default server ports, please see the module install section of the rc.firewall-2.0.x and rc.firewall-2.2.x rulesets.
Works with the LooseUDP patch and IPPORTFWing TCP and UDP ports 6112 to the internal MASQed game machine. See the Forwarders section for more details.
Works with LooseUDP patch
Other Clients:
Linux, network administration-account package
DOS, a suite containing telnet, ftp, ping, etc.
MS-Windows, Remotely controls a PC over TCP/IP, only work if it is a client but not a host without a specific port forwarding setup. See the Forwarders section for more details.
uses NTP - network time protocol
Cannot connect to server
Cannot connect to opposite side
Cannot work at present (it makes invalid assumptions about addresses).
This section provides a more in-depth guide on using the 2.0.x firewall tool, IPFWADM. See below for IPCHAINS rulesets
This example is for a firewall/masquerade system behind a PPP link with a static PPP address (dynamic PPP instructions are included but disabled). The trusted interface is 192.168.0.1 and the PPP interface IP address has been changed to protect the guilty :). I have listed each incoming and outgoing interface individually to catch IP spoofing as well as stuffed routing and/or masquerading. Anything not explicitly allowed is FORBIDDEN (well.. rejected actually). If your IP MASQ box breaks after implementing this rc.firewall script, be sure that you edited it for your configuration and check your /var/log/messages or /var/adm/messages SYSLOG file for any firewall errors.
For more comprehensive examples of a strong IP Masqueraded IPFWADM rulesets for PPP, Cablemodem users, etc., please see TrinityOS - Section 10 and GreatCircle's Firewall WWW page
NOTE: If you get a dynamically assigned TCP/IP address from your ISP (PPP, ADSL, Cablemodems, etc.), you CANNOT load this strong ruleset upon boot. You will either need to reload this firewall ruleset EVERY TIME you get a new IP address or make your /etc/rc.d/rc.firewall ruleset more intelligent. To do this for PPP users, carefully read and un-comment out the properly lines in the "Dynamic PPP IP fetch" section below. You can also find more details in the TrinityOS - Section 10 doc for more details on Strong rulesets and Dynamic IP addresses.
Please also be aware that there are several GUI Firewall creation tools available as well. Please see the FAQ section for full details.
Lastly, if you are using a STATIC PPP IP address, change the "ppp_ip="your.static.PPP.address"" line to reflect your address.
----------------------------------------------------------------
#!/bin/sh # # /etc/rc.d/rc.firewall: An example of a semi-STRONG IPFWADM firewall ruleset # PATH=/sbin:/bin:/usr/sbin:/usr/bin # testing, wait a bit then clear all firewall rules. # uncomment following lines if you want the firewall to automatically # disable after 10 minutes. # (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 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 since # # Redhat Users: you may try changing the options in /etc/sysconfig/network from: # # FORWARD_IPV4=false # to # FORWARD_IPV4=true # echo "1" > /proc/sys/net/ipv4/ip_forward #CRITICAL: Enable automatic IP defragmenting since it is d