Strange IPv6 behavior, and connectivity issues

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello,
I've been having an issue with IPv6 connectivity on my client devices recently. I'm not sure when it started but it used to work as expected at least a week ago and worked by default with a fresh install.
Pings and connections from the router to IPv6 addresses work as expected. However, connections from lan using IPv6 do not reach wan. I am not receiving any route errors, and DHCP is communicating with the clients for IPv6 connectivity.

Im hopeful that someone could assist me in the right direction, because ive sinked several hours into this with no change.

IPv4 is much simpler than IPv6 in my understanding. So I fail to grasp some of the concepts of IPv6 at this time, like why my device says it has 5 IPv6 assigned. I've attempted to follow about 7 different posts on OpenWRT forums and could not get a solution.

My ISP (Charter) automatically assigns a /64 to the router, but allows a /56 on request, which I currently have setup. Setup is a simple connection of the router to ISP's modem, and out to their network.

  • Traceroute on client gives a strong attempt, but only returns *s ( 1 * * *, 2 * * *, etc).
  • Default ICMPv6 rules are enabled
  • I can ping the router using IPv6 from the client (ping6 fdc8:5211:f5d0::1)
  • Traceroute6 from client to router works as expected, with only one hop.

LAN Status on Luci:

  • IPv4: 192.168.1.1/24
  • IPv6: 2600:6c48:523f:XXXX::1/64
  • IPv6: fdc8:5211:f5d0::1/64

WAN6 Status on Luci:

  • IPv6: 2600:6c48:700a:800:482f:71e1:YYYY:YYYY/128
  • IPv6-PD: 2600:6c48:XXXX:XXXX::/56

IP's pulled by client:

    inet6 fe80::1c99:b2ea:2e61:14cf%en0 prefixlen 64 secured scopeid 0x4 
	inet6 2600:6c48:XXXX:XXXX:f0:3cc8:4f21:8979 prefixlen 64 autoconf secured 
	inet6 2600:6c48:XXXX:XXXX:c4e9:27:9acc:2729 prefixlen 64 autoconf temporary 
	inet6 fdc8:5211:f5d0:0:1cd9:e9a3:45be:f56e prefixlen 64 autoconf secured 
	inet6 fdc8:5211:f5d0:0:6df3:4d2f:41af:7719 prefixlen 64 autoconf temporary

/etc/config/dhcp:

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

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'

/etc/config/network

config globals 'globals'
	option ula_prefix 'fdc8:5211:f5d0::/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'

config interface 'wan'
	option ifname 'eth1.2'
	option proto 'dhcp'
	option peerdns '0'
	list dns '127.0.0.1'
	list dns '1.1.1.1'

config interface 'wan6'
	option ifname 'eth1.2'
	option proto 'dhcpv6'
	option reqprefix '56' #set because ISP by default likes to issue a /64, but is willing to issue a /56

Route info (ifstatus wan6)

"route": [
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::201:5cff:fea2:3646",
			"metric": 512,
			"valid": 8997,
			"source": "2600:6c48:523f:XXXX::/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::201:5cff:fea2:3646",
			"metric": 512,
			"valid": 8997,
			"source": "2600:6c48:700a:800:482f:71e1:YYYY:YYYY/128"
		}
	],
2

Well, you have no lan6 interface in /etc/config/network. That might explain your IPv6 connectivity issues. At least you're seeing a ULA and a WAN routable address on your client, so address assignment is working clearly.

Adding this and then reloading the network service should get you going probably:

config interface 'lan6'
        option ifname '@lan'
        option proto 'dhcpv6'
        option reqprefix 'no'
1 Like
3

Thanks for your response!
I added that to my network config, and reloaded the service. I had no change in connectivity, so I went ahead and rebooted the router and reset my network card on my laptop just as a sanity check. Still no change.
I also don't recall having an alias setup for lan6 previously when IPv6 was working as expected, but maybe I am misremembering.

I wasn't sure how the firewall handled aliases, so I also assigned it to the lan firewall zone.

The new Lan6 status is:

  • IPv6: fdc8:5211:f5d0::1/64
  • IPv6: 2600:6c48:523f:XXXX::8c6/128
  • IPv6: fdc8:5211:f5d0::8c6/128

Edit:

After a short wait the new interface status removed the local addresses, and instead changed to:

  • IPv6: 2600:6c48:523f:XXXX:c441:1eff:fe32:2ebc/64
  • IPv6: 2600:6c48:523f:XXXX::942/128
  • IPv6: 2600:6c48:523f:XXXX:c441:1eff:0:942/128
4

Any difference with e.g. ping6 or traceroute6 after you reload your firewall?

1 Like
5

I went to check, and suddenly everything is working again. It took roughly 30 minutes but now my clients have connectivity. Not sure if the DHCP server or something on the clients was caching invalid values.

Thanks for your help! Not sure why after a reboot it wasn't working for a while.

Quick question, does that mean any other vlan also would need the alias in order to start functioning?

1 Like
6

I think for your LAN to work, no. But for routable IPv6, it might be needed.

1 Like
7

Thanks!

A issue has popped up, the stability of the IPv6 is questionable. Without any config changes, the IP's swap back to post #3 with the original status before the edit, causing the connectivity to fail. It does sometimes work, and the client still shows all the IPs. When the connectivity was working correctly, the ULA addresses didn't appear on the client's assigned IP list.

Edit:
I'm wondering if this is actually some kind of routing error.
From what I understand with IPv6 every device is meant to have it's own address (no NAT like IPv6). So the router submits a request to my ISP for a "PD" allocation, which allows multiple subnets worth of IPv6 addresses, and means that the ISP should then route everything in my allocation to my router, and anything from my allocation to it's destination based off their routing policies.

If its the case that I can see my PD allocation in Luci, and I can see my end clients being allocated an IPv6 address. Plus my end clients are told they have a route to the internet but are not receiving any rejections or data back, that either some weird routing error is occurring in OpenWRT or within my ISP? I wonder this because the ISP is issuing a /128 IPv6 directly to my router, but also issuing a PD. So both OpenWRT and my ISP understand how to handle the /128, but something is getting messed up when it comes to addresses allocated under the PD? Not an expert, just been digging for nearly 6 hours at this point to figure out whats going on.

Edit2:
The connectivity issues don't seem to be dependent on the devices. One device can have IPv6 connectivity while another doesn't. They can also both have access or also both lose access randomly.

8

From what I understood your ISP WAN address (a /128 is effectively a single address) can (but should not necessarily) be within the prefix they are giving you. The prefix is then used to give routable addresses to your clients through prefix delegation, afaik.

ULA addresses aren't routable, they're just for LAN use. Shouldn't matter much. Like your print shows apparently the fe80: address as your route (which is to be expected I've been told). IPv6 has a duplicate address detection (DAD) in place so you shouldn't have any clashes there either.

I assume all your devices get their IPv6 addresses the same way? Any differences in OS/... etc.? Android apparently doesn't support DHCPv6, e.g.

9

ISP WAN address (a /128 is effectively a single address) can (but should not necessarily) be within the prefix they are giving you.

My ISP WAN address is a /128 separate prefix 2600:6c48:700a:800:482f:71e1:yyyy:yyyy/128, while my PD delegation is 2600:6c48:523f:xx00::/56.
The lan interface is allocated a /64 (2600:6c48:523f:xx00::1) from the /56 by OpenWRT (aka not static set), and the clients in the lan zone are being allocated addresses in the interface's /64.
I'm using iOS, MacOS, and Windows for client testing. My roommate has an android device but I don't really have that IPv6 support as a priority. Either way I have stateless and stateful enabled, and all my clients are being assigned unique IPs. I'm assuming iOS and MacOS don't have any significant different network handling when it comes to routing or allocation.

One possible pattern that I have noticed is that the lan interface lists 2600:6c48:523f:xx00:: as the prefix its assigned to use, but the clients that actually have connectivity under it typically display a 2600:6c48:523f:xx01:: address. When the device decides to use a 2600:6c48:523f:xx00::prefix the networking doesn't work. May be a red herring, but also may be something?
Edit: Just confirmed that pattern, Was able to get MacOS to pull a new IPv6 address, and this time it pulled from the xx00, and I lost connectivity on the device. When I was able to convince it to pull again and seemingly randomly it pulled a xx01, connection was restored.

10

So I was wondering if something weird was going on in the routing of OpenWRT and played around, and while I am not sure of the implication of my change it did appear to fix my problem.

So I noticed that anytime a device assigned a IPv6 in the 2600:6c48:523f:xx00:: prefix, that the connectivity failed. However, when it assigned a 2600:6c48:523f:xx01:: the connection worked as expected.

So out of a random hunch I decided to remove the IPv6 assignment length from lan option ip6assign '64'. Then clients on the 2600:6c48:523f:xx00:: prefix started to work as expected.

I'm confused because I expected ip6assign to assign a /64 block to be used by any clients on the interface. However if that was meant to be the case, why when it was set and supposed to be using 2600:6c48:523f:xx00::, clients were being randomly assigned to 2600:6c48:523f:xx01::?

I really don't understand whats going on here, because things don't seem to be following expected behavior as listed in Wiki's IPv6 start guide. I'd prefer to stay inline of the expected behavior and get the /64 block working on the interface as suggested. Wonky workarounds only go so far.

11

The 00, 01, ... numbering happens when an IP address expires (you should see something like 'obsolete' or 'deprecated' next to it. That's normal. IPv6 will keep these around for some time to inform other clients addresses have changed, apparently.

So your ipv6assign setting is now empty altogether? I set a /60 (I have a /56 prefix from my ISP).

I'm still new to the whole IPv6 configuration thing as well. Luckily a friend knows his way around a bit, otherwise I'd still be banging my head against the wall as well.

12

Setting ipv6assign to disabled allowed any traffic from 00 to actually reach the WAN. When it was reenabled any traffic from 00 lost connectivity. This is weird because the 00 is what is actually assigned to the interface.

The reason why I don't want to keep this setting is because I want to follow the suggested settings laid out by OpenWRT, and make it easier to assign specific blocks to separate vlans. I'm currently ignoring the other vlans until I get the lan working.

1 Like
13

So through frustration I started playing with every single possible setting available. Eventually, I enabled IGMP Snooping on the interface and things seemed to be working. I couldn't find any correlation between IGMP snooping and IPv6 connectivity in docs.
I guess IGMP snooping is needed for IPv6 multicast configuration data. However that doesn't explain why my devices seemed to be configuring just fine. Maybe this has something to do with the way OpenWRT routes IPv6 data? I'm really not too sure.
This is either a fluke or a temporary moment of connectivity, but all my devices seem fine now. I have no clue why, or whats going on with this.. But I am going to keep testing for a while and see if its now stable

14

So suddenly Wan6 began failing to utilize IPv6 and recognize any allocations, used an old tomato router and found everything worked fine. Not sure why this is happening. I wondered if something broke when flashing the new version a week or so ago.

I've given up, I reverted back to a backup of 10.7.3 where everything seemed to be working fine. Since my upgrade to 10.7.5 I've had a ton of random issues, IPv6 connectivity, random service connection errors, dnscrypt was struggling to remain stable. I'm gonna wait until a new major release and manually upgrade everything. I'm sure most of this is my own fault, but I doubt that my configs should just completely fail to work when going from 10.7.3 -> 10.7.5. Gonna stick with the old version and not satisfy my urge to stay up-to-date.

OpenWRT has been great, but the recent random issues since my upgrade has just been a nightmare. Gonna stick with what worked well. Hopefully no one else is having this issue and comes to this post for a solution. Hopefully I'm not exploited through the security fixes in 10.7.5

Thank you very much @Borromini, I greatly appreciate all your help so far.

15

Happy to help even though it didn't work out in the end.

Is this on master or 19.07? I see there were some DHCPv6 fixes committed to the master tree today.

16

OpenWrt 19.07.5, r11257-5090152ae3

17

Okay, I couldn't let this not bother me. Flashed a fresh version of OpenWrt 19.07.5 r11257-5090152ae3.
The default config that comes with OpenWRT continues to have connectivity issues. The fresh install picked up my ISP's /56 automatically, and its old IPv6 /128 for router connectivity. Clients are being issued IPs correctly and v6 connectivity to the router is working like normal, but connectivity to WAN is still failing.
Could this be some kind of bug? I'm really not sure how a complete fresh install (other than renaming my Wi-Fi and adding a password) is still not working. Interesting enough, enabling IGMP snooping does allow connectivity, but isn't on by default. I'm also interested in forwarding multicast and my understanding is that enabling snooping can break multicast forwarding across zones using smcrouted.

18

I don't think your configuration is correct.

config interface 'lan6'
        option ifname '@lan'
        option proto 'dhcpv6'
        option reqprefix 'no'

This means there is a DHCPv6 server at LAN side and you are trying to request IPv6 addresses from it.

1 Like
19

I am also with Spectrum and I also request a /56 prefix with no problem, have you tried a different modem?

20

I am also with Spectrum and I also request a /56 prefix with no problem, have you tried a different modem?

I receive a /56 with no issues, as far as I can tell everything seems to be working fine on my ISP side. My problem is that LAN clients are having a connectivity issues when using v6. I mention the /56 to show the proper PD delegation from my ISP.

I don't think your configuration is correct.

Through further testing I discovered that didn't make a difference, so in the end I removed it. Doesn't matter now as I have flashed fresh. I also noticed the DHCPv6 server just received an IP already assigned to the interface.