Linux Netfilter discussions
 help / color / mirror / Atom feed
* dropping UNTRACKED packets, breaks IPv6 - why?
@ 2013-07-26  1:59 Christoph Anton Mitterer
  2013-07-26  7:07 ` Arturo Borrero Gonzalez
  2013-07-27 19:49 ` Pascal Hambourg
  0 siblings, 2 replies; 6+ messages in thread
From: Christoph Anton Mitterer @ 2013-07-26  1:59 UTC (permalink / raw)
  To: netfilter

Hi.

I usually have some default rules in place on all nodes which look about
like this:
---------------------
-A INPUT        --in-interface lo       -j ACCEPT
-A OUTPUT       --out-interface lo      -j ACCEPT

-A INPUT       -m state  --state UNTRACKED     -j DROP
-A FORWARD      -m state  --state UNTRACKED     -j DROP
-A OUTPUT      -m state  --state UNTRACKED     -j DROP

-A INPUT        -m state  --state INVALID       -j DROP
-A FORWARD      -m state  --state INVALID       -j DROP
-A OUTPUT       -m state  --state INVALID       -j DROP

#handle IPsec only sources/destinations
#snip/snap

#allow incoming packets for all established and all related connections
-A INPUT        -m state  --state ESTABLISHED,RELATED   -j ACCEPT

#allow incoming ICMP packets
-A INPUT        --protocol icmpv6       -j ACCEPT
---------------------
And the same for IPv4.

The idea with dropping the UNTRACKED/INVALID was that such packages are
probably not good fellows and should stay out...

Okay... now with IPv4 everything works as expected...


But with v6 nothing works at all and I get Destination unreachables
(even on pings)... I can't even reach the gateway.

When I disable dropping the untracked packets... it starts working,...
even when afterwards I enable it again.
Seems that there is some connection between the host an the gateway
shown then by conntrack.


Now... question is why?


Cheers,
Chris.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dropping UNTRACKED packets, breaks IPv6 - why?
  2013-07-26  1:59 dropping UNTRACKED packets, breaks IPv6 - why? Christoph Anton Mitterer
@ 2013-07-26  7:07 ` Arturo Borrero Gonzalez
  2013-07-26 20:20   ` Christoph Anton Mitterer
  2013-07-27 19:49 ` Pascal Hambourg
  1 sibling, 1 reply; 6+ messages in thread
From: Arturo Borrero Gonzalez @ 2013-07-26  7:07 UTC (permalink / raw)
  To: Christoph Anton Mitterer; +Cc: netfilter

On 26 July 2013 03:59, Christoph Anton Mitterer
<christoph.anton.mitterer@physik.uni-muenchen.de> wrote:
> Hi.
>
> I usually have some default rules in place on all nodes which look about
> like this:
> ---------------------
> -A INPUT        --in-interface lo       -j ACCEPT
> -A OUTPUT       --out-interface lo      -j ACCEPT
>
> -A INPUT       -m state  --state UNTRACKED     -j DROP
> -A FORWARD      -m state  --state UNTRACKED     -j DROP
> -A OUTPUT      -m state  --state UNTRACKED     -j DROP
>
> -A INPUT        -m state  --state INVALID       -j DROP
> -A FORWARD      -m state  --state INVALID       -j DROP
> -A OUTPUT       -m state  --state INVALID       -j DROP
>
> #handle IPsec only sources/destinations
> #snip/snap
>
> #allow incoming packets for all established and all related connections
> -A INPUT        -m state  --state ESTABLISHED,RELATED   -j ACCEPT
>
> #allow incoming ICMP packets
> -A INPUT        --protocol icmpv6       -j ACCEPT

Could you provide a ip6tables-save format ruleset?

> ---------------------
> And the same for IPv4.
>
> The idea with dropping the UNTRACKED/INVALID was that such packages are
> probably not good fellows and should stay out...
>
> Okay... now with IPv4 everything works as expected...
>
>
> But with v6 nothing works at all and I get Destination unreachables
> (even on pings)... I can't even reach the gateway.
>
> When I disable dropping the untracked packets... it starts working,...
> even when afterwards I enable it again.
> Seems that there is some connection between the host an the gateway
> shown then by conntrack.
>
>
> Now... question is why?

What is the default policy? I guess you are not allowing ICMP messages
in OUTPUT. ICMP messages are important in IPv6.

Regards.

-- 
Arturo Borrero González

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dropping UNTRACKED packets, breaks IPv6 - why?
  2013-07-26  7:07 ` Arturo Borrero Gonzalez
@ 2013-07-26 20:20   ` Christoph Anton Mitterer
  0 siblings, 0 replies; 6+ messages in thread
From: Christoph Anton Mitterer @ 2013-07-26 20:20 UTC (permalink / raw)
  To: Arturo Borrero Gonzalez; +Cc: netfilter

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

Hi.

On Fri, 2013-07-26 at 09:07 +0200, Arturo Borrero Gonzalez wrote:
> Could you provide a ip6tables-save format ruleset?
see attachment...


> What is the default policy? I guess you are not allowing ICMP messages
> in OUTPUT. ICMP messages are important in IPv6.
No I do...

It's as if ICMP was UNTRACKED.

Just removing either
-A INPUT -m state --state UNTRACKED -j DROP
or
-A OUTPUT -m state --state UNTRACKED -j DROP
alone isn't enough... I really need to remove both (for the first time).

Cheers,
Chris.

[-- Attachment #2: rules.v6 --]
[-- Type: text/x-iptables, Size: 1367 bytes --]

*filter




:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]




-A INPUT	--in-interface lo	-j ACCEPT
-A OUTPUT	--out-interface lo	-j ACCEPT

-A INPUT	-m state  --state UNTRACKED	-j DROP
-A FORWARD	-m state  --state UNTRACKED	-j DROP
-A OUTPUT	-m state  --state UNTRACKED	-j DROP

-A INPUT	-m state  --state INVALID	-j DROP
-A FORWARD	-m state  --state INVALID	-j DROP
-A OUTPUT	-m state  --state INVALID	-j DROP

#handle IPsec only sources/destinations
-A INPUT	--protocol udp  -m multiport  --destination-ports isakmp,isakmp-nat_espinudp	-j ACCEPT
-A OUTPUT	--protocol udp  -m multiport  --destination-ports isakmp,isakmp-nat_espinudp	-j ACCEPT
-N ipsec-only-in
-N ipsec-only-out

-A INPUT	-m state  --state ESTABLISHED,RELATED	-j ACCEPT

-A INPUT	--protocol icmpv6	-j ACCEPT




#do not handle packets that were or are going to be IPsec processed
-A ipsec-only-in	-m policy  --strict --dir in --pol ipsec --mode tunnel --proto esp	-j RETURN
-A ipsec-only-out	-m policy  --strict --dir out --pol ipsec --mode tunnel --proto esp	-j RETURN
#deny all non-ESP packets (packets that are not subject to IPsec)
-A ipsec-only-in	! --protocol esp	-j REJECT  --reject-with icmp6-adm-prohibited
-A ipsec-only-out	! --protocol esp	-j REJECT  --reject-with icmp6-adm-prohibited



# other stuff...


-A INPUT	-j REJECT  --reject-with icmp6-port-unreachable




COMMIT

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dropping UNTRACKED packets, breaks IPv6 - why?
  2013-07-26  1:59 dropping UNTRACKED packets, breaks IPv6 - why? Christoph Anton Mitterer
  2013-07-26  7:07 ` Arturo Borrero Gonzalez
@ 2013-07-27 19:49 ` Pascal Hambourg
  2013-07-27 20:53   ` Christoph Anton Mitterer
  1 sibling, 1 reply; 6+ messages in thread
From: Pascal Hambourg @ 2013-07-27 19:49 UTC (permalink / raw)
  To: Christoph Anton Mitterer; +Cc: netfilter

Hello,

Christoph Anton Mitterer a écrit :
> 
> The idea with dropping the UNTRACKED/INVALID was that such packages are
> probably not good fellows and should stay out...

You should not blindly drop UNTRACKED or INVALID IPv6 packets.

Originally, ICMPv6 types related to NDP (Neighbour Discovery Protocol),
i.e. Router Solicitation and Router Advertisement (used for stateless
autoconfiguration), Neighbour Solicitation and Neighbour Advertisement
(used as a replacement for ARP request and reply), and a few others had
the INVALID state. However these types are required for proper IPv6
operation on ethernet-like links. Since kernel 2.6.29, they are not
tracked any more and have the UNTRACKED state. See the commit below.

commit 3f9007135c1dc896db9a9e35920aafc65b157230
Author: Eric Leblond <eric@inl.fr>
Date:   Mon Feb 9 14:33:20 2009 -0800

    netfilter: nf_conntrack_ipv6: don't track ICMPv6 negotiation message

    This patch removes connection tracking handling for ICMPv6 messages
    related to Stateless Address Autoconfiguration, MLD, and MLDv2. They
    can not be tracked because they are massively using multicast (on
    pre-defined address). But they are not invalid and should not be
    detected as such.

    Signed-off-by: Eric Leblond <eric@inl.fr>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dropping UNTRACKED packets, breaks IPv6 - why?
  2013-07-27 19:49 ` Pascal Hambourg
@ 2013-07-27 20:53   ` Christoph Anton Mitterer
  2013-07-28  7:51     ` Pascal Hambourg
  0 siblings, 1 reply; 6+ messages in thread
From: Christoph Anton Mitterer @ 2013-07-27 20:53 UTC (permalink / raw)
  To: Pascal Hambourg; +Cc: netfilter

Hi Pascal.


On Sat, 2013-07-27 at 21:49 +0200, Pascal Hambourg wrote:
> You should not blindly drop UNTRACKED or INVALID IPv6 packets.
I see,... thanks.
Why not INVALID IPv6 packets? AFAICS, the patch you've mentioned only
removes tracking for these kinds of packets, but doesn't mark them
invalid.


1) So... are there any other reasonable default rules one should make
for IPv6 (or IPv4) then?
I guess the kernel itself already assures that any address of his own
interfaces are not accepted as source address for packages coming over
the wire? I.e. to prevent spoofing of the hosts own addresses.

2) What about INVALID/UNTRACKED with respect to IPv4? Is it there still
advisable to DROP them unconditionally?


Oh and btw: Does the IPsec handling I do still work with IPv6 or has
anything changed there as well?

I.e. the idea is that I jump to the ipsec-only-in/out chain for any
source/destination host with that I want to accept only
incoming/outgoing packages when they're IPsec'ed.
The jump happens of course before the:
-A INPUT        -m state  --state ESTABLISHED,RELATED   -j ACCEPT


Thanks,
Chris.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: dropping UNTRACKED packets, breaks IPv6 - why?
  2013-07-27 20:53   ` Christoph Anton Mitterer
@ 2013-07-28  7:51     ` Pascal Hambourg
  0 siblings, 0 replies; 6+ messages in thread
From: Pascal Hambourg @ 2013-07-28  7:51 UTC (permalink / raw)
  To: Christoph Anton Mitterer; +Cc: netfilter

Christoph Anton Mitterer a écrit :
> 
> On Sat, 2013-07-27 at 21:49 +0200, Pascal Hambourg wrote:
>> You should not blindly drop UNTRACKED or INVALID IPv6 packets.
> 
> Why not INVALID IPv6 packets? AFAICS, the patch you've mentioned only
> removes tracking for these kinds of packets, but doesn't mark them
> invalid.

Because before the patch, older kernels marked NDP packets INVALID.

> 1) So... are there any other reasonable default rules one should make
> for IPv6 (or IPv4) then?

Sure. On an ethernet-like interface, accept the following ICMPv6 types,
with hop limit 255 as these packets are link-local only :
- neighbour solicitation and neighbour advertisement in both directions
- router solicitation in output and router advertisement in input if the
box is an IPv6 host using stateless autoconfiguration
- router solicitation in input and router advertisement in output if the
box is an IPv6 router with radvd or the like listening on this interface.
Then you can drop anything else you (don't) like.

> I guess the kernel itself already assures that any address of his own
> interfaces are not accepted as source address for packages coming over
> the wire? I.e. to prevent spoofing of the hosts own addresses.

Yes.

> 2) What about INVALID/UNTRACKED with respect to IPv4? Is it there still
> advisable to DROP them unconditionally?

AFAIK, IPv4 has nothing like NDP, so
- INVALID : normally, yes.
- UNTRACKED : AFAIK, it can only be the result of the NOTRACK target, so
you would know about it.

> Oh and btw: Does the IPsec handling I do still work with IPv6 or has
> anything changed there as well?

I don't use IPSec and don't know about its handling by iptables.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-07-28  7:51 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-26  1:59 dropping UNTRACKED packets, breaks IPv6 - why? Christoph Anton Mitterer
2013-07-26  7:07 ` Arturo Borrero Gonzalez
2013-07-26 20:20   ` Christoph Anton Mitterer
2013-07-27 19:49 ` Pascal Hambourg
2013-07-27 20:53   ` Christoph Anton Mitterer
2013-07-28  7:51     ` Pascal Hambourg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox