VPN Connected, But Internal Hostnames Won't Resolve? A Complete macOS Routing Table Walkthrough

Mon, 01 Jun 2026 18:00:00 +0800

TL;DR:

When two VPNs run side-by-side on macOS (e.g. utun0 and utun15), an aggregate 10.0.0.0/8 route pushed by one of them can silently “swallow” every address in the 10.x.x.x range — including the one you actually wanted to reach on the other VPN. DNS resolves fine; TCP/ICMP just hangs. route -n get is the first knife you should reach for.

You Can SSH Out, but Not Back In: A Fail2Ban False Positive That Broke Reverse Access

Sat, 30 May 2026 15:45:00 +0800

Bottom line

The symptom looked simple: I could SSH from the local machine into a remote internal host, but the reverse SSH path failed when the remote host tried to connect back. sshd was listening, the route table looked fine, and the failure still happened.

The real root cause was not a broken SSH daemon. Fail2Ban had banned the VPN gateway address that represented the return path. From the local machine’s point of view, the incoming SSH session did not appear to come directly from the remote host. It appeared to come from the gateway, so the ban cut off the whole reverse path.

VPN on Margrop Blog

VPN Connected, But Internal Hostnames Won't Resolve? A Complete macOS Routing Table Walkthrough

You Can SSH Out, but Not Back In: A Fail2Ban False Positive That Broke Reverse Access