LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2003-06-30 16:02:14 +00:00
parent 35c836271c
commit 20d34f6591
1 changed files with 447 additions and 320 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

767
LDP/howto/docbook/IP-Masquerade-HOWTO.sgml
View File

@ -16,9 +16,13 @@
</AUTHOR>
<pubdate>
v2.00.052603, May 26, 2003
v2.00.062203, June 22, 2003
</pubdate>
<Abstract>
<para>
v2.00.062203, June 22, 2003
</para>
<para>
This document describes how to enable the Linux IP Masquerade feature on a
given Linux host. IP Masquerade is a form of Network Address Translation or
@ -128,7 +132,7 @@ Dranch's Linux Page</Ulink>. Additional news, mirrors of the HOWTO, and
information regarding IPMASQ can be found at the
<ULink URL="http://ipmasq.webhop.net/">IP Masquerade Resource</ULink> web page.
If you have any technical questions on IP Masquerade, please join the
<ULink URL="http://home.indyramp.net/lists/masq/">IP Masquerade Mailing List</ULink>
<ULink URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade Mailing List</ULink>
instead of sending email to David or Ambrose. Most MASQ problems are -common-
for ALL MASQ users and can be easily solved by users on the list. In addition
to this, the response time of the IP MASQ email list will be much faster than
@ -1756,7 +1760,7 @@ this -- ignore it for now
<Emphasis role="strong">Other 2.2.x options</Emphasis> can be checked
by running "cat /proc/net"
by running "ls /proc/net/"
<Itemizedlist> <!-- 2.2.x sub 2a -->
<listitem>
@ -1776,7 +1780,7 @@ by running "cat /proc/net"
<para>
<Emphasis role="strong">Even more 2.2.x options</Emphasis> can be
checked by running "cat /proc/net"
checked by running "ls /proc/net/"
<Itemizedlist> <!-- 2.2.x sub 2b -->
<listitem>
@ -10793,7 +10797,7 @@ Mandrake v8.0 : YES - ?
<listitem>
<para>
Mandrake v8.1 : YES - ?
Mandrake v8.1 : YES - 2.4.8
</para>
</listitem>
@ -11117,7 +11121,7 @@ first-time Masquerade users who have problems haven't looked here.
<listitem>
<para>
Check the <ULink
URL="http://home.indyramp.net/lists/masq/">IP Masquerade Mailing List
URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade Mailing List
Archives</ULink>, most likely your questions or problems are a common one and
can be found in a simple Archive search.
</para>
@ -11215,9 +11219,9 @@ unsubscribe from the list or change your options.
<para>
The second method is to use a WWW browser and subscribe via a form at
<ULink
URL="http://home.indyramp.net/lists/masq/">http://home.indyramp.net/lists/masq/</ULink>
for the main MASQ list or <ULink URL="http://home.indyramp.net/lists/masq-dev/">
http://home.indyramp.net/lists/masq-dev/</ULink> for the MASQ-DEV list.
URL="http://home.indyramp.net/mailman/listinfo/masq">http://home.indyramp.net/mailman/listinfo/masq</ULink>
for the main MASQ list or <ULink URL="http://home.indyramp.net/mailman/listinfo/masq-dev">
http://home.indyramp.net/mailman/listinfo/masq-dev</ULink> for the MASQ-DEV list.
</para>
<para>
@ -11580,209 +11584,301 @@ echo "1" &#62; /proc/sys/net/ipv4/ip_dynaddr
<Sect1 id="MTU-issues">
<Title>( MTU ) - IP MASQ seems to be working fine but some sites don't work.
This usually happens with WWW and FTP.</Title>
This usually happens with WWW and some FTP sites.</Title>
<para>
There are two possible reasons for this. The first one is VERY common and the
second is very UNCOMMON.
Depending on what Linux kernel version you are running on the MASQ server,
some will people disagree on the real problem. The two following arguments
have valid points, are inter-related, and users from each camp continue to
debate this to this day.
<ItemizedList>
<listitem>
<para>
As of the 2.0.38 and 2.2.9+ Linux kernels, there is a debatable BUG in the
Masquerade code.
</para>
<listitem>
<para>
With modern 2.4.x Linux systems, most users point their finger at the
adminstrators of these remote broken sites (typically SSL-encrypted WWW
sites, etc.) or your MASQ server's upstream router run by your ISP. The
main though it that these machines are either filtering or not properly
responding to SOME or ALL FORMS of ICMP packets (specifically ICMP Code 3
Type 4 - Fragmentation Needed) messages due to a fray of misplaced security
paranoia.
</para>
<para>
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 would 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
return ICMP packets with the ICMP 3 Sub 4 code back to the originating MASQed
computer. Because of this, the packets get dropped.
</para>
<para>
What does that all mean? Basically, say your machine is connected to the
Internet with a MTU of 1492 bytes (Maximum Transmission Unit -- the maximum
packet size your computer can transmit) which is common for PPPoE users.
At the same time, the remote WWW/FTP site is connected to the Internet at a
MTU of 1500 bytes. The way that TCP/IP works is that when a TCP connection
is being negotiated for your HTTP / FTP connection, the remote side will
try to verify that a 1500 byte packet can reach your computer via the
initial TCP "SYN" packet.
</para>
<para>
Other users point their finger at the adminstrators of the 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.
</para>
<para>
Since the packet is too big for your connection, your upstream router (run
by your ISP) will send a ICMP 3:4 (fragmentation needed) packet back to the
remote WWW / FTP server. Within this packet is a recommended smaller MTU
size to retry with. The problem is that either your local upstream router,
some router between you and the remote server, or the remote HTTP / FTP
server is either misconfigured or has a firewall in front of it that is
BLOCKing these ICMP packets.
</para>
</listitem>
<para>
Both arguments have valid points and users from each camp continue to debate
this down 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
<ULink URL="http://www.tux.org/hypermail/linux-kernel/1999week10/0124.html">
MTU Thread from the Linux-Kernel</ULink> list.
</para>
<listitem>
<para>
The final UNCOMMON possibility is a debatable 2.0 / 2.2 kernel bug in the
IPMASQ code. Some users point their finger to the fact that IPMASQ might
have problems with ICMP packets that have the DF or "Don't Fragment" bit set.
Basically, when a MASQ box connects to the Internet with an MTU of anything
less than 1500, some packets will have the DF field set. Though changing
the MTU of the MASQ server's Internet link to 1500 seemingly fixes the
problem, the possible bug is still there. What is believed to be happening
in these older kernels is that the MASQ code is not properly re-writing the
return IP addresses of the ICMP 3 Sub 4 code packets back to the originating
MASQed computer. Because of this, these critical packets get dropped.
</para>
<para>
No worries though. A perfectly good way to bypass this 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 other hand, most HTTP and FTP traffic will SPEED UP!
</para>
<para>
[ -- 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. -- ]
</para>
<para>
To fix this, first see what your current MTU for your Internet link is. To do
so, 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 1500 but serial PPP links will default
to 576.
</para>
</listitem>
</listitem>
</ItemizedList>
</para>
<Sect2>
<Title>Changing the MTU of a PPP link:</Title>
<para>
No worries though. A there are several perfectly good ways to fix this
nasty MTU problem:
<ItemizedList>
<listitem>
<para>
To fix the MTU issue on your PPP link, edit your /etc/ppp/options file and
towards the top, add the following text on two seperate lines: "mtu 1500"
and "mru 1500". Save these new changes and then restart PPP. Like above,
again verify that your PPP link has the correct MTU and MTU.
</para>
</listitem>
<listitem>
<para>
Enable PMTU clamping in PPPoE
</para>
<para>
This solution is mostly for modern 2.4.x and 2.2.x kernel users connected
to the Internet via a PPPoE DSL or Cablemodem connections. This solution
allows for changes to be done ONLY on the MASQ server itself and not on all
of the internal MASQ clients.
</para>
</listitem>
<listitem>
<para>
To fix the MTU issue on a standard Ethernet link to your bridged or routed DSL,
Cablemodem, etc. connection, you need to edit the correct network startup
scripts for your Linux distribution. Please see the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">TrinityOS - Section 16</ULink>
document for network optimizations.
</para>
</listitem>
<listitem>
<para>
Enable PMTU clamping via IPTABLES
</para>
<para>
This solution is only modern 2.4.x kernel users connected via ANY type
of Internet connection. This solution allows for changes to be done ONLY on
the MASQ server itself and not on all of the internal MASQ clients.
</para>
</listitem>
<listitem>
<para>
Change your MASQ server's Internet Link MTU
</para>
<para>This solution will work for any Linux kernel version but is is NOT a
solution if you have a PPPoE connection for DSL/Cablemodem users.
</para>
<para>
It should be noted that some users will balk at this solution because it
can hurt some latency specific programs like TELNET and Internet games but
the impact is only slight. On the other hand, most HTTP and FTP traffic
will SPEED UP!
</para>
</listitem>
<listitem>
<para>
Change the MTU of all internal MASQed machines
</para>
<para>
This solution requires the most work as you have to make minor changes to
ALL of the internal IPMASQed machines. Basically, you would be changing the
MTU on all of the internal machines to match the MTU of your MASQ server's
Internet connection. Fortunately, this solution is usually bulletproof
where as some of the other solutions mentioned in this section might rarely
not work.
</para>
</listitem>
</ItemizedList>
</para>
<Sect2>
<Title>Enabling PMTU Clamping for PPPoE and some PPP Users:</Title>
<para>
For those users who use PPPoE clients for (DSL / Cablemodem) or PPP (Dialup),
you're Internet connection is NOT "eth0" (for example) but usually "ppp0".
In addition to this, your Internet link's MTU or Maximum Transmission Unit
(largest packet you can transmit over the Internet) isn't 1500 bytes but
1492. The 1492 byte MTU comes from the link size of Ethernet (1518 bytes) -
Ethernet MAC overhead (18) = 1500. Then you subtract the PPPoE header (8
bytes) == MTU of 1492. This overhead isn't a big deal but sometimes ISPs or
remote Internet sites do stupid things to break PPPoE or non-1500 byte MTU
connected machines.
</para>
<para>
You can find more info about this topic on the web. Specifically, here is
good presentaion on the topic:
<ULink URL="http://www.trust-factory.com/mss-talk.pdf">mss-talk presentation
(PDF)</ULink>. Here is the entire
<ULink URL=" http://www.trust-factory.com/van_den_berg-lisa02.pdf">Write
up (PDF)</ULink>
</para>
<para>
To enable clamping in both the RP or PPPd PPPoE clients, add the following
line to your /etc/ppp/pppoe.conf file:
<screen>
# - If you have a computer acting as a gateway for a LAN, choose "1412".
# The setting of 1412 is safe for either setup, but uses slightly more
# CPU power.
#
CLAMPMSS=1412
</screen>
</para>
</Sect2>
<Sect2>
<Title>Old UNIX Serial interfaces:</Title>
<Title>Clamping the MSS via IPTABLES:</Title>
<para>
As mentioned above for PPPoE users, some ISPs and WWW sites filter critical
ICMP packets like MTU Path Discovery. Because of this, many users might find
mosr Internet sites work but others hang or work poorly. Fortunately,
recent IPTABLES have added PMTU Clamping support which should help you. If
your using IPTABLES and think you're hitting this issue, try adding the
following line to the end of your rc.firewall-2.4 ruleset. It should be noted
that there is no PMTU clamping support in IPCHAINS.
<screen>
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
</screen>
</para>
<para>
If this line causes an error when you re-run the rc.firewall-2.4* firewall
rulesets, you might need to upgrade your version of IPTABLES which includes
the "TCPMSS" IPTABLES module.
</para>
</Sect2>
<Sect2>
<Title>Changing the External MTU of the MASQ server:</Title>
<para>
This solution usually only applies to DIALUP users since PPPoE users cannot
INCREASE their MTU because of PPPoE's header overhead.
</para>
<para>
To use this solution, first see what your current MTU for your Internet link
is. To do so, run "/bin/ifconfig" on the MASQ server. Look at the lines
that corresponds to your Internet connection and look for the MTU (for
example, ppp0). This NEEDs to be set to 1500. Usually, Ethernet links
will default to 1500 for Ethernet but serial / DIALUP modem PPP links might
default to 576.
</para>
<para>
<ItemizedList>
<listitem>
<para>
Lastly, though this isn't a common problem, some users have found the solution
to the following problem. With PPP users, verify what port is your PPPd code
connecting to. Is it a /dev/cua* port or a /dev/ttyS* port? It NEEDS to be
a /dev/ttyS* port. The cua style is OLD and it breaks some things in very odd
ways.
</para>
</listitem>
<listitem>
<para>
To change the MTU on a standard Ethernet link to your bridged or routed
DSL, Cablemodem, etc. connection, you need to edit the correct network
startup scripts for your Linux distribution. Please see the
<ULink URL="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#TrinityOS">
TrinityOS - Section 16</ULink> document for network optimizations.
</para>
</listitem>
<listitem>
<para>
To change the MTU issue on a PPP (not PPPoE) Internet link, edit your
"/etc/ppp/options" file and towards the top, add the following text on two
seperate lines, add:
<screen>
mtu 1500
mru 1500
</screen>
</para>
<para>
Save these new changes and then restart PPP. Like shown above, verify that
your PPP link has the correct MTU and MTU.
</para>
<para>
CUA Users: Lastly, though this isn't a common problem, some Linux 2.0.x
kernel users have found a MTU solution to the following problem. With PPP
users, verify what port is your PPPd code connecting to. Is it a /dev/cua*
port or a /dev/ttyS* port? It NEEDS to be a /dev/ttyS* port as the
/dev/cua* device ststem has been deprecated and it breaks some things in
very odd ways.
</para>
</listitem>
</ItemizedList>
</para>
</Sect2>
<Sect2>
<Title>PPPoE Users:</Title>
<para>
For those users who use PPPoE, you're Internet connect is NOT "eth0" (for
example) but "ppp0". In addition to this, your Internet link's MTU is no
longer 1500 bytes but 1492 (Ethernet adapter = 1500 - PPPoE header of 8
bytes == MTU of 1492). This isn't a big deal but sometimes ISPs or remote
Internet sites do stupid things to break PPPoE connected machines.
</para>
<para>
Fortunately, not is all lost.
</para>
<para>
If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external
Internet link's MTU, everything should work fine but that can be a lot of work
or maybe you don't have access to those machines.
Some users have found that "claming the mss" setting of the PPPoE client
helps their problem without having to reconfigure all their internal MASQ
machines. To do this, add the following line to your /etc/ppp/pppoe.conf file:
<screen>
# - If you have a computer acting as a gateway for a LAN, choose "1412".
# The setting of 1412 is safe for either setup, but uses slightly more
# CPU power.
CLAMPMSS=1412
</screen>
</para>
</Sect2>
<Sect2>
<Title>Claming the MSS via IPTABLES:</Title>
<para>
As mentioned above for PPPoE users, some ISPs and WWW sites filter critical
ICMP packets like MTU Path Discovery. Because of this, many users might find
mosr Internet sites work but others hang or work poorly. Fortunately,
recent versions of IPTABLES added the TCPMSS module which might help you. If
you're stuck, try adding the following line to the end of your
rc.firewall-2.4 ruleset:
<screen>
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-mtu
</screen>
If this line causes an error when you run the firewall ruleset, you might need
to upgrade your version of IPTABLES.
</para>
</Sect2>
<Sect2>
<Title>Changing the MTU of various operating systems:</Title>
<para>
So, none of the options worked above? Odd.. but realistically, changing the
MTU of all the IPMASQ clients is a good way to go but how to do this? Follow
these simple steps for your respective operating system.
If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external
Internet link's MTU (for example, 1492 for PPPoE users), everything should
work fine and this method is sometimes the MOST EFFECTIVE way of fixing things.
This is including ALL of the solutions mentioned above. But doing things this
way can be a lot of work if there are lots of internal MASQed machines or be
even impossible to do if you don't have administrative access to all the
internal MASQed machines.
</para>
<para>
Follow these simple steps for your respective operating system:
</para>
<para>
The follow examples utilizes an MTU of 1492 for typical PPPoE connections for
The follow examples utilize an MTU of 1492 for typical PPPoE connections for
some DSL and Cablemodem users. It is recommended to use the HIGHEST values
possible for all connections that are 128Kb/s and faster.
It should be noted that some PPPoE ISPs might require an MTU of 1460 for
proper connectivity due to additional overhead in the ISP's network.
</para>
<para>
The only real reason to use smaller MTUs is to lower latency but at the cost
of throughput. Please see:
It should be noted that some PPPoE ISPs might require an MTU setting of 1460
(not 1492) for proper connectivity due to additional overhead in the ISP's
internal network.
</para>
<para>
The only real reason to use smaller MTUs than 1492 or 1460 is to lower your
Internet link's latency but at the cost of throughput. Please see
<ULink URL="http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu">
http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu</ULink>
</para>
<para>
for more details on this topic.
</para>
<para>
*** If you have had SUCCESS, FAILURE, or have procedures for OTHER operating
*** systems, please email David Ranch. Thanks!
If you know how to make similar changes like these to other
OSes like OS/2, MacOS, etc. please email <ULink URL="mailto:dranch@trinnet.net">
David Ranch</ULink> so it can be included in the HOWTO.
</para>
</Sect2>
<Sect2>
<Title>Linux:</Title>
<Sect3>
<Title>Changing the MTU on Linux:</Title>
<para>
@ -11814,10 +11910,159 @@ for more details on this topic.
</para>
</Sect2>
</Sect3>
<Sect2>
<Title>MS Windows 95: </Title>
<Sect3>
<Title>Changing the MTU on MS Windows 2000</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Navigate down to the key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\&#60;ID for Adapter&#62;
Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway,
subnet mask, etc. Find the key one that is for your network card.
5. Create the following Entry:
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp?LN=EN-US&amp;SD=gn&amp;FR=0
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 2000, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows NT 4.x</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Create the following keys in the Registry trees, choose two
possible Registry trees. Multiple entries are for various
network devices like DialUp Networking (ppp), Ethernet NICs,
PPTP VPNs, etc.
http://support.microsoft.com/support/kb/articles/Q102/9/73.asp?LN=EN-US&amp;SD=gn&amp;FR=0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
and
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\&#60;Adapter-name&#62;\Parameters\Tcpip]
Replace "&#60;Adapter-Name&#62;" with the respective name of your uplink LAN NIC
interface
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal&#62;")
(Do NOT include the quotes)
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 4.x, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to make the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows 98: </Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. You should make a backup copy of your Registry before doing anything. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry--&#62;Export Registry
File--&#62;Save a copy of your registry" would only perform Registry MERGES
and NOT do a replacement.
4. Search though each of the Registry trees that end in "n" (e.g. 0007)
and have a Registry entry called "IPAddress" which has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=STRING
name="MaxMTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=STRING
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal&#62;")
type=STRING
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal&#62;")
6. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect3>
<Sect3>
<Title>Changing the MTU on MS Windows 95: </Title>
<para>
@ -11873,164 +12118,13 @@ for more details on this topic.
</para>
</Sect2>
<Sect2>
<Title>MS Windows 98: </Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. You should make a backup copy of your Registry before doing anything. To
do this, copy the "user.dat" and "system.dat" files from the \WINDOWS
directory and put them into a safe place. It should be noted that the
previously mentioned method of using "Regedit: Registry--&#62;Export Registry
File--&#62;Save a copy of your registry" would only perform Registry MERGES
and NOT do a replacement.
4. Search though each of the Registry trees that end in "n" (e.g. 0007)
and have a Registry entry called "IPAddress" which has the IP address
of your NIC. Under that key, add the following:
From http://support.microsoft.com/support/kb/articles/q158/4/74.asp
[Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
type=STRING
name="MaxMTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
5. You can also change the "TCP Receive Window" which sometimes
increases network performance SUBSTANTIALLY. If you notice your
throughput has DECREASED, put these items BACK to their original
settings and reboot.
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
type=STRING
name="DefaultRcvWindow" (Do NOT include the quotes)
value=32768 (Decimal) (Do NOT include the text "(Decimal&#62;")
type=STRING
name="DefaultTTL" (Do NOT include the quotes)
value=128 (Decimal) (Do NOT include the text "(Decimal&#62;")
6. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect2>
<Sect2>
<Title>MS Windows NT 4.x</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Create the following keys in the Registry trees, choose two
possible Registry trees. Multiple entries are for various
network devices like DialUp Networking (ppp), Ethernet NICs,
PPTP VPNs, etc.
http://support.microsoft.com/support/kb/articles/Q102/9/73.asp?LN=EN-US&amp;SD=gn&amp;FR=0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
and
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\&#60;Adapter-name&#62;\Parameters\Tcpip]
Replace "&#60;Adapter-Name&#62;" with the respective name of your uplink LAN NIC
interface
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal&#62;")
(Do NOT include the quotes)
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 4.x, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to make the changes take effect.
------------------------------------------
</ProgramListing>
</para>
</Sect2>
<Sect2>
<Title>MS Windows 2000</Title>
<para>
<ProgramListing>
------------------------------------------
1. Making ANY changes to the Registry is inheritantly risky but
with a backup copy, you should be safe. Proceed at your
OWN RISK.
2. Goto Start--&#62;Run--&#62;RegEdit
3. Registry--&#62;Export Registry File--&#62;Save a copy of your registry
to a reliable place
4. Navigate down to the key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\&#60;ID for Adapter&#62;
Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway,
subnet mask, etc. Find the key one that is for your network card.
5. Create the following Entry:
type=DWORD
name="MTU" (Do NOT include the quotes)
value=1492 (Decimal) (Do NOT include the text "(Decimal)")
http://support.microsoft.com/support/kb/articles/Q120/6/42.asp?LN=EN-US&amp;SD=gn&amp;FR=0
*** If you know how to also change the MSS, TCP Window Size, and the
*** TTL parameters in NT 2000, please email dranch@trinnet.net as I
*** would love to add it to the HOWTO.
5. Reboot to let the changes take effect.
------------------------------------------
</ProgramListing>
</para>
<para>
As stated above, if you know how to make similar changes like these to other
OSes like OS/2, MacOS, etc. please email <ULink URL="mailto:dranch@trinnet.net">
David Ranch</ULink> so it can be included in the HOWTO.
</para>
</Sect3>
</Sect2>
</Sect1>
<Sect1 id="masqed-ftp">
<Title>( FTP ) - MASQed FTP clients don't work. </Title>
@ -13982,7 +14076,7 @@ where the TrinityOS and other Linux documents are kept.
<para>
You may also find more information at <ULink
URL="http://home.indyramp.net/lists/masq/">
URL="http://home.indyramp.net/mailman/listinfo/masq">
The Semi-Original Linux IP Masquerading Web Site</ULink> maintained by Indyramp
Consulting, who also provides the IP Masq mailing list.
</para>
@ -14118,8 +14212,9 @@ fount at
<listitem>
<para>
<ULink URL="http://home.indyramp.net/lists/masq/">IP Masquerade mailing list
Archives</ULink> contains the recent messages sent to the mailing lists.
<ULink URL="http://home.indyramp.net/mailman/listinfo/masq">IP Masquerade
mailing list Archives</ULink> contains the recent messages sent to the mailing
lists.
</para>
</listitem>
@ -14466,7 +14561,8 @@ Enrique Pessoa Xavier, enrique@labma.ufrj.bron the BOOTp setup suggestion
<listitem>
<para>
All the users on the IP-MASQ email list, masq@tiffany.indyramp.com for their
All the users on the IP-MASQ email list, masq@indyramp.com for their
help and support for all the new Linux MASQ users.
</para>
</listitem>
@ -14587,7 +14683,7 @@ Some topics covered in TrinityOS by David Ranch
</Sect1>
<Sect1 id="ChangeLOG">
<Title>Changes </Title>
<Title>ChangeLOG </Title>
<para>
TO do - HOWTO:
@ -14642,6 +14738,37 @@ Update the portfw FTP patch
<!-- Blah -->
<!-- ChangeLOG -->
<para>
Changes from 05/26/03 to 06/22/03
<ItemizedList>
<listitem>
<para>
06/22/03: Updated the various Indyramp MASQ email URLs again as things seemed
to have changed. Again.
</para>
</listitem>
<listitem>
<para>
06/21/03: Rewrote the MTU FAQ section to be more clear, include specific
information of the problems, and also fixed a bad typo for PPPoE users who
were trying to configure "--clamp-mss-to-mtu" when it should have been
"--clamp-mss-to-pmtu" (missing the p in pmtu).
</para>
</listitem>
<listitem>
<para>
06/13/03: Added kernel info for Mandrake 8.1
</para>
</listitem>
<listitem>
<para>
06/02/03: Fixed a typo where extended 2.2.x kernel checks for IPMASQ
functionality was using "cat" and not "ls"
</para>
</listitem>
</ItemizedList>
</para>
<para>
Changes from 04/08/03 to 05/26/03
<ItemizedList>