This procedure assumes the following setup:
The systems are assigned static IP addresses. For more information, see the netcfg(8) man page.
The two systems are named host1 and host2.
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.
Each system uses shared security associations.
With shared SAs, only one pair of SAs is needed to protect the two systems.
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 27, Enabling a Trusted User to Configure and Manage IPsec.
For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.4.
If you administer remotely, see Example 19, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.4 for secure remote login instructions.
This step enables the local naming service to resolve system names to IP addresses without depending on a networked naming service.
## Secure communication with host1 198.51.100.6 host1
## Secure communication with sytem2 198.51.100.33 host2
The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.
# pfedit /etc/inet/ipsecinit.conf
For the syntax of IPsec policy entries and several examples, see the ipsecconf(8) man page.
{laddr host1 raddr host2} 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.
{laddr host2 raddr host1} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
Follow one of the configuration procedures in Configuring IKEv2. For the syntax of the IKE configuration file, see the ikev2.config(5) man page. If you are communicating with a system that only supports the IKEv1 protocol, refer to Configuring IKEv1 and the ike.config(5) man page.
$ pfbash $ /usr/sbin/ipsecconf -c /etc/inet/ipsecinit.conf
Fix any errors, verify the syntax of the file, and continue.
$ 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
$ svcadm enable ipsec/ike:ikev2
$ 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.
For the procedure, see How to Verify That Packets Are Protected With IPsec.
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 20 Configuring IPsec Policy With FIPS 140-2 Approved AlgorithmsIn this example, the administrator configures the IPsec policy on a FIPS 140-2-enabled system to follow a site security policy that requires symmetric algorithms whose key length is 256 bits.
The administrator specifies two possible IPsec policies. The first policy specifies AES in CCM mode with a 256-bit key length for encryption. The second policy specifies AES with a 256-bit key length for encryption and SHA384 for authentication.
{laddr host1 raddr host2} ipsec {encr_algs aes-ccm(256) sa shared} or ipsec {laddr host1 raddr host2} ipsec {encr_algs aes(256) encr_auth_algs sha384 sa shared}Example 21 Configuring IPsec Policy to Use the IKEv2 Protocol Only
In this example, the administrator configures the IPsec policy on a server to ignore the IKEv1 protocol. All SAs will be created by IKEv2. Attempted negotiations with IKEv1 will fail. The administrator creates a corresponding IKEv2 configuration file.
## ipsecinit.conf {raddr 192.0.2.0/27 dir both } ipsec {encr_algs aes-ccm sa shared ike_version 2}
This rule says that any host on the 192.0.2.0/27 subnet can talk to the server by using the combined mode aes-ccm algorithm.
The corresponding IKEv2 configuration file enables all address ranges whose certificate is signed by the same chain of trust as the server to connect with the server1.example.com server:
## ikev2.config ikesa_xform { dh_group 21 auth_alg sha256 encr_alg aes } { label "IKEv2-only certificate" request_http_certs yes auth_method cert local_id DNS = "server1.example.com" remote_id ANY local_addr 0.0.0.0/0 remote_addr 0.0.0.0/0 }
The configuration of the server1 server is complete. Client systems who install the certificate and configure IPsec and IKEv2 can communicate with server1.
Example 22 Transitioning Client Systems to Use IPsec by Using the or pass Action on the ServerIn this example, the administrator is gradually configuring all clients on a subnet to use IPsec. The or pass {} action enables the server to receive packets from all clients on the subnet, including clients that are not configured with IPsec.
## ipsecinit.conf {raddr 192.0.2.0/27 dir both } ipsec {encr_algs aes-ccm sa shared} or pass {}
The or pass {} action passes all traffic that is not encrypted by the specified encryption mechanisms but otherwise satisfies the rule, as well as IPsec traffic that matches the rule. The connection to the server that has an or pass rule must originate from the client. The action is cached when the connection is first established.
All clients on the 192.0.2.0 subnet will be able to establish a connection to the server.