WINBOX 4 WIREGUARD --> RE-IMAGINED

[anav]

When I started using Winbox4, and wireguard, I realized it needs much work! The GUI IMHO is not particularly useful, efficient, or intuitive. Everything is mushed onto one page and one has to sift up and down to find the right information to enter and of course we know there are errors in the current implementation ( allowed IPs being one ). Then there seems to be half thought or more likely incomplete processes presented (in development).

For example, there is an import function is located on the main wireguard interface page, but how do you know which interface this is supposed to apply to? Are you importing an wireguard interface or a peer? When one selects and interface, there is no IMPORT function, which would be the more useful place to have an IMPORT selection??
I personally cannot think of importing files at the router or MT device yet, but there may be some good use cases. I would rank this low on priority.

To compound the strangeness, when you click on an interface, there appears to be an EXPORT function. All one is doing is creating a file name and sending it to the FILES menu in Winbox. There is no option to select which peer has been created for export ???Similarly to the EXPORT function, how do you actually select which peer one is exporting?

Thus if MT is still in development for these items, it would be a good time to sit down and figure out what are the most common scenarios to generate peers and what information is required…and the following discussion/presentation is what I came up with.

The only assumption I make is that one has first created the wireguard interface and the logic follows.
Please feel free to tear apart, or ADD etc. to make it better!!!

[anav]

DISCUSSION:
(1) New Wireguard Interface Creation Process
Discussion: Overall. the current Wireguard Interface creation menu (New) is acceptable except for the ambiguous nature of the private key. A plus symbol is used to indicate a manual private key entry, typically only used in a third-party VPN scenario, where the private key is supplied to the admin. Not intuitive in the least is that if one makes NO selection of private key, and then selects APPLY or OK, a private and public key pair will automatically be generated. This is valid for creating a public key that will be used for all other peers that generate their own key pair. To remove ambiguity and for a better UI experience, suggesting the options be made clearer.

Selecting Auto Generate would then display a private key and a public key in the grey areas.
Selecting Manual would allow entry to the box to the right. After key entry, the public key would be generated below it. Only the manual key box would be modifiable.
Each interface creation typically has two other related activities that need to be executed. The first is an input chain rule, however we are not suggesting this for automation or entry here, as placement of the rule is an admin decision. The second item, that is not mandatory but is used 99.9% of the time, is the address of the wireguard network
Thus proposing that the addition of the address can be done here (Optional). Suggesting that the current text entry of TYPE WIREGUARD.

The wireguard interface can be created without IP address, it is optional. If the IP address is entered here, it auto-populates the corresponding fields in /ip address.
Upon completion of the wireguard interface, the ROUTER Should provide an warning message that states a wireguard IP address should be created at /IP ADDRESS.
This would only be shown if the Optional field was NOT utilized.
…

[anav]

Discussion for the Peer Creation Options:

(2) New Peer Creation Process
Discussion: The current peer creation process is an attempt to squeeze a number of processes into one page and from a UI perspective fails to be an intuitive and clear approach. After some review, even though there is overlap in these processes it is felt that the distinct scenarios would be useful markers for entry. These markers would be Manual Peers (key-pair generation at both ends), Third Party VPN (no local peer key generation) , and Automated Peers ( no remote peer key generation). As well we will take advantage of MT BTH type functionality in terms of the concepts of automating peer profiles as well as exporting peer profiles. Upon review, it is not possible to overlap entries without causing confusion and we will use automation/logic as much as possible to simply entry.
…

…

…

Suggesting that three options be presented to the admin based upon available wireguard interfaces. The next three diagrams depict when the Admin Has selected NEW PEER and NEW is now highlighted. Instead of bringing up the peer creation page, it merely makes the three types of Peers Visible to the right of NEW. The admin chooses the appropriate type which then opens the Peer Creation Page and takes him/her to the start of the appropriate section of the peer creation page. The first sample view shows when no Wireguard interface has been created and thus one cannot create any new peers. The next , depicts what is available when no Wireguard interfaces are available/created with a manually entered private KEY, and the last, if ONLY wireguard interfaces with manual private keys have been created.
…

…

[anav]

Manual Peer creation ( key-pair creation at both ends )

This process addresses setting up the router as a client peer for handshake and setting up incoming client peers. The entry process for ‘manual’ will consist of first entering the Interface Name from a pull-down menu. The next common entry argument is public key from the peer. The next entry should be allowed-addresses. That concludes the most basic entry, and Apply/OK could be entered at this point. In the case of the router being a client for handshake, including the mesh setup, then the next entry is endpoint address. The endpoint port is defaulted to the Router listening port but is modifiable. The next entry is persistent keep alive. This constitutes the second entry criteria and selecting Apply/OK is valid. There other available option is pre-shared key.

3rd Party Peer creation ( no local key-pair creation).

This scenario covers the use-case for when the Router is a client peer for handshake from any other device and typically it’s a 3rd party VPN provider. The difference from Manual Peers is that the private KEY is generated by the 3rd party, not by the MT device. The 3rd party ( or other MT router ) provides a private key for you to use to generate the key pair and thus your public key is already known at the remote device.

The first entry will be interface identification and the router will default to the first Interface on the list with a manually entered private key. This will be followed by the endpoint information. After the selection of Allowed Addresses, and Persistent Keep-Alive, the basic entry has been reached and Apply/OK can be selected. Additional optional entries are available, such as Name of peer, Comments and pre-shared key.

Automated Peer Creation and Dissemination ( no remote key pair generation )

The final menu selection area allows the admin to quickly generate Peers with a one-way path for information, meaning that there is no swapping of keys. In this use-case, the router generates a random private/public key pair for the client peer. The receiving remote peer will not be required to generate a key pair and will already have its public key on the MT router and will also receive the Routers public key (from interface settings) in the file export.

The first entry is Interface selection. You will have noted that the admin has the option to create the wireguard IP address when creating the Wireguard Interface. Once the member enters in the Interface Name, and an IP address has not yet been selected the Admin will be prompted/warned to input the IP address BEFORE PROCEEDING. None of the other entries will be available until a wireguard ip address has been entered. When available the next field, the client address will be defaulted to the next available sequential wireguard IP address and is modifiable. The next entry is Client DNS and it defaults to wireguard gateway address of the router and is modifiable. Next is the endpoint address which defaults to the routers mynetname.net and is modifiable. The endpoint port is not required as it is pulled from the interface listening port. Allowed IPs are then entered and defaults to 0.0.0.0/0 and is modifiable. Finally, the Persistent-Keep alive setting, defaults to .30s and is modifiable. MTU defaults to the interface MTU, but is modifiable. That constitutes the basic entry point for selection of Apply/OK

Once completed, the admin will have the option to export (push) the peer file via the medium of file transfer chosen, OR be able to provide the peer client with an URL (pull) location that they can download the file from. An export file can be in two forms, a QR code jpeg, or the standard Wireguard export format.

After selecting Apply/Okay for the automated peer, the router displays a visual representation of the QR Code, probably to allow someone to take a photo/snip to send to others. Next to the QR code will be Two Export Selections for the admin and only one can be chosen. After the choice the FILE NAME field is available to accept or modify. If one selects URL download the Share location will be available and default to internal memory but is modifiable to a path entry for a file share location (external media). Expiry of never will not be permitted for security and storage reasons. Limit is 48 hours. An optional share key is available for the URL download.

EXPORT

The last bit of cleanup concerns importing and exporting of wireguard files. We have the EXPORT option as part of Automated Client Peer creation, because it makes most sense to put our export efforts there. If MT is willing to expand this effort then suggest the EXPORT TABLE also be made available when creating Manual Peers as well. This would alleviate some of the work of the ADMIN but keep in mind the client device would still need to execute a key pair and send the admin the remote device public key. I see no real advantage at this time to contemplate any import functionality.

[anav]

Blue squigglies on the diagrams are my attempt to show mandatory entries.
One should note that much is based upon having made the wireguard interface first, as this is a reasonable assumption.
Where possible, admins may or may not select fields depending upon logic.
Ignore the poor quality and non-standard type MT entry icons/usage as I am art-challenged and used clipnsave, and paint.

Please feel free to critique and improve the presentation/format/logic !!!

[anav]

BLANK FOR FUTURE IDEAS

[anav]

On feedback from MT, some changes could be made to re-arrange the menus and thus the next attempt will be to do so, while preserving the overall concept of form follows function.

The approach to the wireguard interface is simply superior and should be adopted, including the option to add IP address from this location.
…

…

The same goes for the options available but they will be presented on the SINGLE PEER page instead of the WIREGUARD MENU.
Thus one will still select NEW to access the peer creation page.
…

…

[anav]

1. Due to a better understanding the Responder Function, it is now clear to me that MT had it correctly positioned to be associated with each peer and not the entire interface as I thought.
   However, I have decided to leave the RESPONDER checkbox on the interface page due to the fact that its likely that 99% of the time, every admin will choose the MT device acting as a server peer to have responder only activated. One of the few exceptions one doesnt want to be able to hammer the “other” peer ( aka with initiating a connection ) is the MESH scenario and in this case on would not want to check the box.

I would thus ADD the Responder checkbox to all peers added to the interface automatically, so that if for somereason the admin wanted it unchecked for specific peers (although rare) it would be possible.

In terms of smart programming
Responder checkbox grayed out for 3rd Party key generation for that interface ( manually entered key generation)
Responder checkbox applied automatically for MT own device key generation for that interface ( automatic key generation )

2. Additionally, after better understanding the problem of pinholes and UDP traffic and firewalls, its clear that resetting the wireguard connection is the only course of action and the simplest way to do that is to change the src-port of the client peer for handshake. The router should be able to monitor/detect if there are any responses to the initial handshakes, and if not take action accordingly.
   Assuming the admin wants the router to do so. The additional box for this action is added in the revamped diagram.

Note: OFF by default.

[anav]

…

…

[oskarsk]

Please share your thoughts, community. Is anyone using WireGuard and looking to change or improve anything from a user interface perspective?

[anav]

Hi Oskarsk,
Besides thinking about adding the functionality/option of “amnezia”, to summarize… , for any reader, this thread was designed to:
a. recognize the three main types of wireguard connections
b. attempt to make configuration as smooth and easy as possible
c. to automate sharing of config to clients etc as easy as possible.

When attempting to describe requirements, it became clear that the three wireguard setups involve:

1. when both sides generate private and public Keys ( MT router and other devices - manual )
2. when a third party server provides the private key for both ends. ( MT router is a client device )
3. When MT generates both private and public keys for devices (MT router is server device - automated)

One should be able to identify any wireguard instance in one of the three selections. Note this is not meant to replace BTH, which is a separate USE case, for when ones Router has no public IP address and one still wants to be able to remotely connect to local subnets and/or config ones own router.

However, using the functionality uncovered in BTH (added by MT RoS), we should be able to create QR codes or config files with correct information for especially CASE 3 above!

Not a gui presentation expert by any means. My initial attempt, according to MT feedback was to complex and thus the latest rendition was aimed at mostly a one page config setup displayed to the admin.

The key to keeping wireguard config simple is to maximize logic. Clearly the first step in the wireguard process is for the admin to create a Wireguard Interface. It is at this step that, besides the obvious name, the admin identifies to the MT, whether the Private key is being auto generated by the MT router ( covers case1 and case3) OR is a manual entry from a third party device/provider ( case2 ).

Other Interface Boxes:

• we optionally allow the wireguard Ip address and subnet to be entered here vice having to move screens and go to /IP address.
• we default Responder only to SELECTED, when auto generate is selected ( MT likely server ) and is automatically applied to all client peers ( unselectable at peers).
• we allow selection of src-port rotation ( when MT is client device to combat known issues - resets the handshake )

The logic continues when selecting a new peer.
The first step is to identify the INTERFACE ( by pull-down)
The admin then selects the available presented options.

• If automated Key was selected then Manual and Automated Peers are available.
• If manual Key entry was selected the Third Party Peers selection is available.

The most interesting and NEW work, is the automated peers. Borrowing from BTH, we want to setup an easy method for the admin to provide unique private-public keys for each device. They all of course will get the common public key generated by the MT router for the single wg interface.
Once the requisite information is filled out for the first peer, then, for subsequent peers (endpoint port, address and keep alive are default copied from first peer)

One should not that the MT router will READ the IP address for the interface and will provide the next sequential IP address to send to the next client device peer by default.

Borrowing some more from BTH, we use the Routers capacity to generate and temporarily store QR code and Config Files for sending to clients, and thus have a robust, flexible EXPORT function.

++++++++++++++++++++++
Final thoughts.
I have not covered importing but at least we should be able to import.
a. any standard config file/QR code for when the MT router is a client for handshake on a wireguard network
b. a config file/qr code generated by another MT router ( recipient of automated send )

Please feel free to point out any issue, missing items or potential improvements to the above.

Lastly, I am also asking MT staff to implement available linux code functionality to address our ability to use wireguard on Secondary WAN connections. This is handled by property (fwmark) that is found within normal linux wireguard structure. This property allows all packets emitted by wg to be marked on creation. This would allow us to apply appropriate config changes to ensure incoming WG on wan2 would go back out wan2. We stumble upon this during RoS as most people do not know that the wireguard interface does not apply/decide source IP like other protocols.

[lurker888]

The single biggest strangeness I see about the current interface is that the “client-” type parameters, that are only used for client config and QR code generation are at first glance mixed up with the normal and essential parameters of the local side of the wireguard peer.

I think having the ability to generate configs straight in the UI is a nice thing, but the parameters used only for this should somehow be completely delineated: with a literal line? a heading? on another tab? Also, it should be made clear (in the UI itself) that knowledge of the other side’s private key is not a requirement, and for the more security conscious is actually counter to advice.

@anav

Lastly, I am also asking MT staff to implement available linux code functionality to address our ability to use wireguard on Secondary WAN connections. This is handled by property (fwmark) that is found within normal linux wireguard structure.

I think I must comment on this. What would be the infinitely useful addition would be VRF or routing table awareness similar to other services. (Without patching the kernel this obviously involves use of fwmark.)

Progress in this area is definitely noticeable for most other services; I especially like the way it was done for OpenVPN. Obviously there are priorities at work, and I for one think that fixing the Ecotec ethernet MACs for the new hEX series was indeed more important than this.

[anav]

Agreed, its very confusing when assisting to see all the ‘noise’ of the client config, on the MT router peers settings and making this aspect clearer or less confusing, IF REQUIRED TO BE SEEN, should be done.