All of lore.kernel.org
 help / color / mirror / Atom feed
From: Menno Smits <menno@netboxblue.com>
To: Brent Clark <bclark@eccotours.co.za>
Cc: netfilter@lists.netfilter.org
Subject: Re: REJECT --reject-with icmp-host-unreachable vs DROP
Date: Mon, 27 Mar 2006 23:07:51 +1000	[thread overview]
Message-ID: <4427E3A7.20308@netboxblue.com> (raw)
In-Reply-To: <4427A69D.6010702@eccotours.co.za>

Brent Clark wrote:
> Hi all
> 
> Just something I would like to pick someones brain with.
> 
> If I use the default policy of drop, BUT at the end of the chain use
> the following
> 
> $IPT -t filter -A FORWARD -j REJECT --reject-with
> icmp-host-unreachable
> 
> Would that be ok, or does is another ICMP message I can reply back
> with.

icmp-host-unreachable is fine. The default for the REJECT target is
icmp-port-unreachable which is ok too. If you want to make
troubleshooting easier you may want to want to tailor the ICMP reply
according to the reason that a packet was blocked (ie. was a host
blocked, a network or a port). It doesn't matter too much though.

Do an "iptables -j REJECT --help" to see the available reject types.

> Reason I ask this is because I find that by using the default policy
>  (DROP), some applications keep retrying to make a connection etc.
> 
> Where as this approach, seems to slow things down (I stand to
> correction on this).

Most applications/IP stacks will keep retrying for a while because with
a DROP there is no ICMP packet going back to let the sender know that
its traffic isn't getting through. The packet is just stopped without
letting the sender know. The sender assumes the packet was lost and
tries again until some sort of timeout is reached.

If you use REJECT an ICMP packet is sent back so that the sender know 
that its packet won't get through. This way it won't bother retrying and 
will give up immediately.

Note that this isn't always true. Some applications seem to ignore the 
ICMP reject packets coming back and will keep retrying anyway. The 
built-in command line Windows telnet application seems to do this. I'm 
not sure if this is a Windows thing or just the telnet program.

There are some situations where you should just use DROP instead of 
REJECT, usually for performance reasons where your netfilter machine has 
to deal with a high traffic volume and can't afford to send REJECTs. You 
might also want to use DROP when you get traffic that is almost 
definitely malicious. There's no point in sending a nice REJECT in this 
case.

> If someone could maybe help me understand this or assit I would be
> most grateful.

I hope I've explained it clearly enough.

Menno


  parent reply	other threads:[~2006-03-27 13:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-27  8:47 REJECT --reject-with icmp-host-unreachable vs DROP Brent Clark
2006-03-27  9:21 ` Martijn Lievaart
2006-03-27 13:07 ` Menno Smits [this message]
2006-03-27 15:24 ` Nathaniel Hall

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=4427E3A7.20308@netboxblue.com \
    --to=menno@netboxblue.com \
    --cc=bclark@eccotours.co.za \
    --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 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.