How to Secure Traffic Between Two Systems With IPsec

This procedure assumes the following setup:

• The two systems are named enigma and partym.

• Each system has two addresses, an IPv4 address and an IPv6 address.

• Each system invokes AH protection with the MD5 algorithm, which requires a key of 128 bits.

• Each system invokes ESP protections with the 3DES algorithm, which requires a key of 192 bits.

• Each system uses shared security associations.

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

Before You Begin

You must be in the global zone to configure IPsec policy.

1. On the system console, assume the Primary Administrator role or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

   ---

   Note –

   Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login. For an example, see Example 19–1.

   ---

2. On each system, add host entries to the /etc/inet/hosts file.

   This step enables the service management facility (SMF) to use the system names without depending on nonexistent naming services. For more information, see the smf(5) man page.

   1. On a system that is named partym, type the following in the hosts file:

      # Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 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 2001::eeee:3333:3333 partym

3. 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.

4. Add an IPsec policy entry to the ipsecinit.conf file.

   1. On the enigma system, add the following policy:

      {laddr enigma raddr partym} ipsec {auth_algs any encr_algs any sa shared}

   2. On the partym system, add the identical policy:

      {laddr partym raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

      For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.

5. On each system, add a pair of IPsec SAs between the two systems.

   You can configure Internet Key Exchange (IKE) to create the SAs automatically. You can also add the SAs manually.

   ---

   Note –

   You should use IKE unless you have good reason to generate and maintain your keys manually. IKE key management is more secure than manual key management.

   ---

   • Configure IKE by following one of the configuration procedures in Configuring IKE (Task Map). For the syntax of the IKE configuration file, see the ike.config(4) man page.

   • To add the SAs manually, see How to Manually Create IPsec Security Associations.

6. Verify the syntax of the IPsec policy file.

   # ipsecconf -c -f /etc/inet/ipsecinit.conf

   Fix any errors, verify the syntax of the file, and continue.

7. Refresh the IPsec policy.

   # svcadm refresh svc:/network/ipsec/policy:default

   IPsec policy is enabled by default, so you refresh it. If you have disabled IPsec policy, enable it.

   # svcadm enable svc:/network/ipsec/policy:default

8. Activate the keys for IPsec.

   • If you configured IKE in Step 5, do one of the following:

     • If the ike service is not enabled, enable it.

       # svcadm enable svc:/network/ipsec/ike:default

     • If the ike service is enabled, restart it.

       # svcadm restart svc:/network/ipsec/ike:default

   • If you manually configured keys in Step 5, do one of the following:

     • If the manual-key service is not enabled, enable it.

       # svcadm enable svc:/network/ipsec/manual-key:default

     • If the manual-key service is enabled, refresh it.

       # svcadm refresh svc:/network/ipsec/manual-key:default

9. Verify that packets are being protected.

   For the procedure, see How to Verify That Packets Are Protected With IPsec.

Example 19–1 Adding IPsec Policy When Using an ssh Connection

In this example, the administrator as superuser configures IPsec policy and keys on two systems by using the ssh command to reach the second system. For more information, see the ssh(1) man page.

• First, the administrator configures the first system by performing Step 2 through Step 5 of the preceding procedure.

• Then, in a different terminal window, the administrator uses the ssh command to log in to the second system.

  local-system # ssh other-system 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 2 through Step 8.

• Then, the administrator ends the ssh session.

  other-system # exit local-system #

• Finally, the administrator enables IPsec policy on the first system by completing Step 6 and Step 8.

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