As you might know, I participate in DN42. I have a somewhat peculiar setup, in which some VPS run the routing daemons, and my home router simply has a VPN connection to them and statically routes everything fd00::/8 to them. The router runs OpenWRT, and has dnsmasq setup to resolve DN42 domains via the DN42 anycast servers. I set this up months ago, it worked, I was happy, and didn’t need it since.

Cue last weekend. “Suddenly” the resolution didn’t work anymore. It simply timed out. So I connected to my VPS (which is running DN42 in a namespace) and took a look at tcpdump. Inside the namespace, I saw the strange lines

18:49:05.296629 eth0  In  IP6 fd7a:115c:a1e0::xxx > fd42:d42:d42:53::1.53: 42631+ [1au] AAAA? wiki.dn42. (50)
18:49:05.296679 kioubit Out IP6 fd3e:bc05:2d6::80.50255 > fd42:d42:d42:53::1.53: 42631+ [1au] AAAA? wiki.dn42. (50)
18:49:05.302946 tinc_dn42 In  IP6 fd42:d42:d42:53::1.53 > fd3e:bc05:2d6::80.50255: 42631 1/0/1 AAAA fd42:d42:d42:80::1 (66)
18:49:05.302990 kioubit Out IP6 fd3e:bc05:2d6::80 > fd42:d42:d42:53::1: ICMP6, destination unreachable, unreachable route fd3e:bc05:2d6::80, length 122

And all the time I was thinking… “huh??? Why is fd3e:bc05:2d6::80 unreachable??? It is clearly in the ip -6 a output!!!”. I looked through all the iptables statistics and couldn’t find the culprit.

A join in the DN42 IRC and some back and forth later, someone suggested “Hey, what’s with the fd7a:… address? Is there a route for that?”.

And of course, no, it wasn’t! I was so focused on the ICMP6 message that I didn’t notice the incoming line. As you can read in my other article linked above, I perform NAT. Of course in that case it probably wouldn’t make sense for the ICMP6 message to tell someone that there’s no route for the original IP (before NAT).

So, but… where does the fd7a:… address come from?
The answer is Tailscale. Unfortunately, they decided to use the fd00::/8 IP range, which collides with DN42. I didn’t do any DN42 stuff since installing it, so I didn’t notice that.
But… why is that address used at all for the DNS request?
Weeeeell… I found out as well. It comes from OpenWRT. I simply set up a static route there, and Linux does its best to determine the source address for the DNS request. And it seems the Tailscale one was a closer match than the address from my own DN42 prefix.
So, how to fix that?
It’s not as easy as you think!. Merely using the “source” option in the config file would work for IPv4, but for IPv6 it has a different meaning!
But why does it say “no route to host” instead of using a default route?
Because I configured bird to insert an “unreachable” route for the fd::/8 prefix to avoid leaking traffic.

# ip -6 route show fd00::/8 table dn42
unreachable fd00::/8 dev lo proto bird src fd3e:bc05:2d6::1 metric 500 pref medium

At this point, it’s Monday evening. Unnerved, I threw my hands in the air and simply put a line of

ip -6 route replace fd00::/8 ... src <my-openwrt-dn42-address>

in /etc/rc.local and called it a day. My setup works again, and I learned something again. Don’t just look at the last line, look at the whole picture. A lesson I actually already learned in the ubuntuusers forums when asking for help compiling a package and only posted the last few make output lines, which of course didn’t contain the actual compilation error…