test

System Administration Guide: IP Services

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

This procedure extends the procedure How to Secure Traffic Between Two Systems With IPsec. The setup is described in Description of the Network Topology for the IPsec Tasks to Protect a VPN. In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

Note –

Perform the steps in this procedure on both systems.

Before You Begin

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

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

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

    Note –

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

  2. Control the flow of packets before configuring IPsec.

    1. Ensure that IP forwarding and IP dynamic routing are disabled.


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

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


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

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

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.

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

      Caution – Caution –

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

    3. Verify that most network services are disabled.

      Verify that loopback mounts and the ssh service are running.


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

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

    Choose one of the following options:

  4. Add IPsec policy.

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

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

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


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

# WAN traffic uses ESP with 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

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


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

# WAN traffic uses ESP with 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs 3des encr_auth_algs md5 sa shared}

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


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

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

    The syntax of the file is the following:


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

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


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

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


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

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


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

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


    # svcadm restart svc:/network/initial:default

  9. Turn on IP forwarding for the hme1 interface.

    1. On the enigma system, add the router entry to the /etc/hostname.hme1 file.


      192.168.116.16 router

    2. On the partym system, add the router entry to the /etc/hostname.hme1 file.


      192.168.13.213 router

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

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

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

  10. Ensure that the routing protocols do not advertise the default route within the intranet.

    1. On the enigma system, add the private flag to the /etc/hostname.hme0 file.


      10.16.16.6 private

    2. On the partym system, add the private flag to the /etc/hostname.hme0 file.


      10.1.3.3 private

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

  11. Manually add a default route over the hme0 interface.

    The default route must be a router with direct access to the Internet.

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


      # route add default 192.168.116.4

    2. On the partym system, add the following route:


      # route add default 192.168.13.5

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

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

  13. Run a routing protocol.


    # routeadm -e ipv4-routing
# routeadm -u

    You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in the Solaris OS. For a procedure, see How to Configure an IPv4 Router.

Example 19–9 Creating Temporary Tunnels When Testing

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

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

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

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

Example 19–11 Requiring IPsec Policy on All Systems on a LAN

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


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

# WAN traffic uses ESP with 3DES and MD5.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs 3des encr_auth_algs md5}
Example 19–12 Using IPsec to Protect Telnet Traffic Differently From SMTP Traffic

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


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
Example 19–13 Using an IPsec Tunnel in Tunnel Mode to Protect a Subnet Differently From Other Network Traffic

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


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

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


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

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

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