Troubleshooting Wireguard: The 0.0.0.0 Mystery
Back in January I took my family to spend a long weekend at a friend's bach in Langs Beach. Amazing spot, and we were blessed with perfect weather that weekend. Sun, sand, surf — everything you could ask for — warm without being too hot, and not oppressively muggy. Just the ideal weather to spend a few days next to the beach. I even swam alone in the surf at dusk and watched the stars come out.
This was also the first time I encountered any kind of problem using my Wireguard VPN. Usually it works flawlessly, and as soon as I activate the VPN I can access my local network resources as if I were connected at home.
However this time, while I was connected to the bach's wifi, I discovered that although I could still browse the wider internet through the VPN, I couldn't access local resources, such as my NVR — the requests would hang for a long time before timing out. I confirmed that my WAN traffic was indeed being routed through the VPN by checking which IP address I was seen to be browsing from. That was fine, so it indicated the VPN was working correctly.
Perhaps my local resources had gone offline? But all of them going offline at the same time, while the router remained online, seemed unlikely. And if there had been a power cut, they should have restarted gracefully when the power came back, as they have done in the past.
Then I thought to browse to my router's web console, and this is where I started to get really confused. The login page was accessible to me, but my password did not work. Since I was using a touchscreen, I tried a couple more times to ensure I hadn't fat-fingered the password, but no luck.
Retrospectively I'm not sure exactly how I puzzled this one out. In Wireguard, you can specify the destination IP addresses which the tunnel should be used for. I had specified 0.0.0.0/0, ::/0. In my mind, this meant all traffic would have to go through the Wireguard VPN. And the definition per Wikipedia is:
"The CIDR notation 0.0.0.0/0 defines an IP block containing all possible IP addresses."
It turns out, that if the local network your device is connected to uses the same subnet as the network you are trying to connect to, you have to manually specify this as allowed IP addreses.
The router's web login page I was failing to access? It so happened that the bach I was staying at uses the same brand of router as I use at home, so the login page appeared identical. And the subnet the local network was using was identical. So I was trying to use my password to access the router in the bach, without realising it. You can imagine my confusion until I worked out what was going on.
The solution was to add 192.168.80.0/24 to the allowed IPs in the Wireguard connection on my device. And then everything worked as expected.