| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
| |
Debian Buster uses the nftables framework by default.
|
| |
|
|
|
|
|
| |
(That is, remove algorithms from Suite-B-GCM-128.)
Cf. https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
and https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations .
|
| |
|
|
| |
There is no need to bother with X.509 cruft here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use a dedicated, non-routable, IPv4 subnet for IPSec. Furthermore
the subnet is nullrouted in the absence of xfrm lookup (i.e., when there
is no matching IPSec Security Association) to avoid data leaks.
Each host is associated with an IP in that subnet (thus only reachble
within that subnet, either by the host itself or by its IPSec peers).
The peers authenticate each other using RSA public key authentication.
Kernel traps are used to ensure that connections are only established
when traffic is detected between the peers; after 30m of inactivity
(this value needs to be less than the rekeying period) the connection is
brought down and a kernel trap is installed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead, generate a server certificate for each host (on the machine
itself). Then fetch all these certs locally, and copy them over to each
IPSec peer. That requires more certs to be stored on each machines (n
vs 2), but it can be done automatically, and is easier to deploy.
Note: When adding a new machine to the inventory, one needs to run the
playbook on that machine (to generate the cert and fetch it locally)
first, then on all other machines.
|
| |
|
|
| |
Also, use ESP tunnel mode instead of transport mode.
|
| |
|
