So how do you suggest the generated QR code decides what the IP address and DNS server for the client should be?
I have to correct myself the Allowed IPs do indeed default to 0.0.0.0/0, ::/0
in the client config file
So that looks good.
You could perhaps set the Allowed IPs of the server side as IP address as it is often the same but it is error prone so perhaps not a good idea.
I have seen other implementations on which you can enter specific values for the client config file e.g. DNS, endpoint (it defaults to the routers WAN address ), Keep alive, and Peer address
Just FYI and to provide more context - in case the OP didn't see this:
The discussion on GitHub - developer also notes:
it's not intended for server setups e.g. to provide peer settings to a mobile for a router interface which is acting as a wg "server". Said that, you can create & mix multiple "server" and "client" wg interfaces with different key pairs on the same router etc.
Yet - this is the use case you seem to describe?
Main idea of Wireguard was in its simplicity of configuration and now you say that user is expected to scan QR code and input addiotional information by hand? And they still wonder why IPSec didn't become popular
I think you missed this:
Your use case is not the intended one - just to be clear.
The user doesn't have to enter anything by hand, they can copy the Public Key and transfer theirs the same way - if you want this done by QR - feel free to make a request.
I don't recall the official Android app having a method to copy its key via QR, though.
Is it not expected from a router to know DNS server configaration and allowed IPs on the other end of Wireguard tunnel?
Why would you expect that to be the case?
I believe official Wireguard app is the INTENDED one.
They are just two different IP ranges.
Maybe I'm confused - or you're not seeing the official OpenWrt links and discussions on the official forums and GitHub regarding this subject that I've been posting for your review. So to clarify:
Intended use case of luci-app-wireguard QR Code:
- Migrate an existing peer config (e.g. a Mullvad, Azire, etc.) to a phone
Your description - correct us if we're wrong:
- Create a new peer config
Again this is an OpenWrt discussion forum and not affiliated with Wireguard nor are we affiliated with the Android app.
Not that simple - a misconfiguration will cause traffic to fail:
I wonder how you interpret IP range listed in network.wgclient.allowed_ips (with suffix /32 in case of IPv4 and /128 in case of IPv6) ?
I wonder how you interpret IP range listed in network.wgclient.allowed_ips (with suffix /32 in case of IPv4 and /128 in case of IPv6)
That information was already provided:
I wonder how you interpret IP range listed in network.wgclient.allowed_ips (with suffix /32 in case of IPv4 and /128 in case of IPv6) ?
Right, so in the case of a single /32 (or /128) address you could arguably just put that as the IP address for the client. I agree that would probably work in most cases, but what do you do where the allowed IPs is more complex than that? And it still doesn't answer the question of where the DNS address comes from.
Your description - correct us if we're wrong:
Create a new peer config
I doubt that I can generate QR before peer configuration is already created. So yes, I'm talking about use case you are talking about - about setting up Wireguard app on my Android device.
I agree that would probably work in most cases
That would be the ONLY configuration when it works. So yes, IP address is already known. FInally. What else one could expect from simplest configuration of Android app?
So yes, I'm talking about use case you are talking about - about setting up Wireguard app on my Android device.
OK, cool. So to be clear, you're only asking for OpenWrt to arbitrarily pick a DNS server and include it in the config, correct?
What else one could expect from simplest configuration of Android app?
How do you want OpenWrt to pick this DNS server?
So yes, IP address is already known.
No, it can be guessed at (albeit with a high likelihood of being correct) in one specific use case. What about all the other use cases? Or should that be ignored to just solve your issue?
And it still doesn't answer the question of where the DNS address comes from.
From network.vpn.addresses? Like, let's assume, it equals 192.168.10.1/24. I believe there is DNS server somewhere in those numbers.
On an ordinary server-client setup the Allowed IP on the server side is the tunnels address on the client side.
Allowed IP is which IP is allowed so it makes sense that that is the clients tunnel IP address.
Again this assumes a default "server" on the router and a client e.g. your phone or client PC (which by default NAT out via the WG interface).
Of course it does not have to be, in a site-to-site setup you allow more
But as already noted by others the QR code generated here seems different from what you expected.
To be fair I also expected that you could get a config file just like you get from a provider, but at least you get the keys and the missing items are easy to manually add
No, it can be guessed at (albeit with a high likelihood of being correct) in one specific use case.
Yes, no - you change your opinion very fast. In that particular case (and it is one the most common) you pretty much know IP address of your peer. And it is THE ONLY way this configuration will work.