How to Secure Network Traffic Between Two Servers With IPsec

Language:

This procedure assumes the following setup:

The systems are assigned static IP addresses and are running the network configuration profile DefaultFixed. If the netadm list command returns Automatic, see the netcfg(1M) man page for more information.
The two systems are named enigma and partym.
Each system has an IP address. This can be an IPv4 address, an IPv6 address, or both. This procedure uses IPv4 addresses.
Each system is either a global zone or an exclusive-IP zone. For more information, see IPsec and Oracle Solaris Zones.
Each system encrypts traffic with the AES algorithm and authenticates it with SHA-2.

Note - The SHA-2 algorithm might be required at some sites.
Each system uses shared security associations.

With shared SAs, only one pair of SAs is needed to protect the two systems.

Note - To use IPsec with labels on a Trusted Extensions system, see the extension of this procedure in How to Apply IPsec Protections in a Multilevel Trusted Extensions Network in Trusted Extensions Configuration and Administration .

Before You Begin

A user with specific rights can run the following commands without being root:

To run configuration commands, you must become an administrator who is assigned the Network IPsec Management rights profile.
In this administrative role, you can edit IPsec-related system files and create keys by using the pfedit command.
To edit the hosts file, you must be in the root role or have explicit permission to edit that file. See Example 7–7.

For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.2 .

If you administer remotely, see Example 7–1 and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.2 for secure remote login instructions.

On each system, add host entries to the /etc/inet/hosts file.
This step enables the local naming service to resolve system names to IP addresses without depending on a networked naming service.
1. On a system that is named partym, type the following in the hosts file:
```
## Secure communication with enigma
192.168.116.16 enigma
```
2. On a system that is named enigma, type the following in the hosts file:
```
## Secure communication with partym
192.168.13.213 partym
```
On each system, create the IPsec policy file.
The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.
```
# pfedit /etc/inet/ipsecinit.conf
```

Add an IPsec policy entry to the ipsecinit.conf file.
For the syntax of IPsec policy entries and several examples, see the ipsecconf (1M) man page.
1. On the enigma system, add the following policy:
```
{laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
```
  Because the dir keyword is not used, the policy applies to both outbound and inbound packets.
2. On the partym system, add the identical policy:
```
{laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
```

On each system, configure IKE to manage the IPsec SAs.
Follow one of the configuration procedures in Configuring IKEv2. For the syntax of the IKE configuration file, see the ikev2.config (4) man page. If you are communicating with a system that only supports the IKEv1 protocol, refer to Configuring IKEv1 and the ike.config(4) man page.

Note - If you must generate and maintain your keys manually, see How to Manually Create IPsec Keys.

Verify the syntax of the IPsec policy file.
```
% pfbash
# /usr/sbin/ipsecconf -c /etc/inet/ipsecinit.conf
```
Fix any errors, verify the syntax of the file, and continue.

Refresh the IPsec policy.
```
# svcadm refresh ipsec/policy:default
```
IPsec policy is enabled by default, so you refresh it. If you have disabled the IPsec policy, enable it.
```
# svcadm enable ipsec/policy:default
```

Activate the keys for IPsec.
- If the ike service is not enabled, enable it.
  Note - If you are communicating with a system that can only run the IKEv1 protocol, specify the ike:default instance.
```
# svcadm enable ipsec/ike:ikev2
```
- If the ike service is enabled, restart it.
```
# svcadm restart ike:ikev2
```
If you manually configured keys in Step 4, complete the procedure How to Manually Create IPsec Keys to activate the keys.

Verify that packets are being protected.
For the procedure, see How to Verify That Packets Are Protected With IPsec.

Example 7-1 Configuring IPsec Policy Remotely by Using an ssh Connection

In this example, the administrator in the root role configures IPsec policy and keys on two systems by using the ssh command to reach the second system. The administrator is defined identically on both systems. For more information, see the ssh(1) man page.

The administrator configures the first system by performing Step 1 through Step 5 of How to Secure Network Traffic Between Two Servers With IPsec.
In a different terminal window, the administrator uses the identically defined user name and ID to log in remotely with the ssh command.
```
local-system % ssh -l jdoe other-system
other-system # su - root 
Enter password: xxxxxxxx
other-system #
```
In the terminal window of the ssh session, the administrator configures the IPsec policy and keys of the second system by completing Step 1 through Step 7.

The administrator ends the ssh session.

other-system # exit
local-system 
# exit

The administrator enables IPsec policy on the first system by completing Step 6 and Step 7.

The next time the two systems communicate, including by using an ssh connection, the communication is protected by IPsec.

Example 7-2 Configuring IPsec Policy to Run in FIPS 140 Mode

In this example, the administrator configures the IPsec policy on a FIPS 140-enabled system to follow a site security policy that requires symmetric algorithms whose key length is at least 192 bits.

The administrator specifies two possible IPsec policies. The first policy specifies AES in CCM mode for encryption and authentication and the second policy specifies AES with 192-bit and 256-bit key lengths for encryption and SHA384 for authentication.

 {laddr machine1 raddr machine2} ipsec {encr_algs aes-ccm(192...) sa shared} or ipsec
 {laddr machine1 raddr machine2} ipsec {encr_algs aes(192...) encr_auth_algs sha2(384) sa shared}