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. For a discussion, see Transport and Tunnel Modes in IPsec. The examples
and procedures in this section use IPv4 addresses, but the examples and procedures
apply to IPv6 VPNs as well. For a short discussion, see Protecting Traffic With IPsec.

Examples of Protecting a VPN With IPsec by Using Tunnel Mode

Figure 15-1 Tunnel Protected by IPsec

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

## Tunnel configuration ##
# Tunnel name is 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

In this example, all traffic from the local LANs of the Central LAN
in Figure 15-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.

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.

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

Each system is using an IPv4 address space.

Each system has two interfaces. The net0 interface connects to the Internet. In this example, Internet IP addresses begin with 192.168. The net1 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-2 algorithm. In this example, the SHA-2 algorithm requires a 512-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 15-2 Sample VPN Between Offices Connected Across the Internet

As the preceding illustration shows, the procedures use the following configuration parameters.

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

# ipadm set-prop -p hostmodel=strong ipv4

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

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 net1 interface is inside the intranet, IP forwarding must be
turned on for net1. Because tun0 connects the two systems through the Internet, IP
forwarding must remain on for tun0. The net0 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.

On each system, prevent the advertising of the private interface.

# ipadm set-addrprop -p private=on net0

Even if net0 has IP forwarding turned off, 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.

Restart the network services.

# svcadm restart svc:/network/initial:default

Manually add a default route over the net0 interface.

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

On the calif-vpn system, add the following route:

# route -p add net default 192.168.13.5

On the euro-vpn system, add the following route:

# route -p add net default 192.168.116.4

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.