test

System Administration Guide: IP Services

Chapter 19 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 18, IP Security Architecture (Overview). For reference information about IPsec, see Chapter 20, 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:

ProcedureHow to Secure Traffic Between Two Systems With IPsec

This procedure assumes the following setup:

Before You Begin

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

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

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

    Note –

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

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

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

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


      # Secure communication with enigma
192.168.116.16 enigma
2001::aaaa:6666:6666 enigma

    2. On a system that is named enigma, type the following in the hosts file:


      # Secure communication with partym
192.168.13.213 partym
2001::eeee:3333:3333 partym

  3. On each system, create the IPsec policy file.

    The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.

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

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


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

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


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

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

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

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

    Note –

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

  6. Verify the syntax of the IPsec policy file.


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

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

  7. Refresh the IPsec policy.


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

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


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

  8. Activate the keys for IPsec.

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

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


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

      • If the ike service is enabled, restart it.


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

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

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


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

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


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

  9. Verify that packets are being protected.

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

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

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

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

ProcedureHow 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. You have completed How to Secure Traffic Between Two Systems With IPsec so that the following conditions are in effect:

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

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

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.

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

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

  4. Verify the syntax of the IPsec policy file.


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

  5. Refresh the IPsec policy.


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

  6. Refresh the keys for IPsec.

    Your setup is complete. Optionally, you can perform Step 7.

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

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

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

    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.

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

ProcedureHow 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 22–1.

On a Solaris system, you have three options for generating random keys.

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

  2. 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 19–2 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.

ProcedureHow to Manually Create IPsec Security Associations

The following procedure provides the keying material for Step 5 in 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 non-global zone.

  1. Generate the keying material for the SAs.

    1. Determine the keys that you require.

      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 MD5 algorithm for AH. Each number must be 32 characters long. One number is for dst enigma. One number is for dst partym.

      • Two hexadecimal random numbers for the 3DES algorithm for ESP. For a 192-bit key, each number must be 48 characters long. One number is for dst enigma. One number is for dst partym.

    2. Decide on your method of key generation.

  2. On each system, perform the following steps:

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

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

      Note –

      Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

    2. Add the keys to the manual keys file for IPsec.

      1. Edit the /etc/inet/secret/ipseckeys file on the enigma system to 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.
#
#   Backslashes indicate command continuation.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg 3des \
   auth_alg md5  \
   encrkey  d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
   authkey  e896f8df7f78d6cab36c94ccf293f031
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg 3des \
   auth_alg md5  \
   encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e \
   authkey ad9ced7ad5f255c9a8605fba5eb4d2fd

      2. Protect the manual keys file for IPsec with read-only permissions.


        # chmod 400 /etc/inet/secret/ipseckeys

      3. Verify the syntax of the manual keys file.


        # ipseckey -c -f /etc/inet/secret/ipseckeys
    Note –

    The keying material on the two systems must be identical.

Example 19–3 Manually Creating Temporary IPsec Security Associations

In this example, the administrator tests various keys. Later, the administrator will type the permanent keys in the ipseckeys file.

During testing, the administrator creates keys by using the ipseckey command in interactive mode. When the ipseckey command is typed, the > prompt indicates interactive mode.


# ipseckey
>

To replace existing SAs, the administrator flushes the current SAs.


> flush
>

To create SAs for outbound packets, the administrator types the following command:


> add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg 3des \
auth_alg md5 \
encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d \
authkey e896f8df7f78d6cab36c94ccf293f031
>

The administrator types the following command for inbound packets:


> add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg 3des \
auth_alg md5 \
encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e \
authkey ad9ced7ad5f255c9a8605fba5eb4d2fd
>

To exit ipseckey interactive mode, the administrator types the quit command.


> quit
#

To change keys on the communicating system, the administrator follows the same steps. On that system, the first set of keys protects inbound packets and the second set of keys protects outbound packets.

ProcedureHow 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:

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.

  1. On one system, such as partym, become superuser.


    % su -
Password: Type root password
#

  2. 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)

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

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

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

  1. Find the Network rights profiles in the local prof_attr database.


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

    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.

  2. 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).

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

    • To create a role that handles IPsec and IKE only, use the Network IPsec Management rights profile.

  4. 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 19–4 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.

To create the roles, the administrator uses the Solaris Management Console.

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

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

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

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

  4. 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 Express Community Edition 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.

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

Figure 19–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 ##
ifconfig ip.tun0 10.1.2.1 10.2.3.1 tsrc 192.168.1.10 tdst 192.168.2.10
Example 19–5 Creating a Tunnel That All Subnets Can Use

In this example, all traffic from the local LANs of the Central LAN in Figure 19–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 md5 sa shared}
Example 19–6 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 sa shared}
Example 19–7 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 md5 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 md5 sa shared}
Example 19–8 Creating a Tunnel for FTP Traffic for All Subnets

In this example, IPsec policy protects the FTP ports in Figure 19–1 with 3DES 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 3des encr_auth_algs md5 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs 3des encr_auth_algs md5 sa shared}
 

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs 3des encr_auth_algs md5 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs 3des encr_auth_algs md5 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 Express systems. 

Also, protects traffic in tunnel mode between a Solaris Express system, and a system that is running on another platform. 

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 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 Express systems. 

Also, protects traffic in transport mode between a system that is running an earlier version of the Solaris OS and a Solaris Express system. 

How to Protect a VPN With an IPsec Tunnel 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 19–10

Protect tunnel traffic in transport mode over IPv6. 

Protects traffic in transport mode between two 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 19–2.

Figure 19–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 IPv4 procedures use these configuration parameters.

Parameter 

Europe 

California 

System name 

 

enigma
 

partym

System intranet interface 

 

hme1
 

hme1

System Internet interface 

 

hme0
 

hme0

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


10.16.16.6
 

10.1.3.3

System Internet address, also the tsrc address in Step 6 


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

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

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

Note –

Perform the steps in this procedure on both systems.

Before You Begin

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

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

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

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

  2. Control the flow of packets before configuring IPsec.

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

    2. 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 – 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.

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

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

    Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN. To strengthen the policy, see Example 19–11. 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.

    1. 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 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

    2. 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 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


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

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

  7. Protect the tunnel with the IPsec policy that you created.


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

  8. To read the contents of the hostname.ip.tun0 file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

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

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

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

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

  13. 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 the Solaris OS. For a procedure, see How to Configure an IPv4 Router.

Example 19–9 Creating Temporary Tunnels When Testing

In this example, the administrator tests tunnel creation. 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:

Example 19–10 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:

Example 19–11 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 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs 3des encr_auth_algs md5}
Example 19–12 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 19–13 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 md5 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 md5 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}

ProcedureHow 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

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

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

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

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

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

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Caution – 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.

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

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy for the VPN.

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

    1. 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 3DES and MD5.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

    2. 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 3DES and MD5.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


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

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

  7. Protect the tunnel with the IPsec policy that you created.


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

  8. To read the contents of the hostname.ip6.tun0 file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

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

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

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

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

  13. 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 the Solaris OS. For a procedure, see Configuring an IPv6 Router.

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

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.

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

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

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

  2. Control the flow of packets before configuring IPsec.

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

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1
      Caution – 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.

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

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

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

    1. 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 3DES and MD5.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

    2. 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 3DES and MD5.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


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

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

  7. Protect the tunnel with the IPsec policy that you created.


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

  8. To read the contents of the hostname.ip.tun0 file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

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

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

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

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

  13. Run a routing protocol.


    # routeadm -e ipv4-routing
# routeadm -u
Example 19–14 Requiring IPsec Policy on All Systems in Transport Mode

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 3DES and MD5.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs 3des encr_auth_algs md5}

ProcedureHow to Protect a VPN With an IPsec Tunnel in Transport 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

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

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

    Note –

    Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for secure remote login.

  2. Control the flow of packets before configuring IPsec.

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

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Caution – 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.

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

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

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

    1. 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 3DES and MD5.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs 3des encr_auth_algs md5}

    2. 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 3DES and MD5.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs 3des encr_auth_algs md5}

  5. (Optional) Verify the syntax of the IPsec policy file.


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

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

  7. Protect the tunnel with the IPsec policy that you created.


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

  8. To read the contents of the hostname.ip6.tun0 file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

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

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

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

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

  13. Run a routing protocol.


    # routeadm -e ipv6-routing
# routeadm -u

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

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

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

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

  3. Import this manifest into the SMF repository.


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

  4. Enable the ip_spoofcheck service.

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


    # svcadm enable /site/ip_spoofcheck

  5. Verify that the ip_spoofcheck service is online.


    # svcs /site/ip_spoofcheck