You should only really have the public key from the VPN provider.
The private key is one you should have generated yourself -- when you do that, you get a key pair (private and public) -- you use the private key in your wireguard interface config and then you provide the public key that you generated in the process to the VPN provider. There should be a way to upload the public key to the provider.
Or, if the provider insists on giving you the private key that you should be using (which seems a bit backwards), you should find out if you can get new keys issued since it seems like one of them may be corrupt.
Just to be super clear about this, you config should look like this:
config interface 'wg0'
option proto 'wireguard'
option defaultroute '0'
option private_key '<Private Key that you generated yourself>'
list addresses '<Tunnel IP address provided to you by the VPN Provider>'
list allowed_ips '0.0.0.0/0'
option endpoint_port '<Port provided to you by the VPN Provider>'
option route_allowed_ips '1'
option public_key '<Public key provided to you by the VPN Provider>'
option endpoint_host '<Remote Peer routable address or domain name provided to you by the VPN Provider>'
option persistent_keepalive '0'
I have read what you said -- and I repeat -- the VPN Provider should not be creating your private key. But if they are doing that, they should be able to generate a new key (and invalidate the old one) because something is wrong with that key if it is not working in your configuration on OpenWrt.
ok I'll try.
This is new to me, as per the example found here and everywhere else, one simply needs to use the private key and public key shown while using the Linux wireguard app from VPNM providers (which I run on my VM Linux)
I am curious about why the private key you're using seems to be problematic on OpenWrt... out of curiosity, if you were to create another key pair using the VM linux system, would that also fail to work on OpenWrt?
If so, you could safely send me a fresh set of key pairs (from VM Linux) and I could try using those keys to see if I have the same result. My idea here is that I want a disposable pair to work with and I don't want you to send me any private keys that are connected with any services.... but posting a pair of keys that has no use outside a quick test that I can run on my home systems could be interesting.
Not sure it is a good idea.
In the meantime I found something quite disturbing:
If I input a private key, which was from previous settings from my VPN provider, openwrt retrieve as configuration public key the previously associated public key !!!
Were it is even stranger to me is that those keys are not in network config file.
Where are those stored??
Would it be the trick to understand what goes wrong?
To be clear, I'm not proposing that you send me a set of active keys... I'm saying you can make a set of throw-away keys on VMLinux to share here. Those keys would be exclusively for testing (locally) and never in use in any 'live'/internet-exposed context. This is because you said that the keys you generated from VMLinux don't seem to work with OpenWrt WG, so I would be willing to try loading those keys to see if it causes a similar issue only my installation. For example, here is a key pair that I generated just as an example.
How are you entering these keys into the system?
Are you 100% certain that you have the correct keys in the right places (i.e. local private key in the interface configuration, remote public key in the peer config section)? It is very easy to accidentally swap the keys (public/private) because they aren't visually distinguishable.
I figure out what I was doing wrong !!!
I was using my own public key instead of the one from VPN provider... SORRRRYYY!!
I tested with iphone wireguard app... which shown me clearly that public key I was using is directly derived from my own private key.
Very confusing for my little brain, I thought since beginning that "wg show *interface* public-keys" is retrieve the peer public key.. Next time I'll read documentation first
Still not working fully though (DNS?) but at least I can move ahead.