Strange HE 6in4 tunnel disconnects

I am having a strange problem with a Hurricane Electric 6in4 tunnel, and wondering if anyone else has seen anything similar. My ISP (Plusnet in the UK) don't offer native IPv6, but I do have a static IPv4 address, and I'm running OpenWRT 21.02.0 on a TP-Link TL-WDR4300 v1.

root@Router:~# ubus call system board
	"kernel": "5.4.143",
	"hostname": "Router",
	"system": "Atheros AR9344 rev 2",
	"model": "TP-Link TL-WDR4300 v1",
	"board_name": "tplink,tl-wdr4300-v1",
	"release": {
		"distribution": "OpenWrt",
		"version": "21.02.0",
		"revision": "r16279-5cc0535800",
		"target": "ath79/generic",
		"description": "OpenWrt 21.02.0 r16279-5cc0535800"

I have the tunnel defined (as per and it initially works perfectly, but then some time later stops flowing traffic. Restarting the WAN6 interface from either LUCI or the CLI resolves the problem for some further random period of time, as does restarting or powercycling the entire router.

root@Router:~# uci show network.wan6
network.wan6.ip6prefix='2001:REDACTED-PREFIX64::/64' '2001:REDACTED-PREFIX48::/48'

In practice I notice every few days that IPv6 has stopped working, and manually restart the interface. This has been going on for some time now, as until recently I've not had the time to debug it :frowning:

From what I have been able to recently observe, I think that my IPv4 WAN connection is being disconnected by my ISP, and when it reconnects, the 6in4 tunnel also reconnects but from that point on reports lots of TX failures, and fails to flow traffic.

From time of last failure:
Router uptime 6d23h13m43s
WAN / WAN6 uptime 1d10h42m56s
All i/f reporting as up, WAN flowing IPv4 traffic normally, but WAN6 no longer flowing IPv6 traffic

root@Router:~# ifconfig 6in4-wan6
6in4-wan6 Link encap:IPv6-in-IPv4  
          inet6 addr: fe80::c0a8:6401/64 Scope:Link
          inet6 addr: 2001:REDACTED-TUNNEL::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:9529 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@Router:~# ifconfig pppoe-wan
pppoe-wan Link encap:Point-to-Point Protocol  
          inet addr:REDACTED-MY-IPV4  P-t-P:195.166.XXX.XXX  Mask:
          RX packets:2724885 errors:0 dropped:0 overruns:0 frame:0
          TX packets:723756 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:3600470061 (3.3 GiB)  TX bytes:119983329 (114.4 MiB)

I can't see how this is a simple configuration error, as the tunnel does work, at least initially. Similarly, when I restart the tunnel, it starts working again.

At the moment I'm wondering if there is some kind of race conditon going on where the restart of the PPPoE interface triggers the restart of the 6in4 interface, and then that somehow gets ahead of the startup of the interface it depends on (the PPPoE) and fails to handshake properly with the HE endpoint. But that's just a wild guess.

Any help appreciated. Thanks

Make sure your IPv4 is actually static as it's getting harder to have even dynamic public IPv4, let alone static public IPv4.

Be aware of the known issues affecting the entire 21.02 branch:

You can also try adding the following rules:


Yes, sounds like IPv4 changing like @vgaetera noted. You may have to run Tunnelbroker update via DDNS (this is what I do). BTW the update on the interface page only checks once at boot up.


I have static IPv4 address and I don't have any issues. However I have more things configured there than you have. In any case make sure your IPv4 is static indeed.

root@magiatiko:[~]#uci show network.henet

It works using a static IPv4 without extra parameters, but those are necessary if IPv4 is dynamic:


Thanks all. No, my IPv4 address is definitely static. I selected this ISP because they were one of the few in the UK that would supply a true static IPv4 address with no CGNAT. I am also running services here (mail amongst others) that would fail if it were not, and they at least are working fine.

@vgaetera Sorry, my bad - I should have noted that I was seeing this behaviour prior to upgrading to 21.02 too. However, I'm not using software flow offloading anyway :frowning_face:

@trendy The main difference between our configurations are that your have the tunnelid / username / password that I believe are only required for the HE DDNS service (that you shouldn't need if you are on a static IP). My MTU is set to the default of 1280, which may not be optimal, but I can't see it causing this behaviour. Ditto the metric or peerdns settings.

It's certainly an odd situation. I'm pretty sure it's tied up with my ISP occasionally cycling the PPPoE connection that the 6in4 tunnel depends on, so I guess I need to find some way to test that theory :confused: