HOWTO: Opportunistic IPsec
Opportunistic IPsec
The term Opportunistic IPsec is used to describe IPsec deployments that cover a large number of hosts using a single simple configuration on all hosts. Adding hosts do not require reconfiguration of all existing hosts. This concept can be used in an Enterprise or Cloud model, but can also be applied to the Internet at large. To use Opportunistic IPsec at an internet scale, see HOWTO: Opportunistic IPsec using LetsEncrypt. This HOWTO describes the Enterprise or Cloud deployment, sometimes also called Mesh Encryption"
How it works
Libreswan defines Opportunistic Groups that specify if network ranges MUST, SHOULD, MAY or MUST NOT be encrypted. When a host within such a group wants to communicate to another host in the group, libreswan attempts to setup an IPsec tunnel. There are two main triggers for this:
- DNS based triggers
This mode intercepts the application's DNS lookup, attempts to setup a tunnel, and then releases the DNS answer to the application. This mode is currently being developed for the 3.20 release.
- Packet based triggers
This mode installs packet based policies into the kernel. When a host wants to send a packet to another host in the group, the kernel will notify libreswan to attempt to negotiate a tunnel. Once the tunnel is established, the traffic for the target host is allowed to go out encrypted. If the tunnel fails, the traffic will either be blocked or is allowed to pass in the clear, depending on the policy for the target host.
Authentication
Any regular IKEv2 authentication method can be used for Opportunistic IPsec, as these connections are regular libreswan configurations, except for the right=%opportunisticgroup entry that defines the connection for Opportunistic IPsec. A common authentication method it for hosts to authenticate each other based on X.509 certificates using a commonly shared Certificate Authority. That is the method this HOWTO will use, as cloud deployments usually already roll out certificates for each node in the cloud.
PreSharedKey (PSK) authentication is possible, but not recommended as one compromised host would result in group PSK secret being compromised as well. Although a NULL Authentication based authentication method can be used to deploy encryption between nodes even without authentication. This mode still protects against passive attackers.
Opportunistic connections
There are currently five built-in connection groups that are defined for different policies. Each of these has a connection ("conn") entry in ipsec.conf and a file in /etc/ipsec.d/policies/ that lists the members in this group.
- conn private
Hosts in this group can only communicate encrypted and no cleartext is allowed. If the tunnel fails to establish, traffic is dropped
- conn private-or-clear
Hosts in this group will attempt to communicate encrypted, but will allow cleartext if the other end does not support IPsec. During the tunnel negotiation, traffic can be helt or passed in cleartext.
- conn clear-or-private
Hosts in this group not attempt to initiate IPsec for encrypted communication, but will accept incoming requests.
- conn clear
Hosts in this group will never initiate or accept IPsec and only communicate in the clear.
- conn block
Hosts in this group are completely blocked. It is similar to using a firewall rule to drop all traffic. This group is a legacy group and usually not in use.
NAT
NAT is supported, but there is a catch. Pre-NAT IP's cannot be trusted. For example, imagine a cloud that uses 8.8.8.0/24 and has a client on 8.8.8.8. If this client would setup an Opportunistic IPsec connection, it would present itself as 8.8.8.8 (The IP address of Google DNS). The responding IPsec server would build up a tunnel to this client using 8.8.8.8. If it had been configured to use Google DNS, this client would now start receiving all of the server's Google DNS traffic. For that reason, if an incoming client is detected to be behind NAT, the server assigns the client an IP address from its pool. The client will map this IP address inside its IPsec subsystem so that it does not need to configure the given IP address on a real interface. It also allows the client to connect to multiple servers and receiving the same IP address without causing a conflict.
Configurations in this HOWTO assume that no NAT exists between the nodes of the cloud.
Example configuration
Below is a documented example configuration. It assumes all nodes in the cloud have PKCS#12 certificate file. If your certificate system did not supply a PKCS#12 certificate file, but seperate files for the key, certificate and CA certificate, you can use the following command to create a PKCS#12 file:
Such a file contains the host certificate and the CA certificate. To import the PKCS#12 certificate into libreswan, run:
ipsec import file.p12
- /etc/ipsec.conf
config setup protostack=netkey #plutodebug="all" logfile=/var/log/pluto.log
include /etc/ipsec.d/*.conf
- /etc/ipsec.d/oe-certificate.conf
conn private-or-clear rightid=%fromcert rightrsasigkey=%cert rightauth=rsasig right=%opportunisticgroup rightmodecfgclient=yes rightcat=yes # Any CA will do because we only load the LetsEncrypt CA rightca=%any # left=%defaultroute leftid=%null leftauth=null leftmodecfgclient=yes leftcat=yes # narrowing=yes type=tunnel ikev2=insist negotiationshunt=drop failureshunt=passthrough keyingtries=1 retransmit-timeout=3s auto=ondemand