OpenBSD uses ifconfig(8) for creating and managing interfaces. The OpenBSD kernel supports wg(4) since a few years already, so there are no external tools required in that sense.

https://xosc.org/wireguard.html

from rosenpass.

Yes, it doesn't really make sense to talk about “the BSDs.” OpenBSD/FreeBSD/NetBSD are distinct operating systems that have diverged years ago. Each one needs to be considered separately.

from rosenpass.

@clausecker Thank you for your valueable feedback! The reason why the next release is delayed, is because we were trying to port rp ourselves. We will try to make the new release at the end of next week.

from rosenpass.

@emilengler Thank you. I will get to it next week.

from rosenpass.

I think we made the required adjustments, closing. Feel free to reopen if it doesn't work on BSD somehow.

from rosenpass.

@clausecker A port to FreeBSD of the script would be most welcome! Let us know if you if you get stuck somewhere 🙂

from rosenpass.

todo

The ip command can not be used to set up the WG interface on BSD. We should update the script to perform platform detection and use the right commands to setup WG for FreeBSD and OpenBSD.

from rosenpass.

@clausecker @moritzbuhl @emilengler What commands would we need on the various BSD platforms? I think the main hurdle is creating the interface, right?

from rosenpass.

@koraa I've sent you my patch for the rp script to make it compatible to FreeBSD a while ago. The commands are all in there. They are very similar to, but slightly different from OpenBSD.

from rosenpass.

@koraa I've sent you my patch for the rp script to make it compatible to FreeBSD a while ago. The commands are all in there. They are very similar to, but slightly different from OpenBSD.

Wonderful! I forgot about that!

@@ -1,4 +1,4 @@
-#!/usr/bin/env bash
+#!%%BASH%%
 
 set -e
 
@@ -67,7 +67,7 @@ frag_init() {
   explain=0
   frag_transaction=()
   frag "
-    #! /bin/bash
+    #!%%BASH%%
     set -e"
 }
 
@@ -200,13 +200,13 @@ exchange() {
 
   frag "
     # Create the Wireguard interface
-    ip link add dev $(enquote "${dev}") type wireguard || true"
+    ifconfig wg create name $(enquote "${dev}") || true"
 
   cleanup "
-    ip link del dev $(enquote "${dev}") || true"
+    ifconfig $(enquote "${dev}") destroy || true"
 
   frag "
-    ip link set dev $(enquote "${dev}") up"
+    ifconfig $(enquote "${dev}") up"
 
   frag "
     # Deploy the classic wireguard private key
@@ -314,8 +314,6 @@ main() {
   project_name="rosenpass"
   verbose=0
   scriptdir="$(dirname "${script}")"
-  gitdir="$(git -C "${scriptdir}" rev-parse --show-toplevel 2>/dev/null)" || true
-  nixdir="$(readlink -f result/bin/rp | grep -Pio '^/nix/store/[^/]+(?=/bin/[^/]+)')" || true
   binary="$(find_rosenpass_binary)"
 
   # Parse command
@@ -333,6 +331,8 @@ main() {
       *) fatal "Unknown command ${arg}";;
     esac
   done
+
+  kdload -n if_wg || fatal "Cannot load if_wg kernel module"
 
   test -n "${cmd}" || fatal "No command supplied"
   usagestack=("${script}")

Is the #!%%BASH%% strictly necessary? I would like to merge openbsd support using platform detection and I think that syntax is FreeBSD only?

from rosenpass.

We replace %%BASH%% with the actual location of the bash binary during installation. You can ignore that bit. And I think it should read kldload, not kdload; must have been a typo. This is to load the Wireguard kernel module.

from rosenpass.

On FreeBSD there are two ways to create wg(4) WireGuard interface. Either create it directly driver name and unit number e.g. ifconfig -- wg0 create or let the kernel clone one using the lowest available unit number ifconfig wg create. In the later case ifconfig(8) will write the name of the created interface to stdout. Cloning can be combined with renaming into a single ifconfig invocation to ifconfig -- wg create name wg-foo, but the creation an renaming isn't atomic. It's possible that an interface is created, but the renaming fails. In this case ifconfig exits with an exit code != 0, but still writes the interface name to stdout. It's the callers responsibility to read the name of the created interface from stdout and if the exit code isn't 0 to destroy the created interface e.g. ifconfig -- "$name" destroy.

Instead of using a locking protocol to avoid race conditions (e.g. locking configuration file with lockf(1)) the caller can also check the result to recover from them e.g. if ifconfig(8) failed to to create and rename the interface, after cleaning up the temporary interface check if there exists an interface of the desired name and if it's a WireGuard interface. The wg(8) uses membership in the wg interface group to indicate that in interface is a WireGuard interface. A better way to check for this (e.g. a WireGuard media type) would be nice, but afaik none has been implemented.

from rosenpass.

Renaming an interface does not release its unit number. If you run ifconfig -- wg create, it returns wg3 and you rename it to wg-foo (using ifconfig -- wg3 name wg-foo) you can't create a new wg3 directly using ifconfig -- wg3 create, because that asks the kernel for unit number 3 of of the wg driver, but you can have the kernel pick the next free unit and rename it to wg3 because the name is just an interface name (a unique up to 15+1 null terminated string). Confusing, but confirmed using truss and dtrace sigh.

from rosenpass.

Yes, it would be more natural to have the kernel pick an interface name and only provide supplying an explicit interface name as an option.

from rosenpass.

Dear BSD experts, is there currently a consensus on how the script should look like to work with BSDs as well?

from rosenpass.

To my understanding naming interfaces is not compatible between OpenBSD and FreeBSD. I hacked it together for OpenBSD by adding a description. jasperla/openbsd-wip@a2b40ca

from rosenpass.

At that point I am quite indifferent on how we should continue.
On one hand, we could try adding support for each BSD ourselves. On the other hand, we could hope that someone from the FreeBSD/OpenBSD/NetBSD Team decides to maintain a Rosenpass port themselves (of course we would try our best to not make their lives any harder).

Each approach has their own advantages/disadvantages. Maybe we could find a compromise, by staying in active touch with the potential ports maintainer?

from rosenpass.

I have already written a rosenpass port for FreeBSD back when 0.1.1 came out. The one thing missing to make it complete was support for listening to IPv4 and IPv6 separately, which was completed with #27. Since then I'm waiting for you to make a new release so I can complete and release the port. Patching the rp script is trivial and standard part of the porting/packaging process. So I'm really not sure why you still have not made a release since then.

from rosenpass.

@emilengler Thank you for the update. If possible, check if you can make a prerelease to give porters/packages a way to identify potential issues before the main release.

from rosenpass.

@emilengler Thank you for the update. If possible, check if you can make a prerelease to give porters/packages a way to identify potential issues before the main release.

I will tell this to the release manager.

from rosenpass.

@clausecker We've tried to improve the situation of the rp script on FBSD. There's a release candidate tagged on git now. https://github.com/rosenpass/rosenpass/releases/tag/v0.2.0-rc.1

from rosenpass.

@emilengler I can confirm that 0.2.0-rc.1 works fine on FreeBSD. I have prepared a preliminary port which you can find here: http://fuz.su/~fuz/files/rosenpass.tar.xz

To build the port, execute the following commands on a FreeBSD system:

fetch http://fuz.su/~fuz/files/rosenpass.tar.xz
tar xf rosenpass.tar.xz
cd rosenpass
make all
make install

Once 2.0 is released for real, I will go ahead and push the port to the ports collection.

from rosenpass.

Amazing! @wucke13 would you mind tagging 0.2.0 for real?

from rosenpass.

Perhaps you could check if the documentation for rp(1) could be improved slightly (see #116). It was unclear to me what the IP address in the setup example stood for; this tripped me up a bit.

from rosenpass.

Perhaps you could check if the documentation for rp(1) could be improved slightly (see #116). It was unclear to me what the IP address in the setup example stood for; this tripped me up a bit.

Sure. I will have a look at this today or tomorrow.

from rosenpass.