It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-end for isakmpd. But that only highlights the fact that much of the complexity of IPSec is due to history, not because IPSec is intrinsically too complex to make it useable. The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code. There are smarter ways to implement IPSec and IKE, especially when you have the benefit of hindsight.
> I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME
It doesn't automate CA renewal, but you can't even do any kind of PKI using WireGuard as WireGuard doesn't support key signing or key authorities.
FWIW, OpenBSD provides a utility for generating and manipulating X.509 certificates for use with IKE.[1] I've never used it as I'm unfortunately quite familiar with PKIX infrastructure and have my own tools, but AFAIU it's what most people use.
None of this is to say that, when comparing apples to apples, WireGuard isn't a better protocol than IPSec. But SSH also has warts and it would be trivial to come up with a better replacement protocol. We don't need to because we have OpenSSH, a smart implementation that continually discards as much baggage as it can, while still interoperating with a wider ecosystem of alternative implementations.
The fundamental problem is that 1) key management is hard, 2) key management is critical to overall safety and usability. WireGuard sidesteps all of this. It looks great on paper because it's only solving the easiest problem. And it seems great in practice because the ugliness of the ancillary infrastructure isn't counted against it, even though from a wholistic standpoint it should.
[1] https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORI...
I haven't checked whether this is true, but even if it is, that's a damning indictment of IPsec, because on Linux, the entire connection establishment is in userspace, and the kernel only handles per-packet encryption and authentication. WireGuard has the entire negotiation sequence, authentication, routing, timeouts, rekeying, etc in the kernel. With IPsec, you need to have a userspace daemon to manage all of that, with significantly more LoC than the bare per-packet essentials. With WireGuard, you just load the keys into the kernel and you're done. I bet that you're also counting Zinc against WireGuard, but not counting the entire crypto API against IPsec (which, unlike with WireGuard, you might end up actually using).
I suspect that it's not actually true though in the first place, once you add in all of the other stuff like iptables -m policy that only exists to support IPsec.
Nice, but it would be nice to know if that is the default or not on Linux as well.
I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also very annoying.