Created attachment 243735 [details] A WireGuard rc.d script FreeBSD 13.2 and newer include WireGuard support in the base system, but lack an rc.d script to make it easy to take advantage of the imported WireGuard implementation. These are the steps I used before to configure a WireGuard interface: https://blog.rlwinm.de/wireguard-configuration-for-freebsd-13-2 . As a quality of life improvement I reimplemented most of wg-quick(8) features in /bin/sh as rc.d script: https://gist.githubusercontent.com/Crest/c5f408b8d347f41cf3f84bfee6a9224d/raw/8a1f219bf1957d7e1ecbeaa72998961707e27984/wireguard.sh . More details can be found here: https://blog.rlwinm.de/the-missing-wireguard-integration-into-rc-d-for-freebsd-13-2 . I did *not* reimplement the saving the configuration or spawning a daemon that continually messes with the routing table since FreeBSD provides better ways to isolate routing tables (multiple FIBs, vnets).
that looks great, I will look into it. would it be possible for you to open a review in phabricator?: https://reviews.freebsd.org so we can interact and comment inline ? If you prefer this is also doable via a pull request on github.
The rc.d script doesn't work as is on 14-CURRENT because the driver inside if_wg.ko has been renamed from just wg to if_wg. Changing the required_modules from "if_wg:wg" to "if_wg:if_wg" is enough.
(In reply to crest from comment #2) As the module was renammed in https://cgit.freebsd.org/src/commit/?id=61b95bcb42993b24633b280791438266d78f2747 to conform to the convention of prefixing virtual interface driver names with "if_".
(In reply to Baptiste Daroussin from comment #1) I submitted the patch for review: https://reviews.freebsd.org/D41318.
I'll release the PR, as I am going afk for a bit of time, to let other the ability to take it in the meantime, I will grab it back if noone merged it, when I will be back online.
I'm wondering how the routes should be set with this script. None of the two blog posts go into that and the script does not support it if I understand correctly. I'm in the process of preparing my 14.0 upgrades and replacing the old wireguard/wg-quick script, which set the necessary routes for a configuration that looks like this automatically. AllowedIPs = 10.10.10.103/32, 172.17.6.0/24, 10.17.6.0/24 If I manually set them everything works; how can we make this automatic?
The problem is harder than it looks. The wg-quick script contains an ugly hack that amounts to a daemon monitoring a route socket to allow WireGuard not just collect all peers AllowedIPs per tunnel and add an interface route once, but also resolve conflicts inside a single routing table at runtime which is broken by design. FreeBSD has the required features (setfib, vnet) to express such a setup without fragile racy hacks or shells scripts with O(n^2) overhead (with n = number of routes). This is the third version of this shell script and I removed a few features because the rc.d script ran into Greenspun's tenth rule and turned /bin/sh into a dynamically scoped LISP. That version contained higher order functions to loop over peers and their settings for use in the {Pre,Post}x{Up,Down} hooks which would make it trivial to inject the routes from the PostUp hook. The version I've submitted in this PR lacks such features. To automate it using this rc.d script you have to parse the WireGuard configuration inside a hook. It implements both the wg-quick style hooks (it executes them in /bin/sh instead of /bin/bash) and well as call into /etc/rc.d/netif allowing all the usual ways to hook interfaces configuration changes to work too. I can dig out the "semi sentient" rc.d script if you really want to dig through it, but the version in this PR already contains code to extract only the fields understood by the kernel from a wg-quick configuration. As long as you only want to collect the AllowedIPs per interface without preserving which peer they belong to collecting the AllowedIPs into a single variable would work the same as collecting multiple Address lines into a single variable.
Just to spell out the implications of calling /etc/rc.d/netif from the wireguard rc.d script: Static routing works for WireGuard tunnels like any other interface via rc.conf. If you need just three routes you can use something like this: sysrc static_routes+=" route1:wg0 route2:wg0 route3:wg0" sysrc route_route1="10.10.10.103/32 -iface wg0" sysrc route_route2="172.17.6.0/24 -iface wg0" sysrc route_route3="10.17.6.0/24 -iface wg0" to have netif call routing to set up static routes tied to a specific interface. The routes only need a next hop interface because from kernel IP stack point of view WireGuard interfaces are point to point interfaces. The next hop resolution on among the peers is done according to the peer AllowedIPs configuration. The details of this so call cryptokey routing are documented in the WireGuard whitepaper. It may be a layering violation offending purists, but I prefer it over the complicated fragile Cisco style DM-VPN with NHRP providing dynamic multi-point GRE next-hop resolution (or not).