[Solved] Can't ping IPv6 WAN from router

I'm on an adventure to get IPv6 working, but so far OpenWrt seems unable to reach IPv6 hosts on the WAN connection.
My goal is to have my LAN working with both IPv4 and IPv6.

# ping6 -c2 -I eth0.2 www.google.com
PING www.google.com (2a00:1450:400e:807::2004): 56 data bytes

--- www.google.com ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

# ping -c2 -I eth0.2 www.google.com
PING www.google.com (172.217.17.132): 56 data bytes
64 bytes from 172.217.17.132: seq=0 ttl=58 time=3.054 ms
64 bytes from 172.217.17.132: seq=1 ttl=58 time=2.814 ms

--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss

The interface is connected:

Device: eth0.2
Uptime: 2h 40m 22s
MAC: 68:FF:7B:2B:2C:CE
RX: 167.30 MB (714022 Pkts.)
TX: 12.41 MB (87381 Pkts.)
IPv6: ::6aff:[...]:2cce/64
IPv6: 2a01:90a0::6aff:[...]:2cce/64
IPv6-PD: 2a01:90a0:1ff:fb00::/56

Network layout
[ISP] -> bridged ISP router -> OpenWrt router -> [LAN]
The ISP supports IPv6, has their own IPv6 DNS, and configures this via DHCP.

The OpenWrt router is a TP-link Archer C7 with OpenWrt 18.06.4 .

What I've tried

  • reset the router to factory default
  • checked if the wan6 interface was connected. It is. Gets IPv6, DNS and everything.
  • checked for any blocking firewall rules
  • ping6 www.google.com from the router (ssh login). This did resolve to an IPv6 address, but was unable to reach the host
  • checked configs and routing tables. It looks okay to me, but this is where I get confused, as I don't really know what an IPv6 config should look like.
  • connected my laptop directly to the bridged ISP router. This worked perfectly. I got an IPv6 address, and the test at http://v6.testmyipv6.com/ showed a triumph, huge success, so the IPv6 connection from the bridged router is working fine.
  • searching the web, comparing settings, trying out different settings (mostly through LuCi)

Configs
Not sure exactly what you need, but maybe these help. I'm happy to provide more specific info.

ifstatus

# ifstatus wan6
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 1147,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604322,
			"valid": 2591522
		},
		{
			"address": "2a01:90a0::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604521,
			"valid": 2591721
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a01:90a0:1ff:fb00::",
			"mask": 56,
			"preferred": 376853,
			"valid": 603653,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a01:90a0:1ff:fb00::",
					"mask": 60
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591522,
			"source": "::\/0"
		},
		{
			"target": "2a01:90a0::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591721,
			"source": "::\/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "2a01:90a0:1ff:fb00::\/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "2a01:90a0::6aff:[...]:2cce\/64"
		}
	],
	"dns-server": [
		"2a03:[...]::6",
		"2a03:[...]::7",
		"fe80::1"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a0381801001017400000000000000062a038180140100bb0000000000000007"
	}
}

ip route and ip rule

# ip -6 route
default from ::/64 via fe80::1 dev eth0.2  metric 512 
default from 2a01:90a0::/64 via fe80::1 dev eth0.2  metric 512 
default from 2a01:90a0:1ff:fb00::/56 via fe80::1 dev eth0.2  metric 512 
::/64 dev eth0.2  metric 256 
2a01:90a0::/64 dev eth0.2  metric 256 
2a01:90a0:1ff:fb00::/64 dev br-lan  metric 1024 
unreachable 2a01:90a0:1ff:fb00::/56 dev lo  metric 2147483647  error -148
fddb:b901:3a6f::/64 dev br-lan  metric 1024 
unreachable fddb:b901:3a6f::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
unreachable default dev lo  metric -1  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev br-lan  metric 256 
ff00::/8 dev eth0.2  metric 256 
unreachable default dev lo  metric -1  error -128

# ip -6 rule
0:	from all lookup local 
32766:	from all lookup main 
4200000000:	from 2a01:90a0:1ff:fb00::1/60 iif br-lan lookup unspec unreachable
4200000001:	from all iif lo lookup unspec 12
4200000005:	from all iif br-lan lookup unspec 12
4200000007:	from all iif eth0.2 lookup unspec 12
4200000007:	from all iif eth0.2 lookup unspec 12

/etc/config/network

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fddb:b901:3a6f::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth0.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'dhcp'

config device 'wan_dev'
	option name 'eth0.2'
	option macaddr '68:ff:7b:2b:2c:ce'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	option reqaddress 'none'
	option reqprefix 'auto'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 5 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 0t'

/etc/config/firewall

config defaults
	option syn_flood	1
	option input		ACCEPT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

config zone
	option name		lan
	list   network		'lan'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT

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

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option src_ip		fc00::/6
	option dest_ip		fc00::/6
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT

# include a file with users custom iptables rules
config include
	option path /etc/firewall.user

/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv6 'server'
	option ra 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

Any idea what I could be missing here?

I'm perfectly comfortable with Linux and IPv4 networks, but I'm new at OpenWrt, and IPv6 seems to be more complicated than I thought.

Are you running OpenWrt?

The two outputs you pasted don't look like OpenWrt.

  • What is the network prefix (/64, /48)?

Ummmm, this mask is too small for 2 networks (WAN and LAN). You'll need to NAT IPv6, or request a larger subnet from your ISP.

As an alternative, you can use an IPv6 tunnel broker.

Hmmm, it's a different format that I'm used to, but IPv6-PD: 2a01:90a0:1ff:fb00::/56 suggests to me that that @nio has a /56 delegated. I think that the address on WAN6 is that of the ISP's router's subnet.

Can you ping your gateway from your OpenWrt router?

ping6 fe80::1%eth0.2

(IPv6 link-local addresses don't need to be unique, the %eth0.2 says that it's the fe80::1 seen on that link.)

1 Like

Just in case: the eth0.2 interface is used by the WAN6 interface I see in LuCi. This is the WAN port connected to the ISP router.

I can successfully ping the gateway:

# ping6 fe80::1%eth0.2
PING fe80::1%eth0.2 (fe80::1%7): 56 data bytes
64 bytes from fe80::1: seq=0 ttl=255 time=0.786 ms
64 bytes from fe80::1: seq=1 ttl=255 time=0.860 ms
64 bytes from fe80::1: seq=2 ttl=255 time=0.844 ms
64 bytes from fe80::1: seq=3 ttl=255 time=0.747 ms
^C
--- fe80::1%eth0.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.747/0.809/0.860 ms

If I understand correctly, this means that OpenWrt can reach the ISP's gateway through IPv6?
In that case, could the problem be in the routing table?

Kinda strange though that ping6 -c2 -I eth0.2 2a00:1450:400e:807::200e (google IPv6) doesn't get any response, since it explicitly uses the WAN interface. Or perhaps it tries to use a gateway that's not on that interface? I'm getting confused again.. :confused:

I found the solution!
Edit: nope, somehow I'm once again unable to reach the web through IPv6.. See below.

Original:

In LuCi, at the WAN6 interface settings, I set "Request IPv6-address" to "force".
It took a little while before it the new DHCP lease was finished, but I noticed I did get an additional IP address;

evice: eth0.2
Uptime: 0h 4m 27s
MAC: 68:FF:7B:2B:2C:CE
RX: 1.62 GB (8027404 Pkts.)
TX: 1.85 GB (2659711 Pkts.)
IPv6: ::6aff:[...]:2cce/64
IPv6: 2a01:90a0::6aff:[...]:2cce/64
IPv6: 2a01:90a0::1111:2222/128     <-- edited a bit, but this one is new
IPv6-PD: 2a01:90a0:1ff:fb00::/56

Earlier I've had this setting set to "try", but that didn't work. Apparently my router has to be a bit more demanding to get that third IPv6 address.

This also might be what @lleachii was referring to with the small subnet mask, which was probably because the IP with the larger /128 subnet was missing. Guess you were right all along. :slight_smile:

Now I can ping IPv6 from both the router and from the LAN, so all is good.

Can someone explain what these three IPv6 adresses are for? Why don't I get just one address?
If you know a good source to learn about this that would be awesome too.

Edit:

Okay, I went to try a few of those IPv6 check sites, and they timed out again.
I then tried an IPv6 ping from the LAN, and those got not response. Same when I ping from the router.
So once again I'm unable to ping the v6 web.

The only thing I did was take a short break, visit those sites, and then the problem was back.

I tried switching that "Request IPv6-address" setting back- and forth, but it only seems to change if I get that /128 address or not.

Any ideas what this could be?

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

I did, but then the problem returned.. It was merely a brief glimmer of hope.

I've updated my previous response.

I've disabled the setting "Use builtin IPv6-management", save and apply, then re-enabled it and saved again. (I'm not sure what exactly this setting does by the way.)
This got v6 pings working again both from the router and from the LAN.

Web pages are still unavailable though. I've tried this with the browser first, and then with wget on both the router and LAN, with the same results:

$ wget -O - "http://ipv6.google.com" | head -n1
--2019-10-27 13:14:54--  http://ipv6.google.com/
Resolving ipv6.google.com (ipv6.google.com)... 2a00:1450:400e:809::200e
Connecting to ipv6.google.com (ipv6.google.com)|2a00:1450:400e:809::200e|:80... failed: Connection timed out.
Retrying.

--2019-10-27 13:17:05--  (try: 2)  http://ipv6.google.com/
Connecting to ipv6.google.com (ipv6.google.com)|2a00:1450:400e:809::200e|:80... failed: Connection timed out.
Retrying.
^C

The routing has changed. I now see the ISP's full gateway address listed in my routing tables.

Old ifstatus
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 1147,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604322,
			"valid": 2591522
		},
		{
			"address": "2a01:90a0::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604521,
			"valid": 2591721
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a01:90a0:1ff:fb00::",
			"mask": 56,
			"preferred": 376853,
			"valid": 603653,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a01:90a0:1ff:fb00::",
					"mask": 60
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591522,
			"source": "::\/0"
		},
		{
			"target": "2a01:90a0::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591721,
			"source": "::\/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "2a01:90a0:1ff:fb00::\/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1700,
			"source": "2a01:90a0::6aff:[...]:2cce\/64"
		}
	],
	"dns-server": [
		"2a03:[...]::6",
		"2a03:[...]::7",
		"fe80::1"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a0381801001017400000000000000062a038180140100bb0000000000000007"
	}
}
New ifstatus
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 258,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604796,
			"valid": 2591996
		},
		{
			"address": "2a01:90a0::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604796,
			"valid": 2591996
		},
		{
			"address": "2a01:90a0::1111:2222",
			"mask": 128,
			"preferred": 377739,
			"valid": 604539
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a01:90a0:1ff:fb00::",
			"mask": 56,
			"preferred": 377739,
			"valid": 604539,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a01:90a0:1ff:fb00::",
					"mask": 60
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591996,
			"source": "::\/0"
		},
		{
			"target": "2a01:90a0::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591996,
			"source": "::\/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::[ISP_gateway]",
			"metric": 512,
			"valid": 1796,
			"source": "2a01:90a0:1ff:fb00::\/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::[ISP_gateway]",
			"metric": 512,
			"valid": 1796,
			"source": "::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::[ISP_gateway]",
			"metric": 512,
			"valid": 1796,
			"source": "2a01:90a0::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::[ISP_gateway]",
			"metric": 512,
			"valid": 1796,
			"source": "2a01:90a0::1111:2222\/128"
		}
	],
	"dns-server": [
		"2a03:[...]::6",
		"2a03:[...]::7",
		"fe80::1"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a0381801001017400000000000000062a038180140100bb0000000000000007"
	}
}
Old ip -6 route
default from ::/64 via fe80::1 dev eth0.2  metric 512 
default from 2a01:90a0::/64 via fe80::1 dev eth0.2  metric 512 
default from 2a01:90a0:1ff:fb00::/56 via fe80::1 dev eth0.2  metric 512 
::/64 dev eth0.2  metric 256 
2a01:90a0::/64 dev eth0.2  metric 256 
2a01:90a0:1ff:fb00::/64 dev br-lan  metric 1024 
unreachable 2a01:90a0:1ff:fb00::/56 dev lo  metric 2147483647  error -148
fddb:b901:3a6f::/64 dev br-lan  metric 1024 
unreachable fddb:b901:3a6f::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
unreachable default dev lo  metric -1  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev br-lan  metric 256 
ff00::/8 dev eth0.2  metric 256 
unreachable default dev lo  metric -1  error -128
New ip -6 route
default from ::/64 via fe80::[isp_gateway] dev eth0.2  metric 512 
default from 2a01:90a0::1:febb via fe80::[isp_gateway] dev eth0.2  metric 512 
default from 2a01:90a0::/64 via fe80::[isp_gateway] dev eth0.2  metric 512 
default from 2a01:90a0:1ff:fb00::/56 via fe80::[isp_gateway] dev eth0.2  metric 512 
::/64 dev eth0.2  metric 256 
2a01:90a0::/64 dev eth0.2  metric 256 
2a01:90a0:1ff:fb00::/64 dev br-lan  metric 1024 
unreachable 2a01:90a0:1ff:fb00::/56 dev lo  metric 2147483647  error -148
fddb:b901:3a6f::/64 dev br-lan  metric 1024 
unreachable fddb:b901:3a6f::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
unreachable default dev lo  metric -1  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev br-lan  metric 256 
ff00::/8 dev eth0.2  metric 256 
unreachable default dev lo  metric -1  error -128

So ping finally works, but the rest of the web, or at least http, doesn't.

Disabling the firewall had no effect:

# /etc/init.d/firewall stop
Warning: Unable to locate ipset utility, disabling ipset support
 * Flushing IPv4 filter table
 * Flushing IPv4 nat table
 * Flushing IPv4 mangle table
 * Flushing IPv6 filter table
 * Flushing IPv6 mangle table
 * Flushing conntrack table ...
# wget -O - "http://ipv6.google.com" | head -n1
Downloading 'http://ipv6.google.com'
Failed to establish connection

A traceroute from LuCI also gives timeouts:

traceroute to openwrt.org (2a03:b0c0:3:d0::1af1:1), 30 hops max, 64 byte packets
 1  2a01:90a0:2ff:f000:ba69:f4ff:fe00:181a  2.627 ms
 2  *
 3  *
[repeating]
29  *
30  *

I've tried setting the "forward" rule for the WAN zone to "accept", but no luck.

An old post mentioned IPv6 forward rules, but those are already set by default:

# cat /etc/sysctl.d/10-default.conf 
[...]
net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1

Changing the LAN dhcp server IPv6 settings to use dhcp relay instead of dhcp server only caused the LAN not to even be able to ping IPv6 anymore. On the router itself it made no difference, which was to be expected, since the router's own traffic doesn't originate from the LAN.

As far as I can tell it can't be caused by firewall rules, unless I need to create a specific rule for forwarding traffic other than pings?

I'm just trying random things now, since I can't find similar issues online that I haven't seen yet, so any help would be greatly appreciated.

BTW, /128 is smaller than /64. /128 is a single IPv6 address. So, what I identified is not solved.

Perhaps, you can assign /64's from the /56 Prefix Delegation - as @jeff noted (FYI, a /56 provides 265 LAN-sized /64 subnets for your issuance :wink:)???

Your ISP can best explain; but the fe80 IP is the link local (hence your upstream router), the ones beginning with 2a01 are public and global. Just know it's not uncommon in IPv6 to have multiple IPs, from different subnets.

Yea, you are!

  • I'm trying to understand why you changed most of the settings you noted.
  • Wondering when you will configure your LAN for a /64

This and disabling the firewall could be dangerous, I'm not sure why you did this.

  • You may want to reset to defaults and begin with the PD suggestion - I honestly cannot follow all the steps you took
  • You may want to specify one of the public IPv6 addresses when testing ping, not interface

It may be that the IPv6 Address tha DHCPv6 gives to your router is non router. Even tho it looks like public.
That happens to my with my ISP. They give a "fake" IPv6 on the WAN which is the only IP which is routed to the "gateway" (their gateway) but that address can't ping anything else. If I create an interface with a public IPv6 from the Delegated Prefix, I can ping the whole wold but the gateway.

My solution? Create an interface wan2 and a hotplug script to generate SLAAC addresses from the delegated prefixes on LAN.

Thanks for the clarification on the prefix length. So if I understand it correctly, the prefix length is the number of bits from the start of the address that is used for routing, and the remaining bits are the available addresses for the hosts?

Anyway, I have reset the router again, and then set the LAN's "IPv6 assignment length" setting to /64.

See the green marked bits:
Screenshot_2019-10-28_223232
(IPv6 does make for a lot of sensoring..)

After the settings were applied I tested again.
From the router (pinging Google IP:

# ping6 -c2 2a00:1450:400e:80b::2004
PING 2a00:1450:400e:80b::2004 (2a00:1450:400e:80b::2004): 56 data bytes

--- 2a00:1450:400e:80b::2004 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

The laptop got a nice IP in that /64 range, but the same result when trying the ping.

ifstatus wan6 shows this:

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 2478,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604628,
			"valid": 2591828
		},
		{
			"address": "2a01:90a0::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604251,
			"valid": 2591451
		},
		{
			"address": "2a01:90a0:[...]:febb",
			"mask": 128,
			"preferred": 375522,
			"valid": 602322
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a01:90a0:1ff:fb00::",
			"mask": 56,
			"preferred": 375522,
			"valid": 602322,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a01:90a0:1ff:fb00::",
					"mask": 64
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591828,
			"source": "::\/0"
		},
		{
			"target": "2a01:90a0::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591451,
			"source": "::\/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1349,
			"source": "2a01:90a0:1ff:fb00::\/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1349,
			"source": "::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1349,
			"source": "2a01:90a0::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::1",
			"metric": 512,
			"valid": 1349,
			"source": "2a01:90a0::1:febb\/128"
		}
	],
	"dns-server": [
		"2a03:[...]::6",
		"2a03:[...]::7",
		"fe80::1"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a0381801001017400000000000000062a038180140100bb0000000000000007"
	}
}

I notice that the "nexthop" changed to "fe80::1".
When ping was working it was set to a full address "fe80::d6ca:6dff:fed8:5311".

Tomorrow I'll hook up my laptop to the ISP router directly again for a moment and save the network info. Maybe that will help in finding the difference. I'll throw in a traceroute or two for good measure.

@NoTengoBattery: You might be on to something, though I have been able to ping the web for a moment (but nothing else). I'll try to check this tomorrow.

Thanks for now. I'm off to dream about firewalls and lost packets..

Yes, /64 means the first 64 bits of 128 are the “subnet” for IPv6.

If you’re up for digging into things, installing tcpdump-mini on your router and Wireshark on your lap/desktop would be valuable tools. Configuring an SSH key for root on your OpenWrt box will make remote packet monitoring a lot easier.

The plot thickens.

This morning I connected my laptop directly to the ISP router, and I had no internet at all.
I checked that my network settings were on automatic, and I reconnected the cable a few times, but no luck. Weird.
The laptop got a DHCP lease, but that's about it. Even IPv4 didn't respond to pings. DNS resolution did work however.

I didn't have enough time to test everything, but I did save the network configuration.
It really did work this way before, unless I'm going slightly mad. Sadly I didn't save the config that time.

I'm going to ask my ISP for specific settings and clarification of the addresses.

In the meantime, here's the data I gathered this morning, in case it helps:

IP addresses

# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:90a0:[...]:fff0/128 scope global dynamic noprefixroute 
       valid_lft 604015sec preferred_lft 6415sec
    inet6 2a01:90a0::b0ae:[...]:cc1a/64 scope global dynamic noprefixroute 
       valid_lft 2591800sec preferred_lft 604600sec
    inet6 ::b83f:8b5:c23e:3c2d/64 scope global dynamic noprefixroute 
       valid_lft 2591800sec preferred_lft 604600sec
    inet6 fe80::eed0:668:1516:765e/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
For comparison: output when ping worked on router
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::6aff:[...]:2ccd/64 scope link 
       valid_lft forever preferred_lft forever
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:90a0:1ff:fb00::1/60 scope global dynamic 
       valid_lft 604406sec preferred_lft 377606sec
    inet6 fddb:b901:3a6f::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::6aff:[...]:2ccd/64 scope link 
       valid_lft forever preferred_lft forever
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 ::6aff:[...]:2cce/64 scope global dynamic 
       valid_lft 2591989sec preferred_lft 604789sec
    inet6 2a01:90a0::6aff:[...]:2cce/64 scope global dynamic 
       valid_lft 2591989sec preferred_lft 604789sec
    inet6 2a01:90a0:[...]:febb/128 scope global dynamic 
       valid_lft 604406sec preferred_lft 377606sec
    inet6 fe80::6aff:[...]:2cce/64 scope link 
       valid_lft forever preferred_lft forever

Analysing the addresses:
2a01:90a0:[...]:fff0/128
Type: Global unicast.
My public IP?

2a01:90a0::b0ae:[...]:cc1a/64
Type: Global unicast.
This looks like it could be my own public address (range), but the b0ae and the cc1a is different from what I got before.

::b83f:8b5:c23e:3c2d/64
Type: Deprecated, "Reserved by IETF"
So not really used?

fe80::eed0:668:1516:765e/64
Type: Link-Local unicast

Routers must not forward any packets with Link-Local source or destination addresses to other links.

So this address is only used between direct links and can't be used for internet access, correct?

Routes

# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
::/64 dev enp0s31f6 proto ra metric 100 pref medium
2a01:90a0:[...]:fff0 dev enp0s31f6 proto kernel metric 100 pref medium
2a01:90a0::/64 dev enp0s31f6 proto ra metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 100 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 proto ra metric 100 pref medium
default proto ra metric 20100 
	nexthop via fe80::d6ca:6dff:fed8:5311 dev enp0s31f6 weight 1 
	nexthop via fe80::1111:1111:1111:1111 dev enp0s31f6 weight 1 
	nexthop via fe80::ce1a:faff:fee4:9680 dev enp0s31f6 weight 1 
	nexthop via fe80::ce1a:faff:fee0:be00 dev enp0s31f6 weight 1 

The lack of global addresses makes me think this is not a complete routing table.
Compared to when ping worked, I am missing lines like these (from router):

default from ::/64 via fe80:[...]:5311 dev eth0.2  metric 512 
default from 2a01:90a0::1:febb via fe80:[...]:5311 dev eth0.2  metric 512 
default from 2a01:90a0::/64 via fe80:[...]:5311 dev eth0.2  metric 512 
default from 2a01:90a0:1ff:fa00::/56 via fe80:[...]:5311 dev eth0.2  metric 512 

As for TCPdump and Wireshark: I've worked with those before. It's a nice idea, but you need to know what to look for since there's often a whole lot of data passing through, especially if there's other devices using the network. I'd have to isolate the traffic to remove all the noise.
I might give it a go later, that tcpdump-mini does sound pretty neat. :slight_smile:

I found the cause of the issue, sorta.
TL;DR: The routing table uses the wrong gateways, looking for a way to fix that.

First I connected my laptop to the ISP router again.
After I changed the IPv6 address generation mode to "EUI64" and cloned the OpenWrt router's MAC address I was able to use IPv6 in all its glory.

Next I put the cable back in the OpenWrt router, and that worked too. I was even able to use IPv4 and IPv6 from my laptop without any issues!
This is kinda odd since I didn't change anything, but maybe my ISP had corrected something in my profile to get IPv6 working properly..

So I exported and saved all the settings and uploaded the settings I began this adventure with.
IPv6 stopped working, ports 80/443 were refused, and ssh recognised my old username but disconnected as soon as I used the correct password (I had root logins disabled).

After a reset I did some testing in LuCI while simultaneously monitoring the routing table and ping results.
Each time I did something that restarted the interface, the router would pick one of four different gateway addresses and use that in the routing table. Even with the same settings the gateway would sometimes be different.
Depending on the gateway address, IPv6 (internet) would or would not work.

These are the gateways I've seen used by the router:

  • fe80::1 - doesn't work. This one is chosen about 95% of the time.
  • fe80::d6ca:[...]:5311 - doesn't work
  • fe80::1111:1111:1111:1111 - works
  • fe80::ce1a:[...]:be00 - works

There's a few more I've seen assigned when I connected the laptop directly, all in that Local Link range.
Why this random gateway thing happens, I don't know, but the solution seems to be that I use a manual routing table or somehow force the gateway address.

After configuring a static WAN6 connection in /etc/config/network I managed to ping some IPv6 servers from the router only, but I didn't have time to build a proper configuration.
So now I'm looking for a way to translate this ifstatus output to a manual routing table/network configuration. Unless there is a way to force a specific gateway while still using DHCPv6?

Working configs:

ifstatus wan6
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 166471,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604261,
			"valid": 2591461
		},
		{
			"address": "2a01:90a0::6aff:[...]:2cce",
			"mask": 64,
			"preferred": 604795,
			"valid": 2591995
		},
		{
			"address": "2a01:90a0:[...]:febb",
			"mask": 128,
			"preferred": 211529,
			"valid": 438329
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a01:90a0:1ff:fb00::",
			"mask": 56,
			"preferred": 211529,
			"valid": 438329,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a01:90a0:1ff:fb00::",
					"mask": 64
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591461,
			"source": "::\/0"
		},
		{
			"target": "2a01:90a0::",
			"mask": 64,
			"nexthop": "::",
			"metric": 256,
			"valid": 2591995,
			"source": "::\/0"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ce1a:[...]:be00",
			"metric": 512,
			"valid": 1794,
			"source": "2a01:90a0:1ff:fb00::\/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ce1a:[...]:be00",
			"metric": 512,
			"valid": 1794,
			"source": "::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ce1a:[...]:be00",
			"metric": 512,
			"valid": 1794,
			"source": "2a01:90a0::6aff:[...]:2cce\/64"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ce1a:[...]:be00",
			"metric": 512,
			"valid": 1794,
			"source": "2a01:90a0::1:febb\/128"
		}
	],
	"dns-server": [
		"2a03:[...]::6",
		"2a03:[...]::7",
		"fe80::1"
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		"passthru": "001700202a0381801001017400000000000000062a038180140100bb0000000000000007"
	}
}
ip -6 route
default from ::/64 via fe80::ce1a:[...]:be00 dev eth0.2  metric 512 
default from 2a01:90a0:[...]:febb via fe80::ce1a:[...]:be00 dev eth0.2  metric 512 
default from 2a01:90a0::/64 via fe80::ce1a:[...]:be00 dev eth0.2  metric 512 
default from 2a01:90a0:1ff:fb00::/56 via fe80::ce1a:[...]:be00 dev eth0.2  metric 512 
::/64 dev eth0.2  metric 256 
2a01:90a0::/64 dev eth0.2  metric 256 
2a01:90a0:1ff:fb00::/64 dev br-lan  metric 1024 
unreachable 2a01:90a0:1ff:fb00::/56 dev lo  metric 2147483647  error -148
fd01:be2e:9211::/64 dev br-lan  metric 1024 
unreachable fd01:be2e:9211::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
unreachable default dev lo  metric -1  error -128
ff00::/8 dev eth0  metric 256 
ff00::/8 dev br-lan  metric 256 
ff00::/8 dev eth0.2  metric 256 
unreachable default dev lo  metric -1  error -128

I'm still figuring out how the output of ip -6 route relates to ifstatus wan6.
For example, take this line:
default from 2a01:90a0::/64 via fe80::ce1a:[...]:be00 dev eth0.2 metric 512
I can't find that in the ifstatus output.

Or take this route:

  "target": "::",
  "mask": 64,
  "nexthop": "::",
  "metric": 256,
  "valid": 2591461,
  "source": "::\/0"

To me this reads as "traffic from any source to any target should be routed through any gateway"? I probably understand this wrong, because why would such a route exist?

So yeah, I think if I can just understand what these routing rules mean, I should be able to translate that into a static routing table, possibly reconfigure the DHCP server for the LAN, and Bob would be my uncle.

P.S. I've mailed my ISP, but they haven't responded yet. Guess it goes a bit further than "I lost my password" :wink:

This route looks incorrect/redundant, although it might not be a critical issue.

Nope, see:

$ ipcalc ::/64
[...]
Network:	::/64
HostMin:	::
HostMax:	::ffff:ffff:ffff:ffff

https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv6

Okay, so that ::/64 is using the "Unspecified address"?
According to RFC 4291:

It indicates the absence of an address. [...] The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing headers. An IPv6 packet with a source address of unspecified must never be forwarded by an IPv6 router.

..so this does look a bit weird indeed.

As for this bit from ifstatus wan6:

  "target": "::",
  "mask": 64,
  "nexthop": "::",
  "metric": 256,
  "valid": 2591461,
  "source": "::\/0"

I missed the "mask": 64, in my previous comment.
So this uses ::/64 as target, and the "default route" as source, and then using :: again as gateway?
That's two "unspecified" addresses in this routing entry.

In the "Routing Management" section on this OpenWrt userguide page, it says:

Each delegated prefix is added with an unreachable route to avoid IPv6-routing loops.

Perhaps these two entries from ip -6 route and ifstatus are about that unreachable route?

I solved the issue!

At first I got it working by adding static routing in /etc/config/network so that the output of ifstatus wan6 would have the same routing table as when it was working ealier.
This worked, but then I noticed that my ISP doesn't always give me the same Prefix Delegation, so each time I restarted the interface I'd have to update the routing table.

The solution turned out to be really simple. The routing table contained 6 routes, but in the end they all said the same thing, which is "route this traffic through the ISP gateway".
So I added one route to /etc/config/network:

config route6
        option interface 'wan6'
        option target '::/0'
        option gateway 'fe80::ce1a:[...]:be00'
        option metric '512'

This worked for traffic from the router, but not yet for the LAN. This is because of the dynamic PD addresses. Disabling the WAN6 advanced setting "Use default gateway" solved this. In /etc/config/network it looks like this:

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'
        option reqprefix 'auto'
        option reqaddress 'try'
        option defaultroute '0'

That's it! IPv6 now works for all web traffic both from the router and LAN.
Now I can start re-adding the wifi accesspoint, configuring the IoT network, adding the VPN, rerouting DNS..

Thanks for your help. I've learned a lot. Hopefully I didn't cause other problems this way. So far it seems to be fine. :slight_smile:

and the ISP still hasn't responded to my e-mail..

@tmomas I wanted to add "[Solved]" to the title, but I don't have any options to edit the title?

2 Likes

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