Re: How does netfilter decide which in/out-interface a packet has

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello...


On Wed, 2010-03-03 at 18:09 +0100, Pascal Hambourg wrote: 
> > How does netfilter decide which in/out-interface a packet has?
> It doesn't. The packet decides which input interface is arrives on, and
> the routing decision decides which output interface it leaves.
ok...


> > I mean the following:
> > Image I have a host with the following interfaces and addresses:
> > lo: 127.x.x.x and :1/128
> > eth0: 88.88.88.88
> > 99.99.99.99 is a remote address (packets come in via eth0)
> > 
> > Now consider the following cases (source --> destination):
> > "internal traffic":
> > 127.x.x.x   --> 127.x.x.x     => quite clear, in=lo out=lo
> > 127.x.x.x   --> 88.88.88.88   => in=??? out=???
> > 88.88.88.88 --> 88.88.88.88   => in=??? out=???
> > 88.88.88.88 --> 127.x.x.x     => in=??? out=???
> lo in all cases.
Even though 88.88.88.88 is the address of the eth0 interface and from
what you told me just above I'd have guessed, that the (in or out)
interface is eth0 respectively...

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?


> > "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?


> > "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.



Well,.. great :)

Just out of curiosity,... would it be possible to tell the kernel not to
drop such bogus packets at the respective routing decision points?
Could be interesting for programs like sniffers or so...


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux