Simple “split horizon” DNS on PiHole; macOS Tahoe SSH issue; VPN connections need peers...

Local DNS setting in PiHole

Local DNS

I have a CNAME on my main domain that resolves to a DDNS name that’s kept updated from my home network. (Before: https://freedns.afraid.org/ now whatever the MikroTik supplies, with the FreeDNS name  as a backup - two is one, one is none). It worked fine for years but now it’s not resolving properly from inside the LAN. I’'ll troubleshoot that one day but for now, the expedient fix was just to map that host to the internal IP address on the PiHole (6.3 core version, 6.4 web), since the MikroTik is using that as its DNS source. That was easy.

Tahoe SSH authentication issues

But now... Why can’t I login to any of my boxes (even remote) using SSH? Attempts hang at: debug1: Next authentication method: publickey

AI tells me it’s likely an issue with macOS Tahoe’s launchd sockets¹?). I was able to connect to the router via SSH and a password (bypassing the public key exchange) using either one of these:

% SSH_AUTH_SOCK=/dev/null ssh -v rpi

% ssh -o "IdentityAgent none" -v rpi

And I can add that to my global block in .ssh/config (just add the line IdentityAgent none at the top of the file, before any Host entries).

But, Apple, why? Why do you have to keep inserting yourself into what should be straightforward UNIX-to-UNIX(ish) workflows? VNC, SSH ... Just expose the BSD sockets and let the software do what it’s gonna do.  

VPN

I was able to connect using WireGuard from my iPhone and access the VPN addresses and the LAN hosts, but coming in from a macOS machine just hung (no pings, no TCP/IP connections, nada). On the MikroTik, this:

... revealed that only the iPhone was _____. I had to ___ for each client:

> /interface/wireguard/peers/add interface=wg0 public-key="Mac public key" allowed-address=192.168.77.5/32 comment="M5 MacBook Pro"

E.g., public-key="4.........s=' when this was visible in the Manage WireGuard Tunnels interface:

Manage Tunnels screenshot

Also, while troubleshooting I added a misconfigured peer entry. Fonud it with:

> /interface/wireguard/peers/print

Deleted it with:

> /interface/wireguard/peers remove 1 # where '1' is the peer entry I wanted to nuke

Anyway, once I had the peer configured in the MikroTik, everything flowed smoothly. Lovin’ it.

Conclusion

That concludes my geekcore to do list for the day. Now to get back to the stuff that actually pays the bills. (Although, being able to access my LAN server and its repository of documents when I’m working is a godsend in that space, too.)

_________  

¹ Apparently: “When you type ssh, macOS automatically intercepts the command and redirects it to an internal system daemon listener path (e.g., /var/run/com.apple.launchd...) to see if it can handle biometric or hardware keys. If that service daemon hangs, the ssh binary halts permanently right at that line. [1, 2]” The above commands “bypass the operating system's internal background sockets by executing a pure, unattached SSH request directly in terminal memory.”