Improving and Stabilizing the Racoon2 IKE Daemon in NetBSD

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?

• wmf · 4 hours ago

  There is a lot of legacy IPSec out there. For example AWS Site-to-Site VPN seems to still be IPSec.

• JdeBP · 3 hours ago

  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?

  • rjsw · 3 hours ago

    TBF, there is an experimental wireguard implementation in NetBSD as well.

    • JdeBP · 2 hours ago

      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....

• eqvinox · 2 hours ago

  > 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.)

• yawniek · 1 hour ago

  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)

> 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.