An Introduction to FreeS/WAN, Part II

Connect two private LANs securely with a FreeS/WAN tunnel that runs on your existing firewall systems.

Last month I introduced FreeS/WAN,
Linux's implementation of the IPSec tunneling protocol for secure
virtual private networks (VPNs). For my sample configuration, I
used the common scenario of remote access (RA) VPN. RA VPNs, you'll
recall, are used when each remote user is expected to connect to
the home network using separate connections, resulting in a
one-tunnel-per-user setup.

But what happens when some or all of your remote users are
connected to the same local area network (LAN)? I mentioned this
type of site-to-site VPN scenario last month, but I didn't explain
how to set up one. Building site-to-site VPNs with FreeS/WAN,
therefore, is our focus this month.

Architecture: Site-to-Site VPNs

Before we dive into FreeS/WAN configurations, let's take a
quick look at architectural considerations. Figure 1 shows a
typical site-to-site VPN network layout.

Figure 1. Simple Site-to-Site VPN Design

In Figure 1, each site's firewall acts as a tunnel endpoint.
There are several good reasons to use a firewall as a VPN
endpoint:

Convenience: most firewall platforms support IPSec
or some other VPN protocol, eliminating the expense and time
required to configure and administer separate VPN servers.

Security: a firewall acting as a VPN endpoint can
regulate traffic entering and leaving VPN tunnels with excellent
granularity and accuracy.

Simplicity: if your firewall and IPSec software
were designed to run together on the same host, it can be much
easier to get your tunnels working and to troubleshoot them when
they don't.

However, there are several reasons why this type of setup may
not be feasible or desirable:

Non-interoperability: if you aren't in control of
both sides of the VPN tunnel (e.g., if you're connecting to a
vendor's or partner's network), the remote firewall's VPN
implementation may not be compatible with your firewall's.

Performance: if your firewall is already fully or
over-subscribed doing its normal duties, it may not be able to
support the added overhead of VPN authentication and
encryption.

If, for these or other reasons, you can't use your firewall as a
VPN endpoint, you may prefer to use an architecture such as the one
in Figure 2.

Figure 2. Alternative Site-to-Site VPN Design

In Figure 2, each VPN endpoint is a dedicated computer (in
Figure 2 both endpoints are set up this way,
but you can also mix and match, say, a combined firewall/VPN
endpoint on one end and a split on the other). It may seem reckless
to put any device in parallel with your firewall. Couldn't such a
device be used as a back door?

Indeed, it could—unless the VPN server is carefully
configured to accept only VPN traffic and its
VPN software is carefully configured to accept VPN connections from
only approved endpoints, i.e., using strong authentication
mechanisms.

Let's jump right into FreeS/WAN and see how to set up a
site-to-site VPN with endpoints secure enough to reside either on
firewalls or on standalone hosts.

An Example Scenario

Figure 3 shows a site-to-site VPN scenario that's
functionally equivalent to the one in Figure 1. That is, it also
has the same host at each site serving as a combined Linux firewall
and FreeS/WAN IPSec server. Figure 3, however, offers a bit more
detail. First, you can see that each network is connected to the
Internet via a local router. Second, Figure 3 shows the IP
addresses needed for tunnel definitions (we'll see which IPs get
used where shortly).

Figure 3. Our Example Site-to-Site VPN Scenario

In this scenario, we need to set up a VPN tunnel between two
sites' firewalls' respective “external” interfaces. When a user
on one site's LAN wishes to communicate with a host on the other
LAN, the firewall sends those packets through the tunnel. Reply
packets take the same path back through the tunnel. Hosts on either
side may initiate connections through the tunnel.

The firewalls restrict what sort of data may enter and leave
the tunnel at either side. On a combined iptables/FreeS/WAN server,
these firewall rules can be the same, as though no tunnel were
being used, even if network address translation (NAT) is involved.
This point is explained later in this article.

A few important premises about this scenario should be noted.
First, both firewalls are running Linux kernel version 2.4.18.
Second, both firewalls' kernels have been patched with FreeS/WAN
version 1.97 and had the user-space FreeS/WAN tools (same version)
installed as well. Third, the two networks can reach each other
without IPSec, i.e., in the clear. (We don't
want them to communicate that way, but we need
to know they could; otherwise troubleshooting
VPN problems are much harder.)