From: Michael Gale <michael.gale@utilitran.com>
To: Don Cohen <don-nfil1@isis.cs3-inc.com>,
netfilter-devel@lists.netfilter.org
Subject: Re: NAT and ICMP
Date: Fri, 18 Feb 2005 12:57:49 -0700 [thread overview]
Message-ID: <421648BD.6060809@utilitran.com> (raw)
In-Reply-To: <16918.17766.816573.731012@isis.cs3-inc.com>
Hello,
This makes sense from a routing perspective, if your RH box was a
router on the web or routing to public networks then it would be
functioning normally.
How ever is a firewall setup this is a undesirable response ... I would
suggest blocking ICMP traffic on the external interface. Some people
like to allow some specific ICMP traffic like Destination Unreachable or
PATH MTU ... some people simple block all ICMP traffic.
I do not think this is a netfilter problem just a simple configuration
issue depending on your setup.
Michael.
Don Cohen wrote:
> Here's some behavior that seems clearly wrong, though I'm not
> sure what is right. This is from a redhat 8 box, 2.4.18-14,
> so it's possible that this could be either specific to redhat
> or fixed (or at least altered) in later kernels.
>
> This box is connected to a LAN, and doing NAT for that LAN:
>
> inside 10.0.0.2 --- 10.0.0.1 redhat8 24... --- internet --- server
>
> The inside machine connects to the server in the internet.
> In my test case it's doing ssh, running a program that prints
> the time every minute.
> I now disconnect the inside machine.
> The server sends the next time update (to 24..., the address of
> the redhat NAT machine, to be forwarded to the inside machine).
> The redhat machine can no longer reach the inside machine and
> replies with ICMP host unreachable - returning the packet that
> it could not deliver, which is addressed to 10.0.0.2 !
> This is clearly wrong, since the server has no idea who 10.0.0.2
> is. On the other hand, it also makes no sense to claim that
> 24... is an unreachable host - that's the one that is actually
> answering. The best I can think of is that it ought to say that
> the port is unreachable for the packet it received (pre-NAT, so
> its own address and the port as seen at the server).
>
>
--
Michael Gale
Lan Administrator
Utilitran Corp.
Hey, let me file that under important .... > /dev/null
...
"Hey did you read my e-mail"
"Let my check"
^From:.* > /dev/null
"Nope, I missed it, send it again"
next prev parent reply other threads:[~2005-02-18 19:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200502171912.j1HJCFV06530@isis.cs3-inc.com>
2005-02-18 19:43 ` NAT and ICMP Don Cohen
2005-02-18 19:57 ` Michael Gale [this message]
2005-02-18 21:10 ` Michael Gale
2005-02-18 20:47 ` Patrick McHardy
2025-02-14 18:48 Chris Hall
2025-02-19 23:31 ` Sunny73Cr
2025-02-21 1:40 ` Sunny73Cr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=421648BD.6060809@utilitran.com \
--to=michael.gale@utilitran.com \
--cc=don-nfil1@isis.cs3-inc.com \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.