Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Henrik Stoerner <henrik-netfilter@hswn.dk>
To: netfilter@lists.netfilter.org
Subject: Re: Netfilter bug ? NAT'ed connections ignore icmp redirect
Date: Wed, 15 Sep 2004 22:41:00 +0200	[thread overview]
Message-ID: <20040915204100.GA28236@hswn.dk> (raw)
In-Reply-To: <1095262572.1899.66.camel@wolfpack.ljm.dom>

On Wed, Sep 15, 2004 at 11:36:12AM -0400, Jason Opperisano wrote:
> On Wed, 2004-09-15 at 09:39, Henrik Stoerner wrote:

[snip]

thanks Jason, your remark that

> "in-the-true-spirit-of-linux-everything-i-want-to-do-should-work-the-
> way-i-want-no-matter-how-many-RFC's-it-goes-against-or-how-bad-of-an-
> idea-it-is" hat...i will try to explain why i think you're seeing this
> behavior...

did make my day :-)

I wholeheartedly agree - with any hat I can put on - that relying on
ICMP redirects for this is a very bad idea. Had I been responsible for
the design of this network it would have been different, but I am not.
I work at a place where there are people designing networks who
seriously believe they know best how to set things up, and since I am
just the looney playing around with Linux I should not tell them how
to do things.

So my mail to the list was an attempt to understand why netfilter
behaves the way it does - I find it a lot easier to go into a
discussion about matters when I understand them.

> and no--i don't think this is a *bug* in netfilter, i think it's a
> symptom of how linux handles ICMP redirects and the routes created by
> them.  if you read up on how linux treats an ICMP redirect that it
> receives--it limits the scope of the resulting route to host
> communications.

This is the piece of the puzzle that I was missing. It explains the
behaviour I see. I'm re-reading RFC 1122 now, but would appreciate
some pointers to Linux specific docs.

> if you've actually read this far--may i humbly suggest using a dynamic
> routing protocol to route your environment?  zebra/quagga is pretty
> painless--especially if you're familiar with cisco IOS configuration
> syntax.

That would be the ideal solution, I'll try if I can persuade our
network guys to implement this at the router end. If not I guess I'll
have to implement an application-layer proxy instead of using
netfilter for it, and so avoid the problem that way.


Regards,

Henrik



  reply	other threads:[~2004-09-15 20:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-15 13:39 Netfilter bug ? NAT'ed connections ignore icmp redirect Henrik Stoerner
2004-09-15 15:36 ` Jason Opperisano
2004-09-15 20:41   ` Henrik Stoerner [this message]
2004-09-15 18:18 ` Aleksandar Milivojevic

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=20040915204100.GA28236@hswn.dk \
    --to=henrik-netfilter@hswn.dk \
    --cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox