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

[kds69]

Hi All,
First note that I am new to OpenWrt... and quite amazed by the amount of work and how neat is the interface. This changes a lot from my long lasting Linksys router... confusing interface to be polite.

Anyway. I tried to replicate my wireguard vpn connection from my VPN provider.
I actually managed to do it...surprinsingly quite easily yesterday. Got private key, public key, peers, ip, port.. etc
followed well-known post https://forum.openwrt.org/t/solved-nordvpn-openwrt-wireguard-client/36742..

Today, I was expecting my WG tunnel to be revoked and just have to redo same.. but to my surprise, trying to change parameters (keys, ip, peers) leads to Openwrt to totally ignore my WG interface.
There are simply absolutely no package going through the interface... zero, nada. 0Kb/0pkts.
I tried so many ways to create undo, via Luci, via UCI...
What I figured out is that if I just change 1 parameters save/apply, next parameters, save apply, my interface is kind of kept alive and not ignored... to a certain point.
Of course I thought I have found the paramater causing trouble... but not, with another sequence having the faulty parameter, then it is not ignored... until a certain point.
Rebooting is even worse...
so? I'm lost...

firmware 21.02, image for EA6350v3, all updated to the latest

[psherman]

You didn't say what version of OpenWrt you are running, but a restart of the interface is generally necessary.
(I haven't yet tried changing things within Wireguard on 21.02, so I'm not sure if this still applies on the latest).

Changing Wireguard keys/peers and such requires a restart of the wireguard interface (or the entire router) to take effect. I think this was classified as either a bug, but at the very least it is an annoyance.

Double check all of the configuration details. If you can't get it to work after a reboot, consider another method of testing -- use the same configuration on a mobile device or your computer to verify that it is all correct.

[vgaetera]

Disable the option route_allowed_ips and reboot.
Then verify the successful handshake in the VPN status.
This isolates the issue with DNS/NTP race conditions.

[kds69]

fair enough. I have added info to the content (21.02)

well, I have to retry then, more rigourously because I might be confused in the belief my sequencial change keeps it alive, but in fact this is just that from system standpoint there is still no change appended.

[kds69]

ok will try with this method to funnel possibilities
thanks

[kds69]

Well this didn't make any difference. I have no idea what to do now.
here are the my config files:

firewall:

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list device 'br-lan'

config zone
        option name 'wan'
        option masq '1'
        option mtu_fix '1'
        option input 'REJECT'
        option forward 'REJECT'
        option output 'ACCEPT'
        list network 'wan'
        list network 'wan6'
        list network 'wg0'
        list device 'wg0'
config rule
        option name 'Allow-DHCP-Renew'
...

config forwarding
        option src 'lan'
        option dest 'wan'

network:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fabe:cf1b:62e1::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config device
        option name 'eth0'
        option macaddr '61:37:e2:98:4e:74'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ip6assign '60'
        list ipaddr '192.168.2.1/24'

config device
        option name 'eth1'
        option macaddr '61:37:e2:98:4e:73'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 4'
        option vid '1'

config interface 'wg0'
        option proto 'wireguard'
        option defaultroute '0'
        option private_key 'xxxxxxxxxxxxxxxx='
        option listen_port '34907'
        list addresses '10.12.230.114'

config wireguard_wg0
        list allowed_ips '0.0.0.0/0'
        option endpoint_port '1337'
        option route_allowed_ips '1'
        option public_key 'xxxxxxxxxxxx='
        option endpoint_host '85.17.53.52'
        option persistent_keepalive '0'

[kds69]

I tried either with either without. no difference

[psherman]

Do you get a handshake?

[kds69]

Hi,
I guess not, wg show returns...nothing:

root@OpenWrt:~# wg show wg0 latest-handshakes
root@OpenWrt:~#

[psherman]

Run a quick test of the basic wg config using a mobile device or a computer with fireguard installed. Basically the idea is to connect with a single device (such as your phone) using the standard wireguard app and your configuration. This will help validate the configuration so that we can guarantee that it is all good (i.e. keys, IP addresses, port, etc.).

[kds69]

to avoid any confusion. I am not running my own wireguard VPN server, I am trying to use my VPN provider wireguard services (Cybeghost).
To get my client/peers config, I use a VM linux, and then replicate settings. It worked once.... but once only.

[psherman]

@kds69

to avoid any confusion. I am not running my own wireguard VPN server, I am trying to use my VPN provider wireguard services (Cybeghost).

Right -- I figured you are not in control of both sides. That's one of the key reasons we need to know if your basic configuration is actually functioning. If it isn't, you'll just be chasing your tail.

@kds69

To get my client/peers config, I use a VM linux, and then replicate settings. It worked once.... but once only.

I'm not exactly sure what process you're referring to here. But what you need is the following:

From the VPN provider:

• VPN endpoint IP address and port
• VPN public key
• VPN Preshared key, if any
• VPN tunnel IP address

And on the other side, you must have a way to provide the provider with your peer public key.

[kds69]

Thanks for taking the time

I actually have all the above with me.
My VPN provider offers wireguard install on linux machine.
I use this to bring up a wireguard connection on a virtual machine that I run on my Windows 10 PC.
I test tunnelling (ipleak), can browse web etc and all looks good.
With the above I retrieve WG parameters that I need to replicate same on an wireguard interface (wg0) on my openwrt router, which I assign to wan zone.

Thing is that something makes my openwrt router to ignore my wg0 interface. I can't tell what is failing there is nothing in the logs that could guide me to anything (my competences are just zero since I'm new to openwrt)

[psherman]

It shouldn't matter, but try assigning your wireguard network interface to a new firewall zone (maybe called wg). Then forwarding from lan > wg.

[kds69]

I tried this as well... maybe not properly as I am newbie
something like below...

but this would not address the handshake part... seems wg0 is not even trying to connect to peer, isn't it?

[psherman]

wg does not need to forward to wan and lan. You can setup wg to be exactly like WAN (including the input/output/forward and masquerading settings). [EDIT for clarity: the above is true since your VPN is effectively an outbound connection, not a 'road warrior' type setup for remote access]

But you're right, that won't address the handshake.
Is the below configuration EXACTLY the same (other than formatting) as what you are using on the linux system that you said worked?

@kds69

config interface 'wg0'
        option proto 'wireguard'
        option defaultroute '0'
        option private_key 'xxxxxxxxxxxxxxxx='
        option listen_port '34907'
        list addresses '10.12.230.114'

config wireguard_wg0
        list allowed_ips '0.0.0.0/0'
        option endpoint_port '1337'
        option route_allowed_ips '1'
        option public_key 'xxxxxxxxxxxx='
        option endpoint_host '85.17.53.52'
        option persistent_keepalive '0'

[psherman]

Another question: Have you disabled your WG tunnel on the linux machine when you are trying to connect using your router? If not, that is a key factor -- you can only have a single connection at a time.

[kds69]

Indeed, I suspend my VM linux abruptly, and then start my interface on openwrt (and eventually reboot)

What I figured out is that there is something with the private-key. If I use the one provide by my VPN provider (based-64 as it should), the interface doesn't seem to run:

but if I use a private-key generated by openwrt, then the interface runs... but handshake never happens:

[psherman]

You won’t get a handshake if the keys aren’t exchanged properly.

You should have the public key from the vpn service. You will use this in the peer config section.

You will generate a key pair - the private key will be used on your config in the interface config section. you need to provide them with the public key that you generate in the process. They should have a way for you to upload your public key.

[kds69]

Don’t get me wrong, I have with me both private and public keys from my VPN provider.
My point is that in openwrt wireguard won’t even try to connect if I used them as is. Whereas if I use the private key generated via « Generate Key » button, the openwrt wireguard will actually at least try to connect (without connecting successfully though). That's what my 2 screen prints illustrates.
First screen print shows that obvisouly there is no attempt to connect to peer 8with guenuine private key), whereas the second one shows it does try unsuccessfully though (with openwrt generated private key, which I don't really mean it could successfully connect anyway).

So, due to my lack of expertise I don’t know what it means, but it seriously looks like a bug or incompatibility of openwrt wireguard engine the private keys from my VPN provider or soemthing triggered by the generation in wireguard screen that doesn't happen otherwise.