I had a weird macOS homelab issue where Screen Sharing stopped working. At first it looked like the remote Mac was broken, but the real problem was much lower in the network stack: stale or broken IPv4 ARP/neighbor state.
This write-up explains the debugging path and the lesson.
TLDR: clearing ARP fixed the issue. OR USE direct IPV6 Instead of IPV4 192.xx
in terminal and go nuts! e.g.
open 'vnc://[2111:12C2:1111:1220:1459:7802:44FE:5554]'From my client Mac, the remote Mac was visible through Bonjour/mDNS:
dns-sd -B _rfb._tcp local.
dns-sd -B _ssh._tcp local.The remote machine advertised both:
_rfb._tcp # Screen Sharing / VNC
_ssh._tcp # SSH
Resolving the service also worked:
dns-sd -L "Remote Mac" _rfb._tcp local.
dns-sd -L "Remote Mac" _ssh._tcp local.Example output:
Remote Mac._rfb._tcp.local. can be reached at remote-host.local.:5900
Remote Mac._ssh._tcp.local. can be reached at remote-host.local.:22
So discovery was working.
But direct IPv4 access failed:
ping -c 3 192.168.1.50
nc -4 -G 3 -vz remote-host.local 22
nc -4 -G 3 -vz remote-host.local 5900The result was timeout / no response.
However, IPv6 worked:
nc -6 -G 3 -vz remote-host.local 22
nc -6 -G 3 -vz remote-host.local 5900Both SSH and Screen Sharing ports were reachable over IPv6.
Forcing Screen Sharing to use the IPv6 address worked:
open 'vnc://[2001:db8::1234]'But using the hostname or IPv4 address failed:
open "vnc://remote-host.local"
open "vnc://192.168.1.50"This was not actually a Screen Sharing problem.
It was not SSH.
It was not Bonjour.
It was not the macOS firewall.
It was an IPv4 path problem.
The remote Mac was alive and services were running, because IPv6 could reach them. Only IPv4 was broken.
The situation looked like this:
IPv4:
Client Mac -> 192.168.1.50 -> timeout
IPv6:
Client Mac -> 2001:db8::1234 -> works
That means the service was healthy, but IPv4 delivery on the LAN was broken.
Bonjour/mDNS can show that a service exists:
"remote-host.local offers SSH"
"remote-host.local offers Screen Sharing"
But service discovery is not the same as reachability.
A useful rule:
Seeing a service is not proof that you can reach the service.
The network stack still has to resolve and deliver packets correctly.
When connecting to a local Mac, the flow looks like this:
Hostname
↓
IP address: IPv4 or IPv6
↓
TCP port: 22 for SSH, 5900 for Screen Sharing
↓
Layer 2 neighbor mapping
↓
Wi-Fi / Ethernet
In my case:
Hostname resolution: worked
Bonjour discovery: worked
SSH service: worked
Screen Sharing service: worked
IPv6: worked
IPv4: failed
So the failure was lower than the application layer.
IPv4 on a LAN uses ARP.
Before a machine can send traffic to:
192.168.1.50
it needs to know the target device’s MAC address.
So it asks:
Who has 192.168.1.50?
That is ARP.
IPv6 does not use ARP. It uses Neighbor Discovery Protocol, or NDP.
So it is possible for IPv4 to be broken while IPv6 still works.
That is exactly what happened here.
On the client Mac:
ifconfig en0 | egrep "inet |inet6 |status:"
route -n get defaultConfirm that both machines are on the expected LAN.
Example:
Client: 192.168.1.20
Remote: 192.168.1.50
Gateway: 192.168.1.1
dns-sd -B _rfb._tcp local.
dns-sd -B _ssh._tcp local.If the remote Mac appears here, discovery is working.
dns-sd -L "Remote Mac" _rfb._tcp local.
dns-sd -L "Remote Mac" _ssh._tcp local.Then resolve the hostname:
dns-sd -G v4v6 remote-host.localYou may see both IPv4 and IPv6 addresses.
echo "IPv4 SSH:"
nc -4 -G 3 -vz remote-host.local 22
echo "IPv6 SSH:"
nc -6 -G 3 -vz remote-host.local 22
echo "IPv4 Screen Sharing:"
nc -4 -G 3 -vz remote-host.local 5900
echo "IPv6 Screen Sharing:"
nc -6 -G 3 -vz remote-host.local 5900If IPv4 fails but IPv6 succeeds, the remote service is probably fine.
The problem is IPv4-specific.
On both Macs:
sudo pfctl -s info
sudo pfctl -sr | head -120Also check the macOS Application Firewall:
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmodeIn my case, both pf and the Application Firewall were disabled, so the firewall was not the cause.
On the client Mac:
arp -an | grep 192.168.1.50On the remote Mac:
arp -an | grep 192.168.1.20If ARP state is stale or weird, clear it.
On the client:
sudo arp -d 192.168.1.50On the remote Mac:
sudo arp -d 192.168.1.20Or clear all ARP entries:
sudo arp -d -aThen retest:
ping -c 3 192.168.1.50
nc -4 -G 3 -vz 192.168.1.50 22
nc -4 -G 3 -vz 192.168.1.50 5900In my case, clearing ARP fixed the issue.
One of the confusing errors was:
ping: sendto: No route to host
That sounds like a routing problem.
But on a local subnet, it can also mean the machine cannot resolve or reach the Layer 2 neighbor.
In plain English:
I know the IP should be local, but I cannot deliver packets to the device behind that IP.
So do not immediately assume the router or default gateway is the problem.
It may be stale ARP or broken neighbor state.
Assume:
Client Mac: 192.168.1.20
Remote Mac: 192.168.1.50
On the client Mac:
sudo arp -d 192.168.1.50On the remote Mac:
sudo arp -d 192.168.1.20Then retest from the client:
ping -c 3 192.168.1.50
nc -4 -G 3 -vz 192.168.1.50 22
nc -4 -G 3 -vz 192.168.1.50 5900
open "vnc://192.168.1.50"If IPv4 is broken but IPv6 works, you can force Screen Sharing to use IPv6:
open 'vnc://[2001:db8::1234]'For link-local IPv6 addresses, include the interface scope.
Example:
open 'vnc://[fe80::1234:5678:abcd:ef12%25en0]'The %25en0 part is important because % must be URL-escaped inside a URL.
Use a DHCP reservation on the router instead of manually hardcoding IPs on devices.
Recommended setup:
Remote Mac network setting: DHCP
Router: reserves a fixed IP for the remote Mac
Example:
Device: Remote Mac
Reserved IP: 192.168.1.50
Avoid having multiple devices manually configured with overlapping static IPs.
If LAN access becomes weird again, clear ARP on both sides:
sudo arp -d -aThen reconnect.