Tunnel Broker HE disconnect afer a time

[keamas]

Hello, I am using the Hurricane Electric Tunnel Broker to get a IPv6 Connection. The Connection is established by my Sophos UTM 9 Firewall (Astaro).
The Connection and everything works fine. But after a time i am disconnected and need to deactivate and activate the tunnel to get reconnected.
I pinged ipv6.google.com the whole time so traffic was generated but the tunnel disconnected anyway.

Is this a normal behavior or is it a problem of the tunnel broker HE? a wrong configuration? or a problem of the Sophos UTM 9 Firewall?

Can anyone please help me?

[cholzhauer]

It's definitely not normal.  The normal fix for this is to run a ping cron job, but you mentioned that you had that running and the tunnel still disconnected.

How long does it take for the tunnel to disconnect?

[keamas]

I don't know exactly but it is less than 1 day. I will try to monitor this... when the disconnect happens.

[cholzhauer]

Is ping running continuously or is it scheduled? If it's scheduled, what's the schedule?

[keamas]

it is continuously  from a windows machine.

[kasperd]

The Connection is established by my Sophos UTM 9 Firewall (Astaro).

From the symptoms it sounds like the problem is likely with the tunnel endpoint on your firewall. But I don't know anything specific about that firewall, or why it wouldn't be able to keep a tunnel active.

Something is a bit odd on the HE side of the tunnel though. When I try to resolve keamas-1-pt.tunnel.tserv6.fra1.ipv6.he.net, I get two IPv6 addresses. If you can tell me which of them is correct, I can try to ping it from outside with a script that will attempt to estimate the timeout.

[keamas]

Hi the disconnect happens about 24 hours approximately.
Can it be that my IPv4 Internet provider kills my connection after 24 hours and the IPv6 Tunnels doesn't reconnect itself?

This are the IPv6 adresses of the PC which pings ipv6.google.com

IPv6 Address. . . . . . . . . . . : 2001:470:1f0b:7a1::10
IPv6 Address. . . . . . . . . . . : 2001:470:1f0b:7a1:a645:9bd0:69d7:53ea

[kasperd]

Can it be that my IPv4 Internet provider kills my connection after 24 hours and the IPv6 Tunnels doesn't reconnect itself?

The tunnel is supposed to be stateless, which means there isn't a connection, which can be killed. If the tunnel was going through a NAT, then that NAT unit could be introducing state, which can time out.

In the case of NAT any tunnelled packet send from the LAN should be sufficient to keep the connection alive for another timeout period or re-establish it in case it had timed out. Since you are continuously pinging an external IPv6 address, that should avoid a timeout on the NAT. Besides as I understand it, you are not even running the tunnel through a NAT in the first place, since the tunnel endpoint is on a device with a public IPv4 address.

It is possible your ISP could be doing something stateful to your tunnelled packets, and if they do, that could fail in ways similar to the NAT. But the pinging should both prevent the timeout from happening and fix it, if it did happen. So this explanation does not sound very likely.

The next question is, what do you do when it happens? I assume you do something on the tunnel endpoint, such as restarting the device or maybe saving the tunnel settings again. Such an action could fix some bad state on the tunnel endpoint. But I cannot imagine what traffic it could be sending, which could clean up bad state in a device at the ISP. The point is due to the stateless nature, anything the firewall could be sending through your ISP after a restart, would be just the same as on every ping you send through the tunnel.

Based on that the most likely place for the problem to be located is on the firewall. A problem at the ISP is unlikely based on the symptoms you see.

One question I need to ask is if you have a static or dynamic IP address. If the IPv4 address is dynamic, then there might be issues related to updating the IPv4 address. It would be ridiculous if an ISP systematically changes IP addresses every 24 hours on devices, which are active. But it is not impossible.

This are the IPv6 adresses of the PC which pings ipv6.google.com

IPv6 Address. . . . . . . . . . . : 2001:470:1f0b:7a1::10
IPv6 Address. . . . . . . . . . . : 2001:470:1f0b:7a1:a645:9bd0:69d7:53ea

I cannot ping either of those. If I try to traceroute either of those, I do however see the IPv6 address of your firewall, and that is responding to pings. I am now trying to ping that IP at increasing intervals to see when it stops responding.

Since I can ping the firewall but not the PC I am wondering if that is because the problem is only affecting the communication from the PC and not communication from the firewall. Could it be that once the problem shows up, the tunnel is still working, but the communication between the PC and the firewall is not?

I notice you have two IPv6 addresses on the PC. Presumably one is static and the other is a privacy address. AFAIK privacy addresses are typically updated about every 24 hours. So it is not completely unlikely that the problem shows up when the address changes. You should keep an eye out for when that address changes, and see if it is correlated with the problem.

[kasperd]

I do however see the IPv6 address of your firewall, and that is responding to pings. I am now trying to ping that IP at increasing intervals to see when it stops responding.

One ping about 5½ hours ago got through. The next ping 3 hours ago did not get through. At the moment I still see 100% packet loss trying to ping 2001:470:1f0a:7a1::2.

At the moment a traceroute to any of the IPs end at 2001:470:1f0a:1e45::1, which apparently is assigned to the tunnel server. To give me a better idea about what is happening, I need to know what it is you do when you bring the tunnel online again. I also need to know, if you have a static or a dynamic IPv4 address.

[keamas]

, I need to know what it is you do when you bring the tunnel online again. I also need to know, if you have a static or a dynamic IPv4 address.

Hi, get a dynamic IPv4 Address from my Provider A1 Telecom Austria.

I am using the Sophos UTM Firewall.
It has a Web GUI to administrate. On the top there is a Enable / Disable switch.
When I press this it looks in the log like this:

Code Select Expand

2013:07:17-15:03:31 Conrad hurricane[12173]: Exiting...
2013:07:17-15:03:44 Conrad hurricane[27747]: User ID a10ba4221c1a89d176c15b070893abe7
2013:07:17-15:03:44 Conrad hurricane[27747]: Found Tunnel 213334
2013:07:17-15:03:45 Conrad hurricane[27747]: Tunnel 213334
2013:07:17-15:03:45 Conrad hurricane[27747]:  IPv4 93.82.142.244-216.66.80.30
2013:07:17-15:03:45 Conrad hurricane[27747]:  IPv6 2001:470:1f0a:7a1::2-2001:470:1f0a:7a1::1
2013:07:17-15:03:45 Conrad hurricane[27747]:  Network 2001:470:1f0b:7a1::/64
2013:07:17-15:03:45 Conrad hurricane[27747]:  Network 2001:470:724c::/48
2013:07:17-15:03:53 Conrad hurricane[27747]: Setting tunnel 213334 to AUTO
2013:07:17-15:03:53 Conrad hurricane[27747]: +OK: Tunnel endpoint updated to: 178.191.60.10

After disabling and enabling it works...

[kasperd]

Your log shows two different client IPv4 addresses. That's a bit strange. First it shows 93.82.142.244 next it shows 178.191.60.10. According to whois, both are at the same ISP, so it is plausible your router has had each of them at some point.

Also the response from HE shown in the log clearly indicates that your IPv4 address did change at that point.

I guess what happens is that even though your router stays online, your ISP revokes the IPv4 address which was assigned to it and then assign a new IPv4 address to your router. An ISP is not supposed to be doing something like that so frequently. I am wondering if they might be running out of IPv4 addresses and have lowered the DHCP lease time below a reasonable threshold.

When the IPv4 address changes the router might not automatically update the tunnel configuration like it should. The tunnel code might be assuming that the IPv4 address only changes when the router has been restarted. A change of IPv4 address without an update of the config on the tunnel server would explain why you lose IPv6 connectivity.

So my guess is your problem is due to a combination of a configuration mistake at the ISP and a bug in the way the router handles updating of IPv4 address on the tunnel.