Super clear and complete!
I would just have liked some links or tips to harden this a bit, if the author has some references, would be great!
It’s OpenBSD, so just relax. Hardening is built-in and enabled by default.
While true, we mustn’t become complacent.
Thats why you keep your OpenBSD installs regularly updated.
But you are running a vpn service with a weak cipher?
the defaults are depreciated or compromised? news to me.
the only reason “weaker” ciphers are included is for backward compatibility with end points that support nothing else.
I’m referring to following the guide & deploying a service with modp1024. Not the defaults in OpenBSD.
While it’s a decent configuration, doing IKEv2 with the chacha20-poly1305 ciphers as described here is more secure in my opinion. That being said it won’t work for clients that don’t have the cipher baked in as it violates the RFC (in fact I think only OpenIKED has support).
Indeed, you have to opt for the insecure modp1024 option with OS X clients, because with higher settings it’s not possible OS X client to connect using systems prefs client as described in the guide. (issue is on the OS X side)
Isn’t IPsec reportedly broken? There’s nothing official of course, but slides from NSA are leaked:
OpenVPN looks much better.
By what metric does OpenVPN look better?
Security, flexibility. It’s also far simpler. Read e.g. https://www.schneier.com/academic/paperfiles/paper-ipsec.pdf
while I generally agree simpler often leads to more secure, that paper is from 1999. the IPsec code in OpenBSD is widely used, well tested, and has not suffered the plethora of CVEs the OpenVPN code base continues to suffer.
to each their own, but I would (and do) run base OpenBSD code for VPN duties before anything else, including OpenVPN.
It’s not about the security of OpenBSD’s IPsec implementation vs OpenVPN, but the security of IPsec itself vs OpenVPN. So not about implementation, but the standard itself.