openwrt
luci-app-wireguard: Missing option to configure peer address
The Wireguard peer configuration section is missing the address field. I am not aware of configurations omitting the address parameter. It would be handy to set that in the peer configuration so the exported configuration as well as QR code will automatically include the parameter.
At least on Android, the Wireguard app will complain if no address is set and one has to be entered manually after scanning the QR code from the OpenWrt peer config generation page.
In case this is desired behaviour (i.e. to export configs to peers without an address and manually set it on the respective devices), please consider this issue void.
Steps to reproduce:
- Go to: Network → Interfaces → Wireguard → Edit → Peers tab → Edit a peer
Actual behavior:
- The option to set the
addressparameter is not present - As a result, the generated peer config does not contain any
addressparameter
Expected behavior:
- An option to set the
addressparameter for a peer in the peer configuration settings - The
addressparameter is included in the generated peer configs (text and QR code)
Additional Information:
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='22.03.1'
DISTRIB_REVISION='r19777-2853b6d652'
DISTRIB_TARGET='rockchip/armv8'
DISTRIB_ARCH='aarch64_generic'
DISTRIB_DESCRIPTION='OpenWrt 22.03.1 r19777-2853b6d652'
DISTRIB_TAINTS=''
Hm but that generates the parameter AllowedIps for the Peer section and not Address for the Interface section. So that setting would indicate which packet sources are accepted from the connected endpoint. Which is how it is supposed to be used and apparently mapped correctly by the Luci interface.
You have to enter an IP in the Allowed IPs section. For example 192.168.34.2/32.
Well but what would I do if I want to use Allowed IPs for its intended purpose? Say I want to configure the peer with Address 10.0.0.2/32 in the Interface section and want to set AllowedIps 192.168.0.0/24 so the device can receive packets from that specific range?
In that case the generated config and QR Code will contain the AllowedIps parameter, as to its intended usage. Still, there is no address parameter for the Interface section and I need to configure that manually on the target device, for which the configuration is used. Otherwise (at least on Android), it won't even try to establish a connection.
Ok,
here are two scenarios. The screenshot QR codes are obfuscated because the endpoint contains a public IP and scanning the QR code would set that as endpoint.
-
config1 contains a single IP address in the
Allowed IPsfield. Yet in export1 it can be found in theAllowediPsparameter of theInterfacesection. As to your logic, you would expect to see anAddress 10.0.0.32entry in theInterfacesection, where an empty red box is drawn now? That would not make sense because it would use theAllowedIPsparameter of Luci incorrectly and in two different ways depending on if a single IP or a range is entered. -
config2 contains an IP range in the
Allowed IPsfield. As expected, in export2 the range can be found in theAllowedIPsparameter of theInterfacesection.
So in summary, there is no way to enter an IP address in the peer config section in Luci in order for it to show up as Address parameter in the Interface section of the exported configuration.
I hope this makes my issue clear now?
To configure an IP address on the interface, you must enter the corresponding IP in IP Addresses. That is in case the device in question is a "client".
The reason why support for that was not implemented is that it does not appear to be an official option according to man 8 wg. We could add it - but what are the requirements?
Is it a single address or can it be multiple (IPv4 + IPv6)?
Must the addresses lie within the subnets of the router side wireguard interface addresses?
Shall we enforce uniqueness among all peers or allow duplicates?
Shall we automatically allocate a new IP when adding a peer and prefill the field or leave it empty?
What if the user changes the subnets (addresses) of the wireguard interface, shall we clear out all peer addresses or keep them?
Ah, thank you for clarifying. That at least makes sense. So i guess the current path to success (at least on Android) is to scan the QR code and add the IP Address parameter in the app itself.
So i guess the current path to success (at least on Android) is to scan the QR code and add the IP Address parameter in the app itself.
imo, that is poor user experience because it requires whoever is doing the scanning to magically come up with an IP that's not already in use. That is why this is best handled by Luci. It could at least check whatever [Interface] Address is manually assigned to the given peer against the other peers.
imo, that is poor user experience because it requires whoever is doing the scanning to magically come up with an IP that's not already in use. That is why this is best handled by Luci.
Nobody disagrees, but then LuCI has to "magically come up with an IP that's not already in use" and this has to be better defined before we can implement it. See considerations three comments above.
Is it a single address or can it be multiple (IPv4 + IPv6)?
It can be none, one of that or both at the same time and even multiple ones. I would suggest the same input field as used in AllowedIPs.
Must the addresses lie within the subnets of the router side wireguard interface addresses?
The router side wireguard interface does not need to have an interface adress at all, I would not enforce anything other than it should be a valid IPv4 or IPv6 adresse.
Shall we enforce uniqueness among all peers or allow duplicates?
In the beginning it should be sufficent to omit any check for that in order to keep it simple. For example with static DHCP/DNS entries there is no check and dnsmasq does not start if you input duplicates, but I would also keep it simple by omitting the check because I could imagine a scenario where somebody would do
Shall we automatically allocate a new IP when adding a peer and prefill the field or leave it empty?
No, just keep it optional like the private key field.
What if the user changes the subnets (addresses) of the wireguard interface, shall we clear out all peer addresses or keep them?
Just keep it simple, as said before the wireguard interface does not need to have an IP and even if it has one it does not need to be in the same subnet.
In summary I think it would be very helpful to add an optional field like "Private Key" name "Addresses" with the same input type as "Allowed IPs" field and just add the input from there to the generated config.
Hi folks, one PR for for the Addresses field is here, and there is also one for the DNS setting here. I didn't do MTU yet, but if someone really wants it, I can add it. First time contributing so let me know if anything is amiss. The PRs will conflict with each other, but I can fix that after as well.
@jow- I updated my PRs above(https://github.com/openwrt/luci/pull/6352 and https://github.com/openwrt/luci/pull/6351) to address feedback and merge conflicts, let me know your thoughts.
TBH I don't fully understand the outcome of this issue, but in any case I have a similar issue that may be identical or at least very strongly related to this one.
The entry field where you can define the client address when you create a new peer is still called "Allowed IPs" in OpenWrt 24.10, see the screenshot I'm attaching to this issue:
It should be called "Address," however.
(When I generate a config file from what I entered into the field, it will show up as follows:
[Interface]
...
Address = 192.168.9.6/32, fd00:9::6/128
It should be called "Address," however.
https://www.man7.org/linux/man-pages/man8/wg.8.html#CONFIGURATION_FILE_FORMAT_EXAMPLE
[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820
[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
Endpoint = 192.95.5.67:1234
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24
[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
Endpoint = [2607:5300:60:6b0::c05f:543]:2468
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16
[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
Endpoint = test.wireguard.com:18981
AllowedIPs = 10.10.10.230/32
TBH I don't fully understand the outcome of this issue, but in any case I have a similar issue that may be identical or at least very strongly related to this one.
The entry field where you can define the client address when you create a new peer is still called "Allowed IPs" in OpenWrt 24.10, see the screenshot I'm attaching to this issue:
It should be called "Address," however.
(When I generate a config file from what I entered into the field, it will show up as follows:
[Interface] ... Address = 192.168.9.6/32, fd00:9::6/128
This is not a problem: when you configure for a peer, you also configure for the host: from the host perspective, it needs to know what allowed_ips are allowed through the tunnel for the client. From the client perspective, it assumes that the allowed_ips are its interface IPs. This field has a dual purpose. The client config assumes the allowed_ip as its interface IP.
This is why AllowedIPs = 0.0.0.0/0, ::/0 is added for the client peers - so the remote client can route traffic to any destination.
@systemcrash Thanks, Paul.
I must admit I'm even more confused now. :-(
According to the man page you quoted, Address would not be an allowed field in the Interface section. So, I thought "Maybe the man page he quoted was outdated?" Therefore, I looked at the offical, latest man page, and even according to that doc such a config item would be invalid.
And what makes it even more confusing is that all clients I tested (Android, Mac) accept said config item as valid and follow it.
Would be great to hear your clarification, I must be missing something?
(The other explanations you gave make sense, I can understand them. Thanks a lot.)