[GH-ISSUE #2627] Generic Wireguard Client Configs for Universal Wireguard support #5677

Open
opened 2026-08-05 01:04:32 -04:00 by saavagebueno · 0 comments
Owner

Originally created by @snailzrus on GitHub (Sep 21, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2627

I have some devices and VMs running OpenBSD that support Wireguard right out of the box, but cannot connect to Netbird because there is no Netbird client available for OpenBSD.

Describe the solution you'd like

A simple solution I can think of is to add a new "Generic Wireguard Client" option to the 'Add Peer' button. Selecting this option would need to lead to a wizard so you can define things like a Hostname, details about the region & OS, group memberships, and what existing network route rules should apply to it.

Once you have completed selecting the options you would like, Netbird could generate a wireguard config file and necessary keys. The config file would need to have the new peer's netbird IP, the netbird control/relay server address, and the Allowed IPs list for the network routes you selected. An Admin should be able to copy this info into their generic Wireguard client of choice and simply connect as a hub-spoke solution.

As well, at any point afterwards, you should be able to click on the Peer in the Peers section and edit the info you initial set (hostname, etc), but also adjust the Network Routes made available to the Generic Wireguard Client. After saving changes, a new config file should be made available for an Admin to go manually update on the endpoint. It would be ideal to have a warning pop-up when making a change to routes, warning the Admin that they need to go update things manually.

Limitations of a generic config:

  1. Without a Netbird Agent installed, the endpoint wouldn't be able to establish any p2p meshing, and would only be able to do a hub & spoke style connection.
  2. The endpoint wouldn't be doing any sort of auth, purely relying on the keys, but this is already something that Exit Nodes & Setup Keys provides. If an Admin wants to remove or revoke access, they can just delete it from the Peers section to kill the tunnel and erase the keys on Netbird's side.
  3. Any changes to network routes would require an Admin to manually update the config for a Generic Wireguard client accordingly.

Describe alternatives you've considered

It looks like work is going into a FreeBSD client already. While OpenBSD and FreeBSD are different, a client compiled for FreeBSD may work out of the box, or with minor changes, on an OpenBSD system.

Originally created by @snailzrus on GitHub (Sep 21, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2627 ## Is your feature request related to a problem? Please describe. I have some devices and VMs running OpenBSD that support Wireguard right out of the box, but cannot connect to Netbird because there is no Netbird client available for OpenBSD. ## Describe the solution you'd like A simple solution I can think of is to add a new "Generic Wireguard Client" option to the 'Add Peer' button. Selecting this option would need to lead to a wizard so you can define things like a Hostname, details about the region & OS, group memberships, and what existing network route rules should apply to it. Once you have completed selecting the options you would like, Netbird could generate a wireguard config file and necessary keys. The config file would need to have the new peer's netbird IP, the netbird control/relay server address, and the Allowed IPs list for the network routes you selected. An Admin should be able to copy this info into their generic Wireguard client of choice and simply connect as a hub-spoke solution. As well, at any point afterwards, you should be able to click on the Peer in the Peers section and edit the info you initial set (hostname, etc), but also adjust the Network Routes made available to the Generic Wireguard Client. After saving changes, a new config file should be made available for an Admin to go manually update on the endpoint. It would be ideal to have a warning pop-up when making a change to routes, warning the Admin that they need to go update things manually. ### Limitations of a generic config: 1. Without a Netbird Agent installed, the endpoint wouldn't be able to establish any p2p meshing, and would only be able to do a hub & spoke style connection. 2. The endpoint wouldn't be doing any sort of auth, purely relying on the keys, but this is already something that Exit Nodes & Setup Keys provides. If an Admin wants to remove or revoke access, they can just delete it from the Peers section to kill the tunnel and erase the keys on Netbird's side. 3. Any changes to network routes would require an Admin to manually update the config for a Generic Wireguard client accordingly. ## Describe alternatives you've considered It looks like work is going into a FreeBSD client already. While OpenBSD and FreeBSD are different, a client compiled for FreeBSD may work out of the box, or with minor changes, on an OpenBSD system.
saavagebueno added the feature-request label 2026-08-05 01:04:32 -04:00
Sign in to join this conversation.
No Label feature-request
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#5677