[Solved] Troubleshooting no IPv6 connectivity with SLAAC

Installing and Using OpenWrt Network and Wireless Configuration
1

TL;DR

Problem:
No IPv6 connectivity despite valid addresses and routes from some wired/wireless clients.

Solution steps:

  • Double-check that ICMPv6 traffic can pass to the router (FW rule on OpenWRT and external switch configuration, if applicable)
  • MAC filter can mess with wireless packets, consider disabling it

I had an IPv6 tunnel setup running for years without issues. Now I switched to a new native, static network and got some issues regarding IPv6 connectivitity on clients that do not speak DHCPv6, i.e. rely on SLAAC.

Environment:
Public native dual statck with routed /48 IPv6 subnet on gateway (through WAN interface).
/52 IPv6 prefix assigned to OpenWRT box (no DHCPv6 or radvd in upstream, all configured using static routes).

Router runs OpenWRT 19.07.4

Issue is equally present on multiple similar configured bridge interfaces.
Both wired (through external, managed switch) and wireless clients partially work and do not work, so it's likely not the infrastructure.

Interfaces (extract):

config globals 'globals'
	option ula_prefix 'fd00:0:0:1000::/52'

config interface 'wan'
	option ifname 'eth1'
	option _orig_ifname 'eth1'
	option _orig_bridge 'false'
	option proto 'static'
	option gateway '***.***.***.1'
	list ipaddr '***.***.***.2/24'
	option ip6ifaceid 'eui64'
	option ip6gw 'fe80::1'
	option ip6prefix '2001:****:****:1000::/52'
	list ip6addr '2001:****:****:0::2/64'
	list dns '***.***.***.***'
	list dns '***.***.***.***'
	list dns '2001:****:****:****:****:****::****'
	list dns '2001:****:****:****:****:****::****'

config interface 'lan'
	option type 'bridge'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.101.1'
	option ip6assign '64'
	option ifname 'eth0.1'
	option ip6hint '101'

DHCP config (extract):

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

config dhcp 'lan'
	option interface 'lan'
	option leasetime '12h'
	option limit '50'
	option start '100'
	list dns '2001:****:****:1101::1'
	option ra_default '1'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'

Working clients:
Most clients (Linux, Windows, iOS) perform fine.

Client IP/route example:

$ ip -6 address show
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:****:****:1101::a24/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd00::1101:****:****:****:****/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2001:****:****:1101:****:****:****:****/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::****:****:****:****/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:****:****:1101::a24 dev eno1 proto kernel metric 100 pref medium
2001:****:****:1101::/64 dev eno1 proto ra metric 100 pref medium
fd00:0:0:1101::/64 dev eno1 proto ra metric 100 pref medium
fe80::/64 dev eno1 proto kernel metric 100 pref medium
default via fe80::**** dev eno1 proto ra metric 100 pref medium

Not working:
Some clients (Linux, Android) without DHCPv6 do receive valid IPv6 addresses (1-2 public, 1-2 ULA, 1 link local)

$ ip -6 address show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd00::1101:****:****:****:****/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2001:****:****:1104:****:****:****:****/64 scope global mngtmpaddr noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::****:****:****:****/64 scope link 
       valid_lft forever preferred_lft forever

$ ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:****:****:1101::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium
fd00:0:0:1101::/64 dev eth0 proto ra metric 202 mtu 1500 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::****:****:****:**** dev eth0 proto ra metric 202 mtu 1500 pref medium

On the client trying to ping the router (same for external address):

$ ping 2001:****:****:1101::1
PING 2001:****:****:1101::1(2001:****:****:1101::1) 56 data bytes
From 2001:****:****:1101:****:****:****:****: icmp_seq=1 Destination unreachable: Address unreachable
From 2001:****:****:1101:****:****:****:****: icmp_seq=2 Destination unreachable: Address unreachable
[...]
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
[...]

Simultaneous inspection with tcpdump and WireShark on the bridge interface shows repeated neighbor solicitation packets for public and link local address without responses.

636	2472.961068	2001:****:****:1101:****:****:****:****	ff02::1:ff00:1	ICMPv6	86	Neighbor Solicitation for 2001:****:****:1101::1 from **:**:**:**:**:**
637	2481.920958	fe80::****:****:****:****	fe80::****:****:****:****	ICMPv6	86	Neighbor Solicitation for fe80::****:****:****:**** from **:**:**:**:**:**
[...]

Thanks for any hints or thoughts on that issue!

Stefan

2

Remove this from wan.

Is there something in common for the non working hosts? Some switch or access point between them and the OpenWrt?

3

Don‘t even know why the eui64 is configured here :thinking: Good point, but doesn’t change my problem.

The wired clients are connected through one switch hop (the 4 built in ports are only upstream for 4 different VLANs), the wireless clients are connected directly to the radio on the OpenWRT router.
I will try to get one direct wired connection tomorrow to be sure.

Only common difference to the working clients I see right now is the lack of DHCPv6 support. Two Raspbian 10, some Android 10/11, one Arch. Already disabled local firewalls. IPv6 in general is OK with LTE connections.

On most clients (Fedora 32/33, RHEL 7/8, Debian 10, Win10) connections using DHCP, SLAAC and statically assigned secondary/ternary addresses work well.

4

I recall some similar topic with the intermediate switch being the culprit due to snoopings.

5

Read about this, too. Thought I took care about it, but apparently I was wrong... :neutral_face:
Nevertheless thanks for reminding me on that, re-checking solved half of my problems.

Wired: solved

Just connected one failing device directly to the router port => everything fine. I have added corresponding firewall rules for the zones of VLAN 2-4 (router input only for ICMP/DNS/DHCP/... on these networks) and never took care of the switch (or I did, but forgot to persist the configuration, so it was gone after some reboot)

All clients working after ICMPv6 packets are no longer blocked. The switch (L2 managed) indeed has DHCP and IGMP snooping configured. Explicitly allowing ICMPv6 forwarding to the router resolves my connection issues. VLANs 2-4 affected, apparently all working wired clients lived in 1...

Wireless: open
Some clients work (e.g. Fedora laptop, iPad), others (macOS laptop, Android phone) show the exact same behavior as described above.

IGMP snooping is turned off on the bridge interfaces (known issues) and there is no other AP involved.

6

All wireless clients connect directly on the Wifi of the router? There is no third party access point or another switch on the path of the wireless client to the router?

7

Currently the OpenWRT router is the only WiFi AP in the network, so all clients use the same, direct connection.

Two sets (2,4/5GHz) of 3 equally configured networks bridged to VLAN 1,3 and 4.

Wireless configuration 
config wifi-device 'radio0'
	option type 'mac80211'
	option hwmode '11a'
	option distance '8'
	option htmode 'VHT80'
	option country 'DE'
	option channel '36'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option legacy_rates '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option country 'DE'
	option distance '8'
	option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
	option htmode 'HT40'
	option legacy_rates '0'
	
config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'ap'
	option ssid '*****'
	option key '*****'
	option network 'lan'
	option macaddr '**:**:**:**:**:**'
	option encryption 'sae-mixed'
	option ieee80211w '1'
	option disassoc_low_ack '0'
	option macfilter 'allow'
	list maclist '**:**:**:**:**:**'
	[...]

config wifi-iface 'wifinet1'
	[same wifinet0, but radio1]


config wifi-iface 'wifinet{2-5}'
	[pairwise same as 0/1, with different "network" and without MAC filter]
8

The distance is way too short. I think the rule is double the distance of the furthest client times 2, but it doesn't hurt to multiply by 3.
Other than that I don't see anything weird there, are you sure that Android or Linux is not using ephemeral mac addresses? Try to disable mac filter, it is useless anyway.

9

My test clients are ~2m away, so 8 should be fine in this case. Network will be extended anyway, so this is subject to change. Clients use their real MACs, i.e. privacy mode is disabled.

Filter is disabled on all 3 networks now and et voilà, it works!
Setting is more of a legacy artifact, you're absolutely right about the (non)sense in terms of security, so I'm fine without it.

Thanks again for your hints, never thought of a correlation with the filter.

1 Like
10

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.

11

Apparently it is. Verified on 3 different clients that refused connection before :slight_smile:

1 Like
12

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