I can’t seem to connect to the home network through Wireguard from client on Android via Wireguard server on Route10 anymore.
I tried removing and creating new user config on Route10 and exporting new client config (file download), and for other reasons also performed a full PoR for the Route10, but to no avail regarding the Wireguard tunnel.
Phone is OnePlus 10 Pro, and using the Android Wireguard app.
Client config is downloaded from On-premises Control and imported as is to the Wireguard app.
Usually even when there are issues, it will still report connected. So is it truly not connecting at all? Or is it connecting but showing only unidirectional traffic in the client?
You can also check wg show on the router can give peer info, specifically you’d be looking at bytes sent, received and latest handshake. That same info is also in the client app, when you look at extra info for the active connection. If you see the unidirectional issue, you’d only have bytes sent, and would be missing received and a current handshake.
Does the DDNS hostname resolve to the expected external IP? Assuming you’re using that as the peer address and not overwriting it manually. If the external IP DOES resolve correctly, can you provide me the content of /etc/config/firewall? Either here or DM/email is fine, depending on preference. There maybe some identifiable information, like wan IPs or PPPoE credentials, and those are safe to remove (especially any credentials).
So, the full DDNS adress as exported from Control (x.y.ddns.manage.alta.inc) and imported to Wireguard app comes out as a bogon IP from lookup (CLI on Route10), at the Address 1 line, followed by
can’t find…no answer.
The regular Control adress (y.ddns.manage.alta.inc) comes out as my public IP, at the Address 1 line followed by can’t find…no answer.
So, now when I think of it, as I changed ISP a few weeks ago, I might have overlooked the possibility that I might now be behind CGNAT?! And as I am not familiar with that since before I didn’t consider that.
Symptoms above are most certainly associated to CGNAT.
As far as I know, we do plan to add Tailscale support in a future update. Or last time I asked. That won’t help now, but thought it was worth mentioning here.
@ebuckland81 unfortunately this won’t work (at this time) without a direct IP because CGNAT address space is not publicly routable. Tailscale or similar services are required behind CGNAT because they are a mesh-style VPN architecture, where the nodes connect through external coordination servers.
Just as a note, while unlikely, if the Route10 still gets a CGNAT or similar IP on it’s WAN interface then you’ll need to edit the (WG client) profile and add public. subdomain to the DDNS hostname of the peer (like in the WG app on your respective devices). This forces it to use the real external IP instead of the literal interface address. This doesn’t work around CGNAT itself, but if for some reason the public were terminated elsewhere in the network, and you still had a non-routable address on the interface, you’d want to use that hostname variant.
That’s handy to know! Is that mentioned in the DDNS documentation anywhere? I did a quick search for reference purposes and didn’t see that off hand. Thanks!
So within a few days I will give it another shot.
