Added a zone, and now IPv6 is not working right

Installing and Using OpenWrt Network and Wireless Configuration
1

This is going to be a bit long, because I want to include all of the relevant information. TL;DR, IPv6 was working great, until I screwed it up by adding a new zone.

My setup is somewhat complex, but not strange. I have an Archer C7 v2 running OpenWRT 19.07.5. It is the router for my home network behind a bridging cable modem connecting to Comcast Business. The OpenWRT is (mostly) just a router, and I use a Ubiquiti AC-PRO for wireless. (The OpenWRT router does do 802.11b class wifi for some very old devices, so I don't slow down my main wifi).

Everything, including IPv6 worked perfectly with a a single LAN zone. I got a /56 from Comcast, and the router made a /64 for the LAN. Using DHCPv6 and slaac internal devices got an IPv6 address, their name went into the routers DNS, and IPv6 worked great on the internal network, and talking to the rest of the world.

Then I decided it was time to create an IOT zone, because it's called the internet of shitty things for a reason. I created a new IOT zone which can reach the internet, but not the LAN zone. The LAN zone can connect to IOT, though. The 802.11b on OpenWRT is now connected to the IOT zone, and I use a VLAN to the AC-PRO with multiple SSIDs connecting to the appropriate zone.

That all works perfectly for IPv4. DHCP hands out addresses on the right subnet depending on which SSID a device connects to. Devices can reach, or not reach, what they're supposed to etc. No problems.

Now the problem

IPv6 almost works. The router gives a different /64 to the LAN and IOT zones, as expected. Devices joining the network get an IPv6 address, but then things are weird. IPv6 routing does not work right away. Pinging the router's IPv6 address associated with the zones /64 will get things going. My Android phone, which famously only does slaac, gets an address, but then after awhile loses it.

Just to be even more weird, IPv6 on the IOT network works fine. If I connect a device to that network, it can immediately start using IPv6, without having to ping the router first.

Obviously I've messed something up, but I can't figure out what it is. Having to ping the router before IPv6 works is mentioned on other problem reports, but none of the solutions worked for me.

Below are my /etc/config/firewall and /etc/config/network. I hope somebody else can see where I've made a mistake, or suggest things to try. If any other information will be useful in sorting this out, please let me know.

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 'fda1:d876:0d93::/48'

config interface 'lan'
	option type 'bridge'
	option ifname 'eth1.1'
	option proto 'static'
	option ipaddr '192.168.169.6'
	option netmask '255.255.255.0'
	option ip6assign '64'
	option stp '1'
	option ip6hint '01'

config interface 'wan'
	option ifname 'eth0.2'
	option proto 'dhcp'
	list dns '1.1.1.1'
	list dns '1.0.0.1'
	option peerdns '0'

config interface 'wan6'
	option ifname 'eth0.2'
	option proto 'dhcpv6'
	list dns '2606:4700:4700::1111'
	list dns '2606:4700:4700::1001'
	option reqaddress 'try'
	option peerdns '0'
	option reqprefix '56'

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

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

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 6t'
	option vid '2'

config interface 'modem'
	option ifname 'eth0.2'
	option proto 'static'
	option ipaddr '192.168.100.10'
	option netmask '255.255.255.0'

config interface 'iot'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.170.1'
	option netmask '255.255.255.0'
	option ifname 'eth1.3'
	option stp '1'
	option ip6assign '64'
	option ip6hint '02'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '3'
	option ports '0t 4t'

Some of these entries may be redundant, as I'm trying to make sure that all ICMP messages can pass.
firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '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 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

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'

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'

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'

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'

config include
	option path '/etc/firewall.user'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport '80'
	option dest_ip '192.168.169.3'
	option dest_port '80'
	option name 'http'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport '443'
	option dest_ip '192.168.169.3'
	option dest_port '443'
	option name 'https'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport '22'
	option dest_ip '192.168.169.7'
	option dest_port '22'
	option name 'ssh'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport '23'
	option dest_ip '192.168.169.3'
	option dest_port '23'
	option name 'ssh shiner'

config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp udp'
	option src_dport '32400'
	option dest_ip '192.168.169.3'
	option dest_port '32400'
	option name 'plex'

config rule
	option dest_port '22-23'
	option src 'wan'
	option name 'IPv6 SSH'
	option dest 'lan'
	option target 'ACCEPT'
	option proto 'tcp'
	option family 'ipv6'

config rule
	option dest_port '80 443'
	option src 'wan'
	option name 'IPv6 Web'
	option dest 'lan'
	option target 'ACCEPT'
	option proto 'tcp'
	option family 'ipv6'

config rule
	option dest_port '667'
	option src 'lan'
	option name 'darkstat'
	option target 'ACCEPT'
	list proto 'tcp'

config include 'miniupnpd'
	option type 'script'
	option path '/usr/share/miniupnpd/firewall.include'
	option family 'any'
	option reload '1'

config zone 'iot'
	option name 'iot'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option network 'iot'

config forwarding 'iot_wan'
	option src 'iot'
	option dest 'wan'

config rule 'iot_dns'
	option name 'Allow-DNS-IOT'
	option src 'iot'
	option dest_port '53'
	option proto 'tcp udp'
	option target 'ACCEPT'

config rule 'iot_dhcp'
	option name 'Allow-DHCP-IOT'
	option src 'iot'
	option dest_port '67'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6-IOT'
	option family 'ipv6'
	list proto 'udp'
	option src 'iot'
	option dest_port '547'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6-LAN'
	option family 'ipv6'
	list proto 'udp'
	option src 'lan'
	option dest_port '547'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMP-IOT'
	option src 'iot'
	option proto 'icmp'
	option target 'ACCEPT'
	option family 'ipv6'

config forwarding
	option src 'lan'
	option dest 'iot'

config rule
	option family 'ipv6'
	list proto 'icmp'
	option target 'ACCEPT'
	option src 'lan'
	option name 'Allow-ICMP-LAN'

config rule
	option name 'WAN Block'
	option src 'lan'
	list src_ip '192.168.169.8'
	list src_ip '192.168.169.22'
	option dest 'wan'
	option target 'DROP'

config rule
	option name 'ICMP Allow'
	list proto 'icmp'
	option target 'ACCEPT'
	option dest '*'
	option limit '1000/second'

config rule
	option name 'ICMP Try'
	option family 'ipv6'
	list proto 'icmp'
	option src 'lan'
	option dest 'lan'
	option target 'ACCEPT'

I've left out config host sections.
dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option local '/lan/'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option domain 'example.com'
	option nonwildcard '0'
	option tftp_root '/storage/tftpboot'
	option enable_tftp '1'
	option cachesize '500'
	option dhcp_boot 'grubx64.efi'
	option proxydnssec '1'
	list server '/ntp.org/1.1.1.1'
	list server '/ntp.org/2606:4700:4700::1111'
	list server '0::1#5453'
	list server '127.0.0.1#5453'
	option noresolv '1'
	option nonegcache '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '1h'
	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'

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

The only thing that I would change is to add a tag on port 4 for vlan1 on both sides.
Apart from that post also the following: ip -6 addr; ip -6 ro; ip -6 ru; ifstatus wan6

3

The output of those commands are below. I've anonymized things consistently, so it should be possible to see when the same address is referred to.

I can add a vlan tag on port 4, but port 4 plugs directly into an unmanaged switch, where all of the devices should be on the LAN vlan. Port 3 connects to the AC-PRO, which does understand vlans, and has various SSIDs on the proper vlan.

Thanks for looking at this. I hope you can see something obvious, which points to an easy to fix error on my part.

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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f6f2:6dff:fe70:3133/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f6f2:6dff:fe70:3132/64 scope link 
       valid_lft forever preferred_lft forever
12: br-iot: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fda1:d876:d93:2::1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2601:zz:yy:7202::1/64 scope global dynamic noprefixroute 
       valid_lft 263778sec preferred_lft 263778sec
    inet6 fe80::f6f2:6dff:fe70:3132/64 scope link 
       valid_lft forever preferred_lft forever
16: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fda1:d876:d93:1::1/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2601:zz:yy:7201::1/64 scope global dynamic noprefixroute 
       valid_lft 263778sec preferred_lft 263778sec
    inet6 fda1:d876:d93:169::1/64 scope global deprecated dynamic noprefixroute 
       valid_lft 296sec preferred_lft 0sec
    inet6 fda1:d876:d93::1/64 scope global deprecated dynamic noprefixroute 
       valid_lft 244sec preferred_lft 0sec
    inet6 2601:zz:yy:7200::1/64 scope global deprecated dynamic noprefixroute 
       valid_lft 296sec preferred_lft 0sec
    inet6 fe80::f6f2:6dff:fe70:3132/64 scope link 
       valid_lft forever preferred_lft forever
18: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:zz:yy:xx:ww:vv:uu:fb06/128 scope global dynamic noprefixroute 
       valid_lft 263779sec preferred_lft 263779sec
    inet6 fe80::f6f2:6dff:fe70:3133/64 scope link 
       valid_lft forever preferred_lft forever
34: ifb4eth0.2: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 state UNKNOWN qlen 32
    inet6 fe80::9083:32ff:fe85:fc26/64 scope link 
       valid_lft forever preferred_lft forever
38: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::f6f2:6dff:fe70:3132/64 scope link 
       valid_lft forever preferred_lft forever

ip -6 ro

default from 2001:zz:yy:xx:ww:vv:uu:fb06 via fe80::201:5cff:fe87:e46 dev eth0.2 proto static metric 512 pref medium
default from 2601:zz:yy:7200::/56 via fe80::201:5cff:fe87:e46 dev eth0.2 proto static metric 512 pref medium
2601:zz:yy:7201::/64 dev br-lan proto static metric 1024 pref medium
2601:zz:yy:7202::/64 dev br-iot proto static metric 1024 pref medium
unreachable 2601:zz:yy:7200::/56 dev lo proto static metric 2147483647 error 4294967148 pref medium
fda1:d876:d93:1::/64 dev br-lan proto static metric 1024 pref medium
fda1:d876:d93:2::/64 dev br-iot proto static metric 1024 pref medium
unreachable fda1:d876:d93::/48 dev lo proto static metric 2147483647 error 4294967148 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0.2 proto kernel metric 256 pref medium
fe80::/64 dev br-iot proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev ifb4eth0.2 proto kernel metric 256 pref medium
fe80::/64 dev wlan1 proto kernel metric 256 pref medium

ip -6 ru

0:	from all lookup local 
32766:	from all lookup main 
4200000000:	from 2601:zz:yy:7201::1/64 iif br-lan unreachable
4200000000:	from 2601:zz:yy:7202::1/64 iif br-iot unreachable
4200000001:	from all iif lo failed_policy
4200000012:	from all iif br-iot failed_policy
4200000016:	from all iif br-lan failed_policy
4200000018:	from all iif eth0.2 failed_policy
4200000018:	from all iif eth0.2 failed_policy
4200000018:	from all iif eth0.2 failed_policy

ifstatus wan0

{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 128951,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "2001:zz:yy:xx:ww:vv:uu:fb06",
			"mask": 128,
			"preferred": 263746,
			"valid": 263746
		}
	],
	"ipv6-prefix": [
		{
			"address": "2601:zz:yy:7200::",
			"mask": 56,
			"preferred": 263746,
			"valid": 263746,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2601:zz:yy:7201::",
					"mask": 64
				},
				"iot": {
					"address": "2601:zz:yy:7202::",
					"mask": 64
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::201:5cff:fe87:e46",
			"metric": 512,
			"valid": 1798,
			"source": "2601:zz:yy:7200::/56"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::201:5cff:fe87:e46",
			"metric": 512,
			"valid": 1798,
			"source": "2001:zz:yy:xx:ww:vv:uu:fb06/128"
		}
	],
	"dns-server": [
		"2606:4700:4700::1111",
		"2606:4700:4700::1001"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			"2001:558:feed::1",
			"2001:558:feed::2"
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"passthru": "0017002020010558feed0000000000000000000120010558feed00000000000000000002"
	}
}
4

I meant this port 4, which is tagged on vlan 3 too.

The other suspicious thing is the deprecated route you have on lan interface. I suppose that before the iot interface you were using the 7200 prefix and then you used the ip6hint 01 which changed the advertised prefix to 7201. Maybe some hosts didn't yet update their addresses accordingly and they might still use the deprecated address of the lan interface for nameserver.
By the time you read this it must be retracted from the hosts as expired, since the timer was 296 sec.
Verify that all hosts have the correct address and do a reboot if necessary.

5

This is really confusing me. I had to draw a picture. The ports are listed in the order they are shown in luci, which is apparently different than the ports ID in the config file. I think I have the order correct.

         LAN   WAN   IOT
ID Name  VLAN1 VLAN2 VLAN3 Purpose
0  eth1  tag   off   tag   CPU
6  eth0  off   tag   off   CPU
2  LAN 1 unt   off   off   unused
3  LAN 2 unt   off   off   unused
4  LAN 3 unt   off   tag   managed wifi, unmanaged wired
5  LAN 4 unt   off   off   unmanaged wired
1  WAN   off   unt   off   to cable modem

So you are saying I should change 4 (LAN 3, physical port 3) to be tagged on both vlan 3 and vlan 1? What I want is for untagged traffic coming in on 4 to be on the vlan 1 segment. I thought I did that by leaving the vlan untagged, but my understanding of vlans is...not good.

I tried tagging 4 for both vlan 1 and 3, and I got some kind of error. Unfortunately I did not get a look at it, and then OpenWRT reverted to the original setting.

That's pretty much exactly what happened. I restarted networking on everything that hadn't already had it restarted, and the route has gone and not comeback.

Running tcpdump -n -i <dev> icmp6 on wireless (port 4 via AC-PRO wifi) and wired (port 5 via unmanaged switch) has shown me the problem, though I'm not sure what exactly is causing it, or how to fix it. On the wired computer I see router advertisements

IP6 fe80::f6f2:6dff:fe70:3132 > ff02::1: ICMP6, router advertisement, length 176

On the wireless computer I do not see them. I see neighbor related traffic, but not router advertisements. Why would router advertisements not show up?

Running tcpdump on the router on either br-lan or eth1.1 both show router advertisements that never make it to my wireless interface.

6

That is correct. Change VLAN1 to be tagged both on LAN3 and the AC PRO.
Is there any switch between the AC and the router?
If you don't feel comfortable with vlans, create another untagged vlan99 on AC PRO with some static IP to be able to manage it from a PC without vlans.

Do the change connected from the other ports, not connected to the AC PRO. If you change the setting from the AC PRO port and your browser loses communication with the Luci due to vlan mismatch, then it will revert to the original setting. But first do the configuration on the AC PRO, then on OpenWrt.

Connect the wired PC temporarily on LAN3 and verify that you see the RAs in tcpdump. I think you'll see them and most likely the problem will be on AC PRO not forwarding them properly.

7

No, but there is an unmanaged switch after the AC-PRO, so it does need to send untagged packets to the default vlan. The AC-Pro has two bridged ethernet ports, plus the radios, however, I can't control the tagging on the ports with the resolution possible on OpenWRT. (The AC-PRO does provide the same wireless coverage that was previously done by three access points, with better speed and reliability, so I think it does make a great AP, but possibly not usable in a complex and mixed vendor environment.)

Yes, this is exactly what happened.

I agree, and am thinking it is an interaction between the AC-PRO and the OpenWRT, not that their incompatible, but that I'm not getting the settings correct to make them both work together.

With Unifi, it appears that the network named LAN cannot be assigned a VLAN, it is just the default. I think what I have to do is create a new tagged network on Unifi for trusted clients, along with the IOT, and eventually guest VLANs. I'm not sure how exactly the AC-PRO will handle untagged traffic, so this will require a bit of experimentation.

For now though, unfortunately, I've had to revert because the broken IPv6 network was causing problems. <rant mode> For some reason, even though my phone has perfectly good IPv4 networking, when the IPv6 network is down it will not do wifi calling. No idea why, because it works when IPv6 is simply missing. Without wifi calling, even though I have plenty of mobile signal, AT&T sends half my calls straight to voicemail. That is not a good situation when working at home.

Anyway, thank you so much for your help. I do think you got to the core problem. Hopefully I'll get a chance to play with this stuff when it doesn't matter if I can receive calls, and nobody will be upset about the network going up and down.

8

You don't need to do that. I have two AC-Lite and I am not using the default network, which I renamed to void

image
image905×278 5.87 KB

My main network is trendy and it is tagged
image
image825×759 16.2 KB

Just make sure that all options there are disabled. I have filled in only the gateway IP/Mask.

9

Finally got everything back to stable and working. Everything had been working before, but in the messing with Unifi settings I broke something. I originally had some settings in Unifi from a few years ago when I'd experimented with a Unifi router that I could not set back to the way I had them, because I do not currently have a Unifi router. Miracle it ever worked at all.

The key thing with Unifi seemed to be disabling "Auto-Optimize Network" under the "Site" section of the Classic Settings. Optimize network blocks some broadcast traffic or something, which made slaac very unreliable. Other things it does like band steering don't seem to make any difference.

So now that everything is working, I'm in a position to start making changes again, one at a time, and validate that everything works each time. The biggest hurdle is finding a time when I can break things that won't cause screams to emanate from around the house.

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

I remember rolling back the auto-optimize and all other auto-this, auto-that to have all clients connecting without issues.