320 lines
12 KiB
HTML
320 lines
12 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.2J.h">
|
|
<TITLE>The Answer Guy 42: ICMP Masquerading</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
|
|
LINK="#3366FF" VLINK="#A000A0">
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
|
|
border="0" align="middle">
|
|
<font color="#B03060">The Answer Guy</font>
|
|
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
|
|
border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
LinuxCare,
|
|
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
|
|
</H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<!-- endcut ======================================================= -->
|
|
<!-- begin 19 -->
|
|
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
|
|
height="50" width="60" alt="(?) " border="0"
|
|
>ICMP Masquerading</H3>
|
|
|
|
|
|
<p><strong>From Abraham S. Lin on Thu, 27 May 1999
|
|
</strong></p>
|
|
<!-- ::
|
|
ICMP Masquerading
|
|
~~~~~~~~~~~~~~~~~
|
|
:: -->
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Hi, jim,
|
|
This is your e-mail address on Linuxgazette, so I tried. Hope this
|
|
is not your personal mailbox.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
So far it all goes to the same mailbox eventually.
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
After reading all the docs, howtos, and the docs from
|
|
<a href="http://www.xos.nl/">www.xos.nl</a>
|
|
(supposedly original ipfwadm site), there are little mention of icmp
|
|
forwarding, and no examples of it.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
My setup is:
|
|
<ol>
|
|
<li>Redhat 5.2(full install), machine name ken. one interface to internet,
|
|
the other to localnet.
|
|
<li>localnet machines with 10.1.1.x private addresses. (kolya and brian)
|
|
</ol>
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
I did deny on all in/out/forward rules of ipfwadm. And then enabling them
|
|
one by one. It's a tuff job but seems like all is well.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Until I figured that <tt>ping</tt> and <tt>traceroute</tt> doesn't work
|
|
from localnet. Not even from the linux gateway to internet.
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
You don't mention which version of the kernel you're using.
|
|
That's important because most versions of the 2.0 kernel
|
|
series didn't support ICMP masquerading. It's still listed
|
|
as an experimental feature.
|
|
</BLOCKQUOTE>
|
|
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Thanks for this in advance. After this is fixed I think we'll have to make
|
|
ipfirewalling HOWTO better than it is now. It didn't do on icmp forwarding.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Thanks again,
|
|
abe
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
P.S.
|
|
Here's the digest of my <TT>/etc/rc.d/rc.local</TT> on the icmp part:
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Your problem has to do with MASQUERADING of ICMP.
|
|
It has nothing to do with forwarding them.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
You probably have to compile a later 2.0.36 kernel
|
|
to add this support. You could also consider trying
|
|
the 2.2.9 or later kernels and switching to the newer
|
|
IP Chains model.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
IP Masquerading through IPChains is not well explained
|
|
in their HOWTO. I just had to figure that one out
|
|
while teaching Linux classes at SGI (one of my Linuxcare
|
|
roles).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I don't have my example handy but the key is to
|
|
understand that the <tt>-j</tt> option to the ipchains command
|
|
is used both for "jumping" to a chain (that you've
|
|
created) and for declaring a disposition to a given
|
|
packet. Thus ACCEPT, DENY, REJECT, REDIR, RETURN and MASQ
|
|
are sorta treated like chains (you use tham as targets to
|
|
the <tt>-j</tt> option) but they will not be listed with the <tt>-L</tt>
|
|
and are not "flushed" with <tt>-F</tt>, etc.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
When you want to masquerade for a network all you really
|
|
need is:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ipchains -A forward -s $INTERNALNET -d 0.0.0.0/0 -j MASQ
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... add a rule to the (pre-defined) forwarding chain
|
|
so that any package with a source address (<TT>-s</TT>) matching
|
|
our internal address and a destination (<TT>-d</TT>) of anywhere
|
|
(else) is "just" MASQueraded.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I've successfully configured masquerading with
|
|
just that rule (and the usual routes and ip_forwarding
|
|
enabled). It doesn't seem to need any special rule
|
|
to match addresses going from an internal address to
|
|
another internal address. So we don't need to
|
|
do something like:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ipchains -A forward -s $INTERNALNET -d ! $INTERNALNET -j MASQ
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... where the <tt>!</tt> sign negates our address mask and
|
|
comes to refer to any destination that is NOT in our
|
|
internal network.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
This second variation of the rule is more precise and
|
|
probably more correct. However it doesn't seem to be
|
|
necessary.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
I have also been successful in setting up bidirectional
|
|
masqeurading with just two fowarding rules:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ipchains -A forward -s $MYNET -d 0.0.0.0/0 -j MASQ
|
|
ipchains -A forward -s $HISNET -d 0.0.0.0/0 -j MASQ
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... again this seems to work although:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ipchains -A forward -s $MYNET -d $HISNET -j MASQ
|
|
ipchains -A forward -s $HISNET -d $MYNET -j MASQ
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... would seem to be more precise and probably better.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
The examples in the HOWTOs seem to insist on creating
|
|
a separate chain for our masquerading rules using something
|
|
like:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>ipchains -N mymasq
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... and then using various rules to jump (<TT>-j</TT>) into that
|
|
chain (which then just does a MASQ anyway, also using the
|
|
<tt>-j</tt> option). This added level of indirection seems to be
|
|
completely unnecessary for the simple case and is far too
|
|
confusing from the examples. I suggest that people start
|
|
with my simpler examples and only add the additional
|
|
chains of rules as their needs demand it.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Your excerpts:
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>> extip=_EXTERNAL_INTERFACE_IP
|
|
> intip=_INTERNAL_INTERFACE_IP
|
|
> localnet=10.1.1.0/24
|
|
> any=0.0.0.0/0
|
|
> # A ping from kolya to 132.206.1.11 Not right still...........
|
|
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
|
|
> /sbin/ipfwadm -O -a accept -V $extip -P icmp -S $extip 8 -D $any
|
|
> /sbin/ipfwadm -I -a accept -V $extip -P icmp -S $any 0 -D $extip
|
|
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $any 0 -D $localnet
|
|
>
|
|
> # A traceroute from kolya to 132.206.1.11 Not right still.......
|
|
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
|
|
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $intip 11 -D $localnet
|
|
>
|
|
> /sbin/ipfwadm -I -a accept -V $intip -P icmp -S $localnet 8 -D $any
|
|
> /sbin/ipfwadm -O -a accept -V $extip -P icmp -S $extip 8 -D $any
|
|
> /sbin/ipfwadm -I -a accept -V $extip -P icmp -S $any 11 -D $extip
|
|
> /sbin/ipfwadm -O -a accept -V $intip -P icmp -S $any 11 -D $localnet
|
|
>
|
|
> # This line just produces error message. Don't know the syntax for icmp.
|
|
> /sbin/ipfwadm -F -a accept -P icmp -S $localnet 3:11 -D $any
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
I think you probably actually want something more like
|
|
</BLOCKQUOTE>
|
|
|
|
<blockquote><pre>/sbin/ipfwadm -F -a accept -m -P icmp -S $localnet 3 11 -D $any
|
|
</pre></blockquote>
|
|
<BLOCKQUOTE>
|
|
... "port ranges" (the 3:11 syntax) aren't meaningful
|
|
for ICMP. I presume you are trying to limit the
|
|
packet filters to accepting/relaying "echo request" and
|
|
"echo reply" packets in this example. I don't have a
|
|
handy list of ICMP packet types but you definitely also
|
|
want to allow some other packet types to get through
|
|
(for MTU path discovery)!
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Actually I'm not sure that you need it when masquerading
|
|
since the ICMP message that informs a TCP stack that a
|
|
"Don't Fragment" packet was dropped might only need
|
|
to reach our router/gateway (the system performing the
|
|
masquerading). I'm not sure if it needs to get all the
|
|
way back to our host.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
In any event I'd suggest that you adopt the opposite
|
|
strategy with regards to ICMP packets. There are only a
|
|
few of them that need to be filtered out (redirects mainly).
|
|
So far it seems to be safe to let most other ICMP message
|
|
types through. (Well, about as safe as letting any sort
|
|
of IP traffic through, masqueraded or otherwise. Naturally
|
|
you should consider proxying with SOCKS, Dante or DeleGate
|
|
to tighten security even further).
|
|
</BLOCKQUOTE>
|
|
<!-- sig -->
|
|
|
|
<!-- end 19 -->
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 1999, James T. Dennis
|
|
<BR>Published in <I>The Linux Gazette</I> Issue 42 June 1999</H5>
|
|
<H6 ALIGN="center">HTML transformation by
|
|
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
|
|
Starshine Techinical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H6>
|
|
<P> <hr> <P>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<TABLE WIDTH="97%"><TR VALIGN="center" ALIGN="center">
|
|
<TD ROWSPAN="4" COLSPAN="1" WIDTH="37%"><A
|
|
HREF="../lg_answer42.html"
|
|
><IMG SRC="../../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Index ]"></A></td>
|
|
<TD WIDTH="10%"><A HREF="1.html">1</A></TD>
|
|
<TD WIDTH="10%"><A HREF="2.html">2</A></TD>
|
|
<TD WIDTH="10%"><A HREF="3.html">3</A></TD>
|
|
<TD WIDTH="10%"><A HREF="4.html">4</A></TD>
|
|
<TD WIDTH="10%"><A HREF="5.html">5</A></TD>
|
|
<TD WIDTH="10%"><A HREF="6.html">6</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="7.html">7</A></TD>
|
|
<TD><A HREF="8.html">8</A></TD>
|
|
<TD><A HREF="9.html">9</A></TD>
|
|
<TD><A HREF="10.html">10</A></TD>
|
|
<TD><A HREF="11.html">11</A></TD>
|
|
<TD><A HREF="12.html">12</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="13.html">13</A></TD>
|
|
<TD><A HREF="14.html">14</A></TD>
|
|
<TD><A HREF="15.html">15</A></TD>
|
|
<TD><A HREF="16.html">16</A></TD>
|
|
<TD><A HREF="17.html">17</A></TD>
|
|
<TD><A HREF="18.html">18</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD><A HREF="19.html">19</A></TD>
|
|
<TD><A HREF="20.html">20</A></TD>
|
|
<TD><A HREF="21.html">21</A></TD>
|
|
<TD><A HREF="22.html">22</A></TD>
|
|
<TD><A HREF="23.html">23</A></TD>
|
|
<TD><A HREF="24.html">24</A></TD>
|
|
</TR></TABLE>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<P> <hr> <P>
|
|
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<A HREF="../../index.html"
|
|
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="/index.html"
|
|
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
|
|
<A HREF="../lg_bytes42.html"
|
|
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
|
|
<A HREF="../lg_tips42.html"
|
|
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
|
|
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|