Thanks for gathering that information. I think I’ve found your problem:
The endpoint in your client configuration should be your VPN server’s WAN/public IP address/DDNS URL + port. I am going to update
Endpoint = <insert vpn_server_address>:51900 in my guide since
vpn_server_address is ambiguous as to whether it refers to public or private IP address. For the record, it refers to the public IP address of the VPN server (i.e. the router’s public/WAN IP address).
I am also curious what the address is that you’ve blocked out in that same client screenshot. It should be the tunnel IP address you’ve assigned to your client (i.e. 10.253.3.2/32). Our goal here is that the “Address” assigned in the [Interface] section of the client config matches the “AllowedIPs” in the [Peer] section of the server configuration.
This then brings me to the second major problem I see based on your output from
sudo wg (presumably on your server):
That listening port (which, again, I assume is running on the server) doesn’t match up with the listening port set in your server’s wg0.conf where
ListenPort=51900. Additionally, I don’t see it matching up with the
AllowedIps = 10.253.3.2/32.
This makes me think that either the server or the service hasn’t been restarted since making changes to the server’s wg0.conf. You should be able to update the loaded WireGuard configuration by restarting the wg-quick service with
sudo systemctl restart wg-quick@wg0 and rerunning
sudo wg to confirm that the server’s WireGuard tunnel now matches your configuration. Alternatively, you can also just reboot your server/RPi.
As for your port forwarding question, it depends on your router’s configuration. Being consumer-oriented devices, sometimes they will use inaccurate language in an effort to make it more consumer-friendly. On more professional set ups, like pfSense, they use the accurate terminology:
Since pfSense is a firewall it actually inspects the traffic and looks at the packet’s destination address, which in our case would be my server’s public IP address on the assigned WireGuard port (under “Dest. Address” and “Dest. Ports” respectively). It then forwards this traffic onto the RPi VPN server at the appropriate (internal) IP address (NAT IP) and NAT Port.
If you’re using a regular consumer router, they’ll often skip over all this and just have an “external” port that the router will listen on and an “internal port” and “internal IP address” to forward the traffic onto. For additional information and screenshots, check out this guide on port forwarding on the Raspberry Pi and scroll down until you see the Netgear screenshots:
In the above Netgear scenario, pfSense’s “Dest. Ports” is equivalent to Netgear’s “External port range” field, with the “Internal Port Range” and “Internal IP Address” being equivalent to pfSense’s NAT IP and NAT Ports respectively.
If you need additional help for your specific router, additional screenshots would be helpful.
Hope this helps!