Wireguard client QR Codes in Glinet Gui are wrong

There is a bug in the qr codes Glinet web interface generates since from the beginning. Brume 2 fw 4.7.4 but it was wrong in previous versions too.

If you scan the code on clients, like for example Wireguard Android, it results in wrong configuration for the allowed ip list. It gives back the server allowed ip list, not the client allowed ip list.

Example:

the code results in

[Peer]
AllowedIPs = 10.0.0.3/32

which is the allowed ip list for the WG server, not the WG client.

After scanning the code, you always need to manually edit the list again on the client, for example into:

[Peer]
AllowedIPs = 10.0.0.1/32, 0.0.0.0/0

The default option should be "AllowedIPs = 10.0.0.1/32, 0.0.0.0/0" meaning reaching the wg server and then also route all traffic to it.

I disagree.

VPN is mainly for connecting two networks, not for pass-through all traffic.
This is, indeed, an option - but not by default.

the qr code is just wrong from the beginning with AllowedIPs = 10.0.0.3/32 for the client (that is the allowed list for the server). you cant reach anything with that. not even what you said as default.

then you need to do it like this

AllowedIPs = 10.0.0.1/32, 192.168.8.0/24

AllowedIPs = 10.0.0.3/32 is for the SERVER, which the qr code gives back which is just wrong.

ERGO default qr code should for exmple be

AllowedIPs = 10.0.0.1/32, 192.168.8.0/24

and then have a toggle button the qr code generation "route intenet traffic"

reasulting in

AllowedIPs = 10.0.0.1/32, 192.168.8.0/24, 0.0.0.0/0

and also another toggle option to "allow client to client"

AllowedIPs = 10.0.0.0/24, 192.168.8.0/24

I think the bug just come if you manually set clients like this in the options

@bruce Guess you need to have a look?

1 Like

Yea this Allowedips need to be checked closely because they can mean two different things to a client or a server, (I haven't checked this myself in the gl software.)

Example:

For a site to site configuration this needs to be done on the server, but should never return to the qr code for clients, if it shows /24 it would be wrong.

You should view them as routing options for the server exclusive.

If a peer is configurated, the address should be a derived /32 based on the /24 so that each site to site peer work as expected, allowedips can be custom such as 0.0.0.0/0 or specific ips but not perse the peer address this implies its only for adding routing options from the client.

Edit:

Here is a example how I did it on my own source code.

The allowedips is for the wgserver for the peer, when I click to show QR in the luci-proto-wireguard, I get a new window for allowedips to generate the client config. :+1:

1 Like

Thats my point. It seems whoever implemented the QR code generation for the Glinet webinterface didnt have this in mind. The QR code just gives back the WG server configuration, not what the Clients need for the allowed ip entry.

The generation GUI needs to be extended for example like this:

default:

AllowedIPs = 10.0.0.1/32 (wg server ip)

client to client:

AllowedIPs = 10.0.0.1/32, 10.0.0.0/24

VPN cascading:

AllowedIPs = 10.0.0.1/32, 0.0.0.0/0

Reach LAN:

AllowedIPs = 10.0.0.1/32, 192.168.8.0/24 (router lan ip subnet)

1 Like

The QR code is automatically generated depends on the actual profile created by the server, the QR code and the content are correct.

Your feedback probably is a feature request, which means when you manage to create the profile in WG server, and it should be supported to add more customize configuration.

No. Again it is wrong. What is not to understand about this?

AllowedIPs = 10.0.0.3/32

is the server allowedips for that client, not the client allowedips for that server.

Currently, the implementation is the latter. I think it's okay being that way. All the exported options are for attributes of a client. Allowip can relate to many functions, but no need to make them all build upon it.

For "the server allowedips for that client", when we want to access the client's subnet from the server network.
We have route rules:
4.8


4.7

They may be renamed for clearer and closer to the concept of allowips.