Post #2741369

2026-03-15 03:31 UTC

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town yea, but how do you inject/update site B updated GUAs into site A's peer config for site B, and vice versa? But, wait: If you're not punching a hole in the firewall to make the service at site B accessible from the public Internet, then why DDNS the address to a public DNS or against the GUA anyway? If the service should only ever be internally accessible, just pin the DNS record to the ULA and be done with it?

Replies (2)

@hugo@social.treehouse.systems 2026-03-15 03:34

@arichtman@eigenmagic.net @uep@timeloop.cafe @futzle@old.mermaid.town Circling back: Diving into all of this also starts to shed some light on what "value add" Tailscale provides for folks in these circumstances, e.g. providing "app connectors" to do exactly this, with injecting DNS-based routing through the Tailscale overlay into the mix. They can do that, though, because they're running an agent that's "more than just wireguard" and interacts with a coordination layer.

Open ##2741370
@arichtman@eigenmagic.net 2026-03-15 03:46

@hugo@social.treehouse.systems @uep@timeloop.cafe @futzle@old.mermaid.town Since I only want to reliably access Site B's machines from Site A, I suppose I'll make Site B's v6 subnet ULA and assign a couple of well-known/static addresses to the important machines

Open ##2741374