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.	Protects traffic in tunnel mode between two Oracle Solaris systems. Also, protects traffic in tunnel mode between an Oracle Solaris Express system, and a system that is running on another platform.	How to Protect a VPN With an IPsec Tunnel in Tunnel Mode
Protect tunnel traffic in transport mode.	Protects traffic in transport mode between two Solaris systems. Also, protects traffic in transport mode between a system that is running an earlier version of the Solaris OS and an Oracle Solaris system.	How to Protect a VPN With an IPsec Tunnel in Transport Mode
Protect tunnel traffic in transport mode.	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
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.

Each system is using an IPv4 address space. The procedures include examples of IPv6 syntax.
Each system has two interfaces. The hme0 interface connects to the Internet. In this example, Internet IP addresses begin with 192.168. The hme1 interface connects to the company's LAN, its intranet. In this example, intranet IP addresses begin with the number 10.
Each system requires ESP authentication with the SHA–1 algorithm. The SHA–1 algorithm requires a 160-bit key.
Each system requires ESP encryption with the AES algorithm. The AES algorithm uses a 128-bit or 256–bit key.
Each system can connect to a router that has direct access to the Internet.
Each system uses shared security associations.

Figure 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 procedures for the IPv4 network use the following configuration parameters.

This table lists all the configuration parameters for the VPN between Europe and California. The addresses are IPv4 addresses.

Parameter	Europe	California
System name	enigma	partym
System intranet interface	hme1	hme1
System intranet address, also the `-point` address in Step 6	10.16.16.6	10.1.3.3
System intranet address object	hme1/LAN	hme1/LAN
System Internet interface	hme0	hme0
System Internet address, also the `tsrc` address in Step 6	192.168.116.16	192.168.13.213
System Internet address object	hme0/WAN	hme0/WAN
Name of Internet router	router-E	router-C
Address of Internet router	192.168.116.4	192.168.13.5
Tunnel name	tun0	tun0
Tunnel name address object	tun0/to-calif	tun0/to-europe

The following IPv6 addresses are used in the procedures. The tunnel names, tunnel address objects, and Internet and intranet address objects are the same. For information about tunnel names, see Tunnel Configuration and Administration With the dladm Command. For information about address objects, see How to Configure an IP Interface in System Administration Guide: Network Interfaces and Network Virtualization. Also see the ipadm(1M) man page.

This table lists the IPv6 addresses for the VPN between Europe and California.

Parameter	Europe	California
System intranet address	6000:6666::aaaa:1116	6000:3333::eeee:1113
System Internet address	2001::aaaa:6666:6666	2001::eeee:3333:3333
Address of Internet router	2001::aaaa:0:4	2001::eeee:0:1

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

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

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

Note - Perform the steps in this procedure on both systems.

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

Note - To use IPsec in tunnel mode with labels on a Trusted Extensions system, see the extension of this procedure in How to Configure a Tunnel Across an Untrusted Network in Oracle Solaris Trusted Extensions Configuration and Administration.

Before You Begin

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

Become an administrator.
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

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.
Control the flow of packets before configuring IPsec.
1. Ensure that IP forwarding and IP dynamic routing are disabled.
```
# routeadm
```
  On an IPv4 system, the output appears similar to the following:
```
# routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…
```
  On an IPv6 system, the output shows IPv6 routing and configuration settings.
2. If IP forwarding and IP dynamic routing are enabled, disable them.
  - For an IPv4 network, type the following commands:
```
# routeadm -d ipv4-routing
# ipadm set-prop -p forwarding=off ipv4
# routeadm -u
```
  - For an IPv6 network, type the following commands:
```
# ipadm set-prop -p forwarding=off ipv6
# routeadm -d ipv6-routing
# 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.
3. Turn on IP strict destination multihoming.
  - For an IPv4 network, type the following command:
```
# ndd -set /dev/ip ip_strict_dst_multihoming 1
```
  - For an IPv6 network, type the following command:
```
# ndd -set /dev/ip ip6_strict_dst_multihoming 1
```
  Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.
  When strict destination multihoming is enabled, packets that arrive on a particular interface must be addressed to one of the local IP addresses of that interface. All other packets, even packets that are addressed to other local addresses of the system, are dropped.
  
  Caution - The multihoming value reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.
4. 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 AES and SHA-1.
{tunnel tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

For an IPv6 network, the entry appears similar to the following:

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

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

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

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

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

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

For an IPv6 network, the entry appears similar to the following:

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

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

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

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

Create and configure the tunnel, tunnel-name.

For example, name the tunnel tun0, analogous to the hme0 interface.

On the enigma system, create the tunnel and configure it.
- For IPv4 addresses, the syntax appears similar to the following:
```
# dladm create-iptun -T ipv4 -a local=192.168.116.16,remote=192.168.13.213 tun0
# ipadm create-addr -T static -a local=10.16.16.6,remote=10.1.3.3 tun0/to-calif
# ipadm set-ifprop -p forwarding=on -m ipv4 tun0
```
- For IPv6 addresses, the syntax appears similar to the following:
```
# dladm create-iptun -T ipv6
-a local=2001::aaaa:6666:6666,remote=2001::eeee:3333:3333 tun0
# ipadm create-addr -T static \
-a local=2001::aaaa:6666:6666,remote=2001::eeee:3333:3333 tun0/to-calif
# ipadm set-ifprop -p forwarding=on -m ipv6 tun0
```
For information about these commands, see the dladm(1M) and ipadm(1M) man pages, and How to Configure an IP Interface in System Administration Guide: Network Interfaces and Network Virtualization. For information about creating customized names, such as tun0, see Assigning Names to Datalinks in System Administration Guide: Network Interfaces and Network Virtualization.

On the partym system, create the tunnel and configure it:

For IPv4 addresses, the syntax appears similar to the following:

# dladm create-iptun -T ipv4 -a local=192.168.13.213,remote=192.168.116.16 tun0
# ipadm create-addr -T static -a local=10.1.3.3,remote=10.16.16.6 tun0/to-europe
# ipadm set-ifprop -p forwarding=on -m ipv4 tun0

For IPv6 addresses, the syntax appears similar to the following:

# dladm create-iptun -T ipv6 
-a local=2001::eeee:3333:3333,remote=2001::aaaa:6666:6666 tun0
# ipadm create-addr -T static
-a local=6000:3333::eeee:1113,remote=6000:6666::aaaa:1116 tun0/to-europe
# ipadm set-ifprop -p forwarding=on -m ipv6 tun0

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

Restart the network services.

# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.
1. On the enigma system, identify the interface and turn on forwarding:
  - For IPv4 addresses, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 192.168.116.16 hme1/LAN
# ipadm set-ifprop -p forwarding=on -m ipv4 hme1
```
2. On the partym system, identify the interface and turn on forwarding:
  - For IPv4 addresses, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 192.168.13.213 hme1/LAN
# ipadm set-ifprop -p forwarding=on -m ipv4 hme1
```
  - For IPv6 addresses, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 2001::eeee:3333:3333 hme1/LAN
# ipadm set-ifprop -p forwarding=on -m ipv6 hme1
```
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 tun0.
The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.
Ensure that the routing protocols do not advertise the default route within the intranet.
1. On the enigma system, turn off advertising within the intranet.
```
# ipadm create-addr -T static -a 10.16.16.6 -p private=on hme0/WAN
```
  For an IPv6 system, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 6000:6666::aaaa:1116 -p private=on hme0/WAN
```
2. On the partym system, turn off advertising within the intranet.
```
# ipadm create-addr -T static -a 10.1.3.3 -p private=on hme0/WAN
```
  For an IPv6 system, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 6000:3333::eeee:1113 -p private=on hme0/WAN
```
Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. By setting the interface's private flag, these advertisements are prevented.
Manually add a default route over the hme0 interface.
The default route must be a router with direct access to the Internet.
1. On the enigma system, add the following route:
```
# route add default 192.168.116.4
```
  For an IPv6 network, the syntax appears similar to the following:
```
# route add -inet6 default 2001::aaaa:0:4
```
2. On the partym system, add the following route:
```
# route add default 192.168.13.5
```
  For an IPv6 network, the syntax appears similar to the following:
```
# route add -inet6 default 2001::eeee:0:1
```
  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.
Run a routing protocol.
```
# routeadm -e ipv4-routing
# routeadm -u
```
For an IPv6 system, use the ipv6 prefix:
```
# routeadm -e ipv6-routing
# routeadm -u
```
You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in Oracle Solaris. For a procedure, see 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 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 three steps of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode. The administrator names the tunnel test.tun0.

The administrator sets IPsec policy on both systems in the ipsecinit.conf file.

## SYSTEM 1 ipsecinit.conf file
##
## LAN traffic on system1.
{laddr 10.16.16.6 dir both} bypass {}

## WAN traffic on system1.
{tunnel test.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}


## SYSTEM 2 ipsecinit.conf file
##
## LAN traffic on system2.
{laddr 10.1.3.3 dir both} bypass {}

## WAN traffic on system2.
{tunnel test.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Note that the administrator names this tunnel test.tun0.

The administrator verifies the syntax of the file.
```
# ipsecconf -c -f /etc/inet/ipsecinit.conf
```

The administrator uses the dladm command to configure the test.tun0 tunnel and the ipadm command to configure the tunnel IP interface over the link.

system1 # dladm create-iptun -T ipv4 \
-a local=192.168.116.16,remote=192.168.13.213 test.tun0
system1 # ipadm create-addr -T static \
-a local=192.168.116.16,remote=192.168.13.213 test.tun0/tunaddr

# ssh system2
Password: admin-password-on-system2
system2 # dladm create-iptun -T ipv4 \
-a local=192.168.13.213,remote=192.168.116.16 test.tun0
system2 # ipadm create-addr -T static \
-a local=10.1.3.3,remote=10.1.3.3 test.tun0/tunaddr

system1 # dladm create-iptun -T ipv4 \
-a local=192.168.116.16,remote=192.168.13.213 test.tun0
system1 # ipadm create-addr -T static \
-a local=10.16.16.6,remote=10.1.3.3 test.tun0/tunaddr

# ssh system2
Password: admin-password-on-system2
system2 # dladm create-iptun -T ipv4 \
-a local=192.168.13.213,remote=192.168.116.16 test.tun0
system2 # ipadm create-addr -T static \
-a local=10.1.3.3,remote=10.16.16.6 test.tun0/tunaddr

For the syntax of the ipadm command, see the ipadm(1M) man page. For the syntax of the dladm command, see the dladm(1M) man page. For examples, see How to Create and Configure an IP Tunnel.

The administrator enables IPsec policy on the tunnel.

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 # ipadm set-ifprop -p forwarding=on -m ipv4 hme1
system1 # ipadm set-addrpop -p private=on hme0/WAN


system2 # ipadm set-ifprop -p forwarding=on -m ipv4 hme1
system2 # ipadm set-addprop -p private=on ipv4 hme0/WAN
```
For information about address objects, such as hme0/WAN, see the ipadm(1M) man page and How to Configure an IP Interface in System Administration Guide: Network Interfaces and Network Virtualization. For sample procedures that set IP address properties which references address objects, see Setting IP Address Properties in System Administration Guide: Network Interfaces and Network Virtualization.
The administrator manually adds routing and runs the routing protocol by completing Step 11 and Step 12 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode on both systems.

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

The administrator plumbs and configures the tunnel.

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

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

The administrator enables IPsec policy on the tunnel. The policy was created in Step 4 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode.
```
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 12 of How to Protect a VPN With an IPsec Tunnel in Tunnel Mode on both systems.

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 AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}

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 sha1 sa shared}

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

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

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

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

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

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

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

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

Note - Perform the steps in this procedure on both systems.

Become an administrator.
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

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.
Control the flow of packets before configuring IPsec.
For a list of the steps, see Step 2 in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode.
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 AES and SHA-1.
{tunnel tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

For an IPv6 system, the syntax appears similar to the following:

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

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

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

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

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

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

For an IPv6 system, the syntax appears similar to the following:

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

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

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

(Optional) Verify the syntax of the IPsec policy file.
```
# ipsecconf -c -f /etc/inet/ipsecinit.conf
```
Configure the tunnel.
Tunnel configuration for transport mode is the same as tunnel configuration for tunnel mode. For the steps, see Step 6 in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode.
Protect the tunnel with the IPsec policy that you created.
```
# svcadm refresh svc:/network/ipsec/policy:default
```

Restart the network services.

# svcadm restart svc:/network/initial:default

Turn on IP forwarding for the hme1 interface.

On the enigma system, identify the interface and turn on forwarding:

# ipadm create-addr -T static -a 192.168.116.16 hme1/LAN
# ipadm set-ifprop -p forwarding=on -m ipv4 hme1

For IPv6 addresses, the syntax appears similar to the following:

# ipadm create-addr -T static -a 2001::aaaa:6666:6666 hme1/LAN
ipadm set-ifprop -p forwarding=on -m ipv6 hme1

On the partym system, identify the interface and turn on forwarding:

# ipadm create-addr -T static -a 192.168.13.213 hme1/LAN

# ipadm set-ifprop -p forwarding=on -m ipv4 hme1

For IPv6 addresses, the syntax appears similar to the following:

# ipadm create-addr -T static -a 2001::eeee:3333:3333 hme1/LAN
# ipadm set-ifprop -p forwarding=on -m ipv6 hme1

Ensure that routing protocols do not advertise the default route within the intranet.
1. On the enigma system, turn off advertising within the intranet.
```
# ipadm create-addr -T static -a 10.16.16.6 -p private=on hme0/WAN
```
  For an IPv6 system, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 6000:6666::aaaa:1116 -p private=on hme0/WAN
```
2. On the partym system, turn off advertising within the intranet.
```
# ipadm create-addr -T static -a 10.1.3.3 -p private=on hme0/WAN
```
  For an IPv6 system, the syntax appears similar to the following:
```
# ipadm create-addr -T static -a 6000:3333::eeee:1113 -p private=on hme0/WAN
```
Manually add a default route over hme0.
1. On the enigma system, add the following route:
```
# route add default 192.168.116.4
```
  For an IPv6 network, the syntax appears similar to the following:
```
# route add -inet6 default 2001::eeee:0:1
```
2. On the partym system, add the following route:
```
# route add default 192.168.13.5
```
  For an IPv6 network, the syntax appears similar to the following:
```
# route add -inet6 default 2001::eeee:0:1
```

Run a routing protocol.

# routeadm -e ipv4-routing
# routeadm -u

For an IPv6 network, use the ipv6 prefix:

# routeadm -e ipv6-routing
# routeadm -u

Example 19-14 Requiring IPsec Policy on All Systems in Transport Mode

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

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

How to Prevent IP Spoofing

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

Note - Perform the steps in this procedure on both systems.

Become an administrator.
For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

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

Skip Navigation Links
Exit Print View
	System Administration Guide: IP Services Oracle Solaris 11 Express 11/10