---
layout: post
title: Oops, DN42 stopped working
date: 2025-06-16 20:39 +0200
lang: en
categories: tech
---

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]({%post_url 2025-02-02-dn42-put-it-in-a-box-linux-network-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, it decided to use the fd00::/8 IP range, which collides with DN42.
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 my own DN42
prefix. So, how to fix that?  [It's not as easy as you
think!](https://github.com/openwrt/openwrt/issues/13720). Merely using the
"source" option in the config file would work for IPv4, but for IPv6 it has a
different meaning!

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…