17.01.2, problem with configuring ipv6 he.net tunnel

I was once using HE.net on openwrt, with success. Sadly i had to move, change my ISP and use their LTE-router without forwarding proto-41through the nat to my router. so i switched to sixxxs/aiccu.
Now i moved again, and can use my Cable Provider again with my DOCSIS Modem. Sixxs has closed and i can use HE.net again on my own router.
But i cannot bring HE.net 6in4 interface UP and working.

I am using a TP-Link TL-WDR4300 v1, Target: ar71xx My ISP is a CableInternet Provider, and i am behind a Cisco Modem. ISP Cable <-> Modem <-> WAN Port
LEDE Reboot 17.01.4, Kernel Version 4.4.92
My LAN Net is 192.168.100.0/24, my Router LAN IP is 192.168.100.1, my Router WAN is the IP received from my Modem.

root@openwrt:~# cat /etc/config/network wan6
config interface 'wan6'
	option proto '6in4'
	option mtu '1424'
	option peeraddr '216.66.87.14'
	option ip6addr '2001:470:1f1a:b4::2/64'
	option tunnelid 'MY_TUNNELID'
	option username 'MY_USERNAME'
	option ip6prefix '2001:470:xxxx::/48'
	option password 'MY_UPDATE_KEY'
	option auto '0'

I have tried with:
option updatekey 'MY_UPDATE_KEY'
additionally or instead of option password

auto 1 and manually starting does not work. It's disabled atm to check pings to the POP/peeraddr

I have tried with a /64 and a /48 Routed IPv6 Prefix.

root@openwrt:~# cat /etc/config/network lan
config interface 'lan'
... yada yada yada ...
	option ip6assign '60'
	option ip6ifaceid '::1'
	option ip6hint '2001:470:xxxx::'

my firewall configs:

config zone
	option name 'wan'
	option output 'ACCEPT'
	option forward 'REJECT'
	option mtu_fix '1'
	option masq '1'
	option network 'wan wan6'
	option input 'REJECT'

proto41/6in4 is allowed

config rule
	option target 'ACCEPT'
	option name '6in4'
	option src 'wan'
	option proto '41'

Before i connect with my WAN6 interface to HE.net, my routing table looks like:

root@openwrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         h081217094001.d 0.0.0.0         UG    0      0        0 eth0.2
81.217.94.0     *               255.255.255.0   U     0      0        0 eth0.2
81.217.94.1     *               255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   *               255.255.255.0   U     0      0        0 br-lan

I am able to ping the IPv6 Tunnel endpoint 216.66.87.14 with 14ms
When i connect the WAN6 Interface, the ping fails immediately.

root@openwrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         h081217094001.d 0.0.0.0         UG    0      0        0 eth0.2
81.217.94.0     *               255.255.255.0   U     0      0        0 eth0.2
81.217.94.1     *               255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   *               255.255.255.0   U     0      0        0 br-lan
216.66.87.14    192.168.100.1   255.255.255.255 UGH   0      0        0 br-lan

Interrestingly, there is a new route... i do not understand why the ping fails and there is a new ipv4 route.

WAN6 does not receive pakets.
the IPv6 Prefix delegations does work well for the LAN Interface.

Uptime: 0h 2m 5s
MAC-Address: C0:A8:64:01:00:00
RX: 0 B (0 Pkts.)
TX: 4.73 KB (46 Pkts.)
IPv6: 2001:470:1f1a:b4::2/64
IPv6-PD: 2001:470:xxxx::/48

root@openwrt:~# ifconfig 6in4-wan6
6in4-wan6 Link encap:IPv6-in-IPv4  
          inet6 addr: fe80::c0a8:6401/64 Scope:Link
          inet6 addr: 2001:470:1f1a:b4::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1424  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:7916 (7.7 KiB)

any logs needed? any information missing?
any ideas what i am doing wrong? Why is there a new route when i connect WAN6? why does the ping stop to the peeraddr?

Comparing your config with mine, I see you have a "/64" at the end of "option ip6addr", while I have nothing after the ":2". Then, "ifconfig" reports a "/128" on the "global" link.

Also, perhaps you could try connecting to another node.

hi,

it's the wrong route which is set when the interface comes up.

root@openwrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         h081217094001.d 0.0.0.0         UG    0      0        0 eth0.2
81.217.94.0     *               255.255.255.0   U     0      0        0 eth0.2
81.217.94.1     *               255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   *               255.255.255.0   U     0      0        0 br-lan
216.66.87.14    192.168.100.1   255.255.255.255 UGH   0      0        0 br-lan

root@openwrt:~# route del 216.66.87.14

root@openwrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         h081217094001.d 0.0.0.0         UG    0      0        0 eth0.2
81.217.94.0     *               255.255.255.0   U     0      0        0 eth0.2
81.217.94.1     *               255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   *               255.255.255.0   U     0      0        0 br-lan

root@openwrt:~# ping 216.66.87.14 
PING 216.66.87.14 (216.66.87.14): 56 data bytes
64 bytes from 216.66.87.14: seq=0 ttl=59 time=14.264 ms
64 bytes from 216.66.87.14: seq=1 ttl=59 time=15.238 ms
64 bytes from 216.66.87.14: seq=2 ttl=59 time=13.976 ms
^C
--- 216.66.87.14 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 13.976/14.492/15.238 ms
root@openwrt:~# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:4001:81b::200e): 56 data bytes
64 bytes from 2a00:1450:4001:81b::200e: seq=0 ttl=52 time=109.783 ms
64 bytes from 2a00:1450:4001:81b::200e: seq=1 ttl=52 time=110.358 ms
^C
--- ipv6.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 109.783/110.070/110.358 ms
root@openwrt:~# 

hmm, that's finally or one of the the problems. the route which gets set. any idea how to remove this route when the interface comes up?

@eduperez thanks for helping and checking your values. adding /64 to the ip6addr should not make a problem, though i already testd with or without it.

also the /128 should be unrelated i guess.

can you compare your routes? if there is a route to your POP through your LAN?

Why is the tunnel attached to LAN???

that's a good question. the route is always created when the interface is going up.
at the moment i have to delete it manually afterwards.

OK, that's a big problem.

Obviously, the configuration says that the IPv6 network is reachable on the LAN...instead of on the WAN at 216.66.87.14. Obviously, your route is wrong, so you're not transmitting IPv6 packets.

On my config, I created a new IPv6-in-IPv4 interface...

  • Local IPv4: BLANK
  • Remote IPv4: you would use "Server IPv4 Address" at your https://tunnelbroker.net/ account
  • Local IPv6 address: the ::2 IP issued to you "Client IPv6 Address" listed on the site
  • Routed IPv6 address: (use the /64 issued on the site for one LAN, apply for a /48 to issue IPv6 addresses to multiple LANs) under "Routed IPv6 Prefixes"
  • YOU MUST ALLOW ICMP-Echo-Request FROM THE HE TUNNEL CHECKER. SEE THE TUNNELBROKER PAGE FOR THIS IP ADDRESS. YOUR TUNNEL WON'T COME ONLINE UNTIL THE CHECKER RECEIVES AN ECHO-REPLY.

From there, you must issue a subnet to each LAN on your device (if you have more than one LAN, you must apply for a /48).

If anyone possibly mixed it:

  • I receive an IPv4 on my WAN Port through DHCP which is 81.217.xx.x
  • The IPv4 Remote Peeraddress for the henet POP is 216.66.87.14, This is the Tunnel Server at the other side.
  • The IPv4 Peeraddress is added to the routing table, which is wrong. This routing breaks connectivity to the pop, no ipv4-connectivity to the POP disables the creation of the Tunnel.
  • When the route is removed, the 6in4-tunnel gets established and a ping6 finally works to ipv6.google.com
  • When the Interface is connected again, for example after a power loss, the wrong route is added again.

@lleachii As you can see, when the route is deleted, the ping works. It's not a blocked-icmp something, it's a not reachable POP server because of a wrong added route to the pop server i guess

This is already done. I can already ping6 ipv6.google.com. IPv6 Delegation works from the tunnel to the lan interface.

With my configuration, bringing up the tunnel also creates a new IPv4 route that points to the other endpoint, but the gateway and the interface correspond to my WAN.

I also noticed another difference between our configurations: in my "config interface 'wan6'" section, I have a "option ifname 'pppoe-wan'" line.

hmm, interresting.
regarding: https://lede-project.org/docs/user-guide/ipv6_ipv4_transitioning#protocol_6in4_ipv6-in-ipv4_tunnel

:!: This protocol type does not need an ifname option set in the interface section. The interface name is derived from the section name, e.g. config interface sixbone would result in an interface named 6in4-sixbone.

Because of the missing ifname, my interface wan6 results to name 6in4-wan6
It's possible to define a name directly with ifname

do i read the documentation right? do you think it relates to the routing problem ?

Notice that I am using the name of the IPv4 WAN interface in the ifname option; sorry, I cannot remember why I put it there...

i have a new finding.
btw, the problem also appears in CHAOS CALMER (15.05, r46767), i've downgraded for testing reasons.

I have added a static route to /etc/config/network

config route
	option target '216.66.87.14'
	option gateway '0.0.0.0'
	option interface 'wan'

this makes it possible to bring the 6in4-henet interface up and connect to henet tunnelbroker.

root@OpenWrt:/etc/config# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         81.217.xx.xx     0.0.0.0         UG    0      0        0 eth0.2
81.217.xx.xx     0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
81.217.xx.xx     0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br-lan
216.66.87.14    0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2

but if i restart/reconnect the interface via luci manually, the wrong route will be again set.

root@OpenWrt:/etc/config# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         81.217.xx.xx     0.0.0.0         UG    0      0        0 eth0.2
81.217.xx.xx     0.0.0.0         255.255.255.0   U     0      0        0 eth0.2
81.217.xx.xx     0.0.0.0         255.255.255.255 UH    0      0        0 eth0.2
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 br-lan
216.66.87.14    192.168.100.1   255.255.255.255 UGH   0      0        0 br-lan

how can i prevent this route?
216.66.87.14 192.168.100.1 255.255.255.255 UGH 0 0 0 br-lan
why does it appear?

sending the traffic to br-lan is wrong. it should be sent to the wan port to the internet instead to the local lan.

Why do you have '192.168.100.1' as gateway in you configuration? Remove it and replace with static routes for your internal networks if you need.

option gateway '192.168.100.1'

When i reboot, the manual set route is working. Then the HENET Interface connects and starts working.

That is the question i ask. When i restart the 6in4 interface, the route becomes added to the routing table instead of my manually created route.

This is what i already do. But the wrong route is added again when i reconnect the 6in4 interface.

I don't understand. Do you mean "option gateway '192.168.100.1' " was added automatically to the lan interface when you configured or restarted the 6in4 interface?

From pastbin in the first message:

config interface 'lan'
        option type 'bridge'
        option ifname 'eth1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.100.2'
        option gateway '192.168.100.1'
        option dns '8.8.8.8 194.204.152.34 194.204.159.1'

@mikma thanks for looking so close and re-reading the whole thread. The "option gateway ‘192.168.100.1" is from a different User at the beginning, not me. And the setting is in his Lan Bridge Interface. i guess i should split and create a new thread instead.

when i restart my 6in4 interface, the route "216.66.87.14 192.168.100.1 255.255.255.255 UGH 0 0 0 br-lan" is added. But 216.66.87.14 is the remote ip address from the henet server. this should be routed through the default gateway and WAN Interface, not to the BR-LAN interface to the local network.

Faced this issue on OpenWrt 18.06.4, r7808-ef686b7292

below script solved the problem
need to place it to /etc/hotplug.d/iface/
and name it something like 99-ipv6_fix
replace 216.66.87.14 to the IP of your tunnel endpoint

if [ "ifup" = "$ACTION" ] && [ "wan6" = "$INTERFACE" ]; then
	IPV6_ROUTE=$(ip route show | grep "216.66.87.14" | grep "br-lan")
	if [ -n "$IPV6_ROUTE" ]; then
		ip route del $IPV6_ROUTE
		logger -t "ipv6_fix" "Deleted route: $IPV6_ROUTE"
	fi
fi

Please use solution from this reply 17.01.2, problem with configuring ipv6 he.net tunnel

1 Like

Did you try that?

3 Likes

That worked, thanks!
Seems that i've missed this config
Actually ipv6 worked out of the box on my main router, but not with this device

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.