All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@vger.kernel.org
Subject: Re: How does netfilter decide which in/out-interface a packet has
Date: Thu, 04 Mar 2010 23:59:27 +0100	[thread overview]
Message-ID: <4B903B4F.2030708@plouf.fr.eu.org> (raw)
In-Reply-To: <1267698530.22478.27.camel@etppc09.garching.physik.uni-muenchen.de>

Christoph Anton Mitterer a écrit :
> 
> So the kernel basically sees when packets do not leave the box but are
> just "internal traffic" and uses lo for this?
> 
> I assume this also applies for byte counters like RX/TX packets and
> they're accounted on lo?

Yes and yes.

>>> "incoming traffic (from remote):
>>> 99.99.99.99 --> 127.x.x.x     => is that possible at all? how would  
>>> the in=/out= be?
>> eth0, but the packet is discarded after PREROUTING by the input routing
>> decision which prohibits receiving a packet with a loopback address from
>> outside (a non loopback interface).
> Ah great,... so I don't have to manually drop such stuff... right?
> 
> Are such packets dropped (like DROP) or are the rejected with error
> codes?

They are silently discarded, like DROP. Some of these packets are logged
when sysctl net.ipv4.conf.*.log_martians is enabled. Otherwise you can
log (and drop) them with iptables.

>>> "outgoing traffic (to remote):
>>> 127.x.x.x --> 99.99.99.99     => is that possible at all?
>> Not possible, the output routing decision prohibits sending a packet
>> with a loopback address outside the host (on a non loopback interface).
> So the same as above,... this is handled automatically and I don't need
> to setup specific rules to block such evil.

Note that I observed once that the kernel allowed sending IPv6 packets
outside the host with the source address ::1 (IPv6 loopback address),
which should be prohibited. I didn't test all "impossible" addresses but
there may be other cases. So it may be worth filtering with ip(6)tables
anyway.

> Just out of curiosity,... would it be possible to tell the kernel not to
> drop such bogus packets at the respective routing decision points?

Not without hacking into the kernel source AFAIK.

  reply	other threads:[~2010-03-04 22:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-03 15:54 How does netfilter decide which in/out-interface a packet has Christoph Anton Mitterer
2010-03-03 17:09 ` Pascal Hambourg
2010-03-04 10:28   ` Christoph Anton Mitterer
2010-03-04 22:59     ` Pascal Hambourg [this message]
2010-03-07  3:14       ` Christoph Anton Mitterer
2010-03-07 12:45         ` Pascal Hambourg

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=4B903B4F.2030708@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@vger.kernel.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.