System Administration Guide: IP Services

Chapter 20 Configuring IPsec (Tasks)

This chapter provides procedures for implementing IPsec on your network. The procedures are described in the following task maps:

For overview information about IPsec, see Chapter 19, IP Security Architecture (Overview). For reference information about IPsec, see Chapter 21, IP Security Architecture (Reference).

Protecting Traffic With IPsec (Task Map)

The following task map points to procedures that set up IPsec between one or more systems. The ipsecconf(1M), ipseckey(1M), and ifconfig(1M) man pages also describe useful procedures in their respective Examples sections.

Task	Description	For Instructions
Secure traffic between two systems.	Protects packets from one system to another system.	How to Secure Traffic Between Two Systems With IPsec
Secure a web server by using IPsec policy.	Requires non-web traffic to use IPsec. Web clients are identified by particular ports, which bypass IPsec checks.	How to Use IPsec to Protect a Web Server From Nonweb Traffic
Display IPsec policies.	Displays the IPsec policies that are currently being enforced, in the order in which the policies are enforced.	How to Display IPsec Policies
Generate random numbers.	Generates random numbers for keying material for manually created security associations.	How to Generate Random Numbers on a Solaris System How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services
Create or replace security associations manually.	Provides the raw data for security associations: IPsec algorithm name and keying material Key for the security parameter index IP source and destination addresses	How to Manually Create IPsec Security Associations
Check that IPsec is protecting the packets.	Examines `snoop` output for specific headers that indicate how the IP datagrams are protected.	How to Verify That Packets Are Protected With IPsec
(Optional) Create a Network Security role.	Creates a role that can set up a secure network, but has fewer powers than superuser.	How to Configure a Role for Network Security
Manage IPsec and keying material as a set of SMF services.	Describes when and how to use the commands that enable, disable, refresh, and restart services. Also describes the commands that change the property values of services.	How to Manage IKE and IPsec Services
Set up a secure virtual private network (VPN).	Sets up IPsec between two systems that are separated by the Internet.	Protecting a VPN With IPsec (Task Map)

Protecting Traffic With IPsec

This section provides procedures that enable you to secure traffic between two systems and to secure a web server. To protect a VPN, see Protecting a VPN With IPsec (Task Map) . Additional procedures provide keying material and security associations, and verify that IPsec is working as configured.

The following information applies to all IPsec configuration tasks:

IPsec and zones – To manage IPsec policy and keys for a shared-IP non-global zone, create the IPsec policy file in the global zone, and run the IPsec configuration commands from the global zone. Use the source address that corresponds to the non-global zone that is being configured. You can also configure IPsec policy and keys in the global zone for the global zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone. Starting in the Solaris 10 7/07 release, you can use IKE to manage keys in a non-global zone.
IPsec and RBAC – To use roles to administer IPsec, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. For an example, see How to Configure a Role for Network Security.
IPsec and SCTP – IPsec can be used to protect Streams Control Transmission Protocol (SCTP) associations, but caution must be used. For more information, see IPsec and SCTP.

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 requires ESP encryption with the AES algorithm, which requires a key of 128 bits, and ESP authentication with the SHA1 message digest, which requires a 160–bit key.
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 for the system or for a shared-IP zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone.

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 20–1.

On each system, check host entries.

In the current release, add the host entries to the /etc/inet/hosts file.

On a system that is running a release prior to the Solaris 10 7/07 release, add IPv4 and IPv6 entries to the /etc/inet/ipnodes file. The entries for one system must be contiguous in the file. For more information about system configuration files, see TCP/IP Configuration Files and Chapter 11, IPv6 in Depth (Reference).

If you are connecting systems with IPv4 addresses only, you modify the /etc/inet/hosts file. In this example, the connecting systems are running an earlier Solaris release and are using IPv6 addresses.
1. On a system that is named enigma, type the following in the hosts or ipnodes file:
  # Secure communication with partym 192.168.13.213 partym 2001::eeee:3333:3333 partym
2. On a system that is named partym, type the following in the hosts or ipnodes file:
  # Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 enigma
Using the naming services for symbolic names is insecure.

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.

Add an IPsec policy entry to the ipsecinit.conf file.
1. On the enigma system, add the following policy:
  {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
2. On the partym system, add the identical policy:
  {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
  For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.

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.

Enable IPsec policy.
- If you are running a release prior to the Solaris 10 4/09 release, reboot the system.
  # init 6
  Then, go to How to Verify That Packets Are Protected With IPsec.
- Starting in the Solaris 10 4/09 release, refresh the IPsec service and enable the key management service.
  
  Complete the steps from Step 7 to Step 10.

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.

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

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

Verify that packets are being protected.

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

Example 20–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 6.
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.

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

Example 20–2 Securing Traffic With IPsec Without Rebooting

The following example is useful when you are running a release prior to the Solaris 10 4/09 release. That is, in your release, IPsec is not managed as a service. The example describes how to implement IPsec in a test environment. In a production environment, it is more secure to reboot than to run the ipsecconf command. For the security considerations, see the end of this example.

Instead of rebooting at Step 6, choose one of the following options:

If you used IKE to create keying material, stop and then restart the in.iked daemon.
# pkill in.iked # /usr/lib/inet/in.iked
If you added keys manually, use the ipseckey command to add the SAs to the database.
# ipseckey -c -f /etc/inet/secret/ipseckeys
Then, activate the IPsec policy with the ipsecconf command.
# ipsecconf -a /etc/inet/ipsecinit.conf

Security Considerations – Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, a socket that is already in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf.

How to Use IPsec to Protect a Web Server From Nonweb Traffic

A secure web server allows web clients to talk to the web service. On a secure web server, traffic that is not web traffic must pass security checks. The following procedure includes bypasses for web traffic. In addition, this web server can make unsecured DNS client requests. All other traffic requires ESP with AES and SHA-1 algorithms.

Before You Begin

You must be in the global zone to configure IPsec policy. For an exclusive-IP zone, you configure IPsec policy in the non-global zone. You have completed How to Secure Traffic Between Two Systems With IPsec so that the following conditions are in effect:

Communication between the two systems is protected by IPsec.
Keying material is being generated, either manually or by IKE.
You have verified that packets are being protected.

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.

Determine which services need to bypass security policy checks.

For a web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.

Create IPsec policy for the web server and enable it.
- Starting in the Solaris 10 4/09 release, follow the steps from Step 4 to Step 7.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 8 to Step 11.
Step 12 is optional in all Solaris releases.

Add the web server policy to the IPsec policy file.

Add the following lines to the /etc/inet/ipsecinit.conf file:

# Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

This configuration allows only secure traffic to access the system, with the bypass exceptions that are described in Step 4.

Verify the syntax of the IPsec policy file.

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

Refresh the IPsec policy.

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

Refresh the keys for IPsec.
- If you configured IKE in Step 5 of How to Secure Traffic Between Two Systems With IPsec, restart the ike service.
  # svcadm restart svc:/network/ipsec/ike
- If you manually configured keys in Step 5 of How to Secure Traffic Between Two Systems With IPsec, refresh the manual-key service.
  # svcadm refresh svc:/network/ipsec/manual-key:default
Your setup is complete. Optionally, you can perform Step 12.

Create a file in the /etc/inet directory for the web server policy.

Note –

The following steps configure a web server that is running a release prior to the Solaris 10 4/09 release.

Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this file:

# Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

This configuration allows only secure traffic to access the system, with the bypass exceptions that are described in Step 4.

Copy the contents of the file that you created in Step 8 into the /etc/inet/ipsecinit.conf file.

Protect the IPsecWebInitFile file with read-only permissions.
# chmod 400 IPsecWebInitFile

Secure the web server without rebooting.

Choose one of the following options:
- If you are using IKE for key management, stop and restart the in.iked daemon.
  # pkill in.iked # /usr/lib/inet/in.iked
- If you are manually managing keys, use the ipseckey and ipsecconf commands.
  
  Use the IPsecWebInitFile as the argument to the ipsecconf command. If you use the ipsecinit.conf file as the argument, the ipsecconf command generates errors when policies in the file are already implemented on the system.
  # ipseckey -c -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/IPsecWebInitFile
Caution –
Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, a socket that is already in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf. The same warning applies to restarting the in.iked daemon.

You can also reboot. Rebooting ensures that the IPsec policy is in effect on all TCP connections. At reboot, the TCP connections use the policy in the IPsec policy file.

(Optional) Enable a remote system to communicate with the web server for nonweb traffic.

Type the following policy in a remote system's ipsecinit.conf file:
# Communicate with web server about nonweb stuff # {laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
A remote system can communicate securely with the web server for nonweb traffic only when the systems' IPsec policies match.

How to Display IPsec Policies

You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments.

Before You Begin

You must run the ipsecconf command in the global zone. For an exclusive-IP zone, you run the ipsecconf command in the non-global zone.

Assume a role that includes the Network IPsec Management profile, or become superuser.

If you are running a release prior to the Solaris 10 4/09 release, the Network IPsec Management profile is not available. Use the Network Security profile.

To create a role that includes a network security profile and assign that role to a user, see How to Configure a Role for Network Security.

Display IPsec policies.
1. Display the global IPsec policy entries in the order that the entries were added.
  $ ipsecconf
  The command displays each entry with an index followed by a number.
2. Display the IPsec policy entries in the order in which a match occurs.
  $ ipsecconf -l
3. Display the IPsec policy entries, including per-tunnel entries, in the order in which a match occurs.
  $ ipsecconf -L

How to Generate Random Numbers on a Solaris System

If you are specifying keys manually, the keying material must be random. The format for keying material for a Solaris system is hexadecimal. Other operating systems can require ASCII keying material. To generate keying material for a Solaris system that is communicating with an operating system that requires ASCII, see Example 23–1.

If your site has a random number generator, use that generator. Otherwise, you can use the od command with the /dev/random Solaris device as input. For more information, see the od(1) man page.

In the Solaris 10 4/09 release, you can also use the pktool command. The syntax of this command is simpler than the syntax of the od command. For details, see How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services.

Generate random numbers in hexadecimal format.
% od -x|-X -A n file | head -n
-x

Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.

-X

Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.

-A n

Removes the input offset base from the display.

file

Serves as a source for random numbers.

head -n

Restricts the display to the first n lines of output.

Combine the output to create a key of the appropriate length.

Remove the spaces between the numbers on one line to create a 32-character key. A 32-character key is 128 bits. For a security parameter index (SPI), you should use an 8-character key. The key should use the 0x prefix.

Example 20–3 Generating Key Material for IPsec

The following example displays two lines of keys in groups of eight hexadecimal characters each.

% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

By combining the four numbers on the first line, you can create a 32-character key. An 8-character number that is preceded by 0x provides a suitable SPI value, for example, 0xf3447465.

The following example displays two lines of keys in groups of four hexadecimal characters each.

% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

By combining the eight numbers on the first line, you can create a 32-character key.

How to Manually Create IPsec Security Associations

The following procedure provides the keying material for the procedure, How to Secure Traffic Between Two Systems With IPsec. You are generating keys for two systems, partym and enigma. You generate the keys on one system, and then use the keys from the first system on both systems.

Before You Begin

You must be in the global zone to manually manage keying material for a shared-IP zone.

Generate the keying material for the SAs.

You need three hexadecimal random numbers for outbound traffic and three hexadecimal random numbers for inbound traffic.

Therefore, one system needs to generate the following numbers:
- Two hexadecimal random numbers as the value for the spi keyword. One number is for outbound traffic. One number is for inbound traffic. Each number can be up to eight characters long.
- Two hexadecimal random numbers for the SHA1 algorithm for authentication. For a 160–bit key, each number must be 40 characters long. One number is for dst enigma. One number is for dst partym.
- Two hexadecimal random numbers for the AES algorithm for ESP encryption. For a 256-bit key, each number must be 64 characters long. One number is for dst enigma. One number is for dst partym.
If you have a random number generator at your site, use the generator. You can also use the od command. See How to Generate Random Numbers on a Solaris System for the procedure.

On the system console on one of the systems, 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.

Create the SAs.
- Starting in the Solaris 10 4/09 release, follow the steps from Step 8 to Step 10.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 4 to Step 9.

Enable the ipseckey command mode.
# ipseckey >
The > prompt indicates that you are in ipseckey command mode.

If you are replacing existing SAs, flush the current SAs.
> flush >
To prevent an adversary from having time to break your SAs, you need to replace the keying material.

Note –
You must coordinate key replacement on communicating systems. When you replace the SAs on one system, the SAs must also be replaced on the remote system.

To create SAs, type the following command.

> add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm  \
protocol-prefixkey random-hex-string-of-algorithm-specified-length

You also use this syntax to replace SAs that you have just flushed.

protocol

Specifies either esp or ah.

random-hex-string

Specifies a random number of up to eight characters in hexadecimal format. Precede the characters with 0x. If you enter more numbers than the security parameter index (SPI) accepts, the system ignores the extra numbers. If you enter fewer numbers than the SPI accepts, the system pads your entry.

addr

Specifies the IP address of one system.

addr2

Specifies the IP address of the peer system of addr.

protocol-prefix

Specifies one of encr or auth. The encr prefix is used with the esp protocol. The auth prefix is used with the ah protocol, and for authenticating the esp protocol.

protocol-algorithm

Specifies an algorithm for ESP or AH. Each algorithm requires a key of a specific length.

Authentication algorithms include MD5 and SHA1. Starting in the Solaris 10 4/09 release, SHA256 and SHA512 are supported. Encryption algorithms include DES, 3DES, AES, and Blowfish.

random-hex-string-of-algorithm-specified-length

Specifies a random hexadecimal number of the length that is required by the algorithm. For example, the MD5 algorithm requires a 32-character string for its 128-bit key. The 3DES algorithm requires a 48-character string for its 192-bit key.

For example, on the enigma system, protect outbound packets.

Use the random numbers that you generated in Step 1.

For Solaris 10 1/06:

> add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg aes \
auth_alg sha1 \
encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
authkey 6fab07fec4f2895445500ed992ab48835b9286ff
>

Note –

The peer system must use the same keying material and the same SPI.

Still in ipseckey command mode on the enigma system, protect inbound packets.

Type the following commands to protect the packets:

> add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg aes \
auth_alg sha1 \
encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
authkey c80984bc4733cc0b7c228b9b74b988d2b7467745
>

Note –

The keys and SPI can be different for each SA. You should assign different keys and a different SPI for each SA.

To exit ipseckey command mode, press Control-D or type quit.

Add the keying material to the /etc/inet/secret/ipseckeys file.

In releases prior to the Solaris 10 4/09 release, this step ensures that the keying material is available to IPsec at reboot.

The lines of the /etc/inet/secret/ipseckeys file are identical to the ipseckey command line language.

For example, the /etc/inet/secret/ipseckeys file on the enigma system would appear similar to the following:

# ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

Protect the file with read-only permissions.
# chmod 400 /etc/inet/secret/ipseckeys

Repeat the procedure on the partym system.

Use the same keying material that was used on enigma.

The keying material on the two systems must be identical. As shown in the following example, only the comments in the ipseckeys file differ. The comments differ because dst enigma is inbound on the enigma system, and outbound on the partym system.

# partym ipseckeys file
#
# for inbound packets
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for outbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

Enable the manual-key service.
# svcadm enable svc:/network/ipsec/manual-key
To replace keys in the current release, see Example 20–4.

Example 20–4 Replacing IPsec SAs

In this example, the administrator is configuring a system that is running the current Solaris 10 release. The administrator generates new keys, changes the keying information in the ipseckeys file, then restarts the service.

First, the administrator generates the keys by completing How to Generate Random Numbers on a Solaris System.

Then, the administrator uses the generated keys in the /etc/inet/secret/ipseckeys file.

The administrator used the same algorithms. Therefore, the administrator changes the values of SPI, encrkey and authkey only:

add esp spi 0x8xzy1492 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey 0a1f3886b06ebd7d39f6f89e4c29c93f2741c6fa598a38af969907a29ab1b42a \
   authkey a7230aabf513f35785da73e33b064608be41f69a
#
# add esp spi 0x177xce34\
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey 4ef5be40bf93498017b2151d788bb37e372f091add9b11149fba42435fefe328 \
   authkey 0e1875d9ff8e42ab652766a5cad49f38c9152821

Finally, the administrator restarts the manual-key service. The restart command flushes the old keys before adding the new keys.
# svcadm restart manual-key

How to Verify That Packets Are Protected With IPsec

To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:

AH: Prefix indicates that AH is protecting the headers. You see AH: if you used auth_alg to protect the traffic.
ESP: Prefix indicates that encrypted data is being sent. You see ESP: if you used encr_auth_alg or encr_alg to protect the traffic.

Before You Begin

You must be superuser or have assumed an equivalent role to create the snoop output. You must have access to both systems to test the connection.

On one system, such as partym, become superuser.
% su - Password: Type root password #

From the partym system, prepare to snoop packets from a remote system.

In a terminal window on partym, snoop the packets from the enigma system.
# snoop -v enigma Using device /dev/hme (promiscuous mode)

Send a packet from the remote system.

In another terminal window, remotely log in to the enigma system. Provide your password. Then, become superuser and send a packet from the enigma system to the partym system. The packet should be captured by the snoop -v enigma command.
% ssh enigma Password: Type your password % su - Password: Type root password # ping partym

Examine the snoop output.

On the partym system, you should see output that includes AH and ESP information after the initial IP header information. AH and ESP information that resembles the following shows that packets are being protected:

IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
...

How to Configure a Role for Network Security

If you are using role-based access control (RBAC) to administer your systems, you use this procedure to provide a network management role or network security role.

Find the Network rights profiles in the local prof_attr database.

In the current release, the output appears similar to the following:

% cd /etc/security
% grep Network prof_attr
Network IPsec Management:::Manage IPsec and IKE...
Network Link Security:::Manage network link security...
Network Management:::Manage the host and network configuration...
Network Security:::Manage network and host security...
Network Wifi Management:::Manage wifi network configuration...
Network Wifi Security:::Manage wifi network security...

If you are running a release prior to the Solaris 10 4/09 release, the output appears similar to the following:

% cd /etc/security
% grep Network prof_attr
Network Management:::Manage the host and network configuration  
Network Security:::Manage network and host security  
System Administrator::: Network Management

The Network Management profile is a supplementary profile in the System Administrator profile. If you have included the System Administrator rights profile in a role, then that role can execute the commands in the Network Management profile.

Determine which commands are in the Network Management rights profile.
% grep "Network Management" /etc/security/exec_attr Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config … Network Management:suser:cmd:::/usr/sbin/snoop:uid=0
The solaris policy commands run with privilege (privs=sys_net_config). The suser policy commands run as superuser (uid=0).

Decide the scope of the network security roles at your site.

Use the definitions of the rights profiles in Step 1 to guide your decision.
- To create a role that handles all network security, use the Network Security rights profile.
- In the current release, to create a role that handles IPsec and IKE only, use the Network IPsec Management rights profile.

Create a network security role that includes the Network Management rights profile.

A role with the Network Security or the Network IPsec Management rights profile, in addition to the Network Management profile, can execute the ifconfig, snoop, ipsecconf, and ipseckey commands, among others, with appropriate privilege.

To create the role, assign the role to a user, and register the changes with the name service, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

Example 20–5 Dividing Network Security Responsibilities Between Roles

In this example, the administrator divides network security responsibilities between two roles. One role administers wifi and link security and another role administers IPsec and IKE. Each role is assigned to three people, one person per shift.

The roles are created by the administrator as follows:

The administrator names the first role LinkWifi.
- The administrator assigns the Network Wifi, Network Link Security, and Network Management rights profiles to the role.
- Then, the administrator assigns the LinkWifi role to the appropriate users.
The administrator names the second role IPsec Administrator.
- The administrator assigns the Network IPsec Management and the Network Management rights profiles to the role.
- Then, the administrator assigns the IPsec Administrator role to the appropriate users.

How to Manage IKE and IPsec Services

The following steps provide the most likely uses of the SMF services for IPsec, IKE, and manual key management. By default, the policy and ipsecalgs services are enabled. Also by default, the ike and manual-key services are disabled.

To manage IPsec policy, do one of the following:

After adding new policies to the ipsecinit.conf file, refresh the policy service.
# svcadm refresh svc:/network/ipsec/policy

After changing the value of a service property, view the property value, then refresh and restart the policy service.

# svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf
# svcprop -p config/config_file policy
/etc/inet/MyIpsecinit.conf
# svcadm refresh svc:/network/ipsec/policy
# svcadm restart svc:/network/ipsec/policy

To automatically manage keys, do one of the following:
- After adding entries to the /etc/inet/ike/config file, enable the ike service.
  # svcadm enable svc:/network/ipsec/ike
- After changing entries in the /etc/inet/ike/config file, refresh the ike service.
  # svcadm refresh svc:/network/ipsec/ike
- After changing the value of a service property, view the property value, then refresh and restart the service.
  # svccfg -s ike setprop config/admin_privilege=modkeys # svcprop -p config/admin_privilege ike modkeys # svcadm refresh svc:/network/ipsec/ike # svcadm restart svc:/network/ipsec/ike
- To stop the ike service, disable it.
  # svcadm disable svc:/network/ipsec/ike

To manually manage keys, do one of the following:

After adding entries to the /etc/inet/secret/ipseckeys file, enable the manual-key service.
# svcadm enable svc:/network/ipsec/manual-key

After changing the ipseckeys file, refresh the service.
# svcadm refresh manual-key

After changing the value of a service property, view the property value, then refresh and restart the service.

# svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile
# svcprop -p config/config_file manual-key
/etc/inet/secret/MyIpseckeyfile
# svcadm refresh svc:/network/ipsec/manual-key
# svcadm restart svc:/network/ipsec/manual-key

To prevent manual key management, disable the manual-key service.
# svcadm disable svc:/network/ipsec/manual-key

If you modify the IPsec protocols and algorithms table, refresh the ipsecalgs service.
# svcadm refresh svc:/network/ipsec/ipsecalgs

Troubleshooting

Use the svcs service command to find the status of a service. If the service is in maintenance mode, follow the debugging suggestions in the output of the svcs -x service command.

Protecting a VPN With IPsec

IPsec tunnels can protect a VPN. In the Solaris 10 7/07 release, a tunnel can be in tunnel mode or transport mode. Tunnel mode is interoperable with the implementation of IPsec by other vendors. Transport mode is interoperable with earlier versions of the Solaris OS. For a discussion of tunnel modes, see Transport and Tunnel Modes in IPsec.

Tunnels in tunnel mode offer more fine-grained control of the traffic. In tunnel mode, for an inner IP address, you can specify the particular protection you want, down to a single port.

For examples of IPsec policies for tunnels in tunnel mode, see Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode.
For the procedures that protect VPNs, see Protecting a VPN With IPsec (Task Map) .

Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode

Figure 20–1 IPsec Tunnel Diagram

Diagram shows a VPN that connects two LANs. Each LAN
has four subnets.

The following examples assume that the tunnel is configured for all subnets of the LANs:

## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10

Example 20–6 Creating a Tunnel That All Subnets Can Use

In this example, all traffic from the local LANs of the Central LAN in Figure 20–1 can be tunneled through Router 1 to Router 2, and then delivered to all local LANs of the Overseas LAN. The traffic is encrypted with AES.

## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Example 20–7 Creating a Tunnel That Connects Two Subnets Only

In this example, only traffic between subnet 10.1.2.0/24 of the Central LAN and subnet 10.2.3.0/24 of the Overseas LAN is tunneled and encrypted. In the absence of other IPsec policies for Central, if the Central LAN attempts to route any traffic for other LANs over this tunnel, the traffic is dropped at Router 1.

## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}

Example 20–8 Creating a Tunnel for Email Traffic Only Between Two Subnets

In this example, a tunnel is created for email traffic only. The traffic is delivered from subnet 10.1.2.0/24 of the Central LAN to the email server on the 10.2.3.0/24 subnet of the Overseas LAN. The email is encrypted with Blowfish. The policies apply to the remote and local email ports. The rport policy protects email that Central sends to the remote email port of Overseas. The lport policy protects email that Central receives from Overseas on local port 25.

## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

Example 20–9 Creating a Tunnel for FTP Traffic for All Subnets

In this example, IPsec policy protects the FTP ports in Figure 20–1 with AES for all subnets of the Central LAN to all subnets of the Overseas LAN. This configuration works for the active mode of FTP.

## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Protecting a VPN With IPsec (Task Map)

The following task map points to procedures that configure IPsec to protect traffic across the Internet. These procedures set up a secure virtual private network (VPN) between two systems that are separated by the Internet. One common use of this technology is to protect traffic between home workers and their corporate office.

Task	Description	For Instructions
Protect tunnel traffic in tunnel mode over IPv4.	Protects traffic in tunnel mode between two Solaris 10 systems, two Oracle Solaris systems, or between a Solaris 10 system and an Oracle Solaris Express system. The Solaris 10 system must be running at least the Solaris 10 7/07 release. Also, protects traffic in tunnel mode between a Solaris 10 system or an Oracle Solaris Express system, and a system that is running on another platform. The Solaris 10 system must be running at least the Solaris 10 7/07 release.	How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4
Protect tunnel traffic in tunnel mode over IPv6.	Protects traffic in tunnel mode between two Oracle Solaris systems that are using the IPv6 protocol.	How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6
Protect tunnel traffic in transport mode over IPv4.	Protects traffic in transport mode between two Solaris 10 systems, two Solaris systems, or between a Solaris 10 system and an Oracle Solaris system. The Solaris 10 system must be running at least the Solaris 10 7/07 release. Also, protects traffic in transport mode between a system that is running an earlier version of the Solaris OS and a Solaris 10 or an Oracle Solaris system. The Solaris 10 system must be running at least the Solaris 10 7/07 release.	How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4
Protect tunnel traffic in transport mode over IPv4.	Protects traffic by using an older, deprecated syntax. This method is useful when you are communicating with a system that is running an earlier version of the Solaris OS. This method simplifies comparing the configuration files on the two systems.	Example 20–11 Example 20–16
Protect tunnel traffic in transport mode over IPv6.	Protects traffic in transport mode between two Oracle Solaris systems that are using the IPv6 protocol.	How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6
Prevent IP spoofing.	Creates an SMF service to prevent the system from forwarding packets across a VPN without decrypting the packets.	How to Prevent IP Spoofing

Description of the Network Topology for the IPsec Tasks to Protect a VPN

The procedures that follow this section assume the following setup. For a depiction of the network, see Figure 20–2.

Each system is using an IPv4 address space.

For a similar example with IPv6 addresses, see How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6.
Each system has two interfaces. The hme0 interface connects to the Internet. In this example, Internet IP addresses begin with 192.168. The hme1 interface connects to the company's LAN, its intranet. In this example, intranet IP addresses begin with the number 10.
Each system requires ESP authentication with the SHA–1 algorithm. The SHA–1 algorithm requires a 160-bit key.
Each system requires ESP encryption with the AES algorithm. The AES algorithm uses a 128-bit or 256–bit key.
Each system can connect to a router that has direct access to the Internet.
Each system uses shared security associations.

Figure 20–2 Sample VPN Between Offices Separated by the Internet

Diagram shows details of VPN between Europe and California
offices.

As the preceding illustration shows, the procedures for the IPv4 network use the following configuration parameters.

Parameter

Europe

California

System name

enigma

partym

System intranet interface

hme1

hme1

System intranet address, also the -point address in Step 7

10.16.16.6

10.1.3.3

System Internet interface

hme0

hme0

System Internet address, also the tsrc address in Step 7

192.168.116.16

192.168.13.213

Name of Internet router

router-E

router-C

Address of Internet router

192.168.116.4

192.168.13.5

Tunnel name

ip.tun0

ip.tun0

The following IPv6 addresses are used in the procedures. The tunnel names are the same.

Parameter

Europe

California

System intranet address

6000:6666::aaaa:1116

6000:3333::eeee:1113

System Internet address

2001::aaaa:6666:6666

2001::eeee:3333:3333

Address of Internet router

2001::aaaa:0:4

2001::eeee:0:1

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4

In tunnel mode, the inner IP packet determines the IPsec policy that protects its contents.

This procedure extends the procedure How to Secure Traffic Between Two Systems With IPsec. The setup is described in Description of the Network Topology for the IPsec Tasks to Protect a VPN.

Note –

Perform the steps in this procedure on both systems.

In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

Before You Begin

You must be in the global zone to configure IPsec policy for the system or for a shared-IP zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone.

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 secure remote login.

Control the flow of packets before configuring IPsec.

Ensure that IP forwarding and IP dynamic routing are disabled.

# routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:

# routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

Turning off IP forwarding prevents packets from being forwarded from one network to another network through this system. For a description of the routeadm command, see the routeadm(1M) man page.

Turn on IP strict destination multihoming.
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.

When strict destination multihoming is enabled, packets that arrive on a particular interface must be addressed to one of the local IP addresses of that interface. All other packets, even packets that are addressed to other local addresses of the system, are dropped.

Caution –
The multihoming value reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

Disable most network services, and possibly all network services.

Note –

If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

Choose one of the following options:

If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.
# netservices limited

Otherwise, individually disable network services.

# svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

Verify that most network services are disabled.

Verify that loopback mounts and the ssh service are running.

# svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

Add a pair of SAs between the two systems.

Choose one of the following options:
- Configure IKE to manage the keys for the SAs. Use one of the procedures in Configuring IKE (Task Map) to configure IKE for the VPN.
- If you have an overriding reason to manually manage the keys, see How to Manually Create IPsec Security Associations.

Add IPsec policy.

Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN. To strengthen the policy, see Example 20–12. For additional examples, see Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode.

In this policy, IPsec protection is not required between systems on the local LAN and the internal IP address of the gateway, so a bypass statement is added.

On the enigma system, type the following entry into the ipsecinit.conf file:

# LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

On the partym system, type the following entry into the ipsecinit.conf file:

# LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf

To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:
- Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

Configure the tunnel, ip.tun0, in the /etc/hostname.ip.tun0 file.

The syntax of the file is the following:
system1-point system2-point tsrc system1-taddr tdst system2-taddr router up
1. On the enigma system, add the following entry to the hostname.ip.tun0 file:
  10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up
2. On the partym system, add the following entry to the hostname.ip.tun0 file:
  10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

Protect the tunnel with the IPsec policy that you created.
# svcadm refresh svc:/network/ipsec/policy:default

To read the contents of the tunnel configuration file into the kernel, restartRestart the network services.
# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.
1. On the enigma system, add the router entry to the /etc/hostname.hme1 file.
  192.168.116.16 router
2. On the partym system, add the router entry to the /etc/hostname.hme1 file.
  192.168.13.213 router
IP forwarding means that packets that arrive from somewhere else can be forwarded. IP forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have IP forwarding turned on.

Because the hme1 interface is inside the intranet, IP forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, IP forwarding must be turned on for ip.tun0.

The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.

Ensure that the routing protocols do not advertise the default route within the intranet.
1. On the enigma system, add the private flag to the /etc/hostname.hme0 file.
  10.16.16.6 private
2. On the partym system, add the private flag to the /etc/hostname.hme0 file.
  10.1.3.3 private
Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. By setting the interface's private flag, these advertisements are prevented.

Manually add a default route over the hme0 interface.

The default route must be a router with direct access to the Internet.
1. On the enigma system, add the following route:
  # route add default 192.168.116.4
2. On the partym system, add the following route:
  # route add default 192.168.13.5
  Even though the hme0 interface is not part of the intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system appears to be a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

To complete the procedure, go to Step 22 to run a routing protocol.

Configure the tunnel, ip.tun0.

Note –

The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

Use ifconfig commands to create the point-to-point interface:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

On the enigma system, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

On the partym system, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

Protect the tunnel with the IPsec policy that you created.
# ipsecconf

Bring up the router for the tunnel.
# ifconfig ip.tun0 router up

Turn on IP forwarding for the hme1 interface.
# ifconfig hme1 router
IP forwarding means that packets that arrive from somewhere else can be forwarded. IP forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have IP forwarding turned on.

Because the hme1 interface is inside the intranet, IP forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, IP forwarding must be turned on for ip.tun0.

The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.

Ensure that routing protocols do not advertise the default route within the intranet.
# ifconfig hme0 private
Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. By setting the interface's private flag, these advertisements are prevented.

Manually add a default route over hme0.

The default route must be a router with direct access to the Internet.
1. On the enigma system, add the following route:
  # route add default 192.168.116.4
2. On the partym system, add the following route:
  # route add default 192.168.13.5
  Even though the hme0 interface is not part of the intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system appears to be a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname.ip.tun0 file.
system1-point system2-point tsrc system1-taddr tdst system2-taddr router up
1. On the enigma system, add the following entry to the hostname.ip.tun0 file:
  10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up
2. On the partym system, add the following entry to the hostname.ip.tun0 file:
  10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

Configure the interface files to pass the correct parameters to the routing daemon.

On the enigma system, modify the /etc/hostname.interface files.

# cat /etc/hostname.hme0
## enigma
10.16.16.6 private

# cat /etc/hostname.hme1
## enigma
192.168.116.16 router

On the partym system, modify the /etc/hostname.interface files.

# cat /etc/hostname.hme0
## partym
10.1.3.3 private

# cat /etc/hostname.hme1
## partym
192.168.13.213 router

Run a routing protocol.
# routeadm -e ipv4-routing # routeadm -u
You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in Oracle Solaris. For a procedure, see How to Configure an IPv4 Router.

Example 20–10 Creating Temporary Tunnels When Testing

In this example, the administrator tests tunnel creation on a Solaris 10 4/09 system. Later, the administrator will use the procedure How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 to make the tunnels permanent. During testing, the administrator performs the following series of steps on the systems system1 and system2:

On both systems, the administrator completes the first five steps of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

The administrator uses the ifconfig command to plumb and configure a temporary tunnel.

system1 # ifconfig ip.tun0 plumb
system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
          tsrc 192.168.116.16 tdst 192.168.13.213

# ssh system2
Password: admin-password-on-system2
system2 # ifconfig ip.tun0 plumb
system2 # ifconfig ip.tun0  10.1.3.3 10.16.16.6 \
          tsrc 192.168.13.213 tdst 192.168.116.16

The administrator enables IPsec policy on the tunnel. The policy was created in Step 4 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.
system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default
The administrator makes the Internet interface a router and prevents routing protocols from going over the intranet interface.
system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private
The administrator manually adds routing and runs the routing protocol by completing Step 12 and Step 22 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 on both systems.

Example 20–11 Creating a Tunnel to an Earlier Version of a Solaris System by Using the Command Line

In the Solaris 10 7/07 release, the syntax of the ifconfig command was simplified. In this example, the administrator tests tunnel creation to a system that is running a version of Solaris prior to the Solaris 10 7/07 release. By using the original syntax of the ifconfig command, the administrator can use identical commands on the two communicating systems. Later, the administrator will use How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 to make the tunnels permanent.

During testing, the administrator performs the following steps on the systems system1 and system2:

On both systems, the administrator completes the first five steps of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

The administrator plumbs and configures the tunnel.

system1 # ifconfig ip.tun0 plumb
system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
          tsrc 192.168.116.16 tdst 192.168.13.213 \
          encr_algs aes encr_auth_algs sha1
system1 # ifconfig ip.tun0 router up

# ssh system2
Password: admin-password-on-system2
system2 # ifconfig ip.tun0 plumb
system2 # ifconfig ip.tun0 10.1.3.3  10.16.16.6 \
          tsrc 192.168.13.213 tdst 192.168.116.16 \
          encr_algs aes encr_auth_algs sha1
system2 # ifconfig ip.tun0 router up

The administrator enables IPsec policy on the tunnel. The policy was created in Step 4 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.
system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default
The administrator makes the Internet interface a router and prevents routing protocols from going over the intranet interface.
system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private
The administrator adds routing by completing Step 12 and Step 22 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 on both systems.

Example 20–12 Requiring IPsec Policy on All Systems on a LAN

In this example, the administrator comments out the bypass policy that was configured in Step 4, thereby strengthening the protection. With this policy configuration, each system on the LAN must activate IPsec to communicate with the router.

# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}

Example 20–13 Using IPsec to Protect Telnet Traffic Differently From SMTP Traffic

In this example, the first rule protects telnet traffic on port 23 with Blowfish and SHA-1. The second rule protects SMTP traffic on port 25 with AES and MD5.

{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}

Example 20–14 Using an IPsec Tunnel in Tunnel Mode to Protect a Subnet Differently From Other Network Traffic

The following tunnel configuration protects all traffic from subnet 10.1.3.0/24 across the tunnel:

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

The following tunnel configurations protect traffic from subnet 10.1.3.0/24 to different subnets across the tunnel. Subnets that begin with 10.2.x.x are across the tunnel.

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6

To set up a VPN on an IPv6 network, you follow the same steps as for an IPv4 network. However, the syntax of the commands is slightly different. For a fuller description of the reasons for running particular commands, see the corresponding steps in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Note –

Perform the steps in this procedure on both systems.

This procedure uses the following configuration parameters.

Parameter

Europe

California

System name

enigma

partym

System intranet interface

hme1

hme1

System Internet interface

hme0

hme0

System intranet address

6000:6666::aaaa:1116

6000:3333::eeee:1113

System Internet address

2001::aaaa:6666:6666

2001::eeee:3333:3333

Name of Internet router

router-E

router-C

Address of Internet router

2001::aaaa:0:4

2001::eeee:0:1

Tunnel name

ip6.tun0

ip6.tun0

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 secure remote login.

Control the flow of packets before configuring IPsec.

For the effects of these commands, see Step 2 in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Ensure that IP forwarding and IP dynamic routing are disabled.

# routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:

# routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

Turn on IP strict destination multihoming.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1
Caution –
The value of ip6_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

Disable most network services, and possibly all network services.

Note –

If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

Choose one of the following options:

If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.
# netservices limited

Otherwise, individually disable network services.

# svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

Verify that most network services are disabled.

Verify that loopback mounts and the ssh service are running.

# svcs | grep network
online         Aug_02   svc:/network/loopback:default
...
online         Aug_09   svc:/network/ssh:default

Add a pair of SAs between the two systems.

Choose one of the following options:
- Configure IKE to manage the keys for the SAs. Use one of the procedures in Configuring IKE (Task Map) to configure IKE for the VPN.
- If you have an overriding reason to manually manage the keys, see How to Manually Create IPsec Security Associations.

Add IPsec policy for the VPN.

Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN.

On the enigma system, type the following entry into the ipsecinit.conf file:

# IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

On the partym system, type the following entry into the ipsecinit.conf file:

# IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf

To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:
- Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.
1. On the enigma system, add the following entry to the hostname.ip6.tun0 file:
  6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up
2. On the partym system, add the following entry to the hostname.ip6.tun0 file:
  6000:3333::eeee:1113 6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

Protect the tunnel with the IPsec policy that you created.
# svcadm refresh svc:/network/ipsec/policy:default

To read the contents of the tunnel configuration file into the kernel, restart the network services.
# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.
1. On the enigma system, add the router entry to the /etc/hostname6.hme1 file.
  2001::aaaa:6666:6666 inet6 router
2. On the partym system, add the router entry to the /etc/hostname6.hme1 file.
  2001::eeee:3333:3333 inet6 router

Ensure that routing protocols do not advertise the default route within the intranet.
1. On the enigma system, add the private flag to the /etc/hostname6.hme0 file.
  6000:6666::aaaa:1116 inet6 private
2. On the partym system, add the private flag to the /etc/hostname6.hme0 file.
  6000:3333::eeee:1113 inet6 private

Manually add a default route over hme0.
1. On the enigma system, add the following route:
  # route add -inet6 default 2001::aaaa:0:4
2. On the partym system, add the following route:
  # route add -inet6 default 2001::eeee:0:1

To complete the procedure, go to Step 22 to run a routing protocol.

Configure a secure tunnel, ip6.tun0.

Note –

The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

On the enigma system, type the following commands:

# ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

On the partym system, type the following commands:

# ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

Protect the tunnel with the IPsec policy that you created.
# ipsecconf

Bring up the router for the tunnel.
# ifconfig ip6.tun0 router up

On each system, turn on IP forwarding for the hme1 interface.
# ifconfig hme1 router

Ensure that routing protocols do not advertise the default route within the intranet.
# ifconfig hme0 private

Manually add a default route over hme0.

The default route must be a router with direct access to the Internet.
1. On the enigma system, add the following route:
  # route add -inet6 default 2001::aaaa:0:4
2. On the partym system, add the following route:
  # route add -inet6 default 2001::eeee:0:1

Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname6.ip6.tun0 file.

The entry replicates the parameters that were passed to the ifconfig command in Step 14.
1. On the enigma system, add the following entry to the hostname6.ip6.tun0 file:
  6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up
2. On the partym system, add the following entry to the hostname6.ip6.tun0 file:
  6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

On each system, configure the interface files to pass the correct parameters to the routing daemon.

On the enigma system, modify the /etc/hostname6.interface files.

# cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private

#  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

On the partym system, modify the /etc/hostname6.interface files.

# cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private

# cat /etc/hostname6.hme1
## partym
2001::eeee:3333:3333 inet6 router

Run a routing protocol.
# routeadm -e ipv6-routing # routeadm -u
You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in Oracle Solaris. For a procedure, see Configuring an IPv6 Router.

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4

In transport mode, the outer header determines the IPsec policy that protects the inner IP packet.

This procedure extends the procedure How to Secure Traffic Between Two Systems With IPsec. In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

This procedure uses the setup that is described in Description of the Network Topology for the IPsec Tasks to Protect a VPN. For a fuller description of the reasons for running particular commands, see the corresponding steps in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Note –

Perform the steps in this procedure on both systems.

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 secure remote login.

Control the flow of packets before configuring IPsec.

Ensure that IP forwarding and IP dynamic routing are disabled.

# routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:

# routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

Turn on IP strict destination multihoming.
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Caution –
The value of ip_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

Disable most network services, and possibly all network services.

Note –

If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

Choose one of the following options:

If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.
# netservices limited

Otherwise, individually disable network services.

# svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

Verify that most network services are disabled.

Verify that loopback mounts and the ssh service are running.

# svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

Add a pair of SAs between the two systems.

Choose one of the following options:
- Configure IKE to manage the keys for the SAs. Use one of the procedures in Configuring IKE (Task Map) to configure IKE for the VPN.
- If you have an overriding reason to manually manage the keys, see How to Manually Create IPsec Security Associations.

Add IPsec policy.

Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN. To strengthen the policy, see Example 20–15.

On the enigma system, type the following entry into the ipsecinit.conf file:

# LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

On the partym system, type the following entry into the ipsecinit.conf file:

# LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf

To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:
- Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

Configure the tunnel, ip.tun0, in the /etc/hostname.ip.tun0 file.
1. On the enigma system, add the following entry to the hostname.ip.tun0 file:
  10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up
2. On the partym system, add the following entry to the hostname.ip.tun0 file:
  10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

Protect the tunnel with the IPsec policy that you created.
# svcadm refresh svc:/network/ipsec/policy:default

To read the contents of the hostname.ip.tun0 file into the kernel, restartRestart the network services.
# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.
1. On the enigma system, add the router entry to the /etc/hostname.hme1 file.
  192.168.116.16 router
2. On the partym system, add the router entry to the /etc/hostname.hme1 file.
  192.168.13.213 router

Ensure that routing protocols do not advertise the default route within the intranet.
1. On the enigma system, add the private flag to the /etc/hostname.hme0 file.
  10.16.16.6 private
2. On the partym system, add the private flag to the /etc/hostname.hme0 file.
  10.1.3.3 private

Manually add a default route over hme0.
1. On the enigma system, add the following route:
  # route add default 192.168.116.4
2. On the partym system, add the following route:
  # route add default 192.168.13.5

To complete the procedure, go to Step 22 to run a routing protocol.

Configure the tunnel, ip.tun0.

Note –

The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

Use ifconfig commands to create the point-to-point interface:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

On the enigma system, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

On the partym system, type the following commands:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

Protect the tunnel with the IPsec policy that you created.
# ipsecconf

Bring up the router for the tunnel.
# ifconfig ip.tun0 router up

Turn on IP forwarding for the hme1 interface.
# ifconfig hme1 router

Ensure that routing protocols do not advertise the default route within the intranet.
# ifconfig hme0 private

Manually add a default route over hme0.

The default route must be a router with direct access to the Internet.
# route add default router-on-hme0-subnet
1. On the enigma system, add the following route:
  # route add default 192.168.116.4
2. On the partym system, add the following route:
  # route add default 192.168.13.5

Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname.ip.tun0 file.

system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

On the enigma system, add the following entry to the hostname.ip.tun0 file:

10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 router up

On the partym system, add the following entry to the hostname.ip.tun0 file:

10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 router up

Configure the interface files to pass the correct parameters to the routing daemon.

On the enigma system, modify the /etc/hostname.interface files.

# cat /etc/hostname.hme0
## enigma
10.16.16.6 private

# cat /etc/hostname.hme1
## enigma
192.168.116.16 router

On the partym system, modify the /etc/hostname.interface files.

# cat /etc/hostname.hme0
## partym
10.1.3.3 private

# cat /etc/hostname.hme1
## partym
192.168.13.213 router

Run a routing protocol.

# routeadm -e ipv4-routing
# routeadm -u

Example 20–15 Requiring IPsec Policy on All Systems in Transport Mode

# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}

Example 20–16 Using Deprecated Syntax to Configure an IPsec Tunnel in Transport Mode

In this example, the administrator is connecting a Solaris 10 7/07 system with a system that is running the Solaris 10 release. Therefore, the administrator uses Solaris 10 syntax in the configuration file and includes the IPsec algorithms in the ifconfig command.

The administrator follows the procedure How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4 with the following changes in syntax.

For Step 4, the syntax of the ipsecinit.conf file is the following:

# LAN traffic to and from this address can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{} ipsec {encr_algs aes encr_auth_algs sha1}

For Step 14 to Step 16, the syntax to configure a secure tunnel is the following:

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213 \
encr_algs aes encr_auth_algs sha1

# ifconfig ip.tun0 router up

# ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213 \
encr_algs aes encr_auth_algs sha1

The IPsec policy that is passed to the ifconfig commands must be the same as the IPsec policy in the ipsecinit.conf file. Upon reboot, each system reads the ipsecinit.conf file for its policy.

For Step 20, the syntax of the hostname.ip.tun0 file is the following:

10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 encr_algs aes encr_auth_algs sha1 router up

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6

Note –

Perform the steps in this procedure on both systems.

This procedure uses the following configuration parameters.

Parameter

Europe

California

System name

enigma

partym

System intranet interface

hme1

hme1

System Internet interface

hme0

hme0

System intranet address

6000:6666::aaaa:1116

6000:3333::eeee:1113

System Internet address

2001::aaaa:6666:6666

2001::eeee:3333:3333

Name of Internet router

router-E

router-C

Address of Internet router

2001::aaaa:0:4

2001::eeee:0:1

Tunnel name

ip6.tun0

ip6.tun0

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 secure remote login.

Control the flow of packets before configuring IPsec.

Ensure that IP forwarding and IP dynamic routing are disabled.

# routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:

# routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

Turn on IP strict destination multihoming.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1
Caution –
The value of ip6_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

Verify that most network services are disabled.

Verify that loopback mounts and the ssh service are running.

# svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

Add a pair of SAs between the two systems.

Choose one of the following options:
- Configure IKE to manage the keys for the SAs. Use one of the procedures in Configuring IKE (Task Map) to configure IKE for the VPN.
- If you have an overriding reason to manually manage the keys, see How to Manually Create IPsec Security Associations.

Add IPsec policy.

Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN.

On the enigma system, type the following entry into the ipsecinit.conf file:

# IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

On the partym system, type the following entry into the ipsecinit.conf file:

# IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf

To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:
- Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.
- If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.
1. On the enigma system, add the following entry to the hostname.ip6.tun0 file:
  6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up
2. On the partym system, add the following entry to the hostname.ip6.tun0 file:
  6000:3333::eeee:1113 6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

Protect the tunnel with the IPsec policy that you created.
# svcadm refresh svc:/network/ipsec/policy:default

To read the contents of the hostname.ip6.tun0 file into the kernel, restart the network services.
# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.
1. On the enigma system, add the router entry to the /etc/hostname6.hme1 file.
  2001::aaaa:6666:6666 inet6 router
2. On the partym system, add the router entry to the /etc/hostname6.hme1 file.
  2001::eeee:3333:3333 inet6 router

Ensure that routing protocols do not advertise the default route within the intranet.
1. On the enigma system, add the private flag to the /etc/hostname6.hme0 file.
  6000:6666::aaaa:1116 inet6 private
2. On the partym system, add the private flag to the /etc/hostname6.hme0 file.
  6000:3333::eeee:1113 inet6 private

Manually add a default route over hme0.
1. On the enigma system, add the following route:
  # route add -inet6 default 2001::aaaa:0:4
2. On the partym system, add the following route:
  # route add -inet6 default 2001::eeee:0:1

To complete the procedure, go to Step 22 to run a routing protocol.

Configure a secure tunnel, ip6.tun0.

Note –

The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

On the enigma system, type the following commands:

# ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

On the partym system, type the following commands:

# ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6  6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

Protect the tunnel with the IPsec policy that you created.
# ipsecconf

Bring up the router for the tunnel.
# ifconfig ip6.tun0 router up

Turn on IP forwarding for the hme1 interface.
# ifconfig hme1 router

Ensure that routing protocols do not advertise the default route within the intranet.
# ifconfig hme0 private

On each system, manually add a default route over hme0.

The default route must be a router with direct access to the Internet.
1. On the enigma system, add the following route:
  # route add -inet6 default 2001::aaaa:0:4
2. On the partym system, add the following route:
  # route add -inet6 default 2001::eeee:0:1

On each system, ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname6.ip6.tun0 file.

The entry replicates the parameters that were passed to the ifconfig command in Step 14.
1. On the enigma system, add the following entry to the hostname6.ip6.tun0 file:
  6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up
2. On the partym system, add the following entry to the hostname6.ip6.tun0 file:
  6000:3333::eeee:1113 6000:6666::aaaa:1116 \ tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

Configure the interface files to pass the correct parameters to the routing daemon.

On the enigma system, modify the /etc/hostname6.interface files.

# cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private

#  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

On the partym system, modify the /etc/hostname6.interface files.

# cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private

# cat /etc/hostname6.hme1
## 
partym2001::eeee:3333:3333 inet6 router

Run a routing protocol.

# routeadm -e ipv6-routing
# routeadm -u

Example 20–17 Using Deprecated Syntax to Configure IPsec in Transport Mode Over IPv6

The administrator follows the procedure How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6 with the following changes in syntax.

For Step 4, the syntax of the ipsecinit.conf file is the following:

# IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{} ipsec {encr_algs aes encr_auth_algs sha1}

For Step 14 to Step 17, the syntax to configure a secure tunnel is the following:

# ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 \
encr_algs aes encr_auth_algs sha1

# ifconfig ip6.tun0 inet6 router up

The IPsec policy that is passed to the ifconfig commands must be the same as the IPsec policy in the ipsecinit.conf file. Upon reboot, each system reads the ipsecinit.conf file for its policy.

For Step 20, the syntax of the hostname6.ip6.tun0 file is the following:

6000:6666::aaaa:1116  6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333 \
encr_algs aes encr_auth_algs sha1 router up

How to Prevent IP Spoofing

To prevent the system from forwarding packets to another interface without trying to decrypt them, the system needs to check for IP spoofing. One method of prevention is to set the IP strict destination multihoming parameter by using the ndd command. When this parameter is set in an SMF manifest, the parameter is set when the system reboots.

Note –

Perform the steps in this procedure on both systems.

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.

Create the site-specific SMF manifest to check for IP spoofing.

Use the following sample script, /var/svc/manifest/site/spoof_check.xml.

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='Custom:ip_spoof_checking'>

<!--    This is a custom smf(5) manifest for this system. Place this
        file in /var/svc/manifest/site, the directory for local
        system customizations. The exec method uses an unstable
        interface to provide a degree of protection against IP
        spoofing attacks when this system is acting as a router.

        IP spoof protection can also be achieved by using ipfilter(5).
        If ipfilter is configured, this service can be disabled.

        Note: Unstable interfaces might be removed in later
        releases.  See attributes(5).
-->

<service
        name='site/ip_spoofcheck'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />
        <single_instance />

        <!--    Don't enable spoof protection until the
                network is up.
        -->
        <dependency
                name='basic_network'
                grouping='require_all'
                restart_on='none'
                type='service'>
        <service_fmri value='svc:/milestone/network' />
        </dependency>

        <exec_method
                type='method'
                name='start'
                exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
<!--    
     For an IPv6 network, use the IPv6 version of this command, as in:
                exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
-->
                timeout_seconds='60'
        />

        <exec_method
                type='method'
                name='stop'
                exec=':true'
                timeout_seconds='3'
        />

        <property_group name='startd' type='framework'>
                <propval
                        name='duration'
                        type='astring'
                        value='transient'
                />
        </property_group>

        <stability value='Unstable' />

</service>
</service_bundle>

Import this manifest into the SMF repository.

# svccfg import /var/svc/manifest/site/spoof_check.xml

Enable the ip_spoofcheck service.

Use the name that is defined in the manifest, /site/ip_spoofcheck.
# svcadm enable /site/ip_spoofcheck

Verify that the ip_spoofcheck service is online.
# svcs /site/ip_spoofcheck

Chapter 20 Configuring IPsec (Tasks)

Protecting Traffic With IPsec (Task Map)

Protecting Traffic With IPsec

How to Secure Traffic Between Two Systems With IPsec

Before You Begin

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

Example 20–2 Securing Traffic With IPsec Without Rebooting

How to Use IPsec to Protect a Web Server From Nonweb Traffic

Before You Begin

How to Display IPsec Policies

Before You Begin

How to Generate Random Numbers on a Solaris System

Example 20–3 Generating Key Material for IPsec

How to Manually Create IPsec Security Associations

Before You Begin

Example 20–4 Replacing IPsec SAs

How to Verify That Packets Are Protected With IPsec

Before You Begin

How to Configure a Role for Network Security

Example 20–5 Dividing Network Security Responsibilities Between Roles

How to Manage IKE and IPsec Services

Troubleshooting

Protecting a VPN With IPsec

Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode

Figure 20–1 IPsec Tunnel Diagram

Example 20–6 Creating a Tunnel That All Subnets Can Use

Example 20–7 Creating a Tunnel That Connects Two Subnets Only

Example 20–8 Creating a Tunnel for Email Traffic Only Between Two Subnets

Example 20–9 Creating a Tunnel for FTP Traffic for All Subnets

Protecting a VPN With IPsec (Task Map)

Description of the Network Topology for the IPsec Tasks to Protect a VPN

Figure 20–2 Sample VPN Between Offices Separated by the Internet

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4

Before You Begin

Example 20–10 Creating Temporary Tunnels When Testing

Example 20–11 Creating a Tunnel to an Earlier Version of a Solaris System by Using the Command Line

Example 20–12 Requiring IPsec Policy on All Systems on a LAN

Example 20–13 Using IPsec to Protect Telnet Traffic Differently From SMTP Traffic

Example 20–14 Using an IPsec Tunnel in Tunnel Mode to Protect a Subnet Differently From Other Network Traffic

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4

Example 20–15 Requiring IPsec Policy on All Systems in Transport Mode

Example 20–16 Using Deprecated Syntax to Configure an IPsec Tunnel in Transport Mode

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6

Example 20–17 Using Deprecated Syntax to Configure IPsec in Transport Mode Over IPv6

How to Prevent IP Spoofing

Example 20–1 Adding IPsec Policy When Using an `ssh` Connection