Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: March 2018
 
 

How to Protect the Connection Between Two LANs With IPsec 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 Network Traffic Between Two Servers With IPsec. The setup 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 Secure Network Traffic Between Two Servers With IPsec.


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 Trusted Extensions Configuration and Administration.

Before You Begin

Each system is either a global zone or an exclusive-IP zone. For more information, see IPsec and Oracle Solaris Zones.

    A user with specific rights can run these commands without being root.

  • To run configuration commands, you must become an administrator who is assigned the Network IPsec Management rights profile.

  • To edit IPsec-related system files and create keys, you use the pfedit command.

  • To edit the hosts file, you must be in the root role or have explicit permission to edit that file.

For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.

If you administer remotely, see Example 32, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3 for secure remote login instructions.

  1. Control the flow of packets before configuring IPsec.
    1. Disable IP forwarding and IP dynamic routing.
      # routeadm -d ipv4-routing
      # ipadm set-prop -p forwarding=off ipv4
      # routeadm -u

      Disabling 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. Enable IP strict multihoming.
      # ipadm set-prop -p hostmodel=strong ipv4

      Enabling IP strict multihoming requires that packets for one of the system's destination addresses arrive at the correct destination address.

      When the hostmodel parameter is set to strong, 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.

    3. Verify that most network services are disabled.

      Verify that the ssh service is running.

      % svcs | grep network
      …
      online         Aug_09   svc:/network/ssh:default
  2. Add the IPsec policy for the VPN to the /etc/inet/ipsecinit.conf file.

    For additional examples, see Examples of Protecting a VPN With IPsec by Using 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 euro-vpn system, add the following entry to the ipsecinit.conf file:
      # LAN traffic to and from this host can bypass IPsec.
      {laddr 192.0.2.36 dir both} bypass {}
      
      # WAN traffic uses ESP with AES and SHA-2.
      {tunnel tun0 negotiate tunnel} 
       ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
    2. On the calif-vpn system, add the following entry to the ipsecinit.conf file:
      # LAN traffic to and from this host can bypass IPsec.
      {laddr 192.0.2.3 dir both} bypass {}
      
      # WAN traffic uses ESP with AES and SHA-2.
      {tunnel tun0 negotiate tunnel} 
       ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
  3. On each system, configure IKE to add a pair of IPsec SAs between the two systems.

    Configure IKE by following one of the configuration procedures in Configuring IKEv2. For the syntax of the IKE configuration file, see the ikev2.config(4) man page. If you are communicating with a system that only supports the IKEv1 protocol, refer to Configuring IKEv1 and the ike.config(4) man page.


    Note - If you must generate and maintain your keys manually, see How to Manually Create IPsec Keys.
  4. Verify the syntax of the IPsec policy file.
    # ipsecconf -c /etc/inet/ipsecinit.conf

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

  5. Refresh the IPsec policy.
    # svcadm refresh ipsec/policy

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

    # svcadm enable ipsec/policy
  6. Create and configure the tunnel, tun0.

    The following commands configure the internal and external interfaces, create the tun0 tunnel, and assign IP addresses to the tunnel.

    1. On the calif-vpn system, create the tunnel and configure it.
      # ipadm create-ip net1
      # ipadm create-addr -T static -a local=192.0.2.3 net1/inside
      # dladm create-iptun -T ipv4 -a local=198.51.100.33,remote=198.51.100.6 tun0
      # ipadm create-ip tun0
      # ipadm create-addr -T static \
      -a local=192.0.2.3,remote=192.0.2.36 tun0/v4tunaddr

      The first command creates the IP interface net1. The second command adds addresses to net1. The third command creates the IP interface tun0. The fourth command adds IP addresses that are encapsulated in the tunnel link. For more information, see the dladm(1M) and ipadm(1M) man pages.

    2. On the euro-vpn system, create the tunnel and configure it.
      # ipadm create-ip net1
      # ipadm create-addr -T static -a local=192.0.2.36 net1/inside
      # dladm create-iptun -T ipv4 -a local=198.51.100.6,remote=198.51.100.33 tun0
      # ipadm create-ip tun0
      # ipadm create-addr -T static \
      -a local=192.0.2.36,remote=192.0.2.3 tun0/v4tunaddr

      Note - The –T option to the ipadm command specifies the type of address to create. The –T option to the dladm command specifies the tunnel.

      For information about these commands, see the dladm(1M) and ipadm(1M) man pages, and How to Configure an IPv4 Interface in Configuring and Managing Network Components in Oracle Solaris 11.3. For information about customized names, see Network Devices and Datalink Naming in Oracle Solaris in Configuring and Managing Network Components in Oracle Solaris 11.3.

  7. On each system, configure forwarding.
    # ipadm set-ifprop -m ipv4 -p forwarding=on net1
    # ipadm set-ifprop -m ipv4 -p forwarding=on tun0
    # ipadm set-ifprop -m ipv4 -p forwarding=off net0

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

    Because the net1 interface is inside the intranet, IP forwarding must be enabled for net1. Because tun0 connects the two systems through the Internet, IP forwarding must be enabled for tun0. The net0 interface has its IP forwarding disabled off to prevent an outside adversary on the Internet from injecting packets into the protected intranet.

  8. On each system, prevent the advertising of the private interface.
    # ipadm set-addrprop -p private=on net0

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

  9. Restart the network services.
    # svcadm restart svc:/network/initial:default
  10. Manually add a default route over the net0 interface.

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

    1. On the calif-vpn system, add the following route:
      # route -p add net default 198.51.100.31
    2. On the euro-vpn system, add the following route:
      # route -p add net default 198.51.100.1

      Even though the net0 interface is not part of the intranet, net0 does need to reach across the Internet to its peer system. To find its peer, net0 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.