There seems to be a new issue
My interface has its private key set (i even re-set it to the same value and luci complained about no changes to save)
however when i go to WireGuard Status page it says
Interface does not have a public key!
last week when working on this my public key was showing in the status page so idk when or what caused this change
root@OpenWrt:~# wg showconf WireGuard VPN
Usage: wg showconf <interface>
root@OpenWrt:~# wg show
root@OpenWrt:~#
The firewall rule is correct by setting it to destination device input as this is what shows in my rules and works.
Have you tried restarting the interface and then rechecking?
yes, no change 
There can't be a space in the interface name. The output shown from your "wg showconf WireGuard VPN" command is telling you the syntax is wrong. Based on previous replies it should be "wg showconf WireGuardVPN" (no space). Could you try that and post the result?
But first...
The command "wg show" returns nothing on your router. I can re-create this if the interface is down. Try "ifup WireGuardVPN" and then "wg show". If it's still blank the interface is probably down. You could check with:
ubus -v call network.interface.WireGuardVPN status | jsonfilter -e '@.up'
If up it will return true.
i was using the wrong name its actually: wireguardVPN
its the protocol that has the space: WireGuard VPN
but ya it looks like interface is down
root@OpenWrt:~# ifup wireguardVPN
root@OpenWrt:~# wg show
interface: wireguardVPN
root@OpenWrt:~# ubus -v call network.interface.wireguardVPN status | jsonfilter -e '@.up'
false
but i dont understand, it shows started in luci
Bring up on boot
IS checked (true)
i rebooted but it still reports false
interface is down
Well, that makes sense if it was also having a problem with the key(s). The driver may not be able to come online. You could try and look at /etc/config/network and try to see what's missing (if anything).
But if it was mine I wouldn't mess with the current config since it's been driven over so much. I would delete the firewall zone, the wg interface, any wg conf files you were using. Then check in /etc/config/network and make sure it's clean - no wg entries. If there are any remaining wg entries in there, remove them before going forward. Then start again using the guide posted just above.
You already know a lot of what was wrong in the original config, so maybe something in the files has been hanging you up without having a full reset?
At any rate, good luck with it.
Nothing interesting there. The client trying to contact the server but no response back. Looks like there is some mistake in the settings so the server is not responding at all.
Thank You All, its finally working!!!
I uninstalled everything, deleted keys and ios app configurations and recreated it all, this time using:
One thing strange about that tutorial is that is has you create 2 key pairs on the openwrt side. However I dont see either of the client- keys being used. unless something in the commands below affect files other then the key files they generate.
$ wg genkey | tee /etc/wireguard/server-privatekey | wg pubkey > /etc/wireguard/server-publickey
$ wg genkey | tee client-privatekey | wg pubkey > client-publickey
So in the end idk if that extra step was key to why it worked this time, or if it was the reinstalling of everything
Glad to hear it's working!
That extra step is probably just because that guide seems to be sourced from this one, which did use that client key pair to set up their phone as a client.
Indeed it is taken from the above page but when followed was telling you to place the wrong public keys in which is why I made that one 
Ah, cool. It's yours. I agree with the need for a concise guide. Yours is the best to date. Besides the extra client key creation command, there were three other things I noticed in your guide that you might think about changing -
Next run the following to make a new Traffic Rule in OpenWRT firewall. Make sure to change
99999to your previously chosen port for WireGuard interface.
For someone new to VPNs and networking it might be good to give them an example of a valid port. The WG quick start guide uses 51820. It's arbitrary, but I could see someone unfamiliar with networking trying to use 99999 from your guide and failing. No need to add potential frustration. Maybe use that port and indicate "or any other valid port number."
Also inherited from your source, the guide is setting AllowedIPs = 10.200.200.2/24 on the server. This should be /32 unless you want all .2.x subnet traffic to go to this peer. Won't matter with one peer, but it could get unpredictable once you have 2 or more peers connected to the same wg interface.
Thanks cpunk. I've amended the walkthrough as you've suggested if you can have a quick look that would be great and I'll then publish fully
we should link to it from the openwrt wireguard page, imo
Feel free to add a link to https://openwrt.org/docs/guide-user/services/vpn/wireguard#external_links
ya i tried yesterday but i forgot my username and didnt see a link to recover it.
Hey, thanks for the quick edit. This is going to help a lot of people.
One tweak - on the server side, peer section AllowedIPs should be /32, but on the client side, their address should be /24 (otherwise they won't be able to reach the .1 address of the vpn server). A lot of people get this confused, since we're not really specifying Address+Mask in the AllowedIPs setting. We're listing addresses or address ranges that should route through to this peer. In this case the client is not also a router, so we should only send traffic for their specific IP through this peer connection, thus /32 mask. If the client/peer was also a router, then we would have their tunnel address/32, plus the network address range beyond, like 192.168.99.1/24.
So in #7 consider changing this:
In the Allowed IP’s section, enter a random IP address in the subnet you previously chose, for example 10.200.200.2/32. This will be the client’s internal IP address.
To something like this:
In the Allowed IP’s section you're indicating what addresses are reached through the tunnel to this peer. In our example we only want to send traffic to the one client's address. To do this, pick an IP address for the client in the subnet you previously chose, and use /32 at the end. For example 10.200.200.2/32.
In #8 is where it will break with /32, so maybe change from this:
Go back to the app and In Addresses , put the exact same of what you specified in Allowed IPs of the client peer, e.g. 10.200.200.2/32.
To something like this:
Go back to the app and in Addresses, put the address you chose for the client and entered on the server in the peer Allowed IPs section, but use the real subnet mask (/24 in CIDR notation) like you did for the server Address, e.g. 10.200.200.2/24.
Maybe you can simplify that a bit. But that's a first crack at explaining it.
Updated as suggested. Hopefully if the steps now make sense and are correct i can make it look nicer and try and simplify the wording.
Link has now been added. Hopefully this will help some people out.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.