Print

[BinaryStream]

ill be online fine for days then all of a sudden my tunnel goes down.

Typically ill reboot or change my IP and it will resolve it, but theres gotta be a better way to resolve the problem.

I use the net tools linux configuration example initially:

Code: [Select]

ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::209.51.181.2
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:AAAA:BBB::C/64 (only using actual ip6 address)
route -A inet6 add ::/0 dev sit1

Any help on resetting the connection?

[kcochran]

Tunnels are stateless.  The main reasons a tunnel stops working are as follows:

• Use of iptables rules involving conntrack.  You have to ensure that traffic to/from the tunnel server is explicitly permitted, so that conntrack won't timeout the ephemeral auto-rules permitting that traffic
• Changes in IPv4 firewall rules.  While the tunnel is v6, you have to keep the underlying v4 connectivity clear.
• Changes of IPv4 endpoint.
• Potentially misguided ISP firewall policy.

Main thing to check is your iptables, and ensure you're permitting tunnel traffic explicitly, and not relying on conntrack to do the right thing.  It will for v4 only traffic, but it does less well in this case.

[kasperd]

If something could cause the tunnel to go down on the server, then it is plausible that changing your IP can fix it. Because changing your IP requires you to go through the webservice to update the IP, which I assume will delete the tunnel from the tunnel server and recreate it with the new IP.

However it is more likely that something breaks on the client side. In particular if firewall rules or connection tracking is involved around your tunnel endpoint. If the symptom goes away when you just restart your router, then it is most likely a problem with your router. As long as your IP doesn't change, the tunnel server will not know that your router was restarted.

[kcochran]

Even if the router does get a new IP, we won't know they did anything.  Changing the endpoint on the interface just causes the tunnelserver to change the endpoint.  Tunnels only go down on this side when they're deleted.

[kasperd]

Even if the router does get a new IP, we won't know they did anything.  Changing the endpoint on the interface just causes the tunnelserver to change the endpoint.  Tunnels only go down on this side when they're deleted.

Obviously I don't know the implementation details of the service. I don't even know which underlying routing platform it is implemented on. (Differences between the behaviour of the different tunnel servers have given me the impression that they are not all the same, but maybe different versions of one routing platform.)

Most likely the tunnel server and the webservice can get out of sync. And by out of sync I mean what is configured on the tunnel server is not what you'd expect from looking at the setting in the webservice. Getting out of sync like that could easily be the consequence of some rare communication problem not being handled correctly. A well designed system would somehow correct that, and one way it could be corrected is by deleting and recreating the tunnel.

Of course what I was imagining is not the only sensible way to design such a thing. I do think deleting and recreating the tunnel would be more reliable in certain corner cases, but it might not be necessary.