Creating VPNs with IPsec and SSL/TLS

VPN (Virtual Private Network) is a technology that provides
secure communication through an insecure and untrusted network
(like the Internet). Usually, it achieves this by authentication,
encryption,
compression and tunneling. Tunneling is a technique that encapsulates the
packet header and data of one protocol inside the payload field of another
protocol. This way, an encapsulated packet can traverse through networks
it otherwise would not be capable of traversing.

Figure 1. A Basic VPN Tunnel

Currently, the two most common techniques for creating VPNs are IPsec and
SSL/TLS. In this article, I describe the features and characteristics
of
these two techniques and present two short examples of how to create
IPsec
and SSL/TLS tunnels in Linux and verify that the tunnels started
correctly. I also provide a short comparison of these two
techniques.

IPsec and Openswan

IPsec (IP security) provides encryption, authentication
and compression at the network level. IPsec is actually a suite of
protocols, developed by the IETF (Internet Engineering Task Force),
which have existed for a long time. The first IPsec protocols were
defined in 1995 (RFCs 1825–1829). Later, in 1998, these RFCs
were depreciated by RFCs 2401–2412. IPsec implementation in the
2.6 Linux kernel was written by Dave Miller and Alexey Kuznetsov. It
handles both IPv4 and IPv6. IPsec operates at layer 3, the network layer,
in the OSI seven-layer networking model. IPsec is mandatory in IPv6 and
optional in IPv4. To implement IPsec, two new protocols were added:
Authentication Header (AH) and Encapsulating Security Payload (ESP).
Handshaking and exchanging session keys are done with
the Internet Key Exchange (IKE) protocol.

The AH protocol (RFC 2404) has protocol number 51, and it
authenticates both the header and payload. The AH
protocol does not use encryption, so it is almost never used.

ESP has protocol number 50.
It enables us to add a security policy to the packet and
encrypt it, though encryption is not mandatory. Encryption is done by
the kernel, using the kernel CryptoAPI. When two machines are connected
using the ESP protocol, a unique number identifies this
connection; this number is called SPI (Security Parameter Index). Each
packet that flows between these machines has a Sequence Number (SN),
starting with 0. This SN is increased by one for each
sent packet. Each packet also has a checksum, which is called the ICV
(integrity check value) of the packet. This checksum is calculated using
a secret key, which is known only to these two machines.

IPsec has two modes: transport mode and tunnel mode. When
creating a VPN, we use tunnel mode. This means each IP packet is
fully encapsulated in a newly created IPsec packet. The payload of this
newly created IPsec packet is the original IP packet.

Figure 2. An IPsec Tunnel ESP Packet

Figure 2 shows that a new IP header was added at the right, as a result
of working with a tunnel, and that an ESP header also was added.

There is a problem when the endpoints (which are sometimes called peers)
of the tunnel are behind a NAT (Network Address Translation) device. Using
NAT is a method of connecting multiple machines that have an “internal
address”, which are not accessible directly to the outside world. These
machines access the outside world through a machine that does have
an Internet address; the NAT is performed on this machine—usually
a gateway.

When the endpoints of the tunnel are behind a NAT, the NAT modifies the
contents of the IP packet. As a result, this packet will be rejected by
the peer because the signature is wrong. Thus, the IETF issued
some RFCs that try to find a solution for this problem. This solution
commonly is known as NAT-T or NAT Traversal. NAT-T works by encapsulating
IPsec packets in UDP packets, so that these packets will be able to pass
through NAT routers without being dropped. RFC 3948, UDP Encapsulation
of IPsec ESP Packets, deals with NAT-T (see Resources).

Openswan is an open-source project that provides an implementation of user
tools for Linux IPsec. You can create a VPN using Openswan
tools (shown in the short example below). The Openswan Project
was started in 2003 by former FreeS/WAN developers. FreeS/WAN is
the predecessor of Openswan. S/WAN stands for Secure Wide Area Network,
which is actually a trademark of RSA. Openswan runs on many different
platforms, including x86, x86_64, ia64, MIPS and ARM. It supports kernels
2.0, 2.2, 2.4 and 2.6.

Two IPsec kernel stacks are currently available: KLIPS and NETKEY. The
Linux kernel NETKEY code is a rewrite from scratch of the KAME IPsec code. The
KAME Project was a group effort of six companies in Japan to provide a
free IPv6 and IPsec (for both IPv4 and IPv6) protocol stack implementation
for variants of the BSD UNIX computer operating system.

KLIPS is not a part of the Linux kernel.
When using KLIPS, you must apply a patch to the kernel to support NAT-T.
When using NETKEY, NAT-T support is already inside the kernel, and
there is no need to patch the kernel.

When you apply firewall (iptables) rules, KLIPS is the easier case,
because with KLIPS, you can identify IPsec traffic, as this
traffic goes through ipsecX interfaces. You apply iptables rules to these
interfaces in the same way you apply rules to other network interfaces
(such as eth0).

When using NETKEY, applying firewall (iptables) rules is much more complex,
as the traffic does not flow through ipsecX interfaces; one solution can
be marking the packets in the Linux kernel with iptables (with a setmark
iptables rule). This mark is a member of the kernel socket buffer structure
(struct sk_buff, from the Linux kernel networking code); decryption of the
packet does not modify that mark.

Openswan supports Opportunistic Encryption (OE), which enables the creation
of IPsec-based VPNs by advertising and fetching public keys
from a DNS server.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.