Bugs in WireGuard config UI

[Wallifur]

I set up WireGuard VPN server on the router but encountered a few issues that I thought @RMerlin might care about:

• I changed the VPN subnet to a /24 in the 172.16.0.0/12 range, as it's visually distinct from those I typically connect to in 10.0.0.0/8 and 192.168.0.0/16. However, when adding a client peer, the suggested settings for addresses use values from the default 10.6.0.0/24 range, which are both incorrect and hidden in that expando. It would be great if the values were derived from the main subnet setting.
• When adding a client peer, I saw no option to enter my own public key. I assume this means peers' private keys are always stored on the router, which somewhat defeats the purpose of public key cryptography. I understand the convenience, but ideally it would generate peer keys only if not provided, and remain editable after that anyway.
• Under the server's Advanced Settings, the text of the server's public key is unselectable. The private key is, too, but that's usually not needed. On desktop it can at least be copied using a browser's dev tools, on mobile it's basically impossible.

I didn't think these would be specific to my device (AX56U).

Thanks for all your good work. It's breathed a bit more life into my aging hardware, and it was great not having to reconfigure everything when switching to your firmware.

 

[RMerlin]

The WireGuard implementation comes from Asus. Due to the size of this project and being the sole developer, I have to prioritize things. VPN-wise my focus is solely on OpenVPN, so any implementation change in WireGuard would have to come from Asus or a contributed patch. The fact that client keys can only be auto-generated by the router is a known limitation of their implementation, but I simply lack the time to look at possibly improving on this - it's been on my list of things to look into for over two years now...

I can take a look at why the webui doesn't let copy/paste the key. Copy/paste is currently blocked through the entire panel, I will need to check if it's possible to change that or if it's inherent to Asus' design of that panel.

 

[ZebMcKayhan]

• When adding a client peer, I saw no option to enter my own public key. I assume this means peers' private keys are always stored on the router, which somewhat defeats the purpose of public key cryptography. I understand the convenience, but ideally it would generate peer keys only if not provided, and remain editable after that anyway.
• Under the server's Advanced Settings, the text of the server's public key is unselectable. The private key is, too, but that's usually not needed. On desktop it can at least be copied using a browser's dev tools, on mobile it's basically impossible.

Even though the GUI has some limitations, it's still possible to change the keys via SSH: https://www.snbforums.com/threads/wireguard-server-tweaks.85758/post-852124

 

[Wallifur]

The WireGuard implementation comes from Asus.

Ah. It wasn't in my stock firmware before upgrading, so I thought it was your work.

I can take a look at why the webui doesn't let copy/paste the key.

It's probably overridable with a couple of lines of CSS.

Even though the GUI has some limitations, it's still possible to change the keys via SSH

Thanks for that.

 

[RMerlin]

It's probably overridable with a couple of lines of CSS.

Or removing the CSS class that Asus created to prevent copying text from that page.

 

[jksmurf]

I can take a look at why the webui doesn't let copy/paste the key. Copy/paste is currently blocked through the entire panel, I will need to check if it's possible to change that or if it's inherent to Asus' design of that panel.

I was recently setting up my WG connection again (after a FW hard reset) and tried to copy / paste the keys back into the WebGUI (VPN Tab) so I don't have to re-import a new WG profile to all my clients but seems this is still not possible.

Is there a file somewhere in one of the dirs that I can just modify manually?

Thanks!

[EDIT]
The keys seems to be in /etc/wg/server1_client1.conf; at least I can see the old keys in the WebGUI. if you click "apply" though, it makes new keys again, does not save these ones. However it does not work.

I am also not sure what happens to the QR code...

 

[ZebMcKayhan]

I was recently setting up my WG connection again (after a FW hard reset) and tried to copy / paste the keys back into the WebGUI (VPN Tab) so I don't have to re-import a new WG profile to all my clients but seems this is still not possible.

Is there a file somewhere in one of the dirs that I can just modify manually?

Thanks!

[EDIT]
The keys seems to be in /etc/wg/server1_client1.conf; at least I can see the old keys in the WebGUI. if you click "apply" though, it makes new keys again, does not save these ones. However it does not work.

I am also not sure what happens to the QR code...

The keys exists as nvram variables and could be updated via ssh: https://www.snbforums.com/threads/wireguard-server-tweaks.85758/post-852124
The file you found are only latest generated client configs.
If you update the keys you might need to hit apply or something under each peer for it to generate new client config files.

 

[jksmurf]

The keys exists as nvram variables and could be updated via ssh: https://www.snbforums.com/threads/wireguard-server-tweaks.85758/post-852124
The file you found are only latest generated client configs.
If you update the keys you might need to hit apply or something under each peer for it to generate new client config files.

Thank you Zeb, I did see that note earlier but it seemed a lot more complicated than I anticipated. I thought I could just replicate the two key lines.

So I bit the bullet and just made a new key. I'm just finishing off updating my various client devices. but thank you all the same.

 

[RMerlin]

I was recently setting up my WG connection again (after a FW hard reset) and tried to copy / paste the keys back into the WebGUI (VPN Tab) so I don't have to re-import a new WG profile to all my clients but seems this is still not possible.

Is there a file somewhere in one of the dirs that I can just modify manually?

Thanks!

[EDIT]
The keys seems to be in /etc/wg/server1_client1.conf; at least I can see the old keys in the WebGUI. if you click "apply" though, it makes new keys again, does not save these ones. However it does not work.

I am also not sure what happens to the QR code...

They are in nvram. Can't recall the exact variable names, try listing all the server values:

nvram show | grep wgs

 

[jksmurf]

They are in nvram. Can't recall the exact variable names, try listing all the server values:

nvram show | grep wgs

Thank you, so the output of nvram show | grep wgs>MyWGVPN.txt is below. I replaced the various keys with aaa, bbb, cccc and ddd for privacy.

Now, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa= is the Private Key and dddddddddddddddddddddddddd= is the Public key in the profile in the WebGUI.
Oddly the "pairs" a and b are repeated twice, as are "c and d"; but they do not seem to be pairs?

The "pair" "a and d" is what I actually see in the VPN GUI for that profile.

So I guess the question is, for future use by myself (and maybe others), given that I only have one WG profile, which pair is the one that needs to be set and how to set it?

Is it?

nvram set wgs1_c1_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=

OR

nvram set wgsc_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=

and is it?

nvram set wgs1_pub=ddddddddddddddddddddddddddddddddddddd=

OR

nvram set wgs_pub=ddddddddddddddddddddddddddddddddddddd=

followed by?

nvram commit
reboot

wgs1_addr=10.6.0.1/32
wgs1_alive=25
wgs1_c1_addr=10.6.0.2/32
wgs1_c1_caller=Web
wgs1_c1_enable=1
wgs1_c1_name=SmurfWG
wgs1_c1_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
wgs1_c1_pub=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb=
wgs1_dns=1
wgs1_enable=1
wgs1_lanaccess=1
wgs1_nat6=1
wgs1_port=51820
wgs1_priv=ccccccccccccccccccccccccccccccccccccc=
wgs1_psk=0
wgs1_pub=ddddddddddddddddddddddddddddddddddddd=
wgs_addr=10.6.0.1/32
wgs_alive=25
wgs_dns=1
wgs_enable=1
wgs_lanaccess=1
wgs_nat6=1
wgs_port=51820
wgs_priv=ccccccccccccccccccccccccccccccccccccc=
wgs_psk=0
wgs_pub=ddddddddddddddddddddddddddddddddddddd=
wgs_unit=1
wgsc_addr=10.6.0.2/32
wgsc_aips=10.6.0.2/32
wgsc_caips=192.168.9.0/24
wgsc_caller=Web
wgsc_enable=1
wgsc_extinfo=
wgsc_name=SmurfWG
wgsc_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
wgsc_psk=
wgsc_pub=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb=
wgsc_unit=1
wgs1_c1_aips=10.6.0.2/32
wgs1_c1_caips=192.168.9.0/24

 

[RMerlin]

Always use wgs1_*. wgs_* is a temporary storage location used by the webui. When you save, it gets copied to appropriate instance (in this case it will always be wgs1 as there is only one WG server).

 

[jksmurf]

Always use wgs1_*. wgs_* is a temporary storage location used by the webui. When you save, it gets copied to appropriate instance (in this case it will always be wgs1 as there is only one WG server).

Hmm, sorry I am still a little confused as there are wgs1_* and wgs1_c1* versions.
For the WebGUI keys to be replicated it would need to be one of each?

wgs1_c1_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=

AND

wgs1_pub=ddddddddddddddddddddddddddddddddddddd=

From:

wgs1_c1_priv=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
wgs1_c1_pub=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb=
.
.
.
wgs1_priv=ccccccccccccccccccccccccccccccccccccc=
wgs1_psk=0
wgs1_pub=ddddddddddddddddddddddddddddddddddddd=

 

[RMerlin]

wgs1_* are server 1` settings.
wgs1_c1_* are client 1 settings for server 1.

 

[jksmurf]

So in summary: [EDITED] with thanks to @ZebMcKayhan from the post below.

I am writing this mainly for my future reference, but it might help others, if after a Router reset, you want to set up Wireguard (WG) again but do not want to have to export new profile(s) to a bunch of WG Clients, you can import the previous server keys (PrivateKey and PublicKey) into the Router, as follows. This assumes no PSK Keys.

Why do this? Well, because these keys are the only parameters that cannot be easily changed (i.e. reverted to old values) when you create new WG profiles.

1. BEFORE you reset your router, retrieve the old Private and Public keys from nvram!

The format is:

nvram get wgsX_priv AND nvram get wgsX_pub AND nvram get wgsX_cY_priv

where X is normally always 1 and Y=1,2,3..10 according to the number of Client (cY) profiles you have associated with that server. I believe you can only have one WG Server running on these routers and they are not powerful enough for more than one anyway. So, if you have only 1 Client profile, i.e. Y=1, then:

via SSH, from the CLI, issue:

nvram get wgs1_priv
nvram get wgs1_pub
nvram get wgs1_c1_priv

Copy and save these Keys. They will look something like "aaaAAAaAaA/aaaAAAaAaA+aaaAAAaAaA=" and "bbbBBBbBbB/bbbBBBbBbB+bbbBBBbBbB=" and
“cccCCCcCcC/cccCCCcCcC+cccCCCcCcC=“
(with equals (=) signs at the end)

[Side Note Only] issuing:

nvram show | grep wgs>MyWGProfiles.txt

will save the entire set of Wireguard variables contained in nvram to /tmp/home/root# and will also give you (among a lot of other details) the above parameters in one go. You can use WinSCP to pick up that file.

2. RESET your Router

3. Create the New (Old) WG Profile

Under the WebGUI VPN, Others, Wireguard VPN:

Create your "new" (old) profile, using (i) under General, the old "Profile Name" and the "Tunnel IPV4/IPv6" and "Listen Port" Settings and (ii) under Advanced Settings, your options/selections (if you have options that are not default).

Note that Advanced settings shows "NEW" Private and Public Keys, but these cannot be amended here, nor in the VPN Profile "Peer" page.

You can amend (check) you are using the old Username, Address, Allowed IPs (Server) and Allowed IPs (Client) in the profile settings via the WebGUI.

4. SET the Profile Keys BACK to the old values:

via SSH, from the CLI, issue:

nvram set wgs1_priv=aaaAAAaAaA/aaaAAAaAaA+aaaAAAaAaA=
nvram set wgs1_pub=bbbBBBbBbB/bbbBBBbBbB+bbbBBBbBbB=
nvram set wgs1_c1_priv=cccCCCcCcC/cccCCCcCcC+cccCCCcCcC=
nvram commit
reboot

Upon restart, all other parameters being the same as before, you 'should' be able to access your Routers WG server using your existing (unchanged) Client profile(s).

The alternatives of course are:

(I) To get the NEW keys and copy paste them into all your WG Client profiles, if the Client Apps permit; OR
(II) Export the NEW profile(s) and import them to the clients as new profile(s) (which isn't that difficult TBH).

k.

 

[ZebMcKayhan]

via SSH, from the CLI, issue:

nvram set wgs1_c1_priv=aaaAAAaAaA/aaaAAAaAaA+aaaAAAaAaA=
nvram set wgs1_pub=bbbBBBbBbB/bbbBBBbBbB+bbbBBBbBbB=
nvram commit
reboot

Just a Note, if you choose to only update WGS1 Private Key and WGS1_cX Public Key, which indeed is enough to make old clients connect again, you will never be able to make any new devices to this server as WGS1 private and public key are not related anymore. These keys are created as pairs and the public key is calculated based on the private key, they cannot be arbitrary.

I would at least recommend that you retrieve wgs1 public key from your old router/setup:

nvram get wgs1_pub

and write to your new router/setup:

nvram set wgs1_pub=PasteInServerPeerPublicKey

while this will allow you to create new devices for your server, you will still not be able to re-acquire the config files for your old devices if they ever get lost. but when that time comes, you may choose to recreate the device on the server anyway.

of course this all assumes that the user have not used PreSharedKeys, as if that is the case, nothing will work unless these are updated to.

but in my opinion, why not copy all keys while you are at it:
to retrieve them from your old router/setup:

#server peer:
nvram get wgs1_priv
nvram get wgs1_pub
#client1 peer:
nvram get wgs1_c1_priv
nvram get wgs1_c1_pub
nvram get wgs1_c1_psk
#client2 peer:
nvram get wgs1_c2_priv
nvram get wgs1_c2_pub
nvram get wgs1_c2_psk
#a.s.o

to write them to your new router/setup (requires that the device peers are created in the GUI first):

#server peer:
nvram set wgs1_priv=PasteInServerPeerPrivateKey
nvram set wgs1_pub=PasteInServerPeerPublicKey
#client1 peer:
nvram set wgs1_c1_priv=PasteInClient1PrivateKey
nvram set wgs1_c1_pub=PasteInClient1PublicKey
nvram set wgs1_c1_psk=PasteInClient1PSKIfUsed
#client2 peer:
nvram set wgs1_c2_priv=PasteInClient2PrivateKey
nvram set wgs1_c2_pub=PasteInClient2PublicKey
nvram set wgs1_c2_psk=PasteInClient2PSKIfUsed
#a.s.o
nvram commit

 

[jksmurf]

Just a Note

but in my opinion, why not

Thank you so much for that, I was really only going on the advice I got from @RMerlin regarding my specific case and trying to construct a simple how-to for less technically inclined folks such as myself (who are good at following instructions), but you have filled in the blanks and made some really great suggestions, with examples, for this exercise.

Thank you once again.

[EDIT1] I checked your commands and mine do not have any _psk parameters, as expected; nor _c2, as I have just the one profile.

[EDIT2]

I would at least recommend that you retrieve wgs1 public key from your old router/setup:

??? I thought my nvram lines under step 1 did that already ???
What mine did not do, was retrieve wgs1_priv (rather, only wgs1_c1_priv).

k.

 

[ZebMcKayhan]

??? I thought my nvram lines under step 1 did that already ???
What mine did not do, was retrieve wgs1_priv (rather, only wgs1_c1_priv).

via SSH, from the CLI, issue:

nvram get wgs1_c1_priv
nvram get wgs1_pub

yes, you are correct, I missed that. that makes no sense at all (which is probably why I read it backwards). the router does not use its own public key, neither clients private key. they are only there as a reference when generating client config files.

each instance in a wireguard setup requires a set of keys. so the router peer wgs1 has a private and a public key pair that are generated together. client 1 have its own private and public keys, completely separate from router peer keys, they have no correlation at all, but they are very much in relation to each other.

when you start router server it will load a config with its own private key and all clients public keys, nothing else.
any client config will need its own private key that matches the public key in the server peer, and the router public key.
you will notice if you have more than one client that all client config files contains the same public key, this is the router wgs1 public key that needs to match the router wgs1 private key.

so, you see, the router actually only needs wgs1 private key and all clients public keys since that are the only keys it is using. but whenever creating a client peer it needs it's own wgs1 public key to put in the client config files and if this key does not match, encryption will fail and it will not work.

it takes some thinking if you need to collect all keys from various config files as to what key belongs to what. its much more straight forward when retrieving nvram variables and why it works when only copying some keys but it may be confusing about what keys are needed, what will work and what not which is why I wouldn't recommend it. better copy all keys!

 

[jksmurf]

wgs1_* are server 1` settings.
wgs1_c1_* are client 1 settings for server 1.

Coolio.

TBH I really just typed out (what I thought) RMerlin was suggesting, without having too much of an underlying understanding of what I was copying (not the best approach I know).

that makes no sense at all (which is probably why I read it backwards).

OK...

it may be confusing about what keys are needed, what will work and what not which is why I wouldn't recommend it. better copy all keys!

All good. So as long as folks use your two sets of commands as per your post above, the "get, set" operands via nvram get and the nvram set, we're good to go

 

[ZebMcKayhan]

we're good to go

yep, I did it when I wrote the post linked above and it worked without issues. I have even created new peers that could connect via ipv6 which works without issues.

The fact that we have the ability to update the keys and even put Endpoint directive in the server peer means this router is now capable of participating in Wireguard full mesh networks, where several peers could all connect to each other, without any "hub" in the centrum. could be interesting for those running site-2-site with 3 or more sites connected. I have been meaning to write some tutorial on how to set this up, but I haven't seem to found the time yet. Any year now...