IPv6 (6in4) Tunnelbroker Setup

No, I meant the LAN interface on the router. Has that got an IPv6 address?

Oh, sorry! Yes, there are IPv6 addresses on LAN and one of them is from the tunnelbroker assigned prefix. See here:

Protocol: Static address
Uptime: 0h 14m 27s
MAC: ...
RX: 5.78 MB (45436 Pkts.)
TX: 701.43 MB (472145 Pkts.)
IPv4: 192.168.1.1/24
IPv6: 2001:XXX:XXXX::1/60
IPv6: fd23:3587:3330::1/60

Is that not how it should be?

Here is the output of ifstatus henet; ip route get 1::. I'm not sure what the part at the bottom about RTNETLINK answers: Permission denied means.

root@OpenWrt:~# ifstatus henet; ip route get 1::
{
    "up": true,
    "pending": false,
    "available": true,
    "autostart": true,
    "dynamic": false,
    "uptime": 665,
    "l3_device": "6in4-henet",
    "proto": "6in4",
    "updated": [
        "addresses",
        "routes",
        "prefixes"
    ],
    "metric": 0,
    "dns_metric": 0,
    "delegation": true,
    "ipv4-address": [

    ],
    "ipv6-address": [
        {
            "address": "2001:XXX:XXX:XX::2",
            "mask": 64
        }
    ],
    "ipv6-prefix": [
        {
            "address": "2001:XXX:XXXX::",
            "mask": 48,
            "class": "henet",
            "assigned": {
                "lan": {
                    "address": "2001:XXX:XXXX::",
                    "mask": 60
                }
            }
        }
    ],
    "ipv6-prefix-assignment": [

    ],
    "route": [
        {
            "target": "::",
            "mask": 0,
            "nexthop": "::",
            "source": "2001:XXX:XXXX::/48"
        },
        {
            "target": "::",
            "mask": 0,
            "nexthop": "::",
            "source": "2001:XXX:XXXX:XX::2/64"
        }
    ],
    "dns-server": [

    ],
    "dns-search": [

    ],
    "neighbors": [

    ],
    "inactive": {
        "ipv4-address": [

        ],
        "ipv6-address": [

        ],
        "route": [

        ],
        "dns-server": [

        ],
        "dns-search": [

        ],
        "neighbors": [

        ]
    },
    "data": {

    }
}
RTNETLINK answers: Permission denied
1 Like

The answer is still the same:

root@OpenWrt:~# ip route get 1::
RTNETLINK answers: Permission denied
1 Like

Do you think that there is an issue with the routes?

root@OpenWrt:~# ip -6 route show
default from 2001:470:XXXX:XX::/64 dev 6in4-henet proto static metric 1024 pref medium
default from 2001:470:YYYY::/48 dev 6in4-henet proto static metric 1024 pref medium
2001:470:XXXX:XX::/64 dev 6in4-henet proto kernel metric 256 pref medium
2001:470:YYYY::/64 dev br-lan proto static metric 1024 pref medium
unreachable 2001:470:YYYY::/48 dev lo proto static metric 2147483647 error 4294967148 pref medium
fd23:3587:3330::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd23:3587:3330::/48 dev lo proto static metric 2147483647 error 4294967148 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0.2 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev 6in4-henet proto kernel metric 256 pref medium
fe80::/64 dev wlan1 proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 256 pref medium
NET_IF="henet"
. /lib/functions/network.sh
network_flush_cache
network_get_ipaddr6 NET_ADDR "${NET_IF}"
ip route get 1:: from "${NET_ADDR%/*}"
ping6 -w 3 -I "${NET_ADDR%/*}" example.org
traceroute6 -s "${NET_ADDR6%/*}" example.org

Still no luck. Here is the output from the commands above:

root@OpenWrt:~# . /lib/functions/network.sh
root@OpenWrt:~# NET_IF6="henet"
root@OpenWrt:~# network_get_ipaddr6 NET_ADDR6 "${NET_IF6}"
root@OpenWrt:~# ip route get 1:: from "${NET_ADDR6%/*}"
1:: from 2001:470:XXXX:XX::2 dev 6in4-henet proto static src 2001:470:XXXX:XX::2 metric 1024 pref medium
root@OpenWrt:~# ping6 -w 3 -I "${NET_ADDR6%/*}" openwrt.org
PING openwrt.org (2a03:b0c0:3:d0::1af1:1) from 2001:470:XXXX:XX::2: 56 data bytes

--- openwrt.org ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

traceroute6 also failed.

I really appreciate that you're taking the time to help me troubleshoot this. I am at a loss. Any more ideas?

1 Like

Try the static config:

. /lib/functions/network.sh
network_flush_cache
network_find_wan NET_IF
network_get_ipaddr NET_ADDR "${NET_IF}"
uci -q delete network.henet.tunnelid
uci -q delete network.henet.username
uci -q delete network.henet.password
uci -q delete network.henet.mtu
uci set network.henet.ipaddr="${NET_ADDR}"
ifup henet

And repeat the diagnostics.

Still no luck, unfortunately.

1 Like

Where did you get this address from?
The address for my tunnel is not the same as in the wiki.

Where did you get this address from?
The address for my tunnel is not the same as in the wiki.

That's the IPv4 endpoint for my tunnel. I got it from my tunnelbroker 'Tunnel Details' page.

1 Like

I had an HE tunnel working with 19.07.5 but then I upgraded to 19.07.6 and it stopped working.
If you are on 19.07.6 maybe you could try with 19.07.5 and see if it works there.

Be aware that you'll lose the 6in4 package over a sysupgrade, which is required for he.net tunnels to work - reinstall that and you should be all set.

2 Likes

I did re-install all the lost packages and the interface was supposed to be up. "ip -6 a" showed the IPv6 configured and "ifconfig" too but a simple "ping6 ipv6.google.com" didn't work.
One thing I noticed is that the "ip" binary (busybox) doesn't have the "tunnel" command but the interface was configured so I guess openwrt is using some other commands internally (although I couldn't find which ones).

I don't really need the ipv6 tunnel so I've just disabled it. I only had it to play with ipv6 and I can live without it.

But since this was working for me with 19.07.5 I thought maybe @knulf 's problem could be related to 19.07.6.

To be honest I didn't do any more troubleshooting and I can't be 100% sure if it was still working on 19.07.5 the minute before upgrading since, as I said, I wasn't really using the tunnel. But I know it was working when I upgraded to 19.07.5 some time ago and it wasn't working after updating to 19.07.6 earlier today (I did reinstall the packages both times).

Thanks @fgimenezm, I will give downgrading a try if I find some time this week.

There is a new release now: 19.07.7
It has some fixes related to ipv6 point to point links. Not sure if this fixes the tunnel though, but maybe it had something to do with that. I haven't tested it yet.

I don't think it's related, I've ran 6in4 on every 19.07 release and it's been fine. I use imagebuilder to automatically add in any installed packages including 6in4.

2 Likes

I'm starting to think that my ISP is blocking protocol 41... I see my packets going out to the tunnel endpoint but nothing comes back :thinking:

Hello,

I have the same issue. The packet counters on my 6in4-wan6 interface are not incrementing. I can ping the remote IPv4 address of the tunnel, and also the remote IPv6 address from the router. If I ping the remote ipv6 endpoint from the router, the 6in4-wan6 counters are incrementing in and out.

root@OpenWrt:~# ip route get 1::
RTNETLINK answers: Permission denied

6in4 package and kmod-sit are properly installed. I have a public IP address on the wan interface. It appears on the WAN6 page. I am using a snapshot image with kernel version 5.4.98. Any help much appreciated.

I confirm 6in4 works on OpenWrt 19.07.7 in default configuration.
Tested both static and dynamic tunnels without extra firewall rules.

Adding the default route helps to override the source routing filter.
Simultaneously running 6in4 with MWAN or VPN can be problematic.
That would require to properly configure PBR.

Other possible issues can be related to limited or restricted connectivity.
Traffic shaping or filtering performed by the ISP, or missing public IP.

4 Likes