Thunderbolt Strikes Twice: When a NIC Adapter Took Down the Whole NAS

Status: RESOLVED Casualty Count: DNS, SSH, my confidence in Thunderbolt networking Root Causes: 3 (because one problem is never enough)

The plan was simple: plug a Thunderbolt ethernet adapter into Mirach-Maia-Silo (the Unraid NAS) to get 10GbE speeds when transferring files to the Synology. What could go wrong?

Everything. Everything could go wrong.

After plugging in the OWC Thunderbolt dock — and then unplugging it when I realized Unraid didn’t like it — DNS stopped working. SSH became unreachable. The only thing that worked was safe mode, which is Unraid’s way of saying “we’ve given up on your configuration, let’s start fresh.”

The thing is, I had removed the adapter. The damage was already done.

Root Cause #1: The Boot Script That Wasn’t

First discovery: /boot/config/go — the main Unraid boot script — had syntax errors:

# What I found:
if [ condition ]
    do_thing  # Missing 'then'!
fi

# And this gem:
if [ outer ]
    if [ inner ]
        stuff
    fi  # Stray fi with no matching if

When a boot script has syntax errors, services fail silently. You don’t get “syntax error on line 47” — you get “why doesn’t DNS work?”

Fix: Rewrote the script with proper if/then/fi blocks. Created a backup first because I learn from my mistakes (occasionally).

Root Cause #2: Docker Configured for a Dead Interface

Second discovery: /boot/config/docker.cfg contained:

DOCKER_CUSTOM_NETWORKS="wlan0 "

wlan0 was DOWN. Had been DOWN. Will probably remain DOWN forever because this NAS doesn’t have WiFi. But Docker was configured to use it, causing network initialization failures.

The trailing space after wlan0 was a particularly nice touch. Who knows how that got there.

Fix:

DOCKER_CUSTOM_NETWORKS=""

Revolutionary, I know.

Root Cause #3: The Routing Table Betrayal

Third discovery — and this was the subtle one that took actual thinking:

Mirach-Maia-Silo has Tailscale installed. Titawin-Host (192.168.20.100) acts as the subnet router, advertising 192.168.20.0/24 to the Tailscale network. When Tailscale started on Mirach-Maia-Silo, it accepted this route.

Now here’s where it gets interesting:

1. Incoming SSH connection arrives on br0 (the local bridge)
2. Linux kernel needs to send the reply
3. Routing table says “192.168.20.0/24 goes through tailscale0”
4. Reply gets sent via Tailscale interface
5. TCP handshake fails because responses are coming from a different path

This is called asymmetric routing, and it’s the networking equivalent of answering a phone call by yelling out the window.

Fix:

ip rule add to 192.168.20.0/24 lookup main priority 5200

This tells the kernel: “For local subnet traffic, use the main routing table (br0), not Tailscale’s special table 52.”

Added to start-tailscale.sh for persistence across reboots.

What is CorpDNS, Anyway?

During debugging, I encountered Tailscale’s “CorpDNS” setting. In case you’re wondering (I was):

CorpDNS ENABLED (true):

• Tailscale overrides /etc/resolv.conf
• DNS queries go through Tailscale’s servers (100.100.100.100)
• You get magic hostnames like Mirach-Maia-Silo.tail-net-name.ts.net
• Less predictable, more magic

CorpDNS DISABLED (false) — my setting:

• Tailscale doesn’t touch DNS
• System uses configured DNS (8.8.4.4 in my case)
• Must use IP addresses or configure DNS separately
• More predictable, less magic

For a NAS that needs reliable, boring networking? I’ll take “more predictable” every time.

The Network Topology (For Future Reference)

Internet
    |
Router (192.168.20.1)
    |
    +-- Mirach-Maia-Silo (192.168.20.50) - Unraid server
    |       - eth0 -> bond0 -> br0
    |       - Tailscale: 100.64.0.30
    |
    +-- Titawin-Host (192.168.20.100) - Subnet router
    |       - Advertises 192.168.20.0/24 via Tailscale
    |
    +-- Caph-Silo (192.168.20.7) - Synology NAS

The Lesson: Don’t Do Thunderbolt on Unraid

The original goal was faster transfers to the Synology. Thunderbolt on Unraid is unreliable at best, catastrophic at worst.

Better alternatives:

• USB 3.0 to 2.5GbE adapter (~$16, RTL8156 chipset, plug and play)
• USB-C to 5GbE adapter (~$25, RTL8156B chipset)
• Literally anything that isn’t Thunderbolt

If I do add a USB NIC later, the plan:

1. Don’t add it to bond0 — mismatched speeds cause problems
2. Give it a dedicated subnet — e.g., 10.10.10.1/24 for direct Synology connection
3. Keep it off the main network — storage traffic stays isolated
4. Don’t reboot until verified — learned this one the hard way

Verification Commands (For Future Me)

Check routing is correct:

ip route get 192.168.20.7
# Should show "dev br0", not "dev tailscale0"

Check DNS:

nslookup google.com
cat /etc/resolv.conf

Check routing rules:

ip rule | grep 5200
# Should show the local subnet rule

Recovery Options (If This Happens Again)

1. Boot into safe mode (plugins/Docker disabled)
2. Tailscale SSH still works: tailscale ssh root@Mirach-Maia-Silo
3. Restore backups:

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

Three separate issues from one Thunderbolt adapter. DNS broken by routing tables. SSH killed by asymmetric paths. Docker confused by ghost WiFi interfaces. And all I wanted was faster file transfers.

Sometimes the speed upgrade isn’t worth it. Sometimes you just use the slow, reliable 1GbE connection and get on with your life.