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).
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. | |
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. | |
Generate random numbers. |
Generates random numbers for keying material for manually created security associations. | |
Create or replace security associations manually. |
Provides the raw data for security associations:
| |
Check that IPsec is protecting the packets. |
Examines snoop output for specific headers that indicate how the IP datagrams are protected. | |
(Optional) Create a Network Security role. |
Creates a role that can set up a secure network, but has fewer powers than superuser. | |
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. | |
Set up a secure virtual private network (VPN). |
Sets up IPsec between two systems that are separated by the Internet. |
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 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. In the Solaris Express Community Edition, 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.
This procedure assumes the following setup:
The two systems are named enigma and partym.
Each system has two addresses, an IPv4 address and an IPv6 address.
Each system invokes AH protection with the MD5 algorithm, which requires a key of 128 bits.
Each system invokes ESP protections with the 3DES algorithm, which requires a key of 192 bits.
Each system uses shared security associations.
With shared SAs, only one pair of SAs is needed to protect the two systems.
You must be in the global zone to configure IPsec policy.
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.
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.
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.
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 |
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 |
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.
On the enigma system, add the following policy:
{laddr enigma raddr partym} ipsec {auth_algs any encr_algs any sa shared} |
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.
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.
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.
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.
# 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.
Verify that packets are being protected.
For the procedure, see How to Verify That Packets Are Protected With IPsec.
In this example, the administrator as superuser configures IPsec policy and keys on two systems by using the ssh command to reach the second system. For more information, see the ssh(1) man page.
First, the administrator configures the first system by performing Step 2 through Step 5 of the preceding procedure.
Then, in a different terminal window, the administrator uses the ssh command to log in to the second system.
local-system # ssh other-system other-system # |
In the terminal window of the ssh session, the administrator configures the IPsec policy and keys of the second system by completing Step 2 through Step 8.
Then, the administrator ends the ssh session.
other-system # exit local-system # |
Finally, the administrator enables IPsec policy on the first system by completing Step 6 and Step 8.
The next time the two systems communicate, including by using an ssh connection, the communication is protected by IPsec.
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.
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:
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.
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.
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.
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 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.
You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments.
You must run the ipsecconf command in the global zone.
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.
Display IPsec policies.
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.
Display the IPsec policy entries in the order in which a match occurs.
$ ipsecconf -l |
Display the IPsec policy entries, including per-tunnel entries, in the order in which a match occurs.
$ ipsecconf -L |
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.
Use a random number generator. If your site has a generator, do not use this procedure.
Use the od command that is described in this procedure. The od command uses the /dev/random Solaris device as input. For more information, see the od(1) man page.
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 |
Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.
Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.
Removes the input offset base from the display.
Serves as a source for random numbers.
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.
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.
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.
You must be in the global zone to manually manage keying material for a non-global zone.
Generate the keying material for the SAs.
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.
Decide on your method of key generation.
If you have a random number generator at your site, use the generator.
To use the pktool command, see How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services.
To use the od command, see How to Generate Random Numbers on a Solaris System.
On each system, perform the following steps:
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.
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.
Add the keys to the manual keys file for IPsec.
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 |
Protect the manual keys file for IPsec with read-only permissions.
# chmod 400 /etc/inet/secret/ipseckeys |
Verify the syntax of the manual keys file.
# ipseckey -c -f /etc/inet/secret/ipseckeys |
The keying material on the two systems must be identical.
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.
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.
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 ----- ... |
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.
% 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.
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.
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.
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.
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.
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 |
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.
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.
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).
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 |
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} |
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} |
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} |
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} |
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. | ||
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. |
The procedures that follow this section assume the following setup. For a depiction of the network, see Figure 19–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 invokes AH protection with the MD5 algorithm. The MD5 algorithm requires a 128-bit key.
Each system invokes ESP protection with the 3DES algorithm. The 3DES algorithm requires a 192-bit key.
Each system can connect to a router that has direct access to the Internet.
Each system uses shared security associations.
As the preceding illustration shows, the IPv4 procedures use these configuration parameters.
Parameter |
Europe |
California |
||
---|---|---|---|---|
System name |
|
|
||
System intranet interface |
|
|
||
System Internet interface |
|
|
||
System intranet address, also the -point address in Step 6 |
|
|
||
System Internet address, also the tsrc address in Step 6 |
|
|
||
Name of Internet router |
|
|
||
Address of Internet router |
|
|
||
Tunnel name |
|
|
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.
Perform the steps in this procedure on both systems.
You must be in the global zone to configure IPsec policy.
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.
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.
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.
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 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.
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} |
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} |
(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
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 |
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, restart the network services.
# svcadm restart svc:/network/initial:default |
Turn on IP forwarding for the hme1 interface.
On the enigma system, add the router entry to the /etc/hostname.hme1 file.
192.168.116.16 router |
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.
On the enigma system, add the private flag to the /etc/hostname.hme0 file.
10.16.16.6 private |
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.
On the enigma system, add the following route:
# route add default 192.168.116.4 |
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 13 to run a routing protocol.
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.
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:
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 11 and Step 13 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 on both systems.
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 3des encr_auth_algs md5 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 3des encr_auth_algs md5 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 11 and Step 13 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 on both systems.
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} |
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} |
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} |
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.
Perform the steps in this procedure on both systems.
This procedure uses the following configuration parameters.
Parameter |
Europe |
California |
||
---|---|---|---|---|
System name |
|
|
||
System intranet interface |
|
|
||
System Internet interface |
|
|
||
System intranet address |
|
|
||
System Internet address |
|
2001::eeee:3333:3333 |
||
Name of Internet router |
|
|
||
Address of Internet router |
|
|
||
Tunnel name |
|
|
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.
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 |
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.
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 3DES and MD5. {tunnel ip6.tun0 negotiate tunnel} ipsec {encr_algs 3des encr_auth_algs md5 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 3DES and MD5. {tunnel ip6.tun0 negotiate tunnel} ipsec {encr_algs 3des encr_auth_algs md5 sa shared} |
(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.
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 |
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 |
Ensure that routing protocols do not advertise the default route within the intranet.
Manually add a default route over hme0.
To complete the procedure, go to Step 13 to run a routing protocol.
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.
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.
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.
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 |
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.
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 19–14.
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} |
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} |
(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Configure the tunnel, ip.tun0, in the /etc/hostname.ip.tun0 file.
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, restart the network services.
# svcadm restart svc:/network/initial:default |
Ensure that routing protocols do not advertise the default route within the intranet.
Manually add a default route over hme0.
To complete the procedure, go to Step 13 to run a routing protocol.
# routeadm -e ipv4-routing # routeadm -u |
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} |
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.
Perform the steps in this procedure on both systems.
This procedure uses the following configuration parameters.
Parameter |
Europe |
California |
||
---|---|---|---|---|
System name |
|
|
||
System intranet interface |
|
|
||
System Internet interface |
|
|
||
System intranet address |
|
|
||
System Internet address |
|
|
||
Name of Internet router |
|
|
||
Address of Internet router |
|
|
||
Tunnel name |
|
|
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.
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 |
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.
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 3DES and MD5. {tunnel ip6.tun0 negotiate transport} ipsec {encr_algs 3des encr_auth_algs md5} |
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} |
(Optional) Verify the syntax of the IPsec policy file.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.
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 |
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 |
Ensure that routing protocols do not advertise the default route within the intranet.
Manually add a default route over hme0.
To complete the procedure, go to Step 13 to run a routing protocol.
Run a routing protocol.
# routeadm -e ipv6-routing # routeadm -u |
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.
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 |