Protecting a VPN With IPsec

Oracle Solaris can configure a VPN that is protected by IPsec. Tunnels can be created in tunnel mode or in 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.

IPsec in tunnel mode offers 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 Tunnel Mode.

• For the procedures that protect VPNs, see Protecting a VPN With IPsec (Task Map).

Examples of Protecting a VPN With IPsec by Using Tunnel Mode

Figure 20-1 IPsec Tunnel Diagram

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

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

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

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

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

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

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

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

Example 20-8 Creating a Tunnel for sendmail Traffic Only Between Two Subnets

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

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

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

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

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

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

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