wireguard kernel implementation

[Kieeps]

Any new on the progress of the bsd kernel? Read somewhere a while back that it was being pushed to kernel, did it ever land?

And will the plugin currently in opnsense move from userspace to kernel when it gets implemented? :-)

[Greelan]

FreeBSD 13 now has the kernel module so I guess it will come to OPNsense when 13 does (the 13 stable is tentatively scheduled for release by end March)

[Kieeps]

Good news :-) it'll be fun to see if it has any noticeable improvements over the current implementation :-D

Keep upnthe great work!

[Greelan]

I've got no connection to OPNsense, just keen to see the kernel module too. [emoji3] It will definitely have better performance

[Greelan]

I'm also not sure how long typically OPNsense lags behind FreeBSD/HardenedBSD releases, so it could be a while after 13 stable is released

[chemlud]

22.7 or 23.1?

[mimugmail]

FreeBSD 13 itself is not even stable yet

[franco]

The wireguard module is a good candidate for stable/12. The iflib preparations for this module are already backported. With pfSense 2.5 almost out and being based on FreeBSD 12 it's very likely this is going to happen within this year since they always said the userspace implementation is bad and they would rather wait for the "real" thing.

https://redmine.pfsense.org/issues/8786

;)


Cheers,
Franco

[Greelan]

Nice, thanks Franco!

[JeGr]

https://www.netgate.com/blog/wireguard-for-pfsense-software.html

With a new snapshot of pfSense 2.5pre incoming tomorrow and as it's based on 12.2 I suspect the Kernel module if_wg is (al)ready (to be) backported? So it shouldn't take long to bring it further to HardenedBSD I suspect :)
Looking forward to a new kernel space implementation and read speed benchmarks :D

[mimugmail]

Nice!  8)

[chemlud]

Does the kernel implementation have better logging? I could not find anything in my opnsense system logs, except for some errors when the peer is offline (for rebooting). Or does it need higher log level?

[mimugmail]

I'd guess everything stays the same since the userland tool wg-quick doesn't change, it's only crypto offloading to kernel.

[JeGr]

Couldn't find anything about more logging. Even the newly created docs of the pfsense snapshots tells you in the bullet points:

* It operates completely in the kernel
* Configuration is placed directly on the interfaces
* It has no concept of connections or sessions
* There is no "status" of the VPN (e.g. it isn't considered up or down, it has no visible timers, etc.)
* It has no facilities for user authentication
* There is no service daemon to stop or start
* There is only minimal logging from the kernel
* It does not bind to a specific interface or address on the firewall, it accepts traffic to any address on the firewall on its specified port

As it is virtually "service- and status-less" logging would be hard to implement besides errors/messages from the kernel(module) itself. But that's only my understanding, mimugmail may be deeper into that :D

[Patrick M. Hausen]

* It has no concept of connections or sessions
* There is no "status" of the VPN

That's a feature.

"Look, a packet matching my tunnel policy" --> Encrypt with peer's public key, encapsulate in UDP, send to peer instead. Is the peer alive? How the heck should I know?
"Look an encrypted packet" --> Does it come from a configured peer? Does it decrypt with my private key? OK, decrypt, de-encapsulate, throw into ip_input() again.

It's definitely more like GRE or IPIP than, say, OpenVPN. You can do something similar with IPSec, throw away all of ISAKM/IKE and phase 1 and just statically configure phase 2 SAs and keys. Similar result.