SecureConnect Setup
Enterprises have requirements to encrypt in transit data in many environments, particularly in PCI and other regulated environments. Encrypting in transit data is straightforward for an enterprise when the data is moving between datacenters. An enterprise can deploy dedicated security appliances (such as VPN concentrators) to implement IPsec-based communication across open untrusted networks.
However, what if an enterprise needs to encrypt in transit data within a VLAN, datacenter, or PCI environment, or from a cloud location to an enterprise datacenter? Deploying a dedicated security appliance to protect every workload is no longer feasible, especially in public cloud environments. Additionally, configuring and managing IPsec connections becomes more difficult as the number of hosts increases.
SecureConnect Features
SecureConnect has the following key features.
Supported Platforms
SecureConnect works for connections between Linux workloads, between Windows workloads, and between Linux and Windows workloads.
Supported Encryption Protocols
These are the encryption protocols/ciphers enabled by SecureConnect when configuring IPsec between servers:
sha1-aes256sha256-aes256aes256sha256-nullsha1-null!
aes256-sha256-modp2048aes256-sha1-modp2048aes256-sha1-modp1024aes256-sha384-prfsha384-ecp384
IPsec Implementation
SecureConnect implements a subset of the IPsec protocol called Encapsulating Security Payload (ESP), which provides confidentiality, data-origin authentication, connectionless integrity, an anti-replay service, and limited traffic-flow confidentiality.
In its implementation of ESP, SecureConnect uses IPsec transport mode. Using transport mode, only the original payload is encrypted between the workloads. The original IP header information is unchanged so all network routing remains the same. However, the protocol being used will be changed to reflect the transport mode (ESP).
Making this change causes no underlying interfaces to change or be created or any other underlying networking infrastructure changes. Using this approach simply encrypts the data between endpoint workloads.
If SecureConnect is unable to secure traffic between two workloads with IPsec, it will block unencrypted traffic when the policy was configured to encrypt that traffic.
IKE Versions Used for SecureConnect
SecureConnect connections between workloads use the following versions of Internet Key Exchange (IKE) based on workload operating system:
Linux ↔ Linux: IKEv2
Windows ↔ Windows: IKEv1
Windows ↔ Linux: IKEv1
For a list of supported operating systems for managed workloads, see VEN OS Support and Package Dependencies on the Illumio Support portal.
Existing IPsec Configuration on Windows Systems
Installing a VEN on a Windows system does not change the existing Windows IPsec configuration, even though SecureConnect is not enabled. The VEN still captures all logging events (event.log, platform.log) from the Windows system related to IPsec, thereby tracking all IPsec activity.
Performance
The CPU processing power that a workload uses determines the capacity of the encryption. The packet size and throughput assess the power required to process the encrypted traffic using this feature.
In practice, enabling SecureConnect for a workload will unlikely cause a significant spike in CPU processing or a decrease in network throughput. However, Illumio recommends benchmarking performance before enabling SecureConnect and comparing results after enabling it.
Prerequisites, Limitations, and Caveats
Before configuring your workloads to use SecureConnect, review the following prerequisites and limitations, and consider the following caveats.
VEN Versions
To use PKI certificates with SecureConnect, your workloads must be running VEN version 17.2 or later.
Maximum Transmission Unit (MTU) Size
IPsec connections cannot assemble fragmented packets. Therefore, a high MTU size can disrupt SecureConnect for the workloads running on that host.
Illumio recommends setting the MTU size at 1400 or lower when enabling SecureConnect for a workload.
Ports
Enabling SecureConnect for a workload routes all traffic for that workload through the SecureConnect connection using ports 500/UDP and 4500/UDP for NAT traversal and for environments where ESP traffic is not allowed on the network (for example, when using Amazon Web Services). You must allow 500/UDP and 4500/UDP to traverse your network for SecureConnect.
Unsupported SecureConnect Usage
SecureConnect is not supported in the following situations:
SecureConnect cannot be used between a workload and unmanaged entities, such as the label “Any (0.0.0.0/0 and ::/0” (such as, the internet).
SecureConnect is not supported on virtual services.
SecureConnect is not supported on workloads in the Idle policy state. If you enable it for a rule that applies to workloads in both Idle and non-idle policy states, you can impact the traffic between these workloads.
SecureConnect is not supported on AIX and Solaris platforms.
SecureConnect and Build and Test Policy States
When you configure workloads to use SecureConnect be aware of the following caveat.
SecureConnect encrypts traffic for workloads running in all policy states except Idle. If misconfigured, you could inadvertently block traffic for workloads running in the Build and Test policy states.
SecureConnect Host-to-Host Encryption
When you configure workloads to use SecureConnect be aware of the following caveat.
SecureConnect encrypts traffic between workloads on a host-to-host basis. Consider the following example.
In this example, it appears that enabling SecureConnect will only affect MySQL traffic. However, when you enable SecureConnect for a rule to encrypt traffic between a database workload and a web workload over port 3306, the traffic on all ports between the database and web workloads is protected by IPsec encryption.
Use PKI Certificates with SecureConnect
SecureConnect lets you use client-side PKI certificates for IKE authentication and IPsec communication between managed workloads. If you have a certificate management infrastructure, you can leverage it for IKE authentication between workloads because it provides higher security than pre-shared keys (PSKs).
Certificate-based SecureConnect works for connections between Linux workloads, between Windows workloads, and between Linux and Windows workloads.
The IPsec configuration uses the certificate with the distinguished name from the issuer field that you specify during PCE configuration for IKE peer authentication.
Requirements and Caveats
You must have a PKI infrastructure to distribute, manage, and revoke certificates for your workloads. The PCE does not manage certificates or deliver them to your workloads.
The PCE supports configuring only one global CA ID for your organization.
Only use certificates obtained from trusted sources.
The VEN on a workload uses a Certificate Authority ID (CA ID) to authenticate and establish a secure connection with a peer workload.
Connected workloads must have CA identity certificates signed by the same root certificate authority. When workloads on either end of a connection use different CA IDs, the IKE negotiation between the workloads will fail, and the workloads cannot communicate with each other.
The certificates you deploy for PKI or IPsec must have the following properties:
Leaf certificate X.509 field requirement
Version 3
Subject Name DN must contain the Common Name
SubjectAltName (must be the same as the Common Name)
CN and SubjectAltName must be in one of the following formats:
Email Address
DNS
Must contain key usage with:
Digital Signature
Key Encipherment
Data Encipherment
Key Agreement
Must contain Extended key Usage with:
IPSec End System
IPSec User
TLS Web Server Authentication (optional for mac OS x compatibility)
Must contain Authority Key Identifier
Set up Certificates on Workloads
To use PKI certificates with SecureConnect, you must set up certificates on your Windows and Linux workloads independently.
File Requirements
File | Requirements |
|---|---|
Issuer's certificate | The global CA certificate, either root or intermediate, in PEM or DER format NoteOn Linux, the issuer's certificate must be readable by the Illumio user. |
pkcs12 container | Archive containing the public key, private key, and identity certificate generated for the workload host. Sign the identity certificate using the global root certificate. You can password protect the container and private key but do not password protect the public key. |
Installation Locations
Windows Store
Use the Windows OS (for example, Microsoft Management Console (MMC)) to import the files into these locations of the local machine store (not into your user store).
Root certificate: Trusted Root Certificate Store
pkcs12 container: Personal ("My") certificate store
Linux Directories
Copy the files into the following Linux directories. (You cannot change these directories.)
Root certificate:
/opt/illumio_ven/etc/ipsed.d/cacertpkcs12 container:
/opt/illumio_ven/etc/ipsed.d/private
Configure PKI Certificates
You can use client-side PKI certificates for IKE authentication and IPsec communication between managed workloads. The PCE supports configuring only one global CA ID for your organization. Configuring SecureConnect to use certificates applies the setting to All Roles, All Applications, All Environments, and All Locations.
Configuring SecureConnect to use PKI certificates in the global Security Settings page does not manage or deliver certificates for your organization to your workloads.
Note
You must set up certificates on your Windows and Linux workloads independently. For information, see Requirements for Certificate Setup on Workloads.
Go to Settings > Security Settings.
Choose Edit > Configure SecureConnect.
In the Default IPsec Authority field, select Certificate Authority.
In the Global Certificate ID field, enter the distinguished name from the Issuer field of your trusted root certificate. (This certificate is used globally for all workloads in your organization enabled with SecureConnect.)
Click Save.