I suspect I'm in a bubble, so perhaps someone might tell me what I'm missing...
> racoon2 is a system to exchange and install security parameters for IPsec. It consists of an IKEv1/IKEv2 key exchange daemon, a security policy management daemon, and a Kerberos-based key exchange daemon.
When would you use this over wireguard?
There's a hint in
> for built-in Windows, iOS and Android VPN clients.
where I can see value if you want to provide a VPN without needing to install anything on the client, but that doesn't seem like a big thing to me. Or maybe legacy ipsec setups?
IPsec is standardized, Wireguard isn't. This is a two-edged sword; the standardization process has hurt IPsec quite a lot (to the suspicion of active sabotage) but at the same time it's much easier to get an IPsec setup certified for government use.
(Also, cf. down in the thread, you don't have to deal with the Wireguard people showing up and complaining that you implemented it.)
There is a lot of reasons and now that llms can do the overly complex configs there is actually even less reasons to use wireguard.
The killer feature for us is to be able to push routes to clients (unfortunately macos screwed this up royally in recent releases, so i had to build a custom client)
I think that you missed a very important word in the title and URL. Expand your question with context, and it becomes its own answer:
> When would you use a standalone program for NetBSD that is written in C, over a Linux kernel module with a GPL licence, or a standalone program written in one of two languages neither of which comes in NetBSD base, or a perpetually unfinished kernel module that isn't being worked on that is for the wrong BSD anyway?
No, I didn't. NetBSD, FreeBSD, and OpenBSD all have wireguard support in-tree. That there is a Linux implementation and several portable userspace versions running around is beside the point.
(Edit: And to your other comment downthread - Even if NetBSD's in-tree implementation isn't official Wireguard(TM), it's wire-compatible and functionally identical, which is all that matters for this argument.)
Be careful not to say that in front of WireGuard people. There was a whole discussion of how it explicitly was not WireGuard when wg(4) was merged from Ryota Ozaki's personal fork in 2020.
Reading the thread, I'd say that's a mischaracterization of what happened: it appears that it was primarily a misunderstanding of the netbsd's development and the terminology used therein.
You have not read the thread, then. Because people made the point that wg(4) was not WireGuard, but an effectively clean-room implementation done by a NetBSD contributor based upon public doco. The WireGuard person made the point that wg(4) was not WireGuard, had had no involvement from WireGuard, and was incomplete or even faulty in some way. (I've had a look around, and I cannot find Jason A. Donenfeld coming back later in the intervening years to explain what the vague "halfbaked code"'s problems were. Of course, it's a lot more difficult to search mailing list archives than it used to be. But xe definitely did not come back the next week as promised, at least publically.) There was even a side-discussion about removing mention of the name to make it clear that it wasn't WireGuard.
Oof. Bad sign to see either of these, though for opposite reasons. Broken IPv6 points to way insufficient testing & use. IKEv1 meanwhile is deprecated and rather ought to be removed entirely.
I suspect I'm in a bubble, so perhaps someone might tell me what I'm missing...
> racoon2 is a system to exchange and install security parameters for IPsec. It consists of an IKEv1/IKEv2 key exchange daemon, a security policy management daemon, and a Kerberos-based key exchange daemon.
When would you use this over wireguard? There's a hint in
> for built-in Windows, iOS and Android VPN clients.
where I can see value if you want to provide a VPN without needing to install anything on the client, but that doesn't seem like a big thing to me. Or maybe legacy ipsec setups?
> When would you use this over wireguard?
IPsec is standardized, Wireguard isn't. This is a two-edged sword; the standardization process has hurt IPsec quite a lot (to the suspicion of active sabotage) but at the same time it's much easier to get an IPsec setup certified for government use.
(Also, cf. down in the thread, you don't have to deal with the Wireguard people showing up and complaining that you implemented it.)
There is a lot of legacy IPSec out there. For example AWS Site-to-Site VPN seems to still be IPSec.
There is a lot of reasons and now that llms can do the overly complex configs there is actually even less reasons to use wireguard.
The killer feature for us is to be able to push routes to clients (unfortunately macos screwed this up royally in recent releases, so i had to build a custom client)
I think that you missed a very important word in the title and URL. Expand your question with context, and it becomes its own answer:
> When would you use a standalone program for NetBSD that is written in C, over a Linux kernel module with a GPL licence, or a standalone program written in one of two languages neither of which comes in NetBSD base, or a perpetually unfinished kernel module that isn't being worked on that is for the wrong BSD anyway?
No, I didn't. NetBSD, FreeBSD, and OpenBSD all have wireguard support in-tree. That there is a Linux implementation and several portable userspace versions running around is beside the point.
(Edit: And to your other comment downthread - Even if NetBSD's in-tree implementation isn't official Wireguard(TM), it's wire-compatible and functionally identical, which is all that matters for this argument.)
TBF, there is an experimental wireguard implementation in NetBSD as well.
Be careful not to say that in front of WireGuard people. There was a whole discussion of how it explicitly was not WireGuard when wg(4) was merged from Ryota Ozaki's personal fork in 2020.
* https://mail-index.netbsd.org/tech-net/2020/08/25/msg007861....
Reading the thread, I'd say that's a mischaracterization of what happened: it appears that it was primarily a misunderstanding of the netbsd's development and the terminology used therein.
You have not read the thread, then. Because people made the point that wg(4) was not WireGuard, but an effectively clean-room implementation done by a NetBSD contributor based upon public doco. The WireGuard person made the point that wg(4) was not WireGuard, had had no involvement from WireGuard, and was incomplete or even faulty in some way. (I've had a look around, and I cannot find Jason A. Donenfeld coming back later in the intervening years to explain what the vague "halfbaked code"'s problems were. Of course, it's a lot more difficult to search mailing list archives than it used to be. But xe definitely did not come back the next week as promised, at least publically.) There was even a side-discussion about removing mention of the name to make it clear that it wasn't WireGuard.
> NAT-OA payloads in IKEv1 Quick Mode (RFC 3947)
> IPv6 support fixed and enabled by default
Oof. Bad sign to see either of these, though for opposite reasons. Broken IPv6 points to way insufficient testing & use. IKEv1 meanwhile is deprecated and rather ought to be removed entirely.