While it's not a solution that's still really helpful info, thanks. That also explains why there's no outbound packets being caught in the pcap - there's just nowhere for them to go apparently.
For anyone playing along at home, the diagnosis dump script is now up to this point:
dig @127.0.0.1 google.com
dig @1.1.1.1 google.com
dig +tcp @127.0.0.1 google.com
dig +tcp @1.1.1.1 google.com
dig @208.67.222.222 google.com
dig +tcp @208.67.222.222 google.com
hping3 --udp --count 4 192.168.1.1 2>&1
I think at this point I'll try fiddling with a few more underlying network things and see if it makes a difference. I'll get it to dump the v4 and v6 routing tables and see if that ever changes. Because this is also a non-vanilla distro, there could definitely be weirdness in the vendor's kernel or NIC drivers. That unfortunately doesn't leave many options, but rumour has it that Armbian may work on the Rock Pi S.
Just to rule out more possibilities I can see if disabling IPv6 upstreams helps, along with the extra IPv6 addressing that I added for the LAN.
Some recordkeeping notes in case I find info to add later
- Last observed
REFUSEDin the logs was 2022-01-18 01:34:53 (localtime AEDT) - Disabled extra logging and packet dumping 2022-01-18 12:07:30
- At the same time switched back to Cloudflare upstreams (as I originally wanted), and only on IPv4, no IPv6 this time
- Went back to normal codebase with
pihole checkout master - No instances of
REFUSEDseen since then (35hrs), though I haven't been that active on my workstation in the last day either