Problem with IPv6 tunnel

Problem with IPv6 tunnel

[David Balažic]

Hi!

I have set up a (SixXS[1]) IPv6 tunnel on my linux router and have the
problem, that after a while I become unavailable over IPv6 for the
outside world.
Then I I perform some IPv6 activity, like "ping6 ipv6.google.com" I
become accessible again for a while.

A SixXS FAQ entry[2] suggests adding an iptables rule:
 iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface]
-j MASQUERADE

This way I get (iptables -t nat -L ...):

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
postrouting_rule  all  --  anywhere             anywhere
MASQUERADE  all  --  anywhere             anywhere
MASQUERADE !ipv6 --  anywhere             anywhere  # the added rule

I am not an iptables expert, but to me it seems the first MASQUERADE
rule matches all packets and the new one does not make any difference.
Can someone confirm that ?


More info:

kernel 2.4.30 (OpenWRT 1.0 - update is not really an option, unfortunately)
iptables v1.3.3

tunnel set up by AICCU 2007.01.15-console by Jeroen Massar
tunnel config excerpt:

# Protocol and server to use for setting up the tunnel (defaults: none)
#protocol <tic|tsp|l2tp>
#server <server to use>
protocol tic
server tic.sixxs.net

ipv6_interface sixxs

Tunnel type: 6in4-heartbeat

Regards,
David


[1] https://www.sixxs.net/
[2] https://www.sixxs.net/faq/connectivity/?faq=conntracking

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Friday 19 June 2009, 10:31 David Balažic wrote:
> I have set up a (SixXS[1]) IPv6 tunnel on my linux router and have the
> problem, that after a while I become unavailable over IPv6 for the
> outside world.
> Then I I perform some IPv6 activity, like "ping6 ipv6.google.com" I
> become accessible again for a while.

This indeed sounds like netfilter is dropping proto-41 packets when the 
connection tracker thinks that your connection has timed out.

> A SixXS FAQ entry[2] suggests adding an iptables rule:
>  iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface]
> -j MASQUERADE
>
> This way I get (iptables -t nat -L ...):
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
> postrouting_rule  all  --  anywhere             anywhere
> MASQUERADE  all  --  anywhere             anywhere
> MASQUERADE !ipv6 --  anywhere             anywhere  # the added rule
>
> I am not an iptables expert, but to me it seems the first MASQUERADE
> rule matches all packets and the new one does not make any difference.
> Can someone confirm that ?

That's absolutely true. The rule from the FAQ is meant to replace your 
original rule, exempting proto-41 traffic from masquerading and thus 
connection tracking.

Benedikt

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Friday 19 June 2009, 10:31 David Balažic wrote:
> I have set up a (SixXS[1]) IPv6 tunnel on my linux router and have the
> problem, that after a while I become unavailable over IPv6 for the
> outside world.
> Then I I perform some IPv6 activity, like "ping6 ipv6.google.com" I
> become accessible again for a while.

This indeed sounds like netfilter is dropping proto-41 packets when the 
connection tracker thinks that your connection has timed out.

> A SixXS FAQ entry[2] suggests adding an iptables rule:
>  iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface]
> -j MASQUERADE
>
> This way I get (iptables -t nat -L ...):
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
> postrouting_rule  all  --  anywhere             anywhere
> MASQUERADE  all  --  anywhere             anywhere
> MASQUERADE !ipv6 --  anywhere             anywhere  # the added rule
>
> I am not an iptables expert, but to me it seems the first MASQUERADE
> rule matches all packets and the new one does not make any difference.
> Can someone confirm that ?

That's absolutely true. The rule from the FAQ is meant to replace your 
original rule, exempting proto-41 traffic from masquerading and thus 
connection tracking.

Benedikt

Re: Problem with IPv6 tunnel

[David Balažic]

(resending, it seems I forgot to CC the list)
(and again, it seems gmail put some HTML into the last post from me :-( )


One more thing: Where is the timeout for this set ?
After the mentioned ping, the world can contact me for hours.

I want to lower the timeout to a minute or so, so I can test the
setting without the need to wait hours for the timeout to happen.

Thanks,
David

2009/6/19 Benedikt Gollatz <ben@differentialschokolade.org>:
> On Friday 19 June 2009, 10:31 David Balažic wrote:
>> I have set up a (SixXS[1]) IPv6 tunnel on my linux router and have the
>> problem, that after a while I become unavailable over IPv6 for the
>> outside world.
>> Then I I perform some IPv6 activity, like "ping6 ipv6.google.com" I
>> become accessible again for a while.
>
> This indeed sounds like netfilter is dropping proto-41 packets when the
> connection tracker thinks that your connection has timed out.
>
>> A SixXS FAQ entry[2] suggests adding an iptables rule:
>>  iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface]
>> -j MASQUERADE
>>
>> This way I get (iptables -t nat -L ...):
>>
>> Chain POSTROUTING (policy ACCEPT)
>> target     prot opt source               destination
>> postrouting_rule  all  --  anywhere             anywhere
>> MASQUERADE  all  --  anywhere             anywhere
>> MASQUERADE !ipv6 --  anywhere             anywhere  # the added rule
>>
>> I am not an iptables expert, but to me it seems the first MASQUERADE
>> rule matches all packets and the new one does not make any difference.
>> Can someone confirm that ?
>
> That's absolutely true. The rule from the FAQ is meant to replace your
> original rule, exempting proto-41 traffic from masquerading and thus
> connection tracking.
>
> Benedikt
>

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Friday 19 June 2009, 14:03 David Balažic wrote:
> One more thing: Where is the timeout for this set ?

/proc/sys/net/netfilter/nf_conntrack_generic_timeout I presume.

> After the mentioned ping, the world can contact me for hours.

That's much too long for the default setting of a timeout. AFAIK the heartbeat 
client must send keepalive packets every 300 seconds so the tunnel and 
connection tracking timeouts may influence each other.

> I want to lower the timeout to a minute or so, so I can test the
> setting without the need to wait hours for the timeout to happen.

Why do you want to conntrack proto-41 packets at all? If you're worried about 
security, filter the IPv6 traffic using ip6tables.

Benedikt

Re: Problem with IPv6 tunnel

[David Balažic]

2009/6/19 Benedikt Gollatz <ben@differentialschokolade.org>:
> On Friday 19 June 2009, 14:03 David Balažic wrote:
>> One more thing: Where is the timeout for this set ?
>
> /proc/sys/net/netfilter/nf_conntrack_generic_timeout I presume.


I have no netfilter dir under /proc/sys/net

(linux 2.4)


>
>> After the mentioned ping, the world can contact me for hours.
>
> That's much too long for the default setting of a timeout. AFAIK the heartbeat
> client must send keepalive packets every 300 seconds so the tunnel and
> connection tracking timeouts may influence each other.
>
>> I want to lower the timeout to a minute or so, so I can test the
>> setting without the need to wait hours for the timeout to happen.
>
> Why do you want to conntrack proto-41 packets at all?

I don't.
That is why I started this thread: How do I make proto 41 not being
screwed by netfilter ?

Regards,
David

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Friday 19 June 2009, 14:57 David Balažic wrote:
> 2009/6/19 Benedikt Gollatz <ben@differentialschokolade.org>:
> > On Friday 19 June 2009, 14:03 David Balažic wrote:
> >> One more thing: Where is the timeout for this set ?
> >
> > /proc/sys/net/netfilter/nf_conntrack_generic_timeout I presume.
>
> I have no netfilter dir under /proc/sys/net
>
> (linux 2.4)

The connection tracking framework has changed somewhere around Linux 2.6.20, 
Linux 2.4 probably never adopted the new one. Before that, connection tracking 
somehow depended on the layer 3 protocol, so I don't know which timeout 
applies there.

> > Why do you want to conntrack proto-41 packets at all?
>
> I don't.
> That is why I started this thread: How do I make proto 41 not being
> screwed by netfilter ?

As I've told you before: By replacing your MASQUERADE rule with the one that 
you can find in the SixXS FAQ.

Benedikt

Re: Problem with IPv6 tunnel

[David Balažic]

2009/6/19 Benedikt Gollatz <ben@differentialschokolade.org>:
>> > Why do you want to conntrack proto-41 packets at all?
>>
>> I don't.
>> That is why I started this thread: How do I make proto 41 not being
>> screwed by netfilter ?
>
> As I've told you before: By replacing your MASQUERADE rule with the one that
> you can find in the SixXS FAQ.

Aha, I misunderstood you then...
I already did that. Now I just have to wait and see if it works or
will it block after some timeout.


Thanks for the assistance.

David

Re: Problem with IPv6 tunnel

[Chris Hills]

On 19/06/09 12:18, Benedikt Gollatz wrote:
>> I am not an iptables expert, but to me it seems the first MASQUERADE
>> rule matches all packets and the new one does not make any difference.
>> Can someone confirm that ?
>
> That's absolutely true. The rule from the FAQ is meant to replace your
> original rule, exempting proto-41 traffic from masquerading and thus
> connection tracking.

I believe the idea is that if you are terminating the tunnel on your 
router, then this rule should replace your default MASQUERADE rule so 
instead of

MASQUERADE  all  --  anywhere             anywhere
MASQUERADE !ipv6 --  anywhere             anywhere

you should have just:-

MASQUERADE !ipv6 --  anywhere             anywhere

This way the connection is not tracked unnecessarily.

Regards,

Chris Hills

Re: Problem with IPv6 tunnel

[Chris Hills]

Oops, never mind. *squawk!* (parrot)

Re: Problem with IPv6 tunnel

[David Balažic]

Hmm, I replaced the rule as suggested, but something still does not
work correctly.

Any idea ?
Is there a way to check currently active tracked "connection" and see
there some clues as to what additional
rule(s) I need ?

Here is my current output of "iptables -t nat -L -v " :

Chain NEW (1 references)
 pkts bytes target     prot opt in     out     source               destination
50876 4029K RETURN     all  --  any    any     anywhere
anywhere            limit: avg 50/sec burst 100
    0     0 DROP       all  --  any    any     anywhere             anywhere

Chain PREROUTING (policy ACCEPT 1895K packets, 199M bytes)
 pkts bytes target     prot opt in     out     source               destination
50876 4029K NEW        all  --  any    any     anywhere
anywhere            state NEW
50876 4029K prerouting_rule  all  --  any    any     anywhere
   anywhere
 9546 1060K prerouting_wan  all  --  ppp0   any     anywhere
  anywhere

Chain POSTROUTING (policy ACCEPT 168K packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
40337 3020K postrouting_rule  all  --  any    any     anywhere
    anywhere
39964 2984K MASQUERADE !ipv6 --  any    ppp0    anywhere             anywhere

Chain OUTPUT (policy ACCEPT 17461 packets, 2006K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain postrouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain prerouting_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain prerouting_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    1    60 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:21
   16   864 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:22
    7   336 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:24
    0     0 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:110
    0     0 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:230
    0     0 ACCEPT     udp  --  any    any     anywhere
anywhere            udp dpt:4500
(and a few port forwarding for the LAN here)

And the "iptables -L -v" output:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   32  4264 DROP       all  --  any    any     anywhere
anywhere            state INVALID
23403 2529K ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
   81  3240 DROP       tcp  --  any    any     anywhere
anywhere            tcp option=!2 flags:SYN/SYN
17118 1689K input_rule  all  --  any    any     anywhere             anywhere
 9236 1045K input_wan  all  --  ppp0   any     anywhere             anywhere
17094 1688K LAN_ACCEPT  all  --  any    any     anywhere             anywhere
   19  1300 ACCEPT     icmp --  any    any     anywhere             anywhere
    0     0 ACCEPT     gre  --  any    any     anywhere             anywhere
 1136 57040 REJECT     tcp  --  any    any     anywhere
anywhere            reject-with tcp-reset
 9856 1051K REJECT     all  --  any    any     anywhere
anywhere            reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 21 packets, 1008 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     anywhere
anywhere            state INVALID
50766 2459K TCPMSS     tcp  --  any    any     anywhere
anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
2626K 2096M ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
36511 2559K forwarding_rule  all  --  any    any     anywhere
   anywhere
  377 19604 forwarding_wan  all  --  ppp0   any     anywhere
  anywhere
    0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere
36134 2540K ACCEPT     all  --  br0    ppp0    anywhere             anywhere

Chain LAN_ACCEPT (1 references)
 pkts bytes target     prot opt in     out     source               destination
 9212 1044K RETURN     all  --  ppp0   any     anywhere             anywhere
 1799 64764 RETURN     all  --  vlan1  any     anywhere             anywhere
 6083  579K ACCEPT     all  --  any    any     anywhere             anywhere

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  any    any     anywhere
anywhere            state INVALID
33066 5111K ACCEPT     all  --  any    any     anywhere
anywhere            state RELATED,ESTABLISHED
 4131  488K output_rule  all  --  any    any     anywhere             anywhere
 4131  488K ACCEPT     all  --  any    any     anywhere             anywhere
    0     0 REJECT     tcp  --  any    any     anywhere
anywhere            reject-with tcp-reset
    0     0 REJECT     all  --  any    any     anywhere
anywhere            reject-with icmp-port-unreachable

Chain forwarding_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere

Chain forwarding_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.20      tcp dpt:13789
    0     0 ACCEPT     udp  --  any    any     anywhere
192.168.200.20      udp dpt:41234
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.20      tcp dpt:7234
  135  7988 ACCEPT     tcp  --  any    any     anywhere
192.168.200.21      tcp dpt:44210
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.21      tcp dpt:59876
    0     0 ACCEPT     udp  --  any    any     anywhere
192.168.200.21      udp dpt:58932
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.20      tcp dpt:1194
    0     0 ACCEPT     udp  --  any    any     anywhere
192.168.200.20      udp dpt:1194
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.20      tcp dpt:3389
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.120     tcp dpt:23966
    0     0 ACCEPT     tcp  --  any    any     anywhere
192.168.200.95      tcp dpt:5001
    0     0 ACCEPT     udp  --  any    any     anywhere
192.168.200.95      udp dpt:5002

Chain input_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun+   any     anywhere             anywhere

Chain input_wan (1 references)
 pkts bytes target     prot opt in     out     source               destination
    1    60 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:21
   16   864 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:22
    7   336 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:24
    0     0 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:110
    0     0 ACCEPT     tcp  --  any    any     anywhere
anywhere            tcp dpt:230
    0     0 ACCEPT     udp  --  any    any     anywhere
anywhere            udp dpt:4500

Chain output_rule (1 references)
 pkts bytes target     prot opt in     out     source               destination


Maybe add a ACCEPT rule for proto 41 in rule "input_wan" ?

Thanks for any help!

David

2009/6/19 David Balažic <xerces9@gmail.com>:
> Hi!
>
> I have set up a (SixXS[1]) IPv6 tunnel on my linux router and have the
> problem, that after a while I become unavailable over IPv6 for the
> outside world.
> Then I I perform some IPv6 activity, like "ping6 ipv6.google.com" I
> become accessible again for a while.
>
> A SixXS FAQ entry[2] suggests adding an iptables rule:
>  iptables -t nat -A POSTROUTING --proto ! 41 -o [Your IPv4 Interface]
> -j MASQUERADE
>
> This way I get (iptables -t nat -L ...):
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
> postrouting_rule  all  --  anywhere             anywhere
> MASQUERADE  all  --  anywhere             anywhere
> MASQUERADE !ipv6 --  anywhere             anywhere  # the added rule
>
> I am not an iptables expert, but to me it seems the first MASQUERADE
> rule matches all packets and the new one does not make any difference.
> Can someone confirm that ?
>
>
> More info:
>
> kernel 2.4.30 (OpenWRT 1.0 - update is not really an option, unfortunately)
> iptables v1.3.3
>
> tunnel set up by AICCU 2007.01.15-console by Jeroen Massar
> tunnel config excerpt:
>
> # Protocol and server to use for setting up the tunnel (defaults: none)
> #protocol <tic|tsp|l2tp>
> #server <server to use>
> protocol tic
> server tic.sixxs.net
>
> ipv6_interface sixxs
>
> Tunnel type: 6in4-heartbeat
>
> Regards,
> David
>
>
> [1] https://www.sixxs.net/
> [2] https://www.sixxs.net/faq/connectivity/?faq=conntracking
>

Re: Problem with IPv6 tunnel

[David Balažic]

2009/7/9 David Balažic <xerces9@gmail.com>:
> Hmm, I replaced the rule as suggested, but something still does not
> work correctly.
>
> Any idea ?
> ...
> Maybe add a ACCEPT rule for proto 41 in rule "input_wan" ?

I did exactly that:

iptables -A input_wan --proto 41 -s 3.4.5.6 -j ACCEPT

# 3.4.5.6 is the address of the remote tunnel endpoint host

And now it appears to work.
I reduced the timeout in
/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout to 10 for
testing.
I also removed the "MASQUERADE !ipv6 --  anywhere
anywhere" line and left the original
MASQUERADE rule.

Thus far, it works.

Regards,
David

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Thu, 9 Jul 2009 15:06:52 +0200, David Balažic <xerces9@gmail.com>
wrote:
> iptables -A input_wan --proto 41 -s 3.4.5.6 -j ACCEPT

Doing this in the filter tables is too late. You need to accept proto-41
packets in the PREROUTING chain to stop the connection tracker from looking
at them.

You can check "conntrack -L" to see which connections are being tracked.

Re: Problem with IPv6 tunnel

[Pascal Hambourg]

Hello,

Benedikt Gollatz a écrit :
> 
> That's absolutely true. The rule from the FAQ is meant to replace your 
> original rule, exempting proto-41 traffic from masquerading and thus 
> connection tracking.

This idea is totally wrong. Not masquerading a connection has no 
influence about whether it is tracked or not. As soon as the conntrack 
is enabled (and it is necessary for NAT/masquerading), all connections 
are tracked. The only way to prevent a connection from being tracked is 
to use the NOTRACK target in the 'raw' table, which is not available in 
standard 2.4 kernels.

Re: Problem with IPv6 tunnel

[Pascal Hambourg]

Benedikt Gollatz a écrit :
> On Thu, 9 Jul 2009 15:06:52 +0200, David Balažic <xerces9@gmail.com>
> wrote:
>> iptables -A input_wan --proto 41 -s 3.4.5.6 -j ACCEPT
> 
> Doing this in the filter tables is too late.

Why ?

> You need to accept proto-41
> packets in the PREROUTING chain to stop the connection tracker from looking
> at them.

Wrong. Connection tracking happens anyway.

Anyway what David need is to allow 6in4 traffic from the tunnel 
endpoint. This has nothing to do with connection tracking.

Re: Problem with IPv6 tunnel

[Benedikt Gollatz]

On Thu, 09 Jul 2009 17:34:37 +0200, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> wrote:
> Benedikt Gollatz a écrit :
>> On Thu, 9 Jul 2009 15:06:52 +0200, David Balažic <xerces9@gmail.com>
>> wrote:
>> You need to accept proto-41
>> packets in the PREROUTING chain to stop the connection tracker from
>> looking
>> at them.
> 
> Wrong. Connection tracking happens anyway.

You'll have to tell that to the authors of the SixXS FAQ.

> Anyway what David need is to allow 6in4 traffic from the tunnel 
> endpoint. This has nothing to do with connection tracking.

Traffic passing through at first and after a certain time not being able to
pass anymore is a classic symptom of problems with connection tracking.

Re: Problem with IPv6 tunnel

[Pascal Hambourg]

Benedikt Gollatz a écrit :
>
>>> You need to accept proto-41
>>> packets in the PREROUTING chain to stop the connection tracker from
>>> looking at them.
>> 
>> Wrong. Connection tracking happens anyway.
> 
> You'll have to tell that to the authors of the SixXS FAQ.

Maybe. I just read the FAQ entry about connection tracking, and I didn't 
think it was so clueless about Linux conntrack. But I'm so lazy, and 
SixXS puts so many requirements about how to contact them.

>> Anyway what David need is to allow 6in4 traffic from the tunnel 
>> endpoint. This has nothing to do with connection tracking.
> 
> Traffic passing through at first and after a certain time not being able to
> pass anymore is a classic symptom of problems with connection tracking.

It less about connection tracking than about how connection tracking 
states are used in filtering rules. Connection tracking does not matter 
if you accept all traffic. So it is a mostly a filtering issue.

Re: Problem with IPv6 tunnel

[David Balažic]

Just for info, I report that after I "opened" protocol 41 for input
(and removed the nat table changes) my IPv6 tunnel is working fine for
more than 24 hours.

David

2009/7/10 Pascal Hambourg <pascal.mail@plouf.fr.eu.org>:
> Benedikt Gollatz a écrit :
>>
>>>> You need to accept proto-41
>>>> packets in the PREROUTING chain to stop the connection tracker from
>>>> looking at them.
>>>
>>> Wrong. Connection tracking happens anyway.
>>
>> You'll have to tell that to the authors of the SixXS FAQ.
>
> Maybe. I just read the FAQ entry about connection tracking, and I didn't
> think it was so clueless about Linux conntrack. But I'm so lazy, and SixXS
> puts so many requirements about how to contact them.
>
>>> Anyway what David need is to allow 6in4 traffic from the tunnel endpoint.
>>> This has nothing to do with connection tracking.
>>
>> Traffic passing through at first and after a certain time not being able
>> to
>> pass anymore is a classic symptom of problems with connection tracking.
>
> It less about connection tracking than about how connection tracking states
> are used in filtering rules. Connection tracking does not matter if you
> accept all traffic. So it is a mostly a filtering issue.
>
>
> --
> 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: Problem with IPv6 tunnel

[Pascal Hambourg]

David Balažic a écrit :
> Just for info, I report that after I "opened" protocol 41 for input
> (and removed the nat table changes) my IPv6 tunnel is working fine for
> more than 24 hours.

Of course it is working fine.
As I said, the issue was not about conntrack or NAT but filtering. So 
you needed to modify your filtering rules, not the NAT or conntrack. 
Good job.
Now maybe you could report this to the authors of the SixXS FAQ. ;-)

Re: Problem with IPv6 tunnel

[David Balažic]

2009/7/10 Pascal Hambourg <pascal.mail@plouf.fr.eu.org>:

> Now maybe you could report this to the authors of the SixXS FAQ. ;-)

I did mention this in a thread on their forum, but as someone said,
they are hard to reach ;-)

David