miscellaneous netfilter questions

miscellaneous netfilter questions

[Christoph Anton Mitterer]

Hi.


I'd have several questions on netfilter/iptables which I couldn't  
answer myself via the manpages/etc...
I split them up into several mails ;)


1) If I disable conntracking for packets using NOTRACK in raw what  
happens if I e.g. match the state later in filter? Does the rule  
simply not match for such packets or is it INVALID?


2) The addrtype module provides several address types. Where can I  
find which addreses are _exactly_ matched by a given type for a given  
protocol (especially IP4/6).
I'm especiylly (but not only) interested in what LOCAL actually means?
Is it all addresses of a hosts network interfaces PLUS the ALL  
addresses on that networks (like a "localnets")?
Or is it all the addresses which the kernel thinks the host has itself, e.g.
127.x.x.x
:1/128
88.88.88.88 (if that is the address of eth0)
2000:34:ff (if that is the v6 address of eth1)
and perhaps:
10.20.3.5 (if that is the address of ppp0 or wlan0)


3) --fragment
a) It's quite clear what happens if one uses "-f" or "! -f" but what  
happens if neither of the tow is give? Does it mean "! -f" or is it  
like "match not fragmented packets AND fragmented packets (both the  
first AND further fragments).

b) Is it true, that when conntracking is used, that packets are  
automatically defragmented so one doesn't have to care on fragments at  
all?
In that case, what happens to packets for which conntracking was  
disabled (NOTRACK in raw)? Are they also defragmented or not?



Thanks,
Chris.

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

Re: miscellaneous netfilter questions

[Pascal Hambourg]

Hello,

Christoph Anton Mitterer a écrit :
> 
> 1) If I disable conntracking for packets using NOTRACK in raw what  
> happens if I e.g. match the state later in filter? Does the rule  
> simply not match for such packets or is it INVALID?

Packets processed with the NOTRACK target have the UNTRACKED state.

> 2) The addrtype module provides several address types. Where can I  
> find which addreses are _exactly_ matched by a given type for a given  
> protocol (especially IP4/6).
> I'm especiylly (but not only) interested in what LOCAL actually means?
> Is it all addresses of a hosts network interfaces PLUS the ALL  
> addresses on that networks (like a "localnets")?
> Or is it all the addresses which the kernel thinks the host has itself, e.g.

The latter, I guess.

> 3) --fragment
> a) It's quite clear what happens if one uses "-f" or "! -f" but what  
> happens if neither of the tow is give? Does it mean "! -f" or is it  
> like "match not fragmented packets AND fragmented packets (both the  
> first AND further fragments).

The latter, obviously. All packets are matched regardless of fragmentation.

> b) Is it true, that when conntracking is used, that packets are  
> automatically defragmented so one doesn't have to care on fragments at  
> all?

For IPv4, indeed when conntrack is enabled incoming fragmented datagrams
are reassembled before the PREROUTING chains. Note that packets which
are to be delivered locally are reassembled by the stack (not by
conntrack) before the INPUT chains anyway, so you never see fragments in
INPUT chains.

AFAIK things work a bit differently for IPv6 : fragmented datagrams are
"virtually" reassembled for conntrack (the reason being that an IPv6
router does not handle fragmentation/reassembly), but continue to exist
as fragments through the ip6tables chains and the IPv6 stack.

> In that case, what happens to packets for which conntracking was  
> disabled (NOTRACK in raw)? Are they also defragmented or not?

Good question. I have no answer. This requires some code reading or a
bit of testing.

Re: miscellaneous netfilter questions

[ratheesh k]

>> In that case, what happens to packets for which conntracking was
>> disabled (NOTRACK in raw)? Are they also de-fragment or not?
>
> Good question. I have no answer. This requires some code reading or a
> bit of testing.

for IPV4 .

if we have NAT enabled , packets should be defragmented at PREROUTING
chain to map to correct destination { ip + port }

if dont have NAT also , defaragmented packets doesnt have information
about ports , i think it should be defragmented . I dont know about
HOOK in which  it happens .

Thanks,
Ratheesh



On Wed, Mar 3, 2010 at 10:27 PM, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> Hello,
>
> Christoph Anton Mitterer a écrit :
>>
>> 1) If I disable conntracking for packets using NOTRACK in raw what
>> happens if I e.g. match the state later in filter? Does the rule
>> simply not match for such packets or is it INVALID?
>
> Packets processed with the NOTRACK target have the UNTRACKED state.
>
>> 2) The addrtype module provides several address types. Where can I
>> find which addreses are _exactly_ matched by a given type for a given
>> protocol (especially IP4/6).
>> I'm especiylly (but not only) interested in what LOCAL actually means?
>> Is it all addresses of a hosts network interfaces PLUS the ALL
>> addresses on that networks (like a "localnets")?
>> Or is it all the addresses which the kernel thinks the host has itself, e.g.
>
> The latter, I guess.
>
>> 3) --fragment
>> a) It's quite clear what happens if one uses "-f" or "! -f" but what
>> happens if neither of the tow is give? Does it mean "! -f" or is it
>> like "match not fragmented packets AND fragmented packets (both the
>> first AND further fragments).
>
> The latter, obviously. All packets are matched regardless of fragmentation.
>
>> b) Is it true, that when conntracking is used, that packets are
>> automatically defragmented so one doesn't have to care on fragments at
>> all?
>
> For IPv4, indeed when conntrack is enabled incoming fragmented datagrams
> are reassembled before the PREROUTING chains. Note that packets which
> are to be delivered locally are reassembled by the stack (not by
> conntrack) before the INPUT chains anyway, so you never see fragments in
> INPUT chains.
>
> AFAIK things work a bit differently for IPv6 : fragmented datagrams are
> "virtually" reassembled for conntrack (the reason being that an IPv6
> router does not handle fragmentation/reassembly), but continue to exist
> as fragments through the ip6tables chains and the IPv6 stack.
>
>> In that case, what happens to packets for which conntracking was
>> disabled (NOTRACK in raw)? Are they also defragmented or not?
>
> Good question. I have no answer. This requires some code reading or a
> bit of testing.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: miscellaneous netfilter questions

[Christoph Anton Mitterer]

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

Hi Pascal.

Thanks in advance for your detailed answers :)


On Wed, 2010-03-03 at 17:57 +0100, Pascal Hambourg wrote:
> Packets processed with the NOTRACK target have the UNTRACKED state.
Ah, nice,... this is not described in the manpage (at least not in
Debian's 1.4.6 package of iptables).
Perhaps one should add this?


> > Or is it all the addresses which the kernel thinks the host has itself, e.g.
> The latter, I guess.
I looked through some source files of the kernel and iptables,.. but was
not able to really find a definite answer on this... seems to be
"hidden" (well at least to me) ^^


> > a) It's quite clear what happens if one uses "-f" or "! -f" but what  
> > happens if neither of the tow is give? Does it mean "! -f" or is it  
> > like "match not fragmented packets AND fragmented packets (both the  
> > first AND further fragments).
> The latter, obviously. All packets are matched regardless of fragmentation.
Not sure whether this is really so obvious,... anyway, perhaps this
could also be added to the manpage... e.g. for -o and -i it says what
happens if the options are omitted. :)


> For IPv4, indeed when conntrack is enabled incoming fragmented datagrams
> are reassembled before the PREROUTING chains. Note that packets which
> are to be delivered locally are reassembled by the stack (not by
> conntrack) before the INPUT chains anyway, so you never see fragments in
> INPUT chains.
ok... well...
a) What about packages not delivered locally? I assume they're simply
passed on in the fragmented state as they are? Is this always the case?
E.g. if the next hop network as an MTU that is smaller than the fragment
size?

b) All these things which you say that are happening on the stack (e.g.
the defragmentation here, dropping of packets with bogus addresses or
source addresses that match the address of a local interface)... these
things generally happen _before_ netfilter, right? Or at which place are
they happening?


> AFAIK things work a bit differently for IPv6 : fragmented datagrams are
> "virtually" reassembled for conntrack (the reason being that an IPv6
> router does not handle fragmentation/reassembly), but continue to exist
> as fragments through the ip6tables chains and the IPv6 stack.
Ah... I see... uhm... in this case, how would the following work?
Image one wants to allow incomming packets for ssh so we have about:
:INPUT DROP
-A INPUT --protocol tcp -m tcp --destination-port ssh -j ACCEPT

Now packets come in fragmented,... this would not work for later
fragments right, as the port is not known... so as soon as fragmentation
happens, the above would not work (as expected).

But it should work with those rules:
:INPUT DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT --protocol tcp -m tcp --destination-port ssh --syn -j ACCEPT

..because contrack still works, and the fragmented packets are accepted
by the first rule.

Do I understand this correctly?



Thanks again,
Chris.

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

Re: miscellaneous netfilter questions

[Mart Frauenlob]

On 04.03.2010 11:19, Christoph Anton Mitterer wrote:
> Hi Pascal.
> 
> Thanks in advance for your detailed answers :)
> 
> 
> On Wed, 2010-03-03 at 17:57 +0100, Pascal Hambourg wrote:
>> Packets processed with the NOTRACK target have the UNTRACKED state.
> Ah, nice,... this is not described in the manpage (at least not in
> Debian's 1.4.6 package of iptables).
> Perhaps one should add this?

http://markmail.org/message/wwgycjd7o42k7dod

has been ignored, or overseen...


Best regards

Mart

Re: miscellaneous netfilter questions

[Pascal Hambourg]

Christoph Anton Mitterer a écrit :
> 
>> For IPv4, indeed when conntrack is enabled incoming fragmented datagrams
>> are reassembled before the PREROUTING chains. Note that packets which
>> are to be delivered locally are reassembled by the stack (not by
>> conntrack) before the INPUT chains anyway, so you never see fragments in
>> INPUT chains.
> ok... well...
> a) What about packages not delivered locally? I assume they're simply
> passed on in the fragmented state as they are? Is this always the case?

Yes, unless conntrack is enabled.

> E.g. if the next hop network as an MTU that is smaller than the fragment
> size?

Some time ago I had observed on 2.4 kernels that packets which are too
big with DF=0 are fragmented to fit the MTU after the FORWARD chain.
However if nat is enabled, datagrams are reassembled again in
nat/POSTROUTING and fragmented again afterwards. I did not check whether
it is the same on 2.6 kernels or it was optimized in order to reassemble
and fragment only once at most.

> b) All these things which you say that are happening on the stack (e.g.
> the defragmentation here, dropping of packets with bogus addresses or
> source addresses that match the address of a local interface)... these
> things generally happen _before_ netfilter, right? Or at which place are
> they happening?

They happen at different stages of the packet path, betweek netfilter
hooks. Netfilter and the rest of the stack are interleaved. E.g, the
input routing decision is between PREROUTING and INPUT/FORWARD. Diagrams
are available throughout the web.

>> AFAIK things work a bit differently for IPv6 : fragmented datagrams are
>> "virtually" reassembled for conntrack (the reason being that an IPv6
>> router does not handle fragmentation/reassembly), but continue to exist
>> as fragments through the ip6tables chains and the IPv6 stack.
> Ah... I see... uhm... in this case, how would the following work?
> Image one wants to allow incomming packets for ssh so we have about:
> :INPUT DROP
> -A INPUT --protocol tcp -m tcp --destination-port ssh -j ACCEPT
> 
> Now packets come in fragmented,... this would not work for later
> fragments right, as the port is not known... so as soon as fragmentation
> happens, the above would not work (as expected).

I guess so. However IPv6 deprecates fragmentation by routers and makes
path MTU discovery mandatory, so fragmentation with TCP should be very
uncommon.

> But it should work with those rules:
> :INPUT DROP
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> -A INPUT --protocol tcp -m tcp --destination-port ssh --syn -j ACCEPT
> 
> ..because contrack still works, and the fragmented packets are accepted
> by the first rule.
> 
> Do I understand this correctly?

I guess so. However I haven't played much with IPv6 conntrack yet,
although I use IPv6.