Wireguard VPN client - strange behavior during keys, ip, peers change

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.

...please read me: I have the public key of my VPN provider, anmd I have the private key of my VPN provider.

keys are not corrupted, it is openwrt wireguard that doesn't even run.

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>'

config wireguard_wg0
        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'

[/quote]

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.

fully agree, and this is what I have posted

so, thoguh I am reluctant to conclude this, being a pure newbie... there is somehting wrong with openwrt wireguard here

You're the only person who has complained about this issue. I'd be a bit surprised if this is an OpenWrt issue, although it is not beyond the realm of possibility.

BTW, did you remove the option listen_port '34907' from your configuration?

I can rephrase, my private key is generated locally on my VM Linux, so it is not sent to me by my VPN provider...

Ok... that's good. So I assume this means that you provided the corresponding public key to the VPN provider?

yep, firstly I tried without listen port, then with, and so on

the only thing that chnaged behavior was the generation of a new key by openwrt wireguard itself (via Luci)

Listen port should not be part of the configuration. Make sure that is removed.

that is how I did, without and the with to see if there is a difference. nope.

So this is okay -- can you update the public key that you provided to the VPN provider with the new one that was generated with your OpenWrt Wireguard instance?

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.

# Private Key
EAWOY9gqKNQDJQfevKMMXfKdEjjhuZZEBNOigqo48UA=
#Public Key
6uqyvNnzBumSo76prIKzbCduWBbVNLIXQxQGs5+8Yn0=

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
(https://www.wireguard.com/quickstart/)

Still not working fully though (DNS?) but at least I can move ahead.

Yeah, it is really easy to get these confused. Cool that the iPhone app actually can inform the user of this mistake.

What's not working? You can specify the DNS, if you want.

Despite I have set the DNS from VPN provider, I fall into DNS leak https://dnsleaktest.com/

though I am wondering if this is true dns leak or I see the leak of my VPN provider DNS to true DNSs