IPv6: Fixed, again!
AussieBroadband apparently managed to break IPv6 (still in beta, so I guess it’s acceptable) during an upgrade of some of their equipment, which brought to my attention the fact that I never actually fixed why it stopped working after we moved into the new house.
I was opted in to the beta correctly, and everything was configured correctly - our V6 subnet obviously changed, but near as I could tell there was nowhere in the Unifi configuration where it was hard-coded, and the modem was simply a dumb ethernet bridge so where was the issue?
After they fixed it, I completely removed the V6 configuration from the WAN interface, waited for it to provision, then added it back, and it “just worked”. My guess is that the DHCPv6 client on the USG was inappropriately holding on to a lease it couldn’t renew, but on my weekend I didn’t really care enough to figure out why.
I had to repeat the process shortly after to switch over to the /48 they were offering (up from /56, which some folks are suggesting is to bring them into RFC compliance as apparently a /48 is the smallest legal internet routable network size). I was in absolutely zero danger of running out of address space to begin with, but hey, whatever… more entropy for my “privacy” interfaces!
One more annoyance took significantly longer to figure out - after doing all this, my internal “status” page stopped responding! After some investigation, I determined it was going out to CloudFlare, rather than the split-horizon DNS on my LAN forwarding it directly to the internal webserver. Weird.
My first thought was that it was Firefox’s DNSoHTTPS, which they’re constantly trying to shoehorn onto users. I double checked that it was off, but then read some folks (maybe just conspiracy theory) suggesting that sometimes Firefox will turn it back on anyway if it thinks it’s in the user’s best interest, so I configured a canary domain that would supposedly override this, but still no luck.
After some time, I realized I was missing the obvious - I just re-enabled IPv6, and my machines were preferring that over v4. I have the split-horizon DNS override for the A record, but do not have one for AAAA! Lacking an override, the AAAA record from upstream was used instead, so that’s why it was not responding correctly.
I tried to look and see if I could tell the USG to not return an AAAA record for a given hostname, but I came up empty. I didn’t want to hard-code the v6 address of my webserver because my IPv6 skills leave a lot to be desired, but in the end up I came up with a crutch workaround - I encode the IPv4 address in a v6 address, and use that for the AAAA record, and I know it won’t change.
Converting the addresses is simple enough: convert each octet to hex, express it as two sixteen-bit numbers with a colon in the middle, and strap ::FFFF to the front of it, so 10.0.0.2 becomes ::FFFF:0A00:0002.
After doing this, forcing the USG to be provisioned, and restarting Firefox (in lieu of a proper way to force it to dump it’s internal DNS cache), I was back up and running.
fwagglePublished:
Modified:
Filed under:
Location:
Horsham, VIC, AustraliaNavigation: Older Entry Newer Entry