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

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

[Christoph Anton Mitterer]

Hi.

How does netfilter decide which in/out-interface a packet has? 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=???

"incoming traffic (from remote):
99.99.99.99 --> 127.x.x.x     => is that possible at all? how would  
the in=/out= be?
99.99.99.99 --> 88.88.88.88   => quite clear, in=eth0 out=n/a

"outgoing traffic (to remote):
127.x.x.x --> 99.99.99.99     => is that possible at all? how would  
the in=/out= be?
88.88.88.88 --> 99.99.99.99   => quite clear, in=n/a out=eth0


Thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

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

[Pascal Hambourg]

Hello,

Christoph Anton Mitterer a écrit :
> 
> 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.

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

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

> 99.99.99.99 --> 88.88.88.88   => quite clear, in=eth0 out=n/a

Yup.

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

> 88.88.88.88 --> 99.99.99.99   => quite clear, in=n/a out=eth0

Yup.

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

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

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

[Pascal Hambourg]

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.

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

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

Ok... I think I'm confused now ^^


Before you've said:
>> 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.

So what exactly does it mean?
a) If the packet physically arrives on e.g. eth0 ("by wire") it's
interface is counted as eth0, regardless of what its destination-address
says?

b) If it appears on any interface (e.g. eth0 or eth1) its interface is
counted as that one that matches the destination address on the
packet,... even if it appears physically on eth0 but if it still hast
the destination address of eth1


On Thu, 2010-03-04 at 23:59 +0100, Pascal Hambourg wrote:
> 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.
Do you perhaps know where I can see this in the code?
And is this also the case for v6?


> >>> "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.
a) Uhmm... wait... you say "otherwise" does this mean if log_martians is
disabled they are neither logged NOR discarded?
b) What is all regarded as "martians" here,.. there are different
definitions on the web...


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


Thanks,
Chris.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

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

[Pascal Hambourg]

Christoph Anton Mitterer a écrit :
> 
> Before you've said:
>>> 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.
> 
> So what exactly does it mean?
> a) If the packet physically arrives on e.g. eth0 ("by wire") it's
> interface is counted as eth0, regardless of what its destination-address
> says?

Short answer : yes.

Longer answer : more than the physical interface, it is the "logical"
interface that matters. Such logical interfaces types include bridge
(br0), bonding (bond0), VLAN (eth0.1), tunnel (tun0, tap0), PPP (ppp0)...

Note that IP aliases such as eth0:1 are just labels and not interfaces,
neither physical nor logical. They have no existence for the stack and
netfilter.

> b) If it appears on any interface (e.g. eth0 or eth1) its interface is
> counted as that one that matches the destination address on the
> packet,... even if it appears physically on eth0 but if it still hast
> the destination address of eth1

No, the address does not matter. In the weak host model, local addresses
are considered to be assigned to the host as a whole, not to their
specific interfaces.

> On Thu, 2010-03-04 at 23:59 +0100, Pascal Hambourg wrote:
>> 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.
> Do you perhaps know where I can see this in the code?

No, I am just a user, not a developper.

> And is this also the case for v6?

Of course. Why would it be any different ?

>>>>> "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.
> a) Uhmm... wait... you say "otherwise" does this mean if log_martians is
> disabled they are neither logged NOR discarded?

No, they are discarded but not logged. I meant that if a type of packet
is not considered "martian" by the kernel, you can still log and/or drop
it with iptables.

> b) What is all regarded as "martians" here,.. there are different
> definitions on the web...

Yes, and I don't know for sure what it exactly means. The kernel
documentation just says "impossible addresses".