|
Tunnel inactive when idle?!
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Thursday, 20 March 2003 09:53:14
I noticed the following some time ago, but now I have experienced this multiple times I find it worth mentioning;
Problem: an idle tunnel (ie. no ip6 traffic) goes inactive, resulting in "downtime" according to the sixxs 'ping'
I have repeatedly seen this happen: when I have no traffic on the tunnel interface, I get the "your tunnel was down" message the day after. Per definition this is not right ofcourse, since an IP (whether v4 or v6) link should not go up or down depending on the fact if there's traffic flowing through it.
Although the interface seems up (ifconfig) ... and once I do a ping6 to the outside ip6 world I get response. After that ping the tunnel is also 'up' again according to sixxs ofcourse.
Does anyone have a clue why this occurs???? :?
Is it caused at sixxs (ipng)? Is it a known Linux problem?
(running linux 2.4.20, tunnel set-up according to the sixxs faq using 'ip')
Cheers,
Mark
Tunnel inactive when idle?!
Lemme guess, you have NAT and connection tracking enabled ?
Tunnel inactive when idle?!
Shadow Hawkins on Tuesday, 15 April 2003 13:41:56
I have, also experiencing the same problem.
But what has NAT / connection tracking to do with this?
Tunnel inactive when idle?!
Shadow Hawkins on Saturday, 21 June 2003 12:23:58
NAT and connection tracking can provide something similar to a statefull firewall. This means the remote endpoint for any outgoing connection is allowed to send back packets.
The remote end is only allowed to do so for a limited amount of time, i.e. once the 'record' of the connection times out. At that moment, the remote end (such as a SixXS ping) can no longer send packets to your host.
This looks quite like the problem you describe. Try enabling connections for the ipv6/icmp6 protocol tunnels between the SixXS POP and your tunnel endpoint addresses. That should do the trick and prevent further timeout messages.
The following is the ipf/ipfilter version of such a firewall rule. I hope it does the trick (or provide enough hints if you use linux or other systems).
# Incoming connections from an IPv6 tunnel broker are allowed
pass in quick on vlan0 proto ipv6 from 212.19.192.219/32 to your-endpoint-ipv4/32 group 15 # SixXS IPv6 inbound
pass out quick on vlan0 proto ipv6 from your-endpoint-ipv4/32 to 212.19.192.219/32 group 55 # SixXS IPv6 outbound
Greets,
RK
Tunnel inactive when idle?!
![[be]](/s/countries/be.gif) Carmen Sandiego on Wednesday, 25 June 2003 16:50:50
I have this problem too but not exactly the same..., my tunnel is not inactive when idle, it continue's to work great. However the box is acting as a router for my /48 and that works too (it gives out addresses with no problem). But connections from machines behind that router do timeout.. if I traceroute6 from the machine then I can connect to the net again and that works for say 5 minutes, then the connection timesout again.. Strange that you guys experience this problem on the routerbox itself, I only have this on the client machines..
I mailed to the netfilter/iptables mailinglist already but nobody seems to know a working solution. Then I mailed the coreteam which told me that:
no, there is no connection tracking or NAT for IPv6, so they can
certainly not interferer with your connections.
and also suggested that I'd mail to the devel list (which I still didn't get a reply from). It's seems like there isn't a solution for this problem... |:(
Tunnel inactive when idle?!
The problem is that your tunnel is going over IPv4 and that tunnel connection is being tracked.
But if it works on the router itself, then it should also work for the client machines. I think you might have another problem here. Maybe router advert timeouts?
Tunnel inactive when idle?!
Carmen Sandiego on Wednesday, 25 June 2003 18:56:01
Well, I actually don't know :?
How can I fix it? I'm using radvd, and I'm not exactly a wizard with it :p
Tunnel inactive when idle?!
Debug it... aka use tcpdump and see which kind of icmp's you get before the connects fail. And don't forget to dump on the internal and upstream interfaces (tunnel + underlaying interface)
Tunnel inactive when idle?!
Carmen Sandiego on Friday, 11 July 2003 05:16:52
Well, I just did, but there was absolutely no traffic at all, but then I messed around with the settings and found some routes which where unreachable and some that I wonder how they got there, I removed them and changed the assigned /64 on eth1, now everything seems to be working (for the moment :P). I'm testing the connection a bit with some sites via The SixXS IPv6Gate to see if it finally times out and I cannot do anything anymore, but so far so good. :)
I must say that this IPv6Gate thing roxxx :)
Tunnel inactive when idle?!
Shadow Hawkins on Tuesday, 22 July 2003 13:29:07
If you start a background ping to the tunnel end does this solve it?
If so try to figureout what your router/gateway does.
My linux box does some kind of connection tracking on it's own connections related to the tunnel, but didnt show this behaviour for ssh sessions. Due to a lack of (free) time I havent debugged this - but the pings solves the problem of the tunnel going away every x minutes ;)
Could a missing keepalive be it?
Cheers,
Renee.
Tunnel inactive when idle?!
![[pl]](/s/countries/pl.gif) Shadow Hawkins on Monday, 27 October 2003 20:51:23
I solved it by actually compiling the IPv6 support statically into the kernel.
I had the same problem and it turned out to be IPv6 support compiled as a module. The 'autoclean' flag on that loaded module kept unloading it from memory when it wasn't used for some time and that's when I lost connectivity. When you start a ping on your machine it will activate the module again so keeping it in background will keep the module busy thus resident in memory.
You could also try removing the 'autoclean' flag from the module.
For that, please refer to 'man modprobe' . ;)
The strange thing is - why didn't pings from outside keep the module busy? :?
|
![[ch]](/s/countries/ch.gif)
on Thursday, 20 March 2003 12:56:00
Posting is only allowed when you are