Troubleshoot the path by layer

A VPN connection crosses several layers, and any one of them can fail. The fast way to debug is to walk the layers in order, from the device outward, and stop at the first one that is broken.

For the Cloudflare path, the order is: device, route, edge, connector, destination network, service.

Start on the remote device. Confirm the client is connected to the intended team, not a stale one from another job:

warp-cli status
# Status update: Connected

warp-cli registration show | grep Organization
# Organization: flavio-lab

Then check the route. Does the destination match a prefix you routed through Cloudflare, and did you carve it out of the Split Tunnels exclusions? If the address is still excluded, the packet never leaves the laptop, and no dashboard will show it.

Next, the edge. Open the Gateway or Access policy logs and look for an explicit block on your connection. A block here is good news, because the fix is one policy edit away.

Then the connector. Check Tunnel health in the dashboard and run systemctl status cloudflared on the connector host. From that same host, ping the destination. If cloudflared cannot reach the resource locally, Cloudflare cannot either.

Finally the destination itself. Check its firewall, the address the service listens on, and its logs. A service bound to 127.0.0.1 instead of 0.0.0.0 looks exactly like a broken tunnel from the outside.

Change one layer at a time. A broad allow rule can hide the real problem and leave permanent access behind. Plenty of “temporary” rules end up older than the people debugging them.

The WireGuard path has fewer layers, but the same discipline applies. Start with evidence from both peers:

sudo wg show
ip address show wg0
ip route get 10.14.0.1
ping -c 3 10.14.0.1

No recent handshake points toward endpoint, key, UDP, or firewall trouble. A handshake with no useful traffic points toward AllowedIPs, routes, forwarding, DNS, or MTU. Change one layer at a time. Save the before and after output so you can explain which change fixed the path.

Here is what a healthy result looks like, so you know what you are aiming for:

sudo wg show wg0 latest-handshakes
# xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=   1785171243

ip route get 10.14.0.1
# 10.14.0.1 dev wg0 src 10.14.0.2

A recent timestamp and a route through wg0. If either is missing, you know which half of the list to read.

Write down what you expected before running each command. Then compare. Without an expectation, every output looks plausible, and debugging turns into running commands and hoping.