If you can think of any useful FAQ suggestions, please send it to 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 of 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.
How did you put the rc.firewall onto your machine? Did you cut&paste it into a TELNET window, FTP it from a Windows/DOS machine, etc? Try this.. log into your Linux box and run "vim -b /etc/rc.d/rc.firewall" and see if all your lines end in a ^M. If they do, delete all the ^M and try again.
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.
For an excellent and very comprehensive description of the various forms of NAT, please see:
Here is another good site to learn about NAT though many of the URLs are old but still valid:
This is a great URL for learning about other NAT solutions for Linux as well as other platforms:
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 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.
Some users point their finger to the fact that IPMASQ might have problems with packets that have the DF or "Don't Fragment" bit set. Basically, when a MASQ box connects to the Internet with an MTU of anything less than 1500, some packets will have the DF field set. Though changing the MTU 1500 on the Linux box will seemingly fix the problem, the possible bug is still there. What is believed to be happening is that the MASQ code is not properly re-writing the returning ICMP packets with the ICMP 3 Sub 4 code back to the originating MASQed computer. Because of this, the packets get dropped.
Other users point their finger at the adminstrators of the problem remote sites (typically SSL connected sites, etc) and say that because they are filtering ALL FORMS of ICMP (including Type4 - Fragmentation Needed) messages in a fray of security paranoia, they are breaking the fundamental aspects of the TCP/IP protocol.
Both arguments have valid points and people from each camp continue to debate this to this day. If you are a network programmer and you think you can either fix or surmise this.. PLEASE TRY! For more details, check out this following MTU Thread from the Linux-Kernel list.
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!
[ -- If you have a PPPoE connection for your DSL/Cablemodem or choose not to change the MTU to 1500, see below for a different solution. -- ]
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 serial PPP links will default to 576.
For those users who use PPPoE (that has a maximum MTU of 1490) or for those users who choose NOT to use an MTU of 1500, not is all lost. If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external Internet link's MTU, everything should work fine. It should be noted that some PPPoE ISPs might require a MTU of 1460 for proper connectivity.
How do you do this? Follow these simple steps for your respective operating system.
The follow examples show an example of an MTU of 1490 for typical PPPoE connections for some DSL and Cablemodem users. It is recommended to use the HIGHEST values possible for all connections that are 128Kb/s and faster.
The only real reason to use smaller MTUs is to lower latency but at the cost of throughput. Please see:
http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu
for more details on this topic.
*** If you have had SUCCESS, FAILURE, or have procedures for OTHER operating *** systems, please email David Ranch. Thanks!
1. The setting of MTU can vary from Linux distribution to distribution.
For Redhat: You need to edit the various "ifconfig" statements in
the /sbin/ifup script
For Slackware: You need to edit the various "ifconfig" statements in
the /etc/rc.d/rc1.inet
2. Here is one good, any-distribution-will-work example, edit the
/etc/rc.d/rc.local file and put the following at the END of the file:
echo "Changing the MTU of ETH0"
/sbin/ifconfig eth0 mtu 1490
Replace "eth0" with the interface name that is the machine's upstream
connection that is connected to the Internet.
3. For advanced options like "TCP Receive Windows" and such, detailed examples
on how to edit the respective networking scripts for your specific Linux
distro, etc., please see Chapter 16 of
http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start-->Run-->RegEdit
3. You should make a backup copy fo your Registry before doing anything. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry-->Export Registry
File-->Save a copy of your registry" would only do Registry MERGES and NOT
do a replacement.
4. Search though each of the Registry trees that end in "n" (e.g. 0007)
that have a Registry entry called "IPAddress" that has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=DWORD
name="MaxMTU" (Do NOT include the quotes)
value=1490 (Decimal) (Do NOT include the text "(Decimal)")
type=DWORD
name="MaxMSS" (Do NOT include the quotes)
value=1450 (Decimal) (Do NOT include the text "(Decimal>")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=DWORD
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal>")
type=DWORD
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal>")
6. Reboot to make the changes take effect.
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start-->Run-->RegEdit
3. You should make a backup copy fo your Registry before doing anything. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry-->Export Registry
File-->Save a copy of your registry" would only do Registry MERGES and NOT
do a replacement.
4. Search though each of the Registry trees that end in "n" (e.g. 0007)
that have a Registry entry called "IPAddress" that has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=STRING
name="MaxMTU" (Do NOT include the quotes)
value=1490 (Decimal) (Do NOT include the text "(Decimal)")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=STRING
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal>")
type=STRING
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal>")
6. Reboot to make the changes take effect.
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start-->Run-->RegEdit
3. Registry-->Export Registry File-->Save a copy of your registry
to a reliable place
4. Create the following keys in the the Registry trees two
possible Registry trees. Multiple entries are for various
network devices like DialUp Networking (ppp), Ethernet NICs,
PPTP VPNs, etc.
http://support.microsoft.com/support/kb/articles/Q102/9/73.asp?LN=EN-US&SD=gn&FR=0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
and
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Adapter-name>\Parameters\Tcpip]
Replace "<Adapter-Name>" with the respective name of your uplink LAN NIC
interface
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1490 (Decimal) (Do NOT include the text "(Decimal>")
(Do NOT include the quotes)
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 4.x, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to make the changes take effect.
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start-->Run-->RegEdit
3. Registry-->Export Registry File-->Save a copy of your registry
to a reliable place
4. Navigate down to the key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\<ID for Adapter>
Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway,
subnet mask, etc. Find the key one that is for your network card.
5. Create the following Entry:
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1490 (Decimal) (Do NOT include the text "(Decimal)")
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp?LN=EN-US&SD=gn&FR=0
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 2000, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to make the changes take effect.
As stated above, if you know how to make similar changes like these to other OSes like OS/2, MacOS, etc. please email David Ranch so it can be included in the HOWTO.
Check to see that the "ip_masq_ftp" module is loaded. To do this, log into the MASQ server and run the command "/sbin/lsmod". If you don't see the "ip_masq_ftp" module loaded, make sure that you followed the BASIC /etc/rc.d/rc.firewall recommendations found in firewall-examples section. If you are implimenting your own ruleset, make sure you at include most of the examples from the HOWTO or you will have lots of continuing problems.
There might be a few reasons for this:
Make sure you have the right Ethernet settings for both SPEED and DUPLEX.
If you have a DSL or Cablemode, this behavior is unfortunately quite common. Basically what is happening is your ISP is putting your connection into a very low priority queue to better service non-idle connections. The problem is that some enduser's connections will actually be taken OFFLINE until some traffic from the user's DSL/Cablemodem connection wakens the ISP's hardware
What do I recommend to do? Ping your default gateway every 30 seconds. To do this, edit the /etc/rc.d/rc.local file and add the following to the bottom of the file:
ping -i 30 100.200.212.121 > /dev/null &
Replace the 100.200.212.121 with your default router (upstream router).
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.
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.
Please see the multiple-masqed-lans section for full details.
This topic really doesn't have anything to do with IPMASQ and everthing to do with Linux's built-in traffic shaping and rate-limiting. Please see the /usr/src/linux/Documentation/networking/shaper.txt file from your local kernel sources for more details.
You will also find more information about this including several URLs under the 2.2.x-Requirements section for IPROUTE2.
Though this doesn't have much to do with IPMASQ, here are a few ideas. If you kow of any better solutions, please email the author of this HOWTO so they can be added to the HOWTO.
You DON'T. MASQ is a 1:Many NAT setup which not the correct tool to do what you are looking for. You are looking for a Many:Many NAT solution which is traditional NAT setup. Give a look at the shaping FAQ entry below for more details on the IPROUTE2 tool that will do what you need.
For people out there who are considering enabling multiple IP addresses on one internal NIC using "IP Alias" and then PORTFWed ALL of those ports (0-65535) and used IPROUTE2 to maintain the proper source/destination IP pairs, this has been done SUCCESSFULLY on 2.0.x kernels and less successfully on 2.2.x kernels. Regardless of success, it isn't the proper way to do it and is not a supported MASQ configuration. Please, give IPROUTE2 a look.. its the right way to do true NAT.
One thing to also note:
If you have a bridged DSL or Cablemodem connection (not PPPoE), things are a little more difficult because your setup isn't routed. No worries though, check out the "Bridge+Firewall, Linux Bridge+Firewall Mini-HOWTO" on the LDP. It will teach you how to get your Linux box to support multiple IP addresses on a single interface!
There might be a problem with the "netstat" program in 2.0.x-based Linux distros. After a Linux reboot, running "netstat -M" works fine but after a MASQed computer runs some successful ICMP traffic like ping, traceroute, etc., you might see something like:
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 setup: You have multiple internal networks and also multiple external IP addresses and/or networks. What you want to do is have LAN #1 to only use External IP #1 but you wan LAN #2 to use External IP #2.
Internal LAN ----------> official IP
LAN #1 External IP #1 192.168.1.x --> 123.123.123.11
LAN #2 External IP #2 192.168.2.x --> 123.123.123.12
Basically, what we have described here is routing NOT only on the destination address (typical IP routing) but also routing based upon the SOURCE address as well. This is typically called "policy-based routing" or "source routing". This functionality is NOT available in 2.0.x kernels, it *IS* available for 2.2.x kernels via the IPROUTE2 package, and it is not built into the new 2.4.x kernels using IPTABLES.
First, you have to understand that both IPFWADM and IPCHAINS get involved *AFTER* the routing system has decided where to send a given packet. This statement really ought to be stamped in big red letters on all IPFWADM/IPCHAINS/IPMASQ documentation. The reason for this is that users MUST get their routing setup right first and then start adding IPFWADM/IPCHAINS and/or Masq features.
Anyway, for the example 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. Because this functionality has NOTHING to do with IPMASQ, this HOWTO does not cover this topic in great detail. Please see 2.2.x-Requirements for complete URLs and documentation for this topic.
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 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 David Ranch maintains.
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.