Hi folks,
I spent some time trying to understand how BTH works and the functionality being slowly introduced with it, at the same time I was learning to use winbox4. It was clear to me BOTH were unfinished pieces of work with exciting promise. I therefore attemtped to harness the new functionality and improve the config process for US to implement wireguard solutions in the thread linked below.
MT staff are very much interested in developing the gui further and are asking for input HERE.
Please read the thread and comment if able, either in support of the presented scope or other ideas you may have to improve the process. Feel free to, and are encouraged to, ask questions or poke holes.
If I am allowed to go off-topic for a question, I have an issue with Wireguard (that has nothing to do with Mikrotik’s implementation) with the way the Windows client works, more properly how the (stupid) client creates a new interface (and network) at every boot which has two consequences, at every boot:
it asks if the new network is public or private
the name of the interface is incremented by one (I am now a wg 13 on the machine I am using for the test)
I have googled a bit about this issue but it seems like this is not seen as a primary issue by the developers or that the users are accepting it without making much fuss.
I have found only a few suggested possible workarounds, but without any real confirmation that they actually work properly.
So assuming that not everyone using wireguard uses Linux, how do other people on the forum using Windows and Wireguard deal with this issue (if they do)?
I use my iphone primarily and have not played at all with the windows client. Very surprising that it changes interface on you?? Are you stating that you can setup your client to connect remotely to an MT server and the next time you boot up all your config is lost??
Please do comment on the other thread as well, if nothing else, if you like the concept and proposal and if not, how it can be improved!!
No, the Wireguard connection in itself works just fine, and as well settings are kept just fine.
What happens Is that every time Wireguard starts (i.e. at each boot) It installs a new (virtual) network adapter ( similar to when you install a VM like Virtualbox or VmWare).
The (stupid) Windows finds a new network adapter with its own network settings and wants to know if this new network Is to be considered public or private.
UNLIKE the VM ones, this Wireguard virtual interface disappears when you stop the Wireguard client OR shutdown.
At next boot a NEW Wireguard interface Is installed BUT for some reasons the name of the old one remains sticky somewhere so this new interface gets a new suffix incremented by one (it starts as wg1, then wg2, etc.).
Since this name is different from the previous one, for Windows it is a new network, so It asks to classify It as public or private and the cycle repeats.
Workarounds (which I have not yet tested) are seemingly revolving around installing/starting the Wireguard as service or running batch/powershell scripts at boot time removing (from the Registry or wherever they are) the traces of the previous install (so that the name remains always the same wg1, even if “new”).
I have this issue only on Windows 7. On 10 and 11 it keeps the same network name and network profile after reboot. As a workaround for Win7 I’ve set a tick to consider all new networks as Public and changed some firewall rules for Public profile to make all needed services work.
On all of my Windows machines I no longer use the WireGuard GUI client (on most of the devices, the GUI program even has never been started), because I always run Windows with unprivileged user accounts and that GUI requires full admin right at all time.
Running that GUI program is not necessary. All you need after having the installed the official WireGuard Windows client is:
For each WG configuration (.conf file) run this once to create the Windows service, for example if you have two WG1.conf and WG2.conf profiles:
This will create Windows services with the name WireGuard Tunnel: <.conf file name>, for the example above WireGuard Tunnel: WG1 and WireGuard Tunnel: WG2 that you can control like any Windows services (setting startup mode Auto/Manual, start/stop with net start/net stop, or Powershell, or services.msc…).
If the service starts, then the tunnel is running with the adapter named WG1 or WG2 (name of the .conf file), if the service stops then the adapter is removed. But the name will always be predictable, and you will not be re-asked about the Public/Private zone.
If you want to make change to the connection setting, stop the WireGuard Tunnel: xxx service, edit the xxx.conf file with Notepad, then just restart the WireGuard Tunnel: xxx to try the new changes.
If you want to see the tunnels’ status, run the command wg show in an elevated (ULA) command prompt window.
If you no longer want the tunnel associated with the WG1.conf file for example, remove the Windows service by running:
The problem is not with adapter name. The problem is with network location name. These are 2 different things. Adapter name always remains the same, but network location name changes each time, because this stupid driver removes and creates a new device after each reboot. And because every new device has a new identifier, Windows thinks it’s a new network adapter, creates a new network location for it, and asks its type in Windows 7. In 10/11 the driver probably behaves differently.
I no longer have Windows 7 installations to test, but the behavior cannot be blamed on the WireGuard driver, because it does the same thing on all supported versions. At least under Windows 11, the “WG 15” label you see under the adapter name in the Control Panel Network Connections listing depends on the device instance path, the SWD\WireGuard\**GUID** that you can see here:
For the same adapter name, you get different labels if the GUID has changed, that GUID is calculated based on the conf file name, keys, number of peers, public keys and allowed addresses of the peers from the config file:
If none of these parameters has changed, then you’ll get the same device instance path every time the tunnel service starts and adds the network adapters, and Windows retains the full add/remove event log for the adapter and keeps associated settings. If you change one of the data listed above in the config file, then you’ll get a different device instance path and Windows treats it as a different network adapter.
If you haven’t modified the .conf file at all, and reboot your Windows 7, does Windows 7 treat the network adapter as a new adapter every time?
I would agree that any attempt to make the process much easier with the clear inclusion of what information is mandatory and what is optional. That goes for keys, which are server side and which are client side. Some of which I see is included in @anav’s excellent Re-imagined post.
However, according to the code, the GUID should not change unless name/key/peers names/peers allowedIPs have changed (you have the algorithm that generate the GUID in the code above). The only issue I can see is that the generated GUID is not really a real GUID because can result in unsupported values in the “version” 4-bit field of the GUID and maybe Windows 7 rejected that.
Well, theoretically it could be checked by adding function result to the log in this code and then comparing it with actual adapter GUID on both Win7 and 10, but I don’t have enough skills to compile this stuff.
Yep, thanks guys.
I meant Windows 7, apologies for having omitted this not-so-trifling detail.
CGGXANNX’s approach - without the GUI - seems to me a nice solution for the “next” question (that I had not yet asked) which is using the tunnel with an account with non-admin privileges, thanks.
This approach, once the starting (or in case stopping) of the service goes through net start (or sc) can be integrated into a batch (or powershell script) that “cleans” the remains
The smart workaround by Teslasystem while preventing the request for public/private does nothing for the increase in the naming/numbering.
I’ll have to do some experiment with the Registry, there must be a way to remove the old instances or however stop the increasing of names.
Maybe - just maybe - something can be run in the PreUp or PreDown of Wireguard itself (with DangerousScriptExecution enabled).
