opnsense
Import Wireguard client from another system and reuse the QR code and wg0.conf in 'edit peer', ability to edit dns server and tunnel subnet ip address
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [yes] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [ yes] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Is your feature request related to a problem? Please describe.
I have been using wg-easy and wanted to move to opnsense. The plan was to copy all the config across and job done. The issue is that address does not seem to exist in 'edit peer'.. By address I mean the unique ip address each client gets on the tunnel subnet
Describe the solution you like
I would like the fields in 'peer generator' to be present in 'edit peer'. This would enable you to alter them if need be. importantly it would also allow you to export the wg0.conf or use the QR code after the peer generator was used. After creation it is also impossible to change the dns server of a client via 'edit peer'
Describe alternatives you considered
A clear and concise description of any alternative solutions or features you considered.
Additional context
Add any other context or screenshots about the feature request here or links to relevant forum thread or similar
The peer generator is intended to generate new peers, even if you would be able to select an existing peer, it wouldn't help a migration as the private keys are private to the client (and not stored on OPNsense). If you want to bulk import peers, it's likely easier to use our api and push peers into their respective container (which is the peer overview).
I have the public keys, I have the private keys. I have entered them. But nowhere on the page can I change the tunnel subnet ip address in 'edit peer' which is absolutely vital for routing to work.
With regards to the API, imo everything you can do through the api which is functional, should be possible through the GUI, otherwise you're making a situation where the only fix is custom curl commands which affects usability. In addition pushing clients in bulk through the api is likely only to be time effective when you have more than 25 or so peers to create, otherwise it would probably be quicker by hand by the time you've put together the api requests, extracted the data, trouble shooted etc.
In addition it would always be useful to be able to see the wg0.conf in edit client, as well as the qr code in case you ever need to use them again, or modify the configuration.
We're probably not talking the same language here, the gui should offer anything you need, which is the same as available via the api (even more if you count the qr-code generation for new peers).
Wireguard uses an interface configuration (which is the responsibility of the node) and list of accepted peers, nothing more nothing less. A node (OPNsense for example) knows it's own address and the networks it will accept.
Documentation on how this works can be found on our end as well https://docs.opnsense.org/manual/vpnet.html#wireguard
If I create a peer via peers, and not peer generator I should still get a QR code and wg config imo. I should also have the option to edit the DNS entry.
My point is more that edit peers does not contain the same rich functionality that peer generator has. Arguably I might add that peer generator should be called when you click the plus sign in 'peers' and shouldn't really be a tab in it's own right (again imo).
I understand your point, the problem is that peers should not contain the data needed to create the client config for security reasons.
If that is the case then why create and show it in the first place like the 'peer generator' does ?
Maybe the solution is a checkbox allowing you to choose if you want to save it or not ? If opnsense is really going to stand firm on the private key is private then you shouldn't ever see them, nor create them, and the ease of use goes out the window.
It stands to reason that if someone has access to the peer entries either through the Web UI or the API it doesn't really matter at that point if the private keys are there or not. They have the ability at that point to create a new peer or alter an existing peer with different keys. In other words, at that point you're already "owned" and any other security considerations are moot. Leaving out the ability to fully configure or reconfigure an existing peer just makes the service frustrating to deal with.
The peer generator with QR code is an excellent addition. I'm disappointed that this is the reason you can't get QR codes for existing peers.
Just chiming in to express my strong support for this feature request—it would make managing our 40+ users significantly easier as we continue restructuring our network.
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.
It's been 63 days, not 180 - regardless, can someone with permissions please reopen this issue ?
Chiming in to show support. As mentioned above, if someone can access the webgui they can do whatever they want anyway, you're owned. Why cripple admins over imaginary security? Please reopen this.
I would also like this feature as a first-time opnsense convert running into this problem (or at least the option; let the end-user decide what's "secure" in their setup). Every imbedded instance of wireguard I've used allows you to go back in and re-download the config or re-display the QR code. The only alternative is to save QR's and copy/pasted configs to files but that really seems less secure to me to have files floating around vs. a unified secured server source. Furthermore, troubleshooting: when a peer has a problem it would be invaluable to just examine the config server-side rather than dealing with a client device. And, also having the ability to edit all of the settings after creation and just re-deploy via QR or config file vs. starting from scratch or editing on the client device.
