Pre-Script: I'm probably in a bad mental state to reply, but I want to
answer some valid questions before others reply. Please take what I say
and how I say it with a grain of salt. I don't mean anything personally.
I /do/ appreciate the constructive and thought provoking responses that
I'm getting.
On 4/6/21 1:07 PM, Sid Spry wrote:
Can you clarify why you need to use IPsec?
I don't have a /need/ in any normal sense. But I do /want/ to mess /
play with and learn about /IPsec/. -- I have used many other VPNs;
OpenVPN and WireGuard. But I'm finding my understanding of IPsec
lacking, hence my desire to learn about /IPsec/, specifically
/transport/ mode.
If it is to support a commercial client you may be better off
handing them a system based around BSD.
*blink*
Nothing against any of the BSDs, or any other Unix for that matter. But
... I think this is a /Linux/ mailing list. ;-) So ... suggesting
something other than Linux seems counterproductive.
More flexibility will be had from Linux, but pfSense/OPNsense gives
you a point and click web terminal which is easier to train in house
IT on due to the documentation available.
I'd like to add IPFire to that list. Especially considering that it's
Linux based. ;-)
The modes are also usually sufficient -- site to site tunnel (like
the appliances you're used to using), intranet protection, and routing
options for the same.
"Usually" being the operative word. "Sufficient" being in the eye of
the beholder.
*I* /personally/ _frequently_ fall outside of "usually". Being the
person that I am, what is "sufficient" for the vast majority of people
leaves me wanting.
If you control everything you can use wireguard or OpenVPN.
If it wasn't for the fact that I'm wanting to play with / learn about
IPsec, I would completely agree with you. However, my desire to learn
about /IPsec/ is in direct conflict with your otherwise reasonable
suggestion.
To answer some of your later questions in summary:
1. Of the projects libreswan seems to best maintained, though openswan
still releases regularly. I would start with libreswan. For racoon,
see https://www.netbsd.org/docs/network/ipsec/rasvpn.html.
2. Yes, see
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2.
Don't worry about embedding key material in your scripts (unless
you expect someone has bugged your monitor). The key material has
to be on disk in some form anyway.
Please allow me to elaborate.
I view -- what I understand to be the quintessential mode of operation
for -- Pre Shared Keys to have a security weakness ~> flaw in that both
ends must know the PSKs used for each direction. Thus compromising
either end completely compromises the security of the connection.
Further, if we assume that a per-system key is used for {en,de}cryption
(pick one, I don't think it matters which), then we can probably further
assume that the same per-system key is used for {en,de}cryption with
other additional systems. As such, compromising the PSK(s) on one
system likely compromises at least one of the PSK(s) for other systems.
Whats' more is that PSKs tend to be static. -- Maybe there are ways
with IKE to use PFS to ensure minimize damage done by knowing PSK(s).
I feel like most, if not all, of this is avoided by not having PSK(s) or
other keying material in scripts and on systems.
We are probably all familiar with having a TLS certificate key pair on
systems these days. So if we can leverage and re-use those key pairs,
that would be Really Nice™.
Typical usage has the tunnel creation commands referencing key
material.
There is a difference in referencing a PSK and referencing a key pair.
Especially when looking at the output of ps.
Bash disables history in noninteractive shells by default.
I feel like relying on a default, which can be changed, is not a good
basis for security. }:-)
3. Drop opportunistic encryption. It's best if you or the user knows
if the network is secure or not.
Agreed.
The O.E. is more to allow other systems to be able to communicate with
my system /more/ securely if they want to.
There are also ways to have IPTables allow IPsec protected traffic while
blocking unprotected traffic. Thus providing the hard pass / fail that
I think you're alluding to.
4. The authentication header (AH) does not provide
"security."
What does "security" mean?
I agree that AH does not provide /confidentiality/.
Encapsulating security payload (ESP) provides confidentiality and,
if selected, authentication. Check the docs -- usually you want
authentication and confidentiality, merely confidentiality allows
some classes of attacks.
I will check out the authentication option for ESP.
Though, I suspect it's going to be quite a bit more difficult to pull
off a MitM with ESP that's only providing confidentiality assuming that
proper authentication has recently happened in conjunction with
establishing the SAs being used by ESP, a la. IKE.
5. Transport mode may be most appropriate, however you could have
tunnels between all servers
The addition of tunnels very likely means the addition of additional
interfaces and IPs. Which means that now systems inherently become
multi-homed, which is it's own set of problems.
for redundancy.
Please elaborate on what you mean by "for redundancy" here.
I see it as the tunnel likely won't function if the main connection is
down. It's not like an OoB backup connection.
6. Setting up the public key infrastructure will be most of the
headache.
I'm really hoping that there is a way to leverage / utilize something
like Let's Encrypt's (et al.) /existing/ PKI and re-use the existing certs.
Doesn't seem manual if you've got a script for it. A lot of people
stop here.
It's manual in that it currently requires human intervention and that
there isn't automatic re-keying.
If you need consulting time I can offer it, but reading the linked
pages should get you far enough along. I won't mind answering things
in public but do wonder about your interest in IPsec.
Hopefully I've answered some of your questions and have explained where
I'm coming from and why I'm looking at /IPsec/ *specifically*.
--
Grant. . . .
unix || die
