What is the output of "route -A inet6"?
I see problem. Maybe. There is no route to /48.
L¦[17:29:50] # route -A inet6
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::/0 :: U 1024 1 5 6in4-wan6
2001:470:70:cfd::/64 :: Un 256 0 0 6in4-wan6
fd5c:4968:f969::/64 :: U 1024 1 1053 br-lan
fd5c:4968:f969::/48 :: !n 2147483647 0 0 lo
fe80::/64 :: U 256 1 42 br-lan
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 wlan0
fe80::/64 :: Un 256 0 0 6in4-wan6
::/0 :: !n -1 1 2712 lo
::1/128 :: Un 0 2 72 lo
2001:470:70:cfd::/128 :: Un 0 1 0 lo
2001:470:70:cfd::2/128 :: Un 0 2 12 lo
2001:470:71:cfd::/128 :: Un 0 1 0 lo
2001:470:71:cfd::1/128 :: Un 0 2 76 lo
2001:470:64c4::/128 :: Un 0 1 0 lo
2001:470:64c4::1/128 :: Un 0 2 442 lo
fd5c:4968:f969::/128 :: Un 0 1 0 lo
fd5c:4968:f969::1/128 :: Un 0 2 1173 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::/128 :: Un 0 1 0 lo
fe80::b2db:7ebe/128 :: Un 0 1 0 lo
fe80::ea94:f6ff:feed:ba36/128 :: Un 0 2 371 lo
fe80::ea94:f6ff:feed:ba36/128 :: Un 0 1 0 lo
fe80::ea94:f6ff:feed:ba37/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 1 1821 br-lan
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 wlan0
ff00::/8 :: U 256 0 0 6in4-wan6
::/0 :: !n -1 1 2712 loSame, exact, IDENTICAL problem here in Italy, but with both HE and my ISP 6in4 tunnel! Openwrt worked and LEDE doesn't. Synthomos are identical, no packet received on tunnel WAN
[20:04:00]-solaris@main $ ip -6 route
default from 2001:470:70:cfd::/64 dev 6in4-wan6 metric 1024
default from 2001:470:64c4::/48 dev 6in4-wan6 metric 1024
2001:470:70:cfd::/64 dev 6in4-wan6 metric 256
2001:470:64c4::/64 dev br-lan metric 1024
unreachable 2001:470:64c4::/48 dev lo metric 2147483647 error -148
fd5c:4968:f969::/64 dev br-lan metric 1024
unreachable fd5c:4968:f969::/48 dev lo metric 2147483647 error -148
fe80::/64 dev br-lan metric 256
fe80::/64 dev 6in4-wan6 metric 256
fe80::/64 dev eth0 metric 256
fe80::/64 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128
ff00::/8 dev br-lan metric 256
ff00::/8 dev 6in4-wan6 metric 256
ff00::/8 dev eth0 metric 256
ff00::/8 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128
I'm sure you guys wouldn't overlook something like that, but in my case the he.net tunnel would not be established because of the wrong "external" ip address in their system (and/or no icmp ping replies over WAN port on my router with OpenVPN connection setting up default routes).
Just something to keep in mind.
@eterror I stumbled across the exact same problem as well: perfectly working behaviour on OpenWRT, but nothing on LEDE. I found this topic IPv6 on DSL - 2 default Gateways and "Network unreachable", that steered me in the right direction, as I have running latest LEDE (compiled) and had mwan3 installed. I do not need it in my current setup and therefore removed it, solving a similar issue like yours with the routes. One can also disable mwan3 for IPv6, so that should help as well - if that is the source of the problem.
Has the bug/problem been found?. It seems i have the same problem as described.
i was using openwrt with my ISP-Nr.1 and working HE.net. switched to a new ISP-Nr.2 and had to use Sixxs with success. after moving again i could use ISP-Nr.1 again, and use HE.net (sixxxs closed in this time also) and updated to lede. but no success with HE.net so far.
any idea what causes the problems with He.net and LEDE?
@cave I'm still using HE for my IPv6, and it works perfectly. Perhaps you should share your configuration files (remember to hide the passwords) and post the logs from your router.
In my case the problem was with the ISP router that filtered proto 41.
I replaced it with another brand and HE works fine
1 Like
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...