Troubleshooting                                            
** 2/17/25   Tailscale        
  Ver   Troubleshooting        
  2/17/25                                            
   
  Home Copilot  (Troubleshooting Raspberry Pi SSH Timeout)
  Misc
  Troubleshooting Win rpi
  Glossary cmd arp -a look at IP's and MAC's $ sudo systemctl status ssh
    ping <IP> ping the device sudo systemctl enable ssh --now
   
   
    Root Cause #1 (Most Likely)
    Your PC still has an active Tailscale route overriding local LAN traffic
   
    Even if you “exit” Tailscale, Windows often leaves behind:
    •  A Tailscale network adapter
    •  A persistent route for 192.168.7.0/24
    •  A higher‑priority interface metric
    •  A stale DNS or routing entry
    This causes Windows to send packets toward the Tailscale interface, not the Ethernet/Wi‑Fi interface — so the Pi never sees them.
   
    This is exactly why:
    •  You can’t ping the Pi
    •  You can’t SSH
    •  But the Pi can reach the internet
    •  And ARP still shows the Pi (ARP is local broadcast, not routed)
    This is the classic “Tailscale hijacked the route table” scenario.
   
    Step 1  Check your Windows routing table
    Win
    cmd route print
   
    Look under IPv4 Route Table for anything like:
    •  192.168.7.0
    •  192.168.7.0/24
    •  A route pointing to the Tailscale adapter
    •  A Tailscale interface with a lower metric than Wi‑Fi
    If you see a route for 192.168.7.0  that does NOT point to your Wi‑Fi adapter, that’s the smoking gun.
   
    Step 2  Temporarily disable the Tailscale adapter
    In Windows:
    1 Open Control Panel → Network and Internet → Network Connections
    2 Right‑click Tailscale
    3 Choose Disable
   
    Then try:  
     ping 192.168.7.100 and then PuTTY. If it suddenly works, we’ve nailed it.
   
    Step 3 — If it still fails, show me this:
    route print
   
   
    If the Tailscale adapter keeps re‑enabling itself, even after you disable it,     
      then your Windows routing table is being hijacked by a Tailscale service that is still running in the background.
   
    This is exactly why:
    •  You can’t ping the Pi
    •  You can’t SSH
    •  The Pi is clearly alive on 192.168.7.100
    •  ARP sees it
    •  But Windows keeps sending packets into the Tailscale black hole instead of your LAN
    Let’s fix this cleanly and permanently.
   
    Step 1  Stop the Tailscale service (this is the real fix)
   
    Even if you “exit” the app, the service keeps running.
    Open an elevated PowerShell (Run as Administrator):
   
    Pwr net stop Tailscale
    Shell sc config Tailscale start= disabled This prevents the adapter from resurrecting itself.
   
    Now check:
    ping 192.168.7.100 If it replies, we’ve nailed it.
   
    Step 2 — Disable the Tailscale adapter again
    Now that the service is stopped, the adapter will stay down.
    Control Panel → Network Connections → Right‑click Tailscale → Disable
    It should no longer pop back to “Enabled”.
   
    Step 3 — Flush Windows routing table This clears any stale routes Tailscale left behind.
    In elevated PowerShell:
    Pwr route -f This forces Windows to rebuild the routing table from scratch. Your Wi‑Fi will drop for a moment — that’s normal.
    Shell ping 192.168.7.100 and then PuTTY.
   
   
    Why this works
    Tailscale installs:
    •  A virtual network adapter
    •  A background service
    •  Persistent routes
    •  Interface metrics that override LAN traffic
    Even if you “exit” the GUI, the service keeps running and Windows keeps routing 192.168.7.x traffic into the Tailscale adapter instead of your Wi‑Fi interface.
    That’s why you could see the Pi in ARP (broadcast), but could not reach it via unicast.
    Stopping the service + disabling the adapter + flushing routes resets everything.
   
    That did it.  I stopped Tailscale via the PowerShell command and then was able to SSH to the Pi !!
      That’s exactly what I expected to happen — and it confirms the diagnosis perfectly.
      Your Pi was never the problem. Your network wasn’t the problem. Your routing table was being hijacked by a background Tailscale service that kept resurrecting its virtual adapter and intercepting all 192.168.7.x traffic.
      Stopping the service cut off the root cause, and suddenly everything behaved the way it should. Beautifully done.
      If you want to keep using Tailscale on that machine without breaking your LAN again, I can walk you through a clean setup that prevents it from overriding local subnets while still letting you use exit nodes or remote access.
        yes please
   
    Absolutely, Mark — now that we know Tailscale was the culprit, we can set it up so it never hijacks your LAN again, while still giving you all the benefits of remote access. 
    The trick is to make Windows treat Tailscale as a secondary path, not the primary one.
    Below is the clean, reliable setup that works beautifully on Windows and plays nicely with home networks like yours.
   
    Step 1 — Re‑enable the Tailscale service (but safely)
    Once we fix the routing behavior, you can turn the service back on without breaking SSH.
    Pwr sc config Tailscale start= auto
    Shell net start Tailscale
   
    Step 2 — Tell Tailscale NOT to override local LAN routes This is the big one.
    Open Tailscale → Settings → Preferences and make sure:
    •  “Use Tailscale exit node” → OFF
    •  “Route all traffic through Tailscale” → OFF
    •  “Advertise routes” → OFF
    •  “Accept routes” → OFF
    These options are what cause Windows to install routes that override your LAN.
    If any of these were ON, that’s why your Pi vanished.
   
    Step 3 — Force Windows to prefer your LAN over Tailscale
    Windows sometimes gives the Tailscale adapter a lower metric (higher priority).
    We fix that manually.
    1. Open Network Connections Control Panel → Network and Internet → Network Connections
    2. Right‑click your Wi‑Fi adapter → Properties Select Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced
    3. Uncheck Automatic metric Set Interface metric to: 10
    4. Now do the same for the Tailscale adapter Set its metric to:  50
    This guarantees:  
    •  Local LAN traffic → Wi‑Fi
    •  VPN traffic → Tailscale
    •  No more hijacking  
   
    Step 4 — Flush and rebuild the routing table
    This ensures Windows forgets the old Tailscale routes.
    Pwr route -f Your Wi‑Fi will drop for a moment — normal. Then reconnect and verify:
    Shell ping 192.168.7.100
   
    Step 5 — Optional but recommended:
    Tell Tailscale to ignore your LAN subnet entirely This prevents Tailscale from ever touching 192.168.7.x.
    Pwr tailscale set --accept-routes=false This is the “belt and suspenders” fix.
    Shell
   
    Step 6 — Test the final setup
    With Tailscale running normally:
    •  Ping the Pi
    •  SSH into the Pi
    •  Visit a website
    •  Connect to a Tailscale device
    Everything should work without interference.
   
    What you’ve achieved
    You now have:
    •  A Pi reachable on your LAN
    •  Tailscale running without breaking local traffic
    •  A stable routing table
    •  A Windows setup that won’t silently override your network again
    This is the cleanest, most reliable configuration for someone with your network layout.
   
   
    If you want, I can also help you configure MagicDNS, ACLs, or subnet routing so your Pi is reachable over Tailscale and your LAN without conflicts.