The Thunderbolt That Killed DNS

Date: 2026-01-22 Duration: 3 hours Issue: DNS and SSH broken after plugging in Thunderbolt adapter Root Causes: Three. Yes, three separate problems.

The Innocent Beginning

The Mirach-Maia-Silo NAS (Unraid) needed faster transfers to the Caph-Silo (Synology). Both have 10GbE ports. I had an OWC Thunderbolt dock with 10GbE sitting around.

Plugged it in. Unraid saw the interface. Cool.

Unplugged it. That’s when things went sideways.

The Symptoms

After unplugging the Thunderbolt adapter and rebooting:

ping 1.1.1.1
# Works fine

ping google.com
# ping: unknown host google.com

DNS resolution: dead. But raw IP connectivity was fine.

SSH from my workstation: connection refused. Couldn’t get in except via safe mode.

The Unraid web UI? Working fine locally. But DNS and SSH were toast.

Root Cause #1: The Boot Script

Unraid runs /boot/config/go on every boot. It’s a shell script. Someone (me, probably drunk at 2 AM six months ago) had broken it.

if [ something ]; then
  # stuff
if [ something_else ]  # Missing 'then'
  # more stuff
fi
fi  # Extra fi with no matching if

Missing then after an if. Extra fi floating around. The script crashed partway through boot, leaving services half-started.

Fix: Corrected the syntax. Saved a backup first:

cp /boot/config/go /boot/config/go.backup.20260122_203912

Root Cause #2: Docker Zombie Interface

In /boot/config/docker.cfg:

DOCKER_CUSTOM_NETWORKS="wlan0 "

Docker was configured to use wlan0. A WiFi interface. That didn’t exist. That had never existed on this server.

The Thunderbolt adapter created some kind of network state weirdness, and Docker tried to bind to a ghost interface.

Fix: Cleared it:

DOCKER_CUSTOM_NETWORKS=""

Root Cause #3: Tailscale Route Hijacking

This one was subtle.

Titawin-Host (Proxmox at 192.168.20.100) advertises the 192.168.20.0/24 subnet via Tailscale. That’s how I access the network remotely.

When Tailscale started on Mirach-Maia-Silo, it accepted this route. Which meant:

Incoming SSH connections arrive via the local bridge (br0)
The server looks up how to send the reply
Tailscale says “I know that subnet! Route through me!”
Reply goes out via tailscale0 instead of br0
TCP handshake fails because of asymmetric path

The server was receiving traffic on one interface and replying on another. The TCP state machine hates this.

Fix: Priority routing rule:

ip rule add to 192.168.20.0/24 lookup main priority 5200

This tells the kernel: “For traffic destined to the local subnet, always use the main routing table. Don’t let Tailscale’s routing table steal it.”

Added it to the Tailscale startup script so it persists across reboots.

Verification

After all three fixes:

# Check routing uses local interface
ip route get 192.168.20.7
# 192.168.20.7 via 192.168.20.1 dev br0

# Check DNS
nslookup google.com
# Works

# Check the routing rule exists
ip rule | grep 5200
# 5200: from all to 192.168.20.0/24 lookup main

Rebooted into normal mode. Everything came up. DNS works. SSH works. No more Thunderbolt adapter plugged in.

The Lesson About Thunderbolt

Thunderbolt on Unraid is… fragile. The dock I used has hot-plug issues. The kernel doesn’t always clean up the interface state properly when you unplug.

Better alternative: USB 3.0 to 2.5GbE adapter. RTL8156 chipset. Plug and play. No driver drama.

If you need 10GbE, get a PCIe card. Don’t trust Thunderbolt docks for persistent network infrastructure.

Files Modified

File	Change
`/boot/config/go`	Fixed if/then/fi syntax errors
`/boot/config/docker.cfg`	Removed nonexistent wlan0 from custom networks
`/boot/config/start-tailscale.sh`	Added local subnet routing priority

The Moral

One hardware change. Three bugs exposed.

The boot script was always broken. It just happened to fail after the commands I needed.

The Docker config was always wrong. It referenced a nonexistent interface that Docker ignored until now.

The Tailscale routing was always asymmetric. It only mattered when local SSH crossed paths with the subnet advertisement.

Plugging in that Thunderbolt adapter didn’t cause these problems. It revealed them.

Next time I want faster NAS transfers, I’m buying a $16 USB adapter. Not debugging three layers of infrastructure.